Working with Designers
Design is problem-solving, not decoration. Everything follows from whether a PM treats their designer as a strategic partner in solving user problems — or as a service desk that produces mockups on demand.
▸ Try the interactive toolThe framework
Design is not decoration — it's problem-solving. This single reframing is the foundation of the entire tool, because everything follows from whether a PM treats their designer as a strategic partner in solving user problems or as a service provider who produces mockups on demand. Great PMs treat design as a thinking partner; weak ones treat it as a pixel factory.
The difference shows up at the very start of the work. A PM who hands the designer a finished solution to 'make pretty' has wasted the designer's most valuable contribution — their problem-solving — and reduced them to decoration. A PM who brings the designer the problem (with context and constraints) and explores solutions together gets better outcomes, because designers are trained to solve user problems and will often find solutions the PM wouldn't. The reframing from 'make this look good' to 'help me solve this' changes everything downstream.
Design = problem-solving, not decoration. Bring the designer the problem (with context and constraints), not a finished solution to prettify. Partner on the solution; don't hand over a spec to skin.
Try it yourself
What it prevents
When a PM hands a designer a pre-decided solution to make attractive, they throw away the designer's actual expertise — problem-solving — and get worse outcomes than partnership would produce.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Design as decoration | Handing over a solution to 'prettify' wastes the designer's real skill. | Treating design as problem-solving unlocks better solutions. |
| Designer as service desk | Mockups-on-demand reduces a partner to an order-taker. | A strategic partnership engages the designer's full expertise. |
| Solution handed over pre-decided | The PM's solution may be worse than the designer would find. | Bringing the problem lets design explore solutions the PM wouldn't. |
| Late design involvement | Design brought in after key decisions are locked. | Early partnership shapes the solution while it still can. |
Step by step
Reframe design as problem-solving
Internalise that your designer's core value is solving user problems, not producing visuals. This single shift governs everything else in the relationship.
Bring the problem, not the solution
Hand the designer the user problem, the context, the constraints, and the goals — not a finished design to skin. Let them apply their problem-solving to the actual problem.
Explore solutions together early
Involve the designer at the start, while the solution is still open. Their expertise shapes outcomes most when decisions aren't yet locked — bringing them in late wastes it.
Provide context and constraints, not directives
Give the why, the user research, the technical and business constraints — then trust the designer to solve within them. Constraints enable good design; directives suffocate it.
Partner through iteration
Treat design as an ongoing collaboration, not a one-time handoff. Give feedback on whether it solves the problem, not just on aesthetics — and stay a partner through the iterations.
A short illustration
A PM routinely handed their designer fully-formed solutions — wireframes the PM had already drawn — and asked them to 'make it look professional.' The designer, reduced to a decorator, produced polished versions of the PM's ideas, some of which were solving the user problem poorly because the PM wasn't a trained designer.
The reframe was simple but transformative: the PM started bringing the designer the problem instead — the user need, the context, the constraints — and exploring solutions together. The designer, finally applying their actual expertise, proposed approaches the PM would never have conceived, several clearly better at solving the underlying problem. The same person, the same hours, but now a problem-solving partner rather than a pixel factory.
The design partnership
The deliverable is a working relationship where design is engaged as a problem-solving partner from the start — given problems and context, not solutions to skin.
| Design as decoration | Design as problem-solving |
|---|---|
| 'Make this look good' | 'Help me solve this' |
| Hand over a finished solution | Bring the problem & constraints |
| Involve late, to prettify | Involve early, to solve |
| Feedback on aesthetics | Feedback on solving the problem |
Why it matters
Whether design is decoration or problem-solving is decided entirely by the PM, in how they frame the work. Bring a solution to prettify and you get a decorator; bring a problem to solve and you get a partner.
This is fundamentally about not wasting expertise. Designers are trained problem-solvers with a discipline the PM doesn't have — and a PM who pre-decides the solution and hands it over for skinning is, in effect, overruling that expertise before it's applied, often with a worse solution. The reframe to 'design is problem-solving' isn't a platitude about respecting colleagues; it's a practical recognition that the designer will frequently find a better answer to the user problem than the PM would, but only if they're given the problem rather than the PM's answer to it. The discipline mirrors the PRD's what-not-how: the PM owns the problem and the why, and brings those to a partner who owns the solution — which is exactly how the best design work emerges.
Common mistakes
'Make it pretty' wastes the designer's real skill. Frame design as problem-solving.
The PM's solution may be worse. Bring the problem and let design solve it.
Expertise applied after decisions are locked is wasted. Partner early.
Judge whether the design solves the problem, not just how it looks.
When not to use it
- Genuinely trivial visual tweaks. Not every pixel change is a problem-solving exercise — but the default stance should still be partnership.
- No dedicated designer. On teams without design, the principle still informs how the PM approaches solution design — problem first.
- As an excuse for the PM to abdicate. Partnership doesn't mean handing off all product thinking — the PM still owns the problem and the why.
Where this sits in the toolkit
A strong design partnership makes the handoff (Tool 23) far smoother.
'Bring the problem, not the solution' is the what-not-how principle (Tool 13) applied to design.
The problem and context the PM brings to design come from real discovery (Module 3).
Like engineering (Tool 20), design works best as a trusted partnership, not a service relationship.
Reframe a design request
Take a design request you might make ('design a settings page like this mockup'). Rewrite it to hand over the problem instead — what user need, what context, what constraints?
Notice whether your problem-framed version leaves room for the designer to find a solution you hadn't thought of.
If your reframed request invites the designer to solve rather than to decorate, you've made the shift that separates a design partner from a pixel factory — and unlocked the expertise you were otherwise wasting.
New tools and AI deep-dives, occasionally.
No spam. Unsubscribe anytime.