The Product Design Process: How We Take a Product From Problem to Shipped

Most articles about the product design process give you a diagram: five neat boxes with arrows, empathise through to test. It is a useful teaching model and a poor description of what actually happens when a real team with a real deadline builds a real product.

What follows is the product design process we actually run at UntilNow, including the parts that are messy, the decisions that matter more than the phases, and the points where we tell clients to stop. It is written for founders, heads of product and marketing leads who are about to commission product design work and want to know what they are buying.

The short version: the product design process is a sequence of decisions, not a sequence of deliverables. The deliverables exist to make the decisions safe to make.

What the product design process is actually for

A product design process has one job: to reduce the cost of being wrong.

Every product decision is a bet. Building the thing is the expensive way to test the bet. Research, prototypes and design exist to test the same bets at a fraction of the cost, so that when engineering time gets spent, it gets spent on something with evidence behind it.

That framing changes what "good process" means. A good process is not the most thorough one, it is the one that buys you the most certainty per week. Which is why we run the same five phases at very different depths depending on what is actually at risk.

The five phases of our product design process

Phase 1: Framing (week 0 to 1)

Before any research, we get specific about what is being decided. Not "improve onboarding" but "decide whether the drop-off between signup and first project is a comprehension problem or a value problem, because the fix is completely different."

Framing produces three things: the decision the work exists to make, the constraints that are genuinely fixed (tech stack, compliance, launch date, budget), and the measure that would tell you it worked. If a client cannot name the measure, that is not a reason to skip this phase, it is the reason to do it.

The most common failure of a whole product design engagement happens here, in week one, when nobody insists on a sharp question.

Phase 2: Discovery and research (week 1 to 3)

Then we go and find out. Depending on the question, that is some combination of:

• Interviews with users, and separately with the people who sell to them and support them, who often know more
• Analytics and session review, to find where behaviour and belief disagree
• A structured walk through the existing product, if there is one
• Competitive and adjacent review, which is less about competitors and more about what your users have been trained to expect elsewhere

The output is not a research report nobody reads. It is a short set of findings with an explicit confidence level attached to each, because a finding from twelve interviews and a finding from one support anecdote should not carry the same weight in the next decision.

How much of this you need is the biggest variable in the whole process. A new product in an unfamiliar market needs weeks. A checkout redesign where you already have the funnel data might need three days.

Phase 3: Concept and validation (week 3 to 5)

Now we make things, quickly and deliberately roughly. Multiple directions, not one. Two or three genuinely different approaches to the same problem beat one polished approach every time, because the comparison is what reveals what you actually believe.

These get tested. Sometimes with users, sometimes with the sales team, sometimes as a working prototype that people can click through. AI prototyping has changed this phase more than any other: we can now put something clickable in front of people in days rather than weeks, which means we test more ideas and hold onto our first one less tightly. We wrote about that shift in how the design process is changing.

The gate at the end of this phase is the important one: which direction, and what evidence made us choose it. If the answer is "the client preferred it", the phase did not do its job.

Phase 4: Design and systemise (week 5 to 9)

This is the phase people picture when they think of product design: the actual screens, flows, states and interactions, at production quality.

Two things separate this from just drawing screens. First, states. Every screen gets its empty, loading, error, partial and dense-data versions, because that is where products fail in real use and where handover disputes come from. Second, systemisation. Anything that appears more than twice becomes a component, and the components become the beginnings of a design system. Doing this during design costs almost nothing. Doing it afterwards is a separate project.

Engineering is in the room throughout this phase, not at the end of it. The single cheapest quality improvement available to any product team is an engineer looking at designs while they are still cheap to change.

Phase 5: Build support and measure (week 9 onward)

Design does not end at handover. We stay through build for the questions that only appear when something real is being assembled, and then, critically, we go back to the measure defined in phase one.

This is the phase almost every agency engagement quietly drops, because the contract ended at handover. It is also the only phase that tells you whether any of the previous four were worth the money.

The decision gates matter more than the phases

If you take one thing from this: the phases are scheduling. The gates are the process.

There are four, and each one is a moment where the honest answer might be to stop:

1. Is this the right problem? End of framing. Sometimes the answer is that the problem is a pricing problem or a sales problem and no amount of design will move it.
2. Does anyone actually want this? End of discovery. The most valuable outcome of a discovery phase is occasionally a recommendation not to build.
3. Which direction, and why? End of concept. Decided on evidence, documented, so nobody relitigates it in week eight.
4. Did it work? Post-launch, against the measure agreed in week one.

A process that cannot stop at gate one or two is not a process, it is a production line with a discovery-shaped decoration on the front.

The process changes shape depending on what you are building

The same five phases run very differently across the three situations we see most.

A new product, zero to one

Weighted heavily toward phases one to three. The risk is building the wrong thing, so most of the budget goes into reducing that risk before a line of production code exists. Typically 10 to 14 weeks to a validated, designed MVP, and we will push hard to cut scope rather than extend time.

An existing product being redesigned

Weighted toward phases two and four. You already have users, behaviour data and a product that works well enough for people to pay for it, which means the research is richer and the risk is regression rather than irrelevance. The hardest discipline here is resisting a full rebuild when a targeted fix would do. This usually starts as a UX audit.

A feature inside a working product

Compressed, often 3 to 5 weeks total, with framing and the design phase carrying most of the weight. If you have a design system, phase four collapses dramatically, which is the clearest argument for having one.

Where product design processes usually break

In roughly the order we see them:

Research that does not change anything. Weeks of interviews, a deck, and then the team builds what it was always going to build. If research cannot change the plan, do not commission it.

Skipping straight to solutions. The team arrives with the answer already decided and wants design to execute it. Sometimes they are right. The problem is that nobody will find out until launch.

One concept, iterated. Polishing a single direction feels like progress and produces local maxima. You end up with the best possible version of a mediocre idea.

Engineering brought in at handover. Every constraint discovered late costs ten times what it would have cost in week five.

No measure. Without one, the retrospective becomes a debate about taste, and the next project starts from zero learning.

When you do not need this process

Being honest about the limits is part of the pitch, so:

If you are pre-revenue and testing whether anyone cares at all, a full design process is premature. Build the crudest version that lets someone say yes or no, and spend the money on getting it in front of people.

If the change is small and reversible, ship it and watch. Process is for decisions that are expensive to undo.

If your problem is that engineering is slow, design process will not fix it and may make it worse by producing more work than the team can absorb.

And if you have a capable in-house product design team, what you probably need is not a process, it is a specific capability they lack: research, a design system, a senior second opinion. Buy that, not a full engagement.

How AI changed the order, not the point

The visible change is speed. We can generate variations, build clickable prototypes, and produce production-adjacent code far faster than three years ago, which compresses the middle of the process considerably.

The less visible change matters more. When building becomes cheap, the constraint moves upstream. Deciding what is worth building becomes the expensive, valuable part, which means phases one and two are now a larger share of the process, not a smaller one. Faster production of the wrong thing is just faster failure.

FAQ

How long does the product design process take?

A feature: 3 to 5 weeks. A significant redesign: 8 to 12. A new product to validated MVP: 10 to 16. The variable is almost always how much genuine uncertainty exists at the start.

What is the difference between product design and UX design?

Practically, product design covers the commercial and strategic question of what to build as well as how it should work, where UX design focuses on the experience of using it. In a small team the same person does both. In a job ad the titles mean whatever the company wants them to mean.

Do we need research if we already know our users?

You know your loudest users and your most recent conversations. Research is mostly useful for the quiet majority and for the gap between what people say and what they do. If you genuinely have current, structured evidence, we will use yours rather than redo it.

What deliverables do we get?

Typically: a framing document, research findings with confidence levels, tested concepts, production-ready designs with all states, a component set, and handover documentation. Ask any agency to show you their states and their handover docs from a real project. That is where the difference between agencies is visible.

Can we start midway through the process?

Often, yes. If you have solid research, we start at concept. If you have a validated direction, we start at design. What we will not skip is framing, because it takes a day and prevents the most expensive category of mistake.

The takeaway

A product design process is worth having because it makes being wrong cheap and early rather than expensive and late. The phases give it a shape. The gates give it teeth.

If you are commissioning product design work, the questions worth asking are not about methodology. Ask what would make them recommend not building. Ask to see the states from a real project. Ask what they measured afterwards, and what it said.

If you want to talk through what this would look like for your product, that is what we do in a first conversation about digital product design. We will tell you if the answer is a smaller piece of work than you came for.