The product design process, stage by stage

The product design process is not a template you paste over a brief. It requires, in order, understanding the real moment of use rather than the demo conditions, naming the states and edge cases the happy path hides, building the system a screen will sit inside before drawing the screen, getting the words right as a design decision rather than a finishing touch, and saying plainly what a shipped version has and has not proven. Skip a stage and it does not disappear. It gets decided later, by accident, usually by whoever hits the gap first in production.

I have run this order on a clinical mobile product with years to get it right and on a safety app built from a single sentence in about a month. The stages hold at both speeds. What changes is how much time each one gets, not whether it happens.

Stage one: the real moment of use

A process that starts from the screen has already skipped a step. It should start from the place the product will actually be used, because that place decides how much attention is available, and attention is the real constraint every later decision has to fit inside. A form that is reasonable to fill in at a desk can be hostile between patients in a hallway. The design did not change. The setting did.

This is the argument I have made at length in the hallway is the real viewport, built from clinical documentation software where the user was a physician with thirty seconds between rooms. The lesson generalizes past healthcare: name the real moment of use before drawing anything, because the demo conditions a screen gets approved in are almost never the conditions it gets used in.

Stage two: the states and edge cases

Once the context is named, the next stage is naming what can actually happen in it, not just the version where everything goes right. An edge case is not the rare scenario a workshop likes to imagine. It is any real, recurring condition outside the one path a first draft gets drawn for: no result instead of a list, a declined action instead of an accepted one, a field that does not fit the person filling it in.

Skipping a state does not save time. It moves the decision to whoever hits the gap first in production.

Why this stage comes before the system gets built

On Avalon, the clinical product I designed at CureMD, this stage was not optional: a prescription order carries four named outcomes rather than one, an appointment can exist in eight distinct states, and insurance is modelled as a real primary, secondary, and tertiary hierarchy instead of a single clean field. None of those are exotic. They happened on an ordinary day, and naming them before designing them is what kept the product trustworthy once it shipped.

Stage three: the system before the screens

With the context and the states named, the next stage is building the small set of decisions every later screen will draw from: color with roles and contrast pairs, type with a scale, spacing on one unit, and the states from stage two answered once rather than per component. Components come last, because by the time they arrive they are mostly assembly.

The timeline changes how long this stage takes, not whether it happens. The order holds over years, on systems built for a clinical mobile product and for the site you are reading now. It also held in weeks, on a road safety app for drivers built from one sentence and a deadline of about a month, where a tight color system, a type scale anchored by one number, and a small family of reusable components had to exist before the first screen could be trusted, exactly as that build required.

Stage four: the words as a design decision

The fourth stage is easy to treat as finishing work, and that is the mistake. The words on a screen decide as much as the layout does: whether an error says what went wrong and what to do next, whether the same action reads the same way everywhere it appears, whether an instruction assumes a sense the reader might not have.

On Avalon, the error state on Add Patient names what is wrong at the field, in place, rather than failing silently at save. On SeniorConnect, a platform built for adults over fifty, content stays plain and never relies on a tap gesture the reader might not expect. Both are the same discipline applied to words instead of pixels, and the examples that make that concrete are worth reading in full if this stage is new to your process.

Stage five: ship, and say what is not proven

The last stage is the one that gets skipped most quietly: being honest about what the shipped version has actually proven and what it has not. A fast build can prove that a direction works. It does not, on its own, prove that it holds up in the conditions it was designed for, at night, mid-interruption, on a bad connection, unless those conditions were actually tested.

Perceev shipped on both iOS and Android with a working demo for the client. What it had not yet earned, at that point, was testing in the real conditions it was built for, legibility checked while moving rather than at a desk. Saying that plainly, rather than letting a shipped build imply more certainty than it has, is part of the process, not an admission against it.

Running the process against real work

None of these five stages is a ceremony. Each one is a question a real brief has to answer, whether the timeline is years or weeks. Running them in order, rather than starting from the screen and working backward, is a large part of what my product design work actually is on a new engagement: not more screens, but the five decisions underneath them, made on purpose instead of by accident.

Takeaways

The product design process holds five stages in a fixed order: the real moment of use, the states and edge cases that path hides, the system every screen will draw from, the words as a design decision, and an honest account of what shipping has and has not proven. The order does not change with the timeline, only how much time each stage gets. Skipping a stage never removes its decision, it just hands that decision to whoever meets the gap first, usually under deadline and without a designer in the room.

Questions people ask about the product design process