When to prototype in code
5 min read
Most design questions are about layout and hierarchy, and a static frame answers them well. Some are about time: what happens while you drag, how a list behaves with 4,000 rows, whether a gesture feels right under your thumb.
The rule
If the answer depends on something moving, or on real data, build it. If it depends on how things look standing still, draw it.
At Fieldnotes, dragging a quote between two notes was the whole product. We argued about it for a week in Figma. A rough React prototype settled it in an afternoon, because everyone could feel where the drop target was too small.
- Gestures, drag and scroll-linked behaviour.
- Anything with more data than fits on a screen.
- Transitions where timing changes the meaning.
- Empty, loading and error states you keep forgetting.
The prototype does not need to be good code. It needs to answer one question and then be thrown away, or be good enough that it never is.