Redesigning complex components

In the previous article, I explained how I used AI to batch redesign full sets of components, only iterating in my coding agent. This was not an ideological stance btw: Fiuto is itself an experiment on how far I could go using only coding agents to replicate traditional design processes and tooling, and I just did not have the time and staff to do otherwise.

Redesigning complex components after implementation

How do you automate the process of reviewing, redesigning and delivering improvements to an implemented surface?

In the example I show in the video, a share panel had already been implemented, but showed multiple critical UX and UI issues which had not been addressed during delivery. This happens very often in multi-agentic flows, where user intervention can only exist at specific checkpoints, and speed of delivery makes it harder, if not impossible, to review every single delivered surface.

But it happens often also in traditional product teams, where developers pressured for time or testing a new feature must sometimes deliver without design or research input - which will instead require design and research follow-ups, post-implementation. Traditionally, the process is quite complex and has multiple steps, most of them tedious:

review the delivered surface for gaps and issues in user experience, user interface, user interaction: does it follow best practices? Is it a natural and possibly delightful experience?
map the experience against competitors’ surfaces: how does it stand against them?
review against user expectations: can they do what we want them to do?
do an inventory of found issues listed by severity so that fixes can be prioritised
synthesise all findings into a set of design requirements
follow an iterative design process where variants are reviewed with the team until a solution is agreed on
create assets for developers to implement in production. In my experience, only in the most agile teams are these delivered as stories within the repo. Most design teams will only generate specs in Figma, which need translation into actual stories, adding an extra step.
review the implementation for gaps against the agreed solution

The risk for scope drift

It is clear just by looking at the above list that the process not only takes time and plenty of effort, but it also contains several break-points where the final requirements can drift away from the original request, and scope can massively increase from a ‘let’s fix some issues’ task to a ‘let’s totally re-design the feature’, even bypassing tech specs. Anyone working within product, design and dev teams will recognise this as a dreaded occurrence in iterative improvements: scope drift.

Automated design process

Automating the process not only reduces the time to delivery but it also reduces that risk, because the full end-to-end pipeline takes only hours or days at most, rather than weeks, and it all happens in one tool without handoffs.

The same /ux skill family used to update simple components can also be used to automate the process above. The key element is the ux-baseline skill: it gives the coding agent a story with variants that it can evaluate using principles baked into the ux-review skill. In my case this skill is designed around my key audience and my competitive landscape - so that it does not just generate an inventory of issues based on generic UX principles, but it ranks them based on the expectations of that core audience and what others are doing in the same space.

ux-baseline checks whether the current component has an accurate Ladle story. If the story is missing or stale, it refreshes it from the live components before design work starts. This gives every later step the real hierarchy, content, states and theme behaviour.
ux-review examines the whole surface for interaction, content and accessibility problems, using current comparable products as the market reference. ux-visual-review covers hierarchy, composition, density and polish. The findings are combined and ranked by severity before any alternative is designed.
ux-ideate produces one to three alternatives for the whole component. Follow-up rounds use the complete markup of the selected seed and change only the requested design axis. This prevents the agent from improving one state while silently changing the rest of the panel.
Before I lock a direction, I ask for every state where the component behaves differently. For the share panel, that included the default state, existing invitees, a public study where the user could invite people and a public study viewed by someone who could not.
ux-translate maps the selected HTML mockup back to the real component system. Each element must reuse an existing component, deliberately update a shared primitive or become a new reusable component. It then renders the complete selected surface in Ladle. This validates the design in code without wiring it into the live application.
After translation, ux-visual-review runs in fidelity mode and compares the Ladle render with the exact mockup I approved. Material differences go back to ux-translate for one focused correction. The real application integration then moves to the appropriate build workflow based on whether the change is isolated or affects data, routes, permissions or several consumers.

The whole process runs within the coding agent, and it replicates the traditional workflow I mapped above. There is no need to translate Figma components into stories: the whole pipeline works out of Ladle. Stories are its natural output, and they are ready to be implemented.

What is in this video

In the video, I start with a functional share panel produced by the build agent and give Claude Code a screenshot with a short request to improve it. The agent finds the component, reviews the issues by severity and returns three alternatives for the whole panel. I select the second direction, ask for its permission states and agree on the final design in round 4. The selected HTML mockup is then translated into Ladle components and checked against the approved design. Fidelity findings are returned for correction before the component moves to the build agent. The recorded run reached a deployed result in about 2 hours. I still saw details that needed improvement, so this is a case study of the process rather than a claim that one pass produces a finished design.

Conclusion

The same principles used to automate simple component redesign also work when working on complex, multivariate surfaces which have already been implemented. Because stories show isolated components, there is no need for multi-tool handoffs, and the whole process can run in a single coding agent.

The next article covers automated design from scratch, when no existing surface contains the feature. Coming soon.