Build to throw away

Think of it when you cannot decide between designs by talking, or you do not know yet what you want.

In everyday life

Like a cardboard model of a new kitchen: you walk around it, find that the fridge door hits the oven, and throw the cardboard away. Nobody ever cooks in it.

One case

A phone app team argues for 2 weeks about checkout: one long page, or three steps? Then they build the three-step version properly, with tests and polish, in 3 more weeks. In the first user testA session where a real person tries the product while you watch, without help from you., 6 of 10 people give up at step 2.

Five weeks of careful work, then 6 of 10 testers gave up
The case, cell by cell1 cell = 1 tester
Wanted to buy
yesyesyesyesyesyesyesyesyesyes
Finished checkout
yesnonoyesnonoyesnoyesno
Testers who gave up
6
Weeks spent before the test
5
A throwaway version of both designs, shown to the same 10 people, would have taken days.

Every case

Some questions cannot be settled in words: how a screen feels, or whether a set of rules gives the right answer in odd cases. People argue from imagination, and imagination is often wrong. A prototype answers in hours what a debate cannot answer in weeks. It is cheap because it skips everything that makes code safe to ship: tests, error handling, saved data. That is also why you throw it away and keep only the answer.

The word

Engineers call this

prototypeThrowaway code that answers one question fast, such as “does this flow feel right?” You learn from it, then delete it. It is never shipped.

When you can answer a question by looking, build the cheapest thing that lets you look. Keep the answer, delete the code.

Where this idea leads

Skills that encode it

  • prototype Matt PocockThrowaway code that answers one question: no tests, no saved data, clearly marked, and kept afterwards only as the answer.
  • principle-exhaust-the-design-space pstackWith no precedent to follow, build 2 or 3 competing prototypes and compare them side by side before you commit.