Start with the shape of the thing

The shape is the smallest complete account of the experience: who arrives, what they are trying to do, what they see first, which choice they can make, and how the product confirms that something changed.

It does not need to predict every screen or edge case. It needs enough specificity that two people can notice when they are imagining different products—and resolve that difference before code makes it expensive.

A useful shape can usually be told as a short story. Someone arrives with a particular intention. The product gives them enough context to understand where they are, presents one meaningful next step, and responds in a way that makes the result unmistakable. If that story is hard to tell without naming databases, frameworks, or internal services, the experience probably needs another pass.

Write down the parts a person can actually observe:

• What they see before taking action.
• The choice the interface asks them to make.
• What changes immediately after that choice.
• What remains true if they leave and return later.
• How they recover when the expected path does not work.

This description creates a boundary around the first version. Features outside the boundary are not necessarily bad ideas; they simply have not earned their place yet. That distinction matters because an unbounded product can make every technical capability sound urgent, while a concrete experience makes tradeoffs visible.

Edge cases belong in the shape when they change the promise of the experience. Losing a network connection during a payment matters because it creates uncertainty about whether money moved. An unusual avatar filename probably does not matter yet because it does not alter the central path. The point is not to ignore complexity. It is to rank complexity by what a person would feel.

You can test the shape before building much. Describe it to someone unfamiliar with the project and ask them what they expect to happen next. Sketch the states on paper. Walk through the path using static screens. Each misunderstanding is useful: it shows where the product is relying on knowledge the interface has not actually provided.

Once the path is coherent, implementation questions become easier to answer. Persistence follows from what must survive a return visit. Performance priorities follow from which transitions need to feel immediate. Permissions follow from who is allowed to make each meaningful change. The architecture begins to reflect an observed experience instead of a collection of imagined future requirements.