Fiuto: batch-updating simple components

Context

Redesigning components in a design system takes time in a traditional workflow:

1. Designs are first worked on in Figma.
2. They are then reviewed and iterated on with the team.
3. They are then implemented in code.
4. Once implemented in code, they need to be reviewed and iterated on again to make sure that they are consistent with the agreed designs.

The full redesign can take days to weeks, or even months, depending on product complexity. It uses multiple roles with several handoff points, and requires switching between multiple tools, which makes it prone to error due to miscommunication or loss of information between steps: a broken telephone game effect. This is something we are all familiar with.

The traditional workflow. Six stations and a loop: the library lives in Figma, review rounds pile up, the handoff passes a drawing to a developer with nothing shared between them, the build is redone when it does not match, and every failed test sends the work back to iterate. The ruler in the foot counts the weeks.

In this article, I showcase the workflows I’ve implemented while working on Fiuto to automate this process: a set of components is redesigned directly within the coding agent, where they are previewed, iterated on and finally implemented in under 2 hours.

I did this out of necessity as I not only needed to cover all roles, but also did not have the time I would normally need to work directly in Figma for this project. And Fiuto was itself an experiment on design automation, so what better chance to test whether it works?

01The pipeline

The /ux family skill

To automate the process I replicated the traditional design pipeline inside Claude Code as a family of skills. It works because there is no handoff between tools: every step happens in the same agent session, which removes the broken telephone.

An orchestrator skill, /ux, walks through the iterative process with me and dispatches a sub-agent for each step. Each sub-agent runs one skill.

Ladle is a fast drop-in alternative to Storybook. Stories can be previewed and iterated on with the coding agent until they are agreed, which keeps both the input and the output of the pipeline grounded in code. Once signed off, the designs are ready to implement without loss. Implementation then runs through a separate family of build skills.

The /ux family. One orchestrator, five skills, one session: the agent grounds itself in the stories, ranks the issues, proposes variants for me to pick, translates the pick into stories and checks the result against it.

02The session

What is in this video

The session in the video starts from a short prompt: review the atomic components in Ladle and the repository, and propose visual updates for tags and pills, tabs, buttons, dropdowns and form elements. I invoke /ux, which orchestrates the sub-agents through the pipeline until the designs settle as stories in Ladle.

4 min Watch on Loom

A series of iterations that would normally take a couple of days takes a few minutes here. A full rollout of a new batch of component designs takes a couple of hours.

Working with Figma

Figma can be part of an automated process, but designers need to change how they think about it. It cannot be the source of truth if the process is to work consistently.

This works when the Figma design system is lean, or when it is being created from scratch. It is far less effective with a system of hundreds of components, shells, templates and tokens: aligning that to the repository takes time, plenty of it, and is more complex than full automation in code. Neither is shown here, because neither is what this piece demonstrates.

03Setting up your own

Setting up your own design automation

Setting up your own automation is possible. Four things have to be true.

1. Code is the source of truth. Document designs as stories: isolated components you can iterate on with the coding agent before implementation. A story-based system can be created in a non-React repository too. Ask the agent to build it and explain its purpose: design consistency across sessions.
2. The pipeline mirrors your team. Create an orchestrated pipeline of skills that replicates the process your design team already uses.
3. Test until it is consistent. Improve the pipeline until results match your expectations run after run.
4. Do not expect perfection. Once the first three hold, the process is lean and effective, but implementation still needs a pass: details are sometimes missed during iteration and need refining.

What changed

Every item on the left is a place where information used to be lost between steps. Every item on the right keeps the work in one place, in code.

Outcome

The batch shipped as Ladle stories and was implemented across the admin surfaces in the same session. Since then, every component pass on Fiuto has run through the same pipeline.