working-with-design

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