You will not find the product design process in most blogs to be anything but clean. Research, ideate, prototype, test and ship. But go inside a company and you will see the one that is actually in play is far more of a mess. Sales has already put its name on a feature and design is left to scramble; engineering uncovers three constraints no one saw coming; and before you know it the original problem has been left for dead.
For an operator or domain expert with a real idea to put into practice, that discrepancy is significant. The textbook version will show you the activities on paper, but it won’t tell you which ones are worth the effort and which get jettisoned when the heat is on, or which ones are quietly making the call on whether what you ship has any value.
We want to talk about the second version here. How the process really unfolds and how to keep the work from going sideways.
## What the Canonical Process Gets Right, and Where It Stops Being Useful
Open up almost any guide and you will see the same loop: frame the problem, do your research, ideate, prototype, test, iterate and then ship and measure. Some sources like Shopify will have ten stages on their diagram, Contentsquare five, Trinetix three. It is a matter of granularity, not substance.
The loop is right in that design is an iterative affair. You are not going to hit the right answer in one pass and you would be wise not to skip stages, as they cost more to fix down the line.
But the loop leaves out the things that shape an actual project. There is the accessibility law, third-party APIs, security, internal politics and the engineer who knows the system is not going to bend to your wireframe’s will. These are not edge cases, they are the design space. A designer may open a blank Figma file thinking he is starting fresh, but the meaningful constraints are already in the room.
Then there is the question of how much of a process it really is. NSF data on business design activity shows that in 2021 only 16.1 per cent of U.S. companies had a structured, creative approach to design. Some 40% viewed it as a functional task. That is where the difference is made. Teams that use design to make decisions rather than to put some decoration on a screen will always outperform the rest.
## The Loop That Actually Works
There are four stages, and you can define them by what they put on the table. If your team can’t tell you what the output of the current stage is, you are paying for motion.
| Stage | What it produces | Where it fails | | :— | :— | :— | | *Discovery* | A defined user, a framed problem and a written boundary for v1 | Becomes a kickoff meeting; assumptions are never put to the test | | **Design and prototyping** | A working prototype to expose weak points before engineering gets involved | Polished too soon; you review for taste and not behaviour | | **Build and validation** | The software, along with the edge cases you didn’t think to draw | Treated as pure execution and product questions come up too late | | **Launch and learning** | Hard usage data against the targets you set prior to release | The launch is called a finish line and feedback is ignored |
It is all very obvious until you try to apply some discipline. Discovery that yields a thicker brief but no decision is not discovery. A prototype is not a prototype if it has never been in the hands of a customer.
### Discovery: the stage that decides everything else
This is where you turn your knowledge of the workflow and the customer into something the team can build on. You are not here to collect every requirement. You are here to frame the problem tightly so the rest of the team does not have to check in with you every hour.
Do it well and you will have four things in writing for version one: who this is for, the job they need to get done, what success is and what is out of scope. With those in hand most arguments over features sort themselves out. Without them you are left with opinion.
If you are not sure what the brief should look like, we have a guide on how to write one that we use with operators in the first few weeks of a project. The usual way to fail at this is what we in the trade call research theater. You have a team conducting interviews, populating a Miro board with soundbites and churning out a report. And for what? Nothing changes. Research has to be able to put a decision in motion or it is not worth the effort. So before you sit down for an interview, ask yourself: what would we need to hear to alter our course? If the answer is nothing, do yourself a favour and skip it. The budget will thank you.
### Design and prototyping: for thinking, not for show
A designer’s job is not to put up screens for people to ooh and aah over. It is to make a product model that is cheap to break and change. In fact, if your prototype does not make the team a little uncomfortable, it is not doing its job. But when everyone is nodding and saying “looks good” and moving on, you are failing.
Good prototyping and some expensive Figma art are kept apart by two things:
* **Put the flow before the finish.** Get the structure of the experience right with low-fidelity wireframes first. You want a path a user can follow without being coached. The colour and brand can wait until then. * **Get engineering involved from the off.** Some of the more senior types on X are quite blunt about it: you get feasible design by working with engineering, not by handing something over. If your engineer is seeing the prototype for the first time the week before sprint one, you are going to run into constraints in the most costly way possible.
Then there is the matter of what doesn’t happen. The empty states, the errors, the customer who returns after a month and has no recollection of how the system works. A good prototype will force you to talk about these. We call the other approach over-optimizing the happy path; in B2B SaaS it is the usual way to fail.
### Build and validation: where product questions turn into bugs
Do not think a tidy hand-off will save you from a thin discovery process. By the time engineers are putting basic product questions to you in the middle of sprint two, you have already paid for it in rework and in the morale hit of realising the spec was never done.
Make the build part of the design. Let designers be present at grooming and let engineers push back on flows that don’t fit the data model. When product, design and engineering are on the same page for an outcome metric, you will see healthy delivery whether you are at Airbnb or Shopify or Figma.
We saw this when we put together Workform’s AI MVP. The AI wasn’t the hard part with our project management consultant; it was taking the notion of “an assistant for everything” and whittling it down to something an engineer could actually put together. Discovery gave us a specific job to do so the build phase could focus on engineering rather than product. That is the way to go.
### Launch and learning: round two of design
The launch is the first time the product is truly honest with you. Support will be fielding the same three calls all week, users will be clicking in the wrong order or missing the step you assumed was obvious. Don’t take it as a failure. It is just the design process getting some real input.
But you should have some numbers to back you up before you release. Define what “working” is in terms of a signup rate or a drop-off threshold. Keep it simple, but have it in place so that once you are live, the data can settle any debate rather than the last person with the loudest voice.
## The Failure Modes That Stay Constant
We see the same five patterns with the companies and operators we work with. They have nothing to do with craft and everything to do with how the work is managed.
**The HiPPO override.** Your research points to X. The senior person wants Y. Y is what you get. You don’t fix things by winning the argument in the room. The real remedy is to put your decisions and the reasoning behind them on paper, making it plain what the cost of overriding evidence would be. That way, when you do your review next quarter you can ask if Y really did what it was supposed to.
**Building too much, too soon.** Founders have a habit of piling every good idea from the past half-year into version one and putting a label of “ambition” on it. To the user it is just clutter. You need the discipline to single out one user journey that will validate the product’s existence; the rest can hold their horses. If you want to see how to trim a roadmap, this piece on prioritizing product features has the right approach.
**Constraints you should have known about.** Payment regulation, performance budgets, third-party rate limits, localization and accessibility. Come across any of these after you are well into the build and you will be looking at a redesign. Then there are the rules: WCAG 2.2 was made a W3C recommendation in 2023, the U.S. Department of Justice put its ADA web accessibility rule in stone in 2024. Don’t think of them as some optional finishing touch, they dictate the patterns you are able to ship.
**Design system drift.** Leave a design system without an owner or a contribution model and you will have a graveyard of one-off components. The teams that make something of it regard it as a product, not a Figma library. Those that don’t end up with three kinds of input and a host of buttons and a consistency problem they can’t quite put their finger on.
**Metric myopia.** It is easy to shift short-term engagement numbers and to point at them in a quarterly review, but they won’t move trust or retention. In fact, they are apt to take you down a path you didn’t intend. Be wary of leading indicators that look good while the actual outcome is not. Choose the metric that tells you the product is doing what you set out for it to do.
## What AI Is Actually Doing to This Process
If you want an honest read, AI is more of a reordering of the front end than a replacement.
In the early stages of ideation the tools are of genuine use now. You can get a team to put together some rough prototypes in Cursor or Claude and run through variations at less cost before you even fire up Figma. Cambridge Design Thinking would tell you in 2026 that AI-assisted ideation is the default.
But for an experienced designer on implementation work, it is a different story. There is a 2025 study from Hou and his colleagues that is all over the design world which puts it at 57 per cent longer for designers using AI with no quality to show for it. Check the methodology if you like, but the number rings true with what practitioners will tell you in public: where judgment is cheap and the work is exploratory, AI is a help. Where the work is detailed and judgment is expensive, it is of little use.
Here is the bottom line: put AI to work on the front end of the process to open up the funnel, not at the back end to force things through. When you are in the thick of late-stage design, the speed with which you can churn out variations is a red herring. What counts is your grasp of the user and the system, and the trade-offs you are faced with.
How to Match the Process to Your Situation
We have come across some sound advice from practitioners that bears repeating: if you can’t put your process on a single slide for someone who is not on the team, it is overly complicated for the kind of organization you are running.
You have to scale the process to fit the problem. Tinkering with an existing flow calls for a problem statement, a sketch, a quick sync with dev, a build and then some measurement. Put a new product line in front of you and you need full discovery, several rounds of prototyping and hard and fast kill criteria. Apply the big process to a small problem and you have bureaucracy. Do the reverse on a big problem and you are just gambling.
Then there are the operators who are starting from nothing. More often than not they will find three internal references more helpful than any framework:
- A minimum viable product guide to get a handle on what version one actually entails.
- Some way of user story mapping so you are making a series of decisions about the product, not just ticking off features.
- The discipline to do your own user research before you have the budget for a proper discovery phase.
To see how this plays out in the real world with vastly different products, look at the custom ticketing platform we put together for an independent cinema. We did not start with a generic template but with the operator’s reality: no IT people, concession integrations that have to be real, and margins that are thin. The work had a completely different shape to the AI build we did for Workform even though we used the same framework. That is what you mean when you talk about scaling the process to the situation.
The Point of All of This
Do not think of the product design process as a set of rituals to be performed. It is simply how a team goes about making decisions under uncertainty, with evidence and in time to act on them. You will have your methods and tools and frameworks and they are useful, but they do not replace a well-argued case between product, design and engineering, a tight feedback loop with users or a written account of why something was decided.
The teams that put out products worth keeping are not the ones with the most attractive process diagram. They are the ones who have done their homework in discovery so the rest of the work has something firm to stand on. If you have an idea and are trying to figure out what needs to be put to bed before you write any code, that is the sort of early decision work our product design engagements are all about. We even put a money-back guarantee on the discovery phase should the work fail to yield any real clarity.
