The Prototype Is the New Sticky Note

I'm learning design sprints the official way right now, in Google's UX design course. Five days, a team, and a board of sticky notes. Monday you map the problem. Tuesday you sketch solutions. Wednesday you decide. Thursday you build a prototype that looks real and isn't. Friday you put it in front of five users and find out whether any of it was true.

It's a good method. But the sticky-note board is the tell. The sticky note was the cheapest possible unit of an idea, invented for a world where anything more real than paper was expensive — and I keep noticing that world doesn't exist anymore.

A machine built around scarcity

Read the sprint's structure closely and its real subject is scarcity. Prototyping used to be expensive — a week of developer time to fake one product honestly — so the sprint rations it: four days of thinking stand guard over one day of building, because building is the part you can't afford to get wrong twice. User time is rationed just as carefully. Five interviews, one day, scheduled like court dates.

The ceremony makes sense when the materials are precious. Of course you argue for three days before touching anything. Touching things was the expensive part.

That has inverted. Implementation is cheap now — not cheaper, cheap, the way sticky notes were cheap. The meeting about whether to build a thing can cost more than building it before lunch.

Thursday collapsed

The tools I've adopted in the last year inverted that. Building the fake is now the cheap part — sometimes the cheapest part of the whole loop. This website's hardest visual problem, a seam between two worlds rendered in a shader, went through half a dozen serious attempts in a single day: each one built, shipped, and looked at on a real phone, then kept or thrown away. My resume stopped being a document I edit and became a small system I regenerate. A few years ago, at my skill level, working alone, none of that was slower. It was impossible.

So the mechanism itself changed. The sticky note didn't die; it got promoted. The prototype is the new sticky note: cheap enough to be disposable, real enough to argue with. Discussion used to happen about representations — sketches of a seam, notes describing a screen. Now it happens inside the medium. You don't sketch the seam. You build six seams and judge them on the phone, where they'll actually live.

That's why, when the course schedules a full day for the prototype, I can feel the ground shift. Thursday fits in an afternoon now. Thursday fits between dinner and bed.

The bottleneck moved — it didn't vanish

Here's what didn't get cheaper: knowing whether the thing is right.

Users are still scarce. Not their time in the abstract — their truth. A person reacting honestly to something they believe is real cannot be generated. Five of them on a Friday will teach you more than five hundred simulated opinions, because a simulation tells you what someone like that would probably say, and the entire point of Friday is hearing what nobody predicted.

There's a second scarcity the old sprint never had to ration: judgment across abundance. When one prototype takes a week, the argument about which idea deserves it runs itself. When twenty directions can be built in the time one used to take, the scarce skill stops being making. It's choosing — and being able to say why, with evidence that survives contact with a user.

The bottleneck moved from my hands to my head, and from my calendar to someone else's.

What I'd keep

If the five days are scaffolding, some of it is load-bearing. A decider: one person who can end an argument. A timebox: learning expands to fill whatever week you give it. Forced convergence: sketch ten, build one, on purpose. And Friday — real users, protected, never traded away to make the build loop spin faster. Speed Thursday up all you want. Friday is the sensor, and a machine that learns is only as fast as its slowest honest input.

The industry will get there

I wonder how long the official method takes to catch up. The course teaches the sprint as it was codified a decade ago, sticky notes and all, and most companies still run product development on the scarcity assumptions underneath it: prototypes are precious, so argue first and build once.

The forward-thinking companies have already invested — in AI tooling, in prototyping infrastructure, in people whose job is making Thursday cheap. I can't say whether they're quiet about it on purpose. But I wonder if everyone else feels it as pressure first — a competitor shipping in an afternoon what your process needs a week to approve.

Methods lag tools by years, usually. Textbooks lag further. I expect to finish learning the sprint in its classic form right around the time the industry quietly stops running it that way — and I don't think that makes the learning wasted. I don't see how you'd re-time a method you never learned in its original time.

So I'm not learning a dead method. I'm learning the skeleton of one, and running it on hardware its designers didn't have: build loops measured in hours, wrapped around learning loops that still, stubbornly, run at human speed.

The sprint isn't obsolete. It just has to be re-timed. The days were never the point. The learning was — and the learning waits on the one thing that was never going to be automated: another person, telling you you're wrong.

Implementation is free now. Learning never was. I keep wondering which of those two the industry notices first.

Drafted with an AI's help and edited by me, like the rest of this site; the course, the deadlines, and the opinion are mine. Publishing this adds a forty-second point to the Atlas, under WRITING — the map keeps deriving itself.