Understand the domain until the constraints are obvious

The first stage of how I work is called Understand, and it is the one most often cut when a schedule gets tight. That is backwards. It is the stage that makes every later stage shorter.

Requirements are not understanding

A requirements document tells you what someone asked for. It rarely tells you why, and it almost never tells you what they forgot to ask for because it was too obvious to them to say out loud.

The obvious things are exactly the ones that break systems. An inspector knows that a finding must be traceable to who recorded it and when, so they never write it down. A 3D artist knows that an asset which will not open in their tool is worthless regardless of its preview image. A teacher knows that a learner who can game the mechanic will. None of these show up in a feature list. All of them determine whether the product works.

What understanding looks like in practice

It is less glamorous than it sounds.

Watch the work, not the demo. Sit with the person who does the job today, with whatever tools they use now — often a spreadsheet, a shared folder and a lot of memory. The workarounds are the specification. Every place they copy something by hand is a place the system has to be trustworthy.

Collect the words. Domains have vocabulary, and the vocabulary encodes distinctions that matter. When users say "revision" and "version" as if they are different things, they are. A data model that collapses them will fight the users forever.

Find the adversarial moment. Most domains have a point where someone checks the work with suspicion — an audit, a dispute, a refund, a leaderboard. Design for that moment and the ordinary path usually takes care of itself. Design only for the ordinary path and the adversarial moment is where you lose trust.

Follow the money and the liability. Who pays, who is blamed when it goes wrong, and who has to sign something. Those three people are often different, and their needs pull the product in different directions.

Knowing when you are done

You are not done when you can describe the domain. You are done when its constraints stop being surprising — when a new requirement arrives and you can already guess why it exists and what it will conflict with.

That is the moment design becomes fast. Before it, every decision is a guess that needs validating. After it, most decisions are obvious, and the few that are not are the ones worth spending time on.

The cost of skipping it

Skipping this stage does not save time. It moves the learning later, into a period when every lesson has to be paid for twice: once to discover it, and once to undo the code written without it.

The cheapest place to learn a domain is before there is anything to rewrite.