From Paper Wireframe to Shipped Feature in One Week

Long projects hide problems. A feature that takes a quarter to design and build gives everyone months to disagree about what it was for. Over the last year I have been running small features through a fixed one-week routine, and the results have been calmer projects and fewer surprises at launch.

The routine only works for features that fit in a week, which is the point. If it does not fit, it gets split until it does.

The five days

Monday: paper. Sketch the flow on paper with the person who asked for it. No software, no colour. The goal is to agree what happens on each screen and what the user is trying to do.

Tuesday: grey boxes. Turn the sketches into low-fidelity screens and click through them with two or three real users. Fix anything that confuses them before a single pixel is polished.

Wednesday: build the skeleton. Real data, real routes, ugly styling. By the end of the day the feature should work end to end, even if it looks unfinished.

Thursday: design pass. Apply the visual design to the working feature, not to a mock-up. Edge cases such as empty states, long names and slow connections show up here, while there is still time to handle them.

Friday: ship and watch. Release behind a flag, watch how it is used and write down what to change next week.

Why it works

• Everyone sees progress every day, so there are no big reveals.
• Design decisions are tested against working software, not pictures.
• The deadline forces a conversation about scope on Monday instead of on Thursday night.

“A rough thing in production teaches you more in a day than a perfect thing in a file teaches you in a month.”

Studio notes

It is not the right shape for every project. For the many small features that make up most of a product, though, a week is plenty.