The place where we design

A Tuesday morning review

Imagine a design review on a Tuesday morning. The product manager has the laptop. On the screen there is a feature the team has been discussing for weeks: a date filter for the list of invoices. She opens the panel, picks "last 30 days" and presses apply. The list refreshes. She frowns, switches to a custom range, realizes she wants to compare two months, clears everything and starts again. Nobody in the room is explaining what should happen. She is finding out for herself.

Everything on the screen belongs to the product she uses every day: the same buttons, the same type, the same spacing, the same small delay before the list updates. If you walked into the room at that moment, you would assume you were looking at the real application.

You wouldn't be. That filter isn't connected to anything. There is no database behind it and no API answering. The invoices are sample data stored in the browser. And yet the interface exists, it responds, and it is already changing the conversation in the room.

That scene describes a way of working we have been exploring. We started from a SaaS product built in Angular and, with Claude Code, the design team built a mirror of its frontend: a working copy that uses the product's own components and styles. In our experience, the mirror is visually indistinguishable from the real thing. What separates it from the product is its connection to the system, not the way it looks.

Since we started working this way, one question keeps following me out of those reviews. If I can design, test and change an interface directly in the browser, what am I still drawing in Figma for?

Why we learned to draw first

To answer that honestly, it helps to remember why the drawing step exists at all.

For as long as I have worked in product design, the job has had two moments. First we represent the interface. Then someone builds it. The design file is where ideas are allowed to be cheap: we can arrange information, compare three versions side by side and show a direction to the team without anyone writing a line of code. The prototype adds clicks to those drawings so people can walk through them.

Bill Buxton described this territory better than anyone in *Sketching User Experiences* (Buxton, 2007). He separates sketches from prototypes. Sketches are quick, plentiful and disposable; they help you find the right design among many. Prototypes are more refined; they help you get one design right. Both live upstream of the product, and both are justified by the same economics: changing a drawing costs almost nothing, and changing software costs a lot.

A great deal of our method is built on that difference in cost. We drew screens because building them early was expensive. We documented behavior because it didn't exist yet. We linked frames together so that a product manager could imagine what a working feature would feel like.

Stephanie Houde and Charles Hill asked a deceptively simple question in 1997: what do prototypes actually prototype? Their answer was that every prototype tests some mix of three things: the role a product plays in someone's life, its look and feel, and its implementation (Houde and Hill, 1997). A clickable Figma file is very good at look and feel. It says much less about how a filter behaves when the range is empty, or how a list feels when it reloads.

So what happens when building something that you can really use stops being expensive? Development doesn't have to become instant for this to matter. It only has to become easy enough to produce an interface complete enough to think and decide with. At that point, the step we inherited from a different economy deserves a second look.

Back to the review

Let me return to the Tuesday meeting, because what happens after it is the most interesting part.

It's worth being precise about one detail. We are not asking an agent to invent a product from a sentence. The product already exists. It has its own components, its patterns and years of decisions behind them. The team knows its problems. What we are doing is adding or changing a feature inside that world, and the agent works on that solid ground.

After the review, we gave the agent what we had: the Jira ticket for the filter, a page of business rules from Confluence and the transcript of the meeting. A few minutes later, the changes were in the mirror. In our experience with this setup, those changes arrive in three or four minutes; I mention it as an observation of our flow, not as a promise for every task.

Then comes the part I enjoy most: opening the browser and starting to argue with something that answers back. "Move the apply button to the bottom of the panel." "Show how many invoices match before applying." "What happens if someone picks a range with no invoices?" We ask, we look, we try it, we adjust. The conversation stops describing the interface and starts shaping it.

Donald Schön, writing about how professionals think, described design as a reflective conversation with the materials of a situation (Schön, 1983). The designer makes a move, the situation talks back, and the designer responds. For decades, in interface work, the material talked back slowly: through a handoff, a sprint, a build. In the mirror, the material talks back in minutes, and it talks back with the product's own voice.

None of this makes the mirror the product. Saving invoices in the browser proves nothing about the real system. A screen can look exactly like the product and still be a simulation of how it works. Keeping that distinction visible is what lets us know what we have actually tested and what is still open.

When the question itself changes

The speed is not what interests me most. What interests me is what we start noticing once the thing on the table already works.

A drawn screen invites questions about composition. Where does this go, how big is that, which color. A working screen invites questions about experience. In the invoice review, the debate began as "where should the apply button go?" After ten minutes of using the filter, it became a better question: "do we need an apply button at all, or should the list update as soon as you choose a range?" Nobody would have asked that while looking at a static frame, because in a static frame nothing ever updates.

Bret Victor argued in *Inventing on Principle* that creators need an immediate connection to what they create; when you change something, you should see the effect right away (Victor, 2012). Working in the mirror gives product teams a version of that connection. The distance between an idea and its consequence shrinks from days to minutes.

My own role in the room shifts as well. I spend less time narrating the intended behavior and more time watching what people actually do with it. The interface carries part of the explanation that used to depend on me.

In The Future of the Interface I described the design system as a contract: the pieces that exist and the rules for combining them in a way that makes sense. This way of working brings that idea down to everyday practice. When the agent has those pieces and rules at hand, we can explore inside the product's own language instead of redrawing it from scratch in a separate tool.

The cost of two sources of truth

And here the practical questions begin. If the mirror is where we decide, what is the Figma file for?

Keeping a second representation of the same interface has a cost that we rarely name. Which version holds the latest decision: the frame that was approved last week, or the mirror we changed this morning? When someone finds a problem in the filter's behavior, where do we fix it? When we copy into the canvas something we have already clicked through, what are we learning that we didn't know before?

There may be good answers to each of those questions. My point is only that they now need answers. The drawing step used to justify itself by being cheaper than the alternative. When the alternative becomes cheap too, every step has to earn its place by what it helps us understand.

When I still open Figma

I want to be careful about the scope of this argument. I'm describing one specific situation: a product that already exists, a visual language that is already established and a working copy of the interface that design can change. I'm not claiming it covers every project or every stage of the craft.

Even inside that situation, there is a moment when I deliberately leave the browser: when I need distance from the current product.

Working with existing components keeps us consistent, but it also keeps us inside the shape of what already exists. Suppose that, during the invoice review, someone says the real problem isn't the date filter at all. People don't struggle to filter invoices; they struggle to find the one invoice a customer is calling about. That is a different problem, and the mirror is the wrong place to think about it, because every component in it pulls us back toward the current list. If everything starts from what is already there, we risk polishing a solution we should be questioning.

That is Buxton's sketching territory, and the canvas is still the best place I know for it. A blank board where I can draw five rough directions, put them side by side, move pieces around and throw most of them away. There are also moments when I need to see the whole at once instead of walking through it: comparing ways to organize a page, mapping how screens relate, agreeing on a direction before giving it any behavior.

What I'm less sure about is what comes after. Needing a sketch to think through a problem doesn't mean I need a complete copy of every screen and every state in Figma once the direction is clear. Those are two different uses of the same tool, and for years we have treated them as one.

Maybe that's the shift. Figma may keep a valuable role without always sitting at the center of the process. We open it when a question is easier to think about there, instead of opening it by habit before every piece of interface work. The useful question becomes: what will this step help me discover that I can't discover by working on the interface itself?

What speed doesn't fix

There is a real risk in all of this, and I don't want to skip it. When answers arrive this fast, it becomes tempting to spend less time on the question.

Go back to the inputs we gave the agent. A Jira ticket can leave things out. A meeting transcript can contain two people saying opposite things, and an agent can quietly turn that ambiguity into a decision nobody actually made. In our invoice example, the transcript might include the sales lead asking for "all invoices, always" and finance asking for "only this quarter by default." The mirror will show one of those choices, beautifully rendered, and its polish can make it look more settled than it is.

So we have to keep two things apart: what we are exploring and what we have validated. Being able to use the filter doesn't prove that people needed it. Saving data in the browser doesn't prove that permissions, integrations or error cases are solved. Houde and Hill's warning still applies: a convincing look and feel can hide how little we know about implementation.

The mirror itself also needs care. Products move. If the real application changes and the mirror falls behind, we will start making decisions about a version that no longer exists. Bringing design closer to code doesn't remove the work of keeping a shared reference; it moves that work to a new place, and somebody has to own it.

None of these difficulties sends me back to the canvas by default. They send me to examine how we work in the browser: what we make explicit before asking the agent, what we check after, and who keeps the mirror honest.

A question I want to keep open

For a long time, the design file has been the place where an interface takes shape before it becomes software. Now we can do part of that work in the medium where the interface will actually live.

I'm still working out what that means. I don't have a closed conclusion about the place Figma will hold, and I'm not interested in defending a new tool by swapping one habit for another.

What I do believe is that every step in our process should be able to justify itself by what it helps us think and decide. If drawing a screen helps us discover something, we should draw it. If building it and using it helps us discover it better, maybe that is where we should start.

I keep thinking about that Tuesday review. The most valuable moment wasn't when the filter looked right. It was when the product manager, using it, asked a question nobody had thought to ask.

So the next time a new feature lands on my desk, I want to ask myself one thing before opening the usual file: if I can already step into the interface, use it and change it, what do I still need to draw to understand it better?

References

• Buxton, B. (2007). Sketching User Experiences: Getting the Design Right and the Right Design. Morgan Kaufmann.
• Houde, S. and Hill, C. (1997). What do Prototypes Prototype? In Handbook of Human-Computer Interaction (2nd ed.). Elsevier.
• Schön, D. A. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books.
• Victor, B. (2012). Inventing on Principle. Talk at the Canadian University Software Engineering Conference (CUSEC).