The share panel worked. The build agent, the one that implements features into the app, had produced it, it was fully functional, and it did its job. The user experience was not great. There were several issues with it, and I could not even start to make a list of them. That is the tell. When I cannot write the issue list, the component does not need fixes: it needs a redesign, and no batch rule can describe a redesign.
This arc is about the core flows of automated design. The previous article covered batch-updating simple atomic components, pills and buttons, a lot of them but each one simple, where one instruction applied cleanly across the whole set. This is the other case.
What the build agent produced
The share panel is where you share a study, and a study in Fiuto is one test you run with respondents. So the panel carries public links, invited people, and who can do what. The version the build agent had shipped worked. Every control did what it said. The arrangement of those controls was the problem, and the problem was not local to any one of them.
What this replaces
The old shape of this job runs like this. Open Figma. Work through the issues one at a time until the panel is redrawn. Hand the result to the developer. The front-end developer then implements it with the blocks that already exist in the component library, working in the workbench that renders those blocks in isolation, Ladle here, Storybook elsewhere.
That path assumes I can enumerate the issues, which is exactly what I could not do. It also puts a handoff between each of those steps.
What I use instead is a series of skills in Claude Code. A skill is a markdown file of instructions the agent loads when the task matches, so a workflow gets written down once and re-run rather than re-prompted every time. The input is small: I share the screenshot and say improve the share panel. The agent knows where to find the components.
The review, then three variants
The first agent is the UX review agent. It finds the components and returns a review of the issues, listed by severity. That is the list I could not write, and it arrives ordered, before anything gets redrawn.
Then comes a round of alternatives, usually three variants of the redesigned component, whole panels rather than a list of fixes to the one I had.
The first variant is generally the closest to what I shared. The components are the same ones, improved a lot on the design the build agent generated. The second variant separates the public link, the general sharing option for the study, from inviting people into the study, with who has been invited visible in the panel. That one is pretty good. The third is a little more out there: public or private at the top, people at the bottom.
Iterating, and asking for the states
From there it is iteration. I pick an option, ask for a few amends, and the agent keeps going until we agree on a direction.
For round two I asked for different states of variant B rather than more variants. The same panel, but showing the default state, the state where people have already been invited, the state where the link is public and you can still invite people to the document, and the state where the study is public and you cannot invite anyone, which is what a viewer on the study sees.
Asking for states early is the part I would repeat anywhere. The default view of a share panel is the easy one. The permission states are where it goes wrong, and I would rather see them before I approve a direction than after. We agreed the final direction on round four.
Translating the mockup into real components
What comes out of those rounds is a plain HTML mockup. The translate agent converts it into existing components in Ladle, and creates components only where none exist to render the design at high fidelity.
It grounds itself first, on the repo and the library conventions, and then starts working. The output is very close to the mockup, it generates pretty much all the states the design needs, and it maps to the components already in the repo rather than inventing parallel ones.
The fidelity review, and the rework loop
The built version then goes to a second visual review, the fidelity review. It maps the new components against the mockups that were generated and flags items by severity, by how far each one drifts from the original design.
That review goes back to the same translate agent, which re-implements the flagged items and regenerates the components in Ladle. Sending drift back to the agent that built it, rather than to a fresh one, is deliberate: it already holds the mapping decisions the review is arguing with.
Those components then go to the build agent, which is where this article’s loop ends and the normal implementation path picks up.
What two hours bought
At the time of recording, the version on screen was still the old panel, the experience I had spent the loop replacing. I asked the agent to deploy to staging and then to production, and what the video ends on is that deploy.
By then it was about two hours, from when I started working on it to the deployed result. It still needed improvements. It is much better than it was before. For two hours, I think it is great.
Running this with your own agent
None of this needs Fiuto. It needs a repo, a component library, and an agent that can read both.
- Hand the agent a screenshot of the component and one line of intent. Do not write the issue list. If you could write it, you would not need this loop.
- Ask for a severity-ordered review before any redesign, and read it before you look at any design.
- Ask for three whole-component variants rather than three sets of fixes. In my run the first sat close to what I already had, and the other two moved further from it.
- Iterate in rounds. Pick one, ask for amends, and keep the rounds numbered so you know when you have stopped converging.
- Before you approve a direction, ask for its states. Empty, populated, permission-restricted, whatever your component has. Approve the whole set.
- Only then translate into your library. Tell the agent to ground itself on the repo and its conventions first, to reuse existing components, and to create new ones only where the design cannot be rendered faithfully without them.
- Run a fidelity pass that diffs the built component against the approved mockup and flags drift by severity.
- Send that drift back to the agent that did the translation, not to a new one.
- Deploy it and judge it in the product rather than in the library.
The next article opens arc two: designing a fully new feature from scratch, with no existing surface to anchor to.
