Fiuto: redesigning complex components

Before After

Context

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 by the way: 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:

1. 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?
2. Map the experience against competitors’ surfaces: how does it stand against them?
3. Review against user expectations: can they do what we want them to do?
4. Do an inventory of found issues listed by severity so that fixes can be prioritised.
5. Synthesise all findings into a set of design requirements.
6. Follow an iterative design process where variants are reviewed with the team until a solution is agreed on.
7. 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.
8. Review the implementation for gaps against the agreed solution.

The traditional process. The request as a ticket, passed hand to hand and tool to tool through the eight steps. Every handoff adds a line nobody asked for, every review sends it back, and the ruler in the foot counts the weeks: a fix becomes a redesign.

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 redesign 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.

01The pipeline

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.

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.

The same /ux family. On an implemented surface the baseline step does the grounding: it refreshes the story from the live component, so the review, the variants and the fidelity check all measure against the real panel and its states.

02The session

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.

9 min Watch on Loom

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.