Put the Object in the Room

You can't screenshot a feeling

Motion is the part of design that dies in a deck. You can annotate a transition, storyboard it, describe it in the notes column with words like "smooth" and "responsive," and the person reading it will construct something in their head that resembles your intent about as much as a police sketch resembles a face.

I had done everything the standard playbook says to do. Annotated frames. A recorded video walkthrough. A click-through prototype in the design tool, screens wired together with canned transitions. And a click-through has a dishonesty built into it that I only understood later: it plays back at demo speed, with demo content, along the one path I wired. It is a movie of the design. The person watching cannot wander off the path, cannot hesitate, cannot change their mind halfway through a gesture. The prototype performs. It does not answer questions.

Which meant the hesitation was rational. These were people being asked to commit public money to an experience nobody could experience. I spent weeks quietly frustrated with them before admitting they were the only people in the room behaving sensibly.

Underneath that problem sat a second one. Even inside the team, the people who could picture the motion did not agree on it. We traded words like "snappy" and "fluid" at each other, and everyone nodded, and everyone meant something different. You cannot settle an argument about feel with adjectives. There is no spec review for a vibe.

So I built it, over a handful of evenings

At some point the math got obvious. Another round of frames would cost days and settle nothing. A working version might cost a few evenings and settle everything. So I stopped making pictures of the design and built the flow for real: React and TypeScript for the structure and state, Framer Motion doing the animation work, fake data shaped like the service's real data, deployed to a private URL.

I want to be precise about the bar I was building to, because this is where most designers talk themselves out of trying. The code was not production code. It was not even good code. Nobody was ever going to review it or ship it. The bar was one thing only: the prototype had to behave truthfully. Real gestures, real timing, real content lengths, running on an actual phone in an actual hand. Prototype code gets to be ugly. What it does not get to be is a liar.

That distinction changed how fast I could move. Once I let go of doing it "properly," the whole build fit inside a week of evenings. Not because I am an unusually fast engineer. Because a truthful fake is a much smaller thing to build than a real product, and most designers dramatically overestimate the distance between the two.

The prototype caught my own design lying

Here is the part of the story I like least and value most: before it convinced anyone else, the working version turned on me.

There was a transition in that flow I genuinely loved in the frames. In the walkthrough video it read as elegant, this unhurried settling of content into place, and everyone who saw the video agreed. Then I ran it on a device, driving it myself at my own speed instead of the video's speed, and it was wrong. Wrong the way a joke is wrong when you have to explain it. At real speed, under my own thumb, that unhurried settling was just slow. I kept arriving before the interface did, and waiting on an animation you already understand feels like being condescended to, four hundred milliseconds at a time.

Worse, the design had no answer for interruption. What happens when someone taps mid-transition? In a static tool that question does not exist, because frames never get interrupted. In a browser it is one of the first things a real hand does. My careful choreography assumed a patient, obedient user, and there is no such person.

So the version the stakeholders eventually saw was not the one from the deck. Durations came down. Easing curves changed. Every animation became interruptible, which quietly reshaped part of the interaction model. None of those flaws were visible in forty-two frames. All of them were visible within ten minutes of the design becoming real. The browser turned out to be the most useful design critic on that project, and it worked nights for free.

I would rather find out I am wrong in private, at 11pm, than in production on a live government service. Building the thing is how you buy that privacy.

What a URL does that a deck can't

The next meeting was not really a meeting. I had sent the link ahead of time with one line of instruction, and then I watched people around the table use the flow on their own phones, at their own speed, with nobody narrating.

There was a silence that anyone who presents work for a living will recognize as unusual. Then the conversation restarted somewhere entirely new. Nobody asked to see another direction. The questions changed species, from "have we considered" to "when can we have this." A decision that had refused to happen for weeks happened before the coffee was gone.

The hub went on to ship. Nine government agencies have since migrated onto it, and calls to the contact centre have fallen as people find answers for themselves, which was the entire thesis of the thing.

Nothing mystical occurred. A deck of frames invites every viewer to privately imagine their own version of the product, and then the meeting becomes a negotiation between all those imaginary products. A working prototype collapses that. Everyone is reacting to the same object, and disagreement shifts from opinion to observation. "I don't think users will get it" becomes "watch, I tapped it and got it." One of those can be debated forever. The other one cannot.

I will say the uncomfortable part plainly: "I'll just build it" is a political act, and I mean that as a warning as much as a recommendation. Working code carries authority it has not always earned. A bad idea that runs is still a bad idea, and a slick prototype can steamroll a colleague's better concept just because they cannot build theirs. The defensible version of this practice is using the prototype to test the decision rather than to win it, and being visibly willing to lose. Mine caught my own flaw before it caught anyone's approval, and in the room I led with the flaw. I suspect that ordering is most of why it worked.

Designing like someone has to build it

The prototype was the visible part. The durable part was what building it did to my design practice, because designing something and then constructing it teaches you what construction actually needs from design. Design and engineering are one system for making decisions about a product. The mockup and the codebase are two views of the same object, and each one keeps the other honest.

Concretely, here is what changed for me.

I stopped designing screens and started designing states. A screen is a moment. A component is a lifetime: loading, empty, error, partial, interrupted, overflowing. The happy path I used to polish is a sliver of what actually renders in front of users. Now the unglamorous states are in the first draft, and engineers no longer have to invent them on my behalf at 6pm on a Friday. On government work this matters double, because the people using the service are not early adopters who forgive rough edges. They are everyone, on every device, often on the worst connection of their week.

Motion turned into numbers. "Snappy" left my vocabulary as a deliverable and got replaced by durations and easing curves, plus a stated answer to what happens when the animation gets interrupted. Feel is real, but feel ships as values, and if the designer does not choose the values, whoever's sprint is ending will choose them instead. A short ease-out you can interrupt beats a long flourish you have to sit through, and the only way I have ever learned that kind of thing is by feeling both under my own thumb.

I also got interested in the shape of the data, because layout is downstream of it. Which fields are optional, and how long or how late the real content can arrive. Half of what teams file as visual bugs are really data assumptions the mockup never declared.

None of this required becoming an engineer. It required designing as if the browser were going to check my work, because eventually it always does. That mindset is the actual gift you hand your engineering team, more than any redlines or spec sheet: designs that already know they will be built.

And if the building itself is what stops you, that obstacle has mostly dissolved. Between AI coding tools and how approachable the modern front-end stack has become, prototype-grade code is now days of learning, not years. The syntax was never the scarce part. Knowing what the thing should feel like, and recognizing when it does not, is the scarce part, and if you design for a living you already have it. The tools have simply stopped accepting it as an excuse.

So the next time a decision is stuck in its sixth meeting, you have two options. Book the seventh, with fresh frames and a longer walkthrough. Or spend the evenings building the truthful fake and let people touch it.

The room did not go quiet because I argued well. It went quiet because there was suddenly nothing left to argue about. The thing was right there, answering questions faster than anyone could ask them. Most design debates are just the sound a team makes when nobody can see the same object. Put the object in the room.