| name | working-with-design |
| description | Partner with design to create better products, not just prettier ones. Covers when to involve design, how to give useful feedback, and respecting the design process. Use when PM-design handoffs feel clunky, design feedback conversations are unproductive, or design is brought in too late. |
Working with Design
Partner with designers to solve the right problems, not just make things look good.
How to use
/working-with-design Apply design collaboration constraints to this conversation./working-with-design <situation> Navigate a specific PM-design challenge.
Constraints
Involvement Timing
- MUST involve design at the problem definition stage, not after requirements are locked
- Designers SHOULD be in user research conversations alongside PM
- MUST give design time to explore before converging on a solution
- NEVER hand design a finished spec and ask them to "make it pretty"
- SHOULD involve design in prioritization discussions โ they often see user impact PM misses
Problem Framing
- MUST share the user problem, constraints, and success metrics with design โ not a wireframe
- SHOULD provide design with user research, data, and competitive context
- MUST articulate what success looks like so design can evaluate their own work
- NEVER give design a solution to execute. Give them a problem to solve.
Feedback
- MUST give feedback on design decisions in terms of user goals and business outcomes
- SHOULD say "I'm worried users won't find this because..." not "make the button bigger"
- MUST separate personal taste from product judgment. "I don't like blue" is not useful feedback.
- NEVER critique design in front of stakeholders without discussing 1:1 first
- SHOULD trust design expertise on visual and interaction decisions
Process Respect
- MUST respect that good design takes iteration โ the first version is not the final one
- SHOULD agree on review cadence: when will design share work and when will PM give feedback
- MUST protect design time from "quick favors" that fragment their focus
- NEVER go around design to make UI decisions directly with engineering
Anti-Patterns
- The Wireframe PM: designing the solution yourself and handing it to design for execution
- Late Involvement: bringing design in after the PRD is approved and scope is fixed
- Pixel Feedback: commenting on visual details instead of whether the design solves the problem
- Design by Committee: running every design decision through 8 stakeholders
- Ignoring Design Debt: never investing in design consistency, polish, or system improvements
