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 toolDesign 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.
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. |
Internalise that your designer's core value is solving user problems, not producing visuals. This single shift governs everything else in the relationship.
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.
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.
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.
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 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 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 |
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.
'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.
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.
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.