Product Design: From Rough Idea to Working Interface

DataKnobs

Product design

From a rough idea to a working interface.

Product design isn't one activity, and it isn't a straight line either. It's six stages that alternate between widening the options on the table and narrowing them back down — twice. Most of what goes wrong is a team narrowing before it's actually widened.

Opening slide of a presentation on the product design process — Title slide from the source deck. It carries its own text, so it opens full size in a new tab rather than being read at page scale.

The shape

Two diamonds, not one line

It's tempting to picture design as a pipeline — research, then design, then build, in order, once. The stages below don't actually run that way. They form two diamonds joined at the middle: one diamond for figuring out what problem is real, one for figuring out what solution actually solves it.

Each diamond has the same shape — widen, then narrow. Discover widens by surfacing many candidate problems; define narrows to the one worth solving. Ideate widens by generating many candidate solutions; prototype and test narrow to the one that survives contact with real users. Deliver is what happens once both diamonds have actually closed.

Discover

Widens

Before a single screen gets sketched, the job is to find out what's actually going on — talking to the people who'd use this, watching how they work around the problem today, scanning what else already exists. The output isn't an answer yet. It's a wider, more accurate picture of the problem space than the team started with.

This stage is uncomfortable precisely because it resists a clean deliverable. A team that skips it moves faster in the short term and slower everywhere after, because every later decision is now resting on assumptions nobody checked.

Slide illustrating the discover stage of the product design process

Define

Narrows

Discover produces more problem than any team can act on. Define is the narrowing — choosing the one framing worth committing to, stating who it's for, and setting the criteria that will later say whether a solution actually worked.

A weak define stage shows up later as scope creep and stakeholder disagreement that looks like a design problem but is really an unresolved framing problem, resurfacing because it was never actually settled.

Slide illustrating the define stage of the product design process

Ideate

Widens

The second diamond opens the same way the first one did: on purpose, wider than feels efficient. The point of generating many rough concepts isn't that most of them get used — it's that the one concept that does get chosen was actually compared against real alternatives, not just the first idea anyone liked.

Teams that skip straight from define to one polished concept aren't saving time. They're removing the only stage where a genuinely better idea had a chance to compete.

Slide illustrating the ideate stage of the product design process

Prototype

Narrows

Building something people can actually respond to — at whatever fidelity the current question needs, and no higher. A rough sketch can settle whether a flow makes sense; a fully polished mockup is what it takes to judge visual trust or a fine interaction detail.

Building high-fidelity work to answer a low-fidelity question wastes time twice: once making it, and again when nobody wants to throw away work that looks finished, even after a test says to.

Slide illustrating the prototype stage of the product design process

Test

Narrows

Watching someone who actually fits the target user try to complete a real task, without being talked through it. That's a usability test. Asking a colleague or the design team what they think of a screen is feedback — useful for a different purpose, but not a substitute, whatever the summary slide later calls it.

Testing narrows the diamond further: a concept that looked strong on paper either survives contact with a real task or it doesn't, and either result is progress.

Slide illustrating the test stage of the product design process

Deliver & measure

Narrows

Both diamonds have closed by now — the problem is framed, the solution is validated. Delivery hands off specs, states, and edge cases to engineering, and the design's job isn't actually finished until someone checks what happened after launch against the criteria define set at the start.

A team that ships and moves on without measuring has quietly turned its own success criteria into decoration. The criteria only mean something if somebody goes back and checks them.

Slide illustrating the deliver and measure stage of the product design process

Signature tool

Trace the diamond

Click any stage on the shape below. The width at that point is the point — wide means the team should have more options on the table than it's comfortable with; narrow means it's time to commit.

Widens

Discover

Surfacing candidate problems by talking to real people and watching real workarounds. The width here is deliberate — narrowing too soon means later decisions rest on assumptions nobody checked.

Getting it wrong

The shortcuts that don't feel like shortcuts

Jumping straight to one solution

Skipping ideate's width means the "winning" concept was never actually compared against anything. It just got there first.

Testing with the design team

Feedback from people who already understand the intended flow isn't a usability test. It measures whether insiders can follow their own design.

Building high fidelity too early

Polish makes work feel finished before it's been validated, which makes everyone — including the team — more reluctant to change it when a test says to.

Shipping without measuring

Define's success criteria only mean something if someone checks them after launch. Otherwise they were decoration for a pitch deck, not a commitment.

Questions

Common questions

What are the stages of the product design process?

Discover, define, ideate, prototype, test, and deliver. Discover and define make up the problem half; ideate, prototype, and test make up the solution half; deliver hands the validated solution to engineering and checks the result after launch.

Why does the process widen and then narrow, twice?

Because both the problem and the solution are easy to lock in prematurely. Discover widens by gathering many possible problems before define narrows to one framed problem worth solving; ideate widens by generating many possible solutions before prototype and test narrow to one validated approach. Skipping either widening half means the narrowing that follows had nothing real to choose between.

What fidelity should a prototype be?

Whatever is enough to test the question in front of you, and no more. A rough sketch can validate whether a flow makes sense; high fidelity is needed to judge visual trust or fine interaction detail. Building high fidelity to answer a low-fidelity question wastes time and makes people reluctant to throw work away when the test says to.

What counts as a usability test?

Watching someone who fits the target user try to complete a real task with the design, without being coached through it. Asking colleagues or the design team for their opinion is feedback — useful for a different purpose — but it isn't a usability test and shouldn't be reported as one.