How we are making Harness Design happen for real
I wrote about Harness Design as a concept: about what I believe will redefine the role of the product designer, and about putting AI at the center of production and redesigning everything around it.
But a concept without execution is just nice text.
This article is about what comes after: the construction site, the hard decisions, the days that did not go as planned. We are still in the middle of it, and that is exactly why it is worth telling now.
The problem became urgent with AI
Using AI has accelerated software development in a way we can no longer ignore. But this gain in engineering speed created a new bottleneck: design. The engineering team moves fast, and design needs to keep up.
The question for us was how to prototype interfaces faster, with enough quality, without growing the team. And how to have squads without designers allocated producing interfaces consistently.
We already had people using AI to create interfaces by consuming the design system that lived in the code. But it was not enough. Many errors, a lot of rework, speed still far from what the developers could achieve. It became clear that we needed to evolve the design system to put AI at the center, with designers building, maintaining, feeding, and reviewing what comes out of this production line.
Build in-house, buy ready-made, or outsource?
Before anything else, we had to decide the path.
Outsourcing came up quickly. High cost, the knowledge would stay outside the team, and someone would have to follow the external work closely, which would overload them.
Buying a ready-made design system did not solve it either. We already had many components. Adopting an external library would mean adjusting everything that already existed and still dealing with whatever it did not cover.
That left building in-house. What made it viable was the CTO's support from the start. He saw the return: an optimized design system speeds up prototyping, and speed means producing more at lower cost. This alignment rarely happens. In many companies, evolving a design system is always secondary, always deprioritized, always hard to defend. Having leadership see the value is what unlocked everything.
The project structure
I organized the work into six milestones: diagnosis, technical foundation with tokens, governance, two cycles of building components by priority, and finally quality and adoption.
What matters is not the detail of each phase. It is what happened when we tried to execute.
The diagnosis: when three days became five
For the project we would count on the product designer and the developers for the Flutter and React stacks. A small team, but a necessary one. You cannot do a real design system diagnosis without people who know each stack's code in detail.
The plan was three days. On the second day it was already clear there was much more work than expected. We stretched it to five.
This seems like a small detail. It is not.
On that second day, I could have ignored the signal and kept the original deadline. I would have delivered an incomplete diagnosis, made decisions based on wrong assumptions, and the problem we were trying to solve would have repeated itself further on. The temptation to keep the schedule is real, especially when you are reporting to leaders who approved the project based on an estimate.
I kept daily alignments with my direct manager throughout that period, and I created a group in the internal chat with the product and engineering leaders following along. On the fourth day I presented what we had reached: the results of the analysis, the proposals for how to proceed, and the risks of each path. I did not arrive with a ready answer. I arrived with the map so we could decide together.
That meeting happened with the product manager present, and not by chance. The design system is the responsibility of design, but it needs the support of the other leaders. When we talk about evolving a DS, we are talking about impact on the roadmap, on allocation, on deliveries. Without this alignment, the project does not leave paper. Or it leaves and dies halfway.
The decision was to reserve two weeks of exclusive dedication with the product designer and the developers to tackle the next milestones.
For the inventory itself, I created a spreadsheet for each stack, with the product designer and the developers each filling in their side, and centralized everything in Notion. I chose Notion because Claude's MCP works well with it, which made it easier to link things and create the tables. We prioritized by frequency of use.
AI helped a lot with surveying the code. In Figma it was harder and more laborious. We tried using Figma's MCP to automate the analysis. It did not work. It ended up being manual work after all.
Tokens and the AI experiment
With the inventory in hand, we started the technical foundation: colors, typography, spacing, shadows, breakpoints. Tokens are the source of truth that feeds Figma, React, and Flutter at the same time. Without them, any component you create lives in isolation.
Glauber Franco and I spent a week almost entirely focused on this. I reviewed Brad Frost's Atomic Design concepts and used the TD Sunshine channel's videos on variables in Figma as a base. We tested the tokens directly on real components and on existing product screens. This practical test makes a big difference compared to working only in the abstract.
The next step is the LLM-readiness experiment. The reference that most influenced our approach was a Kartva article called "Your Next Design System User Is an AI Agent", which describes how to make a DS queryable by AI agents. The central idea is that each component needs to explain itself: when to use it, when not to, which props exist, and code examples. Without that, tools like Claude Code invent variations that do not exist, and the rework comes back through the window.
The plan is to start with a few components, test with Claude Code, and learn before scaling. We do not yet know what we will find, which is why it makes no sense to move on to many components before understanding what works.
What this process is teaching us
A design system is not a design project. It is a product project, and it needs the engineering team involved from the start. Without the Flutter and React developers in the diagnosis, the inventory would be superficial and the decisions that followed would be wrong.
Diagnosis before building is non-negotiable. The temptation to start building right away is strong. But creating without an inventory guarantees that the current problem repeats itself, with new components on top.
Leadership alignment is not protocol. It is what keeps the project alive. Constant communication with all the leaders along the way is what guaranteed priority when the schedule had to change.
And AI still does not solve everything. It speeds up some parts, fails at others, and for now needs a lot of structured context to work well. Figma's MCP did not deliver what we expected. Manual work came back. That is part of it.
Making Harness Design happen is not glamorous. It is a diagnosis that stretches, alignment meetings with leadership, a spreadsheet filled in by hand, an experiment that does not work. That is what we are building, and this article is part of the record of how we are learning to do it for real.
Comments