In short
Product design is the discipline of deciding how a product works and feels — the flows people take, the states each screen can be in, and the reasons behind both — not just how it looks. UI design is one layer of it. The work holds up only when the person who designs the experience understands, and ideally ships, the thing that gets built.
What product design is
Ask ten people what a product designer does and most will describe someone arranging buttons and choosing colours. That’s a fraction of it. Product design is the discipline of shaping the whole experience of using something — what problem it solves, the path a person takes through it, and how it responds at every step.
A useful way to see the difference: UI design starts with a screen. Product design starts with a question. What is the user trying to get done? What is the shortest honest path to it? Only once those are answered does drawing a screen make sense.
Product design vs UI design
The two are often used interchangeably, and they overlap, but they answer different questions.
- UI design is the surface — layout, type, colour, spacing, components. It makes a screen clear and pleasant to look at.
- Product design decides which screens should exist, what happens between them, and how the product behaves when things go right, go wrong, or haven’t started yet.
Put plainly: UI design makes the screen good. Product design makes sure it’s the right screen in the first place. You need both, but confusing one for the other is how teams end up with beautiful interfaces that solve the wrong problem.
What a product designer delivers
A typical engagement produces a predictable set of artefacts — not as paperwork, but as the decisions made visible:
- User flows — the real paths people take, mapped and pressure-tested before a single screen is drawn.
- Interface design — every screen, designed on purpose rather than assembled from defaults.
- Interaction and motion — how the product responds to input, so it feels considered instead of merely decorated.
- Prototypes — clickable, testable versions that answer the hard questions before code has to.
The states nobody mocks up
The gap between a good product and a frustrating one usually lives in the states no one bothered to design. A screen isn’t one picture — it’s a set of them: the empty state before there’s any data, the loading state, the error state, the “you’ve done everything” state, the too-much-data state.
UI mockups tend to show the happy path with realistic-looking placeholder content. Product design accounts for the rest, because the rest is where users actually get stuck. Designing those states is unglamorous and it is most of the job.
Why it needs one team
Product design decisions are only as good as their survival rate into production. A flow that reads beautifully in a design tool can quietly fall apart when an engineer hits a case the mockups skipped — and with a handoff between separate teams, those cases get resolved by whoever is closest to the deadline, not whoever understands the intent.
When the people who draw the product are the people who build it, the edge cases are designed rather than discovered, and nothing gets specced that can’t ship. That’s the whole argument for running design and development as one practice: the design decision and the build decision become the same decision.
Common questions
What is product design?
Product design is the discipline of shaping how a product works and feels end to end — the flows a user takes, the states each screen can be in, and the decisions behind them — not just how the interface looks.
How is product design different from UI design?
UI design is the visual surface. Product design is broader — it decides what the screens should be, what happens between them, and how the product behaves in every state, including the empty, loading, and error cases UI mockups often skip.
What does a product designer actually deliver?
Typically: mapped user flows, interface designs for every meaningful state, interaction and motion specs, and clickable prototypes used to test decisions before code is written.
Why should the designer and developer be the same team?
Because every handoff is a translation, and translations lose intent. When the people who draw the product also build it, edge cases are designed rather than discovered in QA, and nothing gets specced that cannot ship.