The mock got cheap. The decision didn’t.

The wireframes took an afternoon. A couple of years ago, they would have taken most of a week.

I brought them to review, and the review went well. Product liked them. Architecture didn’t object. Engineering said it looked straightforward. We were done in twenty minutes and moved on to the next thing on the agenda.

Three weeks later, what got built wasn’t what anyone had pictured. Not dramatically, just off in the small ways that cost a sprint to unpick. Product had assumed one thing about the first screen; engineering had assumed another. Neither had said so, because there had been nothing to disagree with. We had all been looking at the same picture and reading it differently.

Which left me with a question I’ve been chewing on ever since. If we can draw the screens in an afternoon, and everyone can see them, and everyone agrees, why does it still take months to decide anything?

The answer is that we only made one part of this cheaper. It wasn’t the part that was slow.

Three costs, and only one moved

Making a mockup isn’t one cost. It’s three, and they don’t behave the same way.

Only the first one got cheaper. The other two are where the job actually is.

Making it is getting something on screen. This is the one that got cheap, and it’s the only one anyone writes about.

Agreeing on it is getting everyone to read it the same way. Does it solve the right problem? Will the person who has to build it say it’s realistic? This costs exactly what it always did. It was never about tools.

Living with it is what you pay if you built the wrong thing: the three weeks of engineering, the migration, the support tickets you’re still answering two years later. This one got more expensive.

More expensive, because we make more options now, and nobody’s attention grew to match. Look at four directions and each one gets a real look. Look at sixteen and you’re skimming. More gets built on less thought.

Three ways it goes wrong

Three things that only start going wrong once options are cheap.

Too many, too shallow. Twelve directions, none of them pushed far enough to learn anything from.

Silence isn’t agreement. A finished-looking screen reads as decided, so nobody argues with it. The objections turn up three weeks into the build instead.

Nobody actually chose. What survives is whatever nobody happened to argue against.

The second one is the review I opened with. We hadn’t agreed. We just hadn’t disagreed yet.

None of this is the tool’s fault. It’s what happens when you speed up one step and leave the rest alone.

Talking to each other was always the hard part

Here’s the bit I didn’t see coming.

When making things was slow, the slowness was hiding the real problem. You’d spend two days on a screen, and over those two days people talked. Constraints came up. Someone remembered a promise we’d made to a customer. That work was happening for free, and none of us noticed.

Take the two days away, and that work doesn’t move somewhere else. It just stops.

It gets harder the faster you go, too. Every screen you make is one more thing somebody has to understand. Ten screens need ten explanations. Cheap mockups don’t only give you more options. They give you more to explain, at exactly the moment you have less time to explain it.

And most of us are now spread across time zones, tools and calendars. You can’t rely on the conversation happening by accident, because there’s no corridor for it to happen in.

So the hard part isn’t drawing screens any more. It’s making yourself understood. Writing the decision down clearly. Saying what you’re not doing, and why. Being specific enough that someone on another team, three weeks from now, doesn’t have to guess.

That’s not a soft skill. It’s the whole job now.

So we moved the agreement somewhere else

We keep our user journeys in one place: half a dozen of them, covering the flows that matter most. Each one is a set of plain HTML screens you can click through in a browser, next to a spec, a short written page saying what the flow does and why, and what we decided against.

It’s all in version control, and any change goes live on an internal site automatically. Anyone on any team can open it and walk the flow themselves.

Before that, “how does this flow work?” got answered from memory, and the answer depended on who you asked. The current version lived in someone’s design file, someone else’s chat thread, and a slide deck from six weeks ago. All three disagreed, and nobody knew which one was current.

Now there’s one answer, and it has a link.

It’s not a glamorous fix. What it buys us is that people disagree early, in writing, while disagreeing is still cheap, instead of three weeks into a build.

Two rules that make it work

Keep it rough on purpose. Grey boxes, no colour, no polish. That’s a rule, not a shortcut.

How finished something looks is a message. A rough wireframe says this is still open. A polished screen says this is settled, and people believe it, even when it’s twenty minutes old and nobody has checked what happens when the list is empty. So if it isn’t decided, we don’t let it look decided. That’s the fix for silence being mistaken for agreement.

Write the spec first, freeze it, then build. Decide what the flow does and why, and write it down. That’s the spec. Then freeze it: no changes while the screens get built. Build them to match, and check them against the spec afterwards.

The spec gets frozen. The screens don’t: they change until everyone agrees. Only then does it get built, and every change along the way is dated.

The freeze is the part that sounds bureaucratic. It’s also the part that stops you making more options instead of making a decision, which is what the other two failures really are.

The screens themselves change constantly, and that’s fine. That’s the whole point of them being rough. What’s frozen is the thing they’re being checked against. When someone wants a change, it goes into the spec first, and the screens follow. So by the time anything reaches production, there’s a dated record of every version and what each one was trying to fix.

It matters which order those come in. Writing the spec first means the argument happens in words, where changing your mind is free. Once there are screens, people argue about the screens.

What it caught

Because every spec is written down and dated, you can see what changed and when, and what we’d decided against at the time.

We took a field out of a form. It was the right call on its own. Weeks later, the spec history made it obvious that removing it had left something else with nowhere to live. Nobody would have remembered. The mockup didn’t show it. The spec did.

What AI is still bad at

It doesn’t remember why. It doesn’t know you tried something two years ago and it confused people. It will hand you an idea you already rejected, with total confidence.

It’s weak at the boring edges: long names, missing data, the third level of nesting nobody thought about.

And it has nothing at stake. It will build whatever you ask for with the same enthusiasm, including the thing that turns into two years of support tickets. It can’t be the person in the room who says I don’t think we should build this.

That last one isn’t a gap I expect to close. It isn’t a skill. It’s caring what happens next, and that doesn’t transfer.

What actually changed

The old job was mostly making things. Making was hard, so being good at making was worth a lot.

Making is the cheap part now. What’s left is choosing, and then explaining the choice well enough that four teams can act on it.

That was always the part that decided whether a product was any good. It was just buried under all the work of producing things.

The tools didn’t take the job. They took away the thing we were hiding behind.