Redesigning components in a design system takes time in a traditional workflow:
- Designs are first worked on in Figma.
- They are then reviewed and iterated on with the team.
- They are then implemented in code.
- 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.
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?
The /ux family skill
To automate it, I replicated the traditional design process within the coding agent (Claude Code) using skills. It works because there is no handoff between tools and it all happens within the same agent session. It gets rid of the broken telephone problem I mentioned above.
It consists of an orchestrator skill (/ux) that can walk with me through the iterative process using sub-agents to perform each subtask in the pipeline, each one using a specific skill:
- ux-baseline: it updates or creates baseline stories in Ladle, so the coding agent will not hallucinate and create components out of the blue, but rather ground them in the existing designs.
- ux-review: reviews an existing surface and provides a list of UX issues ranked by severity. The ranking is based not on generic UX rules, but on my specific audience, the products they likely already use, and my competitive landscape.
- ux-ideate: iterates with me through multiple rounds of design variants in HTML until a solution is agreed on.
- ux-translate: converts the winning variant into Ladle stories using existing components or creating new ones if required.
- finally, ux-fidelity validates that the new stories are loyal to the agreed solution.
Ladle functions as a fast drop-in alternative to Storybook: stories in Ladle can be previewed and iterated on with your coding agent until agreed on. It is the source of truth when it comes to the design system, keeping the input and output grounded in code. Once signed off, designs are ready to be implemented without any loss. Implementation happens through specialised build skill families.
Setting up your own design automation
Setting up your own automation is possible:
- Code is the source of truth: I use Ladle to document designs with stories: isolated components I can iterate on with the coding agent before implementation. You can also create a story-based system with your coding agent in your non-React repo. Just ask the agent to create it for you, explaining the point of it: design consistency across sessions.
- Create an orchestrated design pipeline of skills that replicate the process you use in your design team.
- Test and improve the pipeline until results are consistent and match your expectations.
- Do not expect perfection. While the process is lean and effective once you achieve point 3, you will still need to iterate on implementation: details are sometimes missed during iteration and will require refinement.
Working with Figma
Figma can be part of an automated process: we (designers) need to switch our way of thinking. It cannot be the design system source of truth if we want the process to work consistently. Figma becomes a mirror of what is in code.
Ladle/Storybook or whatever system you use to document stories in code should instead be the source of truth, and Figma a playground where you can manually iterate, or an agent can do so, to achieve higher quality visuals to elevate the product.
This also means total fidelity between the design system in Figma and code is not required. This works if you already have a lean design system in Figma, or even if you want to create a new one from scratch. It is not very effective if you have a design system with hundreds of components, shells, templates and tokens. In this case, you will need to take time, plenty of it, to go through it with your agents to align them to your repo.
I will not show either of these here: it is not what I am trying to demonstrate and they are, ironically, more complex than full automation in code. I will be happy to support you directly if you wish, though. Just get in touch for a consultation.
What is in this video
In the video, I show how I iterate with Claude Code through a series of designs starting from a very simple prompt. I invoke the /ux skill, which orchestrates subagents following a traditional design pipeline until the designs are settled as stories are in Ladle.
A series of iterations that normally would take a couple of days here only takes a few minutes. A full rollout of a new batch of component designs only takes a couple of hours.
Conclusion
Designing directly with your coding agent is possible. You can achieve good results if you can provide agents with good context, a good design system in code, and a set of skills that allows them to replicate a traditional design pipeline.
You will still need to refine your designs after implementation, but it will be orders of magnitude faster than in a traditional multi-role, multi-tool setup.
The next article applies the workflow to complex components, where one shared rule is no longer enough.
