Fiuto: redesigning complex components
A repeatable review, state, translation and fidelity loop for redesigning a complex, implemented, multi-variate component: Fiuto's share panel, reworked inside the coding agent in one session.
Before and after. The share panel in two of its four states, private with invitees and public with the link, rendered from the repository at the commit before the session and at the commit it produced.
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:
- 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.
- Squashed email field
- Revoke is unclear
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.
BaselineChecks 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.
ReviewExamines the whole surface for interaction, content and accessibility problems, using current comparable products as the market reference. A visual review covers hierarchy, composition, density and polish. The findings are combined and ranked by severity before any alternative is designed.
IdeateProduces 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.
StatesBefore 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.
TranslateMaps 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.
FidelityAfter translation, the visual review runs in fidelity mode and compares the Ladle render with the exact mockup I approved. Material differences go back to translation 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.
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.
The session. Nine minutes, from a screenshot and a one-line request to Ladle stories checked against the approved mockup.
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.
Review, states, translation, fidelity: four checks in one session, each grounded in the real component rather than a drawing of it. The scope stays where the request put it, because there is no handoff in which it can grow.
Sources
- Building Fiuto, part 2 ↗fiuto.ai
- Session recording ↗Loom, 9 minutes