Every designer has a process diagram. Most of them are the same diagram, and most of them are decoration: four arrows in a circle, one verb per arrow, no claim anyone could check. Mine is four steps too. The difference I care about is not the shape, it is that each step says what you are left holding when it is over.
That second part is the whole test. A step with no receipt is either a promise nobody can verify or a deliverable nobody asked the reason for, and a process made of those is a way of looking organised rather than a way of working.
Here it is, one step at a time.
From idea to product
Discover
I talk to the people involved before I draw anything: what the goal is, what the constraints are, and which problem we are actually solving. Agreeing on that is the cheapest thing on this list.
Ideate
I sketch, structure and argue the options out until one of them holds up. I change my mind a lot here, which is the point: it costs nothing now and a great deal later.
Design & build
I do the interaction and the visual design in one pass, and then build the real thing, on patterns that keep working long after the first release.
Validate
I put it in front of real users, watch what changes, and keep adjusting once it is out in the world. Shipping is where I find out what I got wrong.
Step 1 of 4: Discover
Discovery is the cheapest thing on the list
The first step is talking to the people involved, before anything is drawn. What the goal is, what the constraints are, which problem we are actually solving.
It is the step most likely to be cut, because it is the one with nothing to look at when it ends. It is also the only one where changing your mind is free. A wrong assumption caught in a conversation costs an hour. The same assumption caught in a build costs a sprint, and caught after release it costs the thing itself, because by then somebody has to defend the decision as well as fix it.
What it leaves behind is a problem statement, the scope and constraints, and an agreed picture of what success looks like. None of those are artefacts anyone frames. All three are things you can be held to later, which is the point.
Ideation is where changing your mind is supposed to happen
I sketch, structure and argue the options out until one of them holds up. I change my mind a lot here, and that is not a failure mode, it is the job: this is the last place in the project where a direction costs nothing to abandon.
The output is user flows, wireframes, and one direction with the argument for it attached. That last one matters more than it sounds. A chosen direction with no recorded reasoning gets undone by the first person who joins the project and does not know why it is that way, including a version of me six months later.
I have written elsewhere about why the handoff is not a document; the short version is that the argument is the deliverable, and the wireframe is just where it happens to be written down.
Design and build is one step, on purpose
This is the step where most process diagrams have two. Design, then a handoff, then build.
I do the interaction and the visual design in one pass, and then build the real thing. Not a prototype: the product, on patterns that keep working after the first release.
Keeping it as one step is a claim about where the interesting decisions live. Half of what a design is only becomes real when it is built. What a loading state feels like at a real network speed, what happens to a layout when the copy is twice as long as the placeholder, which of two interactions survives being used every day. A handoff puts a wall exactly where those questions get asked, and it puts the wall between the person who has the context and the person who has to answer them.
Prototyping is still something I do and still on the list of things I sell. It is just not where a project ends, and this is the step that describes the finish line. So what you are left holding is final screens, a shipped product, and patterns to build the next thing on.
Validation is not the end, it is the next beginning
I put it in front of real users, watch what changes, and keep adjusting once it is out in the world.
Shipping is where I find out what I got wrong. That sentence is not modesty. It is the reason the fourth step exists at all: everything before it is a set of well-argued guesses, and the only thing that converts a guess into knowledge is somebody who did not build it trying to use it.
The receipts here are test sessions, what actually changed, and the next round. That last one is why the steps wrap rather than stop. A process that ends is a description of a project. A process that comes back around is a description of a product.
Why the shape does not matter
The four could be five. Plenty of good processes split discovery in two, or name research separately, and I would not argue with any of them.
What I would argue with is a process where you cannot say, for each step, what somebody is holding when it is over. That is the version that survives a real project, because it is the version that can be checked while the project is still running, rather than admired on a slide at the start of it.