Most startup design problems aren't design problems. They're process problems wearing a design costume.
Missed deadlines, endless rework, stakeholders changing direction mid-sprint, developers building the wrong thing, none of that is inevitable. It's what happens when a team is moving fast without a shared way of working.
I learned this the hard way. A year into working at a startup, I'd watched good design work get wasted because nobody agreed on when a design was actually done, or what "done" even meant. So I built a process. Not a theoretical one, something the team could actually run, week to week, on real problems.
It's five steps: Think, Make, Check, Release, Measure.
Simple on the surface. The value is in what each step forces you to do before you move to the next one.
1.
Think
Most designers skip this step. They hear a problem statement and open Figma.
Think is everything that happens before you touch a design tool. It starts with sitting with the problem on your own writing down what you actually understand about it, what's still unclear, and what could go wrong during implementation. This sounds obvious. Almost nobody does it rigorously.
After that, you take those questions to your manager. Not to get answers, to pressure-test whether you're asking the right questions. Then you talk to the business. You get the context that doesn't show up in the brief.
The two outputs that matter most from this step are the user flow and the information architecture. The user flow maps how someone moves through the feature. The IA decides what information exists at each step. Get the IA wrong and you'll be doing rework at the visual design stage, which is the most expensive place to find out you built the wrong thing.
Document everything. Not a 20-page spec, a short record of what you decided and why. Future you, three weeks into implementation, will be grateful.
This step sets the timeline. When Think is done properly, you know what you're building well enough to say how long it will take. That estimate means something. When teams skip Think and estimate from vibes, the timeline is fiction.
2.
Make
Make has three sub-steps, and the order is non-negotiable.
First, rough solutions sketches, whiteboard, whatever with the product manager and key stakeholders. Three sessions maximum. The goal is to kill bad ideas before they become wireframes. This is where you figure out what you're not building, which is just as important as what you are.
Second, lo-fi wireframes. Build these in Figma or Balsamiq doesn't matter which. What matters is that stakeholders sign off on wireframes before you move to visual design. This is the rule most startups break, and it's why most startups end up redesigning finished screens. Changes at the wireframe stage take an hour. The same change at the visual design stage takes a day.
Third, visual design. By this point, if Think and wireframes went well, visual design should be fast. The main judgment call here is information hierarchy what lives in the first fold, what gets buried. That decision shapes how users experience the feature more than color, typography, or anything else.
3.
Check
Check is where you take what you built back to the people who will live with it, product managers, CPO, CEO, customers, and find out what you got wrong.
You will get something wrong. That's not a failure of the process; it's the point of the process. Finding the error at Check is fine. Finding it after Release is expensive.
Check and Make are a loop. You validate, you adjust, you validate again. The loop ends when stakeholders sign off and you have real confidence in the design, not just a feeling that it's probably good enough.
4.
Release
Designs go to Zeplin. The product manager writes the development story. The developer grooming session happens with the actual design in front of everyone.
The thing most teams skip here: being in the room when developers review the design. That conversation surfaces implementation questions that never make it into comments on a Figma file. Answer them before development starts, not after.
5.
Measure
Once the feature is live, you measure. How are customers using it? What changed? What didn't?
This step is easy to skip because it doesn't feel like design work. It is design work. What you learn in Measure shapes your next Think. Without it, you're iterating on assumptions instead of behavior.
Why This Works
The honest answer is that this process works because it front-loads the hard thinking. Every step where you cut corners, skipping the IA, moving to visual before wireframes are signed off, skipping measurement creates debt that shows up later, at a worse time, when it costs more to fix.
Startups move fast. That's the point. But fast without process isn't speed it's just urgency. The teams that actually ship good work quickly are the ones who slow down at the start of each problem and think before they build.
Five steps. In order. Every time.