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. About putting AI at the center of production and redesigning everything around it.

But a concept without execution is just pretty 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

The use of AI has sped up software development in a way that can no longer be ignored. But that gain in engineering speed created a new bottleneck: design. The engineering team moves fast, and design has to keep up.

The question that came up for us was how to prototype interfaces faster, with enough quality, without growing the team. And how to have squads with no designers allocated producing interfaces with consistency.

We already had people using AI to create interfaces consuming the Design System that lived in code. But it was not enough. Lots of errors, lots of rework, speed still far from what the developers could reach. 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 that pipeline.

Build it in-house, buy it off the shelf or outsource it?

Before anything else, we needed to decide on a path.

Outsourcing was ruled out quickly. High cost, the knowledge would sit outside the team, and it would still overload someone who had to follow the external work closely.

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. And what made it viable was the CTO's support from the start. He saw the return: an optimized Design System produces prototyping speed, and speed means producing more at lower cost. That alignment rarely happens. At 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 structure of the project

I organized the work into six milestones: diagnosis, technical foundation with tokens, governance, two component-building cycles 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 I would have a Product Designer, a Flutter Developer and a React Developer. Small, but necessary. You cannot do a real Design System diagnosis without people who know the code of each stack in detail.

The plan was three days. By the second day it was already clear there was much more work than expected. We stretched it to five.

That 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 on wrong premises, and the problem we were trying to solve would have repeated itself down the road. The temptation to hit the schedule is real, especially when you are reporting to leaders who approved the project with an estimate.

I held daily check-ins with my direct manager throughout this period and created a group in the internal chat with product and engineering leaders following along. On the fourth day I presented where we had gotten to: 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 took place with the product manager present, and not by accident. A Design System is design's responsibility, but it needs promotion from the other leaders. When we talk about evolving a DS, we are talking about impact on the roadmap, on allocation, on deliveries. Without that alignment, the project does not get off the paper. Or it does and dies halfway.

The decision was to reserve two weeks of exclusive dedication from the PD and the developers to tackle the following milestones.

For the inventory itself, I created a spreadsheet for each stack, with the PD and the devs each filling in their own side, and centralized everything in Notion. I chose Notion because Claude's MCP works well with it, which made it easier to link and create the tables. Prioritization was by frequency of use.

AI helped a lot with surveying the code. In Figma it was harder and more laborious. We tried to use the Figma MCP to automate the analysis. It did not work. It ended up being manual work.

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 with almost total focus on this. I reviewed Brad Frost's Atomic Design concepts and used the TD Sunshine channel's videos on Figma variables as a base. We tested the tokens directly on real components and on existing screens of the product. That hands-on 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 an article by Kartva 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, 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 still do not 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

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 Developer and the React Developer in the diagnosis, the inventory would have been superficial and the following decisions mistaken.

Diagnosis before creating is non-negotiable. The temptation to start building right away is strong. But creating without an inventory guarantees that the current problem will repeat 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 secured priority when the schedule had to change.

And AI does not solve everything yet. It speeds up some parts, fails at others, and for now needs a lot of structured context to work well. The Figma MCP did not deliver what we expected. Manual work came back. It comes with the territory.

Making Harness Design happen is not glamorous. It is a diagnosis that stretches, an alignment meeting 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 this for real.

Attachments