Product design has acquired a reputation for being either too fast (Figma sketches that look great and don't survive engineering) or too slow (research phases that produce reports nobody reads). A great product design process is neither — it's a small set of disciplined moves that keep design and engineering moving together, in the same direction, at the same speed. Here's what we've found actually works, after 11+ shipped products.
The job of design isn't "screens"
A common misunderstanding — both inside design teams and outside them — is that product design's output is screens. It isn't. The output is decisions: about who the user is, what problem you're solving for them, what the smallest version of the answer is, and how it should feel. The screens are a downstream consequence of those decisions, easier and cheaper to draw once you've made them.
Process problems in design are almost always decision problems hiding inside Figma. If your team is iterating on layouts for the third week, it's usually because no one settled what the screen is for.
Principle 1: Start in words, not pixels
The cheapest, fastest part of design happens before anyone opens a design tool. It's writing — typically a one-page brief that says, plainly:
- Who the user is, specifically.
- What they're trying to do today, and what's painful about it.
- Why this matters now (and why doing nothing isn't fine).
- What success looks like — the smallest observable behaviour change that says the design worked.
- What this is not. The thing you're deliberately not solving.
A team aligned on that one page will fly through Figma. A team that skipped it will draw, redraw, and re-redraw without ever feeling closer to "done."
Principle 2: Sketch wide before you go narrow
The single most expensive shortcut in product design is committing to the first plausible idea. Great designers actively force themselves to draw more options — uglier, weirder, simpler, more radical — before picking one. Not for the look of it, but because the second or third version usually frames the problem better than the first one did.
A useful rule: don't show stakeholders one option. Show three, with honest trade-offs. Asking "do you like it?" gets you a polite yes. Asking "which of these and why?" gets you a decision.
Principle 3: Wireframes for structure, hi-fi for feel
Skipping wireframes is a common modern mistake. Hi-fi designs are seductive — they look real — and that's exactly the problem when the structure underneath isn't right yet. You spend energy on visual polish for a layout that still has unresolved structural questions.
A rough rule of stages:
- Wireframes — low-fidelity, monochrome, focused on hierarchy and flow. Ugly on purpose, fast on purpose.
- One or two hi-fi screens of the key moment, to establish tone, type, and component direction.
- Hi-fi across the flow once structure is locked.
You can compress this on small projects, but the stages exist for a reason — each one answers a different question.
Principle 4: Design with engineering, not at it
The most common cause of "the engineers built it wrong" is "engineering wasn't in the room early enough." A great design process invites engineering in at the brief stage, not at the handover. Not to constrain the design — to inform it. Engineers know what's a one-day build versus a two-week build, what the existing components can do, what the data model will allow.
A short, weekly design–engineering sync, with both sides looking at the same Figma file, fixes most of the painful disconnects before they happen. It also makes design feasibility checks instant: "can we?" becomes a sentence, not a sprint.
(For why this collaboration matters even more in AI products, see designing for trust — the design decisions there are inseparable from the engineering.)
Principle 5: Use a system, even a small one
Even at MVP, a small, opinionated set of components — typography scale, spacing scale, primary buttons, secondary buttons, inputs, badges — saves more time than it costs. Designers stop re-deciding the same things on every screen. Engineers stop building one-off components. The product gets visually coherent faster.
It doesn't have to be a "design system" with versioning and a Storybook. It does have to be a shared, named set of decisions everyone uses.
Principle 6: Test small, often, and cheaply
The single highest-leverage research move in product design isn't a research phase — it's a 30-minute, lightly-scripted usability test, run on three or four users, on whatever's most recent. Done weekly, this beats almost any larger, more formal research methodology, because the feedback hits while the design is still cheap to change.
What to watch for in the test: hesitation, surprise, going the wrong way, asking for help. These are the cheap signals you'd otherwise discover with paying users. Every team that builds this rhythm reports the same thing — they were wrong about more things than they expected, and cheaply finding out is a superpower.
Principle 7: A working prototype beats a perfect mockup
If a design is contested or risky, the cheapest way to settle it isn't a longer review — it's a clickable prototype, two days of work in Figma or a no-code tool, in front of real users. Static mockups invite opinions ("I think this is nicer"). Working prototypes produce data ("they got stuck here, they understood that").
For products with critical interactions — onboarding, checkout, AI-powered features — invest in the prototype. The decision quality is dramatically higher.
What a great handover looks like
The moment design hands work to engineering is where most design value is lost. The handover that works:
- A linked Figma file with named components and clear states (default, hover, focus, error, empty).
- Edge cases addressed in the file, not in a Slack thread: long names, empty data, error states, loading.
- A short written rationale for any non-obvious choice ("we picked this navigation pattern because…"). Saves the conversation in week three.
- Designers staying involved through implementation, reviewing the real product as it comes together. Pixels move during build; that's normal. A designer eyeballing the result every week keeps things on track.
How this looks across the build
A great product design process isn't a phase. It's a rhythm that runs alongside engineering from kickoff through launch and beyond. Brief, sketch, prototype, build, test, iterate — at the right cadence, on the right things, with the right people in the room.
We bring this rhythm to every product design engagement, and to the AI app development and web app work that follows. If you've got a product where the design feels stuck — or hasn't started yet and you don't want it to be — book a call. One conversation usually unlocks more than another month of iterating.
