The Design Process Nobody Actually Follows

There's a version of the design process that most designers learn early in their careers. It looks something like this: start with research. Build personas. Map user journeys. Wireframe. Test the wireframes. Iterate on the wireframes. Move to high fidelity. Test again. Present to stakeholders. Revise. Test one more time. Then hand off to engineering. Then ship.

It's clean. It's logical. It makes a lot of sense on paper.

And in just over a decade of working with startups, I've almost never seen it produce the results it promises.

What I Keep Seeing Instead

The teams I've worked with that shipped the best products didn't follow that sequence. They skipped most of it. Not because they were careless or didn't value design, but because they'd figured out, usually through painful experience, that frontloading all that work before anything is real doesn't actually reduce risk the way it's supposed to.

What they did instead was closer to: build something small, ship it to a handful of people, watch what happens, and respond. The research wasn't a phase that happened before building. It happened continuously, through usage data and support conversations and watching real behavior in production. The "design process" was compressed into the iteration cycle itself.

These teams weren't anti-process. They were just honest about where the useful information actually comes from.

And this gap is only getting wider. The cost of building a rough working version of something has dropped dramatically in the last couple of years. When it takes less time to prototype an idea than it does to write the research brief that's supposed to justify it, the whole logic of frontloading breaks down. The old sequence assumed building was expensive, so you'd better be sure before you start. That assumption is aging fast.

The Gap Between Theory and Practice

The traditional process is built on an assumption that I think deserves more scrutiny: that if you do enough thinking upfront, you can meaningfully reduce the risk of being wrong.

In my experience, that assumption rarely holds. And the reason is simple: the things that end up mattering most are almost never the things you'd have predicted in a research phase.

I've watched teams spend weeks building detailed personas before product-market fit, creating profiles of users they hadn't actually found yet. The personas felt thorough. They had names and frustrations and daily routines. But they were fiction. Educated guesses dressed up as insight. The real users, when they eventually showed up, looked nothing like the profiles.

I've seen teams run preference tests on mockups, asking people which version of a screen they liked more. The winning design was always the cleaner, more polished one. But "which do you prefer" doesn't answer the question that matters, which is "does this actually solve your problem." Preference and utility aren't the same thing, and testing for one tells you very little about the other.

I've been part of projects where three rounds of Figma review and stakeholder feedback took longer than it would have taken to build the thing and ship it to ten real users. All that review created a sense of rigor. But the rigor was pointed inward, at the team's opinions, not outward at the market.

Why It Persists

The traditional process doesn't work as well as advertised, but it persists. I think there are a few reasons for that, and none of them are cynical.

It feels responsible. Nobody gets in trouble for doing more research. Skipping the persona phase or shipping without a usability test feels reckless, even when the alternative is faster learning from real usage. The process provides cover. If something fails, at least we followed the steps.

It's also what gets taught. Design education and most agency models are built around this sequence. It's how portfolios are structured, how case studies are presented: here's the research, here's the synthesis, here's the solution. I've reviewed portfolios where the process documentation outweighs the actual product work by a wide margin. People spend more time on the journey map than on the thing the user will actually touch. The narrative is clean and linear even though the actual work never is.

And for some designers, the process is where they feel most in control. Research, exploration, testing. That's design territory. Once something ships, the feedback is out of your hands. It can be uncomfortable to let go of that control and let the product speak for itself.

What Actually Produces Signal

The most useful information I've gotten about whether something works has almost never come from a research phase. It's come from watching what people do when the thing is real and in their hands.

Analytics over interviews. Behavior over stated preference. These aren't perfect sources of truth either, but they're grounded in what people actually did rather than what they said they'd do.

Some of the biggest improvements I've been part of came from small changes nobody predicted would matter. A different button label that lifted conversions. Removing a step from onboarding that suddenly unlocked retention. Changing a default state that shifted how people used an entire feature. None of those insights came from a persona doc or a moodboard. They came from shipping and measuring and paying attention.

The pattern I keep noticing in teams that move well is that they treat every release as a research opportunity. The product itself is the research instrument. And the faster they can get something into production, the faster they start learning things that would have been invisible in any amount of upfront planning.

Tools, Not Steps

I want to be clear about what I'm not saying. I'm not saying user research is useless. I'm not saying personas never help. I'm not saying you should never wireframe or test a prototype before building it.

The individual pieces of the traditional process are fine. Some of them are genuinely valuable. The problem is treating them as a sequence that has to be followed in order, every time, regardless of the project.

A user interview is a useful tool when you're stuck and need to understand a behavior you can't explain from data alone. A persona is a useful tool when you have enough real users to base it on and your team needs a shared reference point. A wireframe is a useful tool when the problem is complex enough that jumping straight to build would waste more time than it saves.

But none of them are mandatory steps. They're tools you pull out when the situation calls for them, not rituals you perform because the process says so. The best teams I've worked with treat them exactly this way. They might do a round of user interviews for one project and skip them entirely for the next. They might wireframe a complex flow but go straight to code for a simpler one. There's no guilt about skipping a step because there are no steps. There's just the question of what this particular project needs to move forward.

The issue was never the tools. It was the idea that arranging them in a fixed order would reliably produce good outcomes.

What I've Come to Believe

After working across enough teams and enough products, I've landed on something that would have made me uncomfortable earlier in my career: the best design work I've seen has almost always come from teams that compressed the distance between idea and production as much as possible.

Not recklessly. Not without thought. But with a bias toward making things real and letting real usage inform what happens next, rather than trying to predict the right answer before anything exists.

The traditional design process promises that if you follow the steps, you'll arrive at the right solution. But a repeatable set of steps doesn't produce great work. It produces consistent work, which isn't the same thing. The value of a good designer was never in executing a sequence. It's in judgment and taste and knowing what to do when there is no playbook.

The work that happens in production is the real design process. Everything before it is just a rough draft.