Pm designer translation

PM ↔ Designer Translation Skill

Purpose

Bridge the communication gap between Product Managers and Designers by translating concepts bidirectionally:

• PM → Designer: Translate requirements into design-friendly briefs
• Designer → PM: Translate design rationale into business justification

When to Activate

Activation conditions (any one triggers):

• PM writing a design brief or spec
• Designer presenting design decisions to PM/stakeholders
• Disagreement about design direction
• Balancing user experience with business constraints
• Design review or critique sessions

PM → Designer Translation

Input: Product Requirement

Output: Design Brief

Translation Framework:

1. Feature Request → User Outcome

   • "Add a dashboard" → "Users need to see status at a glance"
   • Describe the outcome, not the UI

2. Business Goal → Design Constraint

   • "Increase conversion" → "Primary CTA must be unmissable"
   • Make business intent explicit

3. Edge Cases → Scenarios

   • "Handle errors" → "Empty state, loading, error, success"
   • List all states the design must address

4. Timeline → Scope Guidance

   • "2 weeks" → "Focus on core flow, polish can follow"
   • Help designers prioritize

Template: Design Brief

## Design Brief: [Feature Name]

### User Problem
Who is this for? What pain are we solving?

### Success Looks Like
What should users be able to do? How will we measure success?

### Constraints
- **Must have:** [Non-negotiables]
- **Timeline:** [Scope implications]
- **Technical:** [Platform, performance, accessibility]
- **Brand:** [Voice, visual guidelines]

### Scenarios to Cover
1. Happy path: [Description]
2. Empty state: [First-time user experience]
3. Error state: [What can go wrong]
4. Edge cases: [List specific scenarios]

### What's Out of Scope
[Explicitly list what NOT to design for now]

### Reference
[Competitor examples, inspiration, existing patterns]

### Open Questions
[Where we need design input, not just execution]

Designer → PM Translation

Input: Design Decision

Output: Business Justification

Translation Framework:

1. Aesthetic Choice → User Impact

   • "More whitespace" → "Reduces cognitive load, faster task completion"
   • Connect visual to outcome

2. UX Pattern → Business Metric

   • "Progressive disclosure" → "Reduces drop-off by not overwhelming users"
   • Link pattern to funnel impact

3. Interaction Design → User Behavior

   • "Hover states and microinteractions" → "Builds confidence, reduces errors"
   • Explain the psychology

4. Design System → Velocity

   • "We need to standardize this" → "Speeds up future features by 40%"
   • Frame consistency as investment

Template: Design Rationale

## Design Decision: [What we chose]

### The Choice
[One sentence: what we're recommending]

### Why This Approach
**User perspective:** [How it helps users]
**Business perspective:** [How it drives metrics]
**Technical perspective:** [Implementation considerations]

### Alternatives Considered
| Option | Pros | Cons | Why Not |
|--------|------|------|---------|
| [A] | | | |
| [B] | | | |

### Trade-offs
What we're giving up and why it's worth it.

### Evidence
- [User research supporting this]
- [Competitor/industry patterns]
- [Principles or heuristics applied]

### Next Steps
[What we need to move forward]

Common Translation Patterns

PM Says → Designer Hears → Better Way

PM Says	Designer Hears	Better Translation
"Make it pop"	Meaningless	"Primary action needs to be the obvious first thing users see"
"Like Apple"	Copy Apple	"Aim for: minimal, confident, focused on one action per screen"
"Users are confused"	My design failed	"Users expected X but encountered Y. How might we bridge that gap?"
"Can we add a button?"	PM designing	"Users need to [action]. What's the best way to surface that?"
"This looks off"	Vague criticism	"I'm not sure this conveys [intended feeling]. Can we explore alternatives?"

Designer Says → PM Hears → Better Way

Designer Says	PM Hears	Better Translation
"This needs more exploration"	Delay	"3 options in 2 days, then decide. Here's why it matters..."
"It doesn't feel right"	Vague pushback	"This violates [principle]. Users will likely [problem]. Here's data..."
"We need a design system"	Scope creep	"Standardizing this saves X hours per feature. Propose: start with [subset]"
"Trust me on this"	No justification	"Here's the research/principle behind this. Happy to walk through it."

Critique & Feedback Framework

Giving Design Feedback (PM → Designer)

Structure:

1. Clarify intent: "Help me understand why..."
2. State observation: "I notice that..."
3. Share concern: "I'm worried users might..."
4. Ask, don't dictate: "How might we...?"

❌ Don't:

• "Move the button to the left"
• "Make it bigger"
• "I don't like it"

✅ Do:

• "The primary action feels hidden. What are our options?"
• "This feels dense. What if we prioritized fewer elements?"
• "I'm not sure this matches the energy we want. Can we explore bolder directions?"

Presenting Design (Designer → PM)

Structure:

1. Context: Remind them of the problem
2. Solution: Show the design
3. Rationale: Explain key decisions
4. Trade-offs: What you considered
5. Ask: What you need (approval, feedback, decision)

❌ Don't:

• Show work without context
• Get defensive about feedback
• Say "just trust me"

✅ Do:

• Tie every decision to user outcome or business goal
• Present 2-3 options when uncertain
• Separate "I need feedback" from "I need approval"

Negotiating Design vs. Business Constraints

When PM Pushes Back on Design

Designer response framework:

1. Acknowledge the constraint
2. Explain the user impact of compromise
3. Offer alternatives with trade-offs
4. Document the decision and risk

"I hear that timeline is tight. If we skip [X], users will 
likely experience [Y]. Two alternatives:

A) Ship without [X], add in v1.1 — Risk: [Z]
B) Cut [other feature] to keep [X] — Risk: [W]

Which trade-off do we prefer?"

When Designer Pushes Back on PM Requirements

PM response framework:

1. Clarify the business constraint
2. Explore if constraint is real
3. Collaborate on alternatives
4. Decide together

"The reason for [requirement] is [business context]. 
Is there a design approach that achieves [goal] differently? 
Open to alternatives that hit the same outcome."

Anti-Patterns

PM Anti-Patterns

• ❌ Designing in the spec ("Put a button here")
• ❌ "Make it like [competitor]" without context
• ❌ Changing requirements after design is done
• ❌ Skipping design for "simple" features
• ✅ Describe outcomes, provide context, stay open

Designer Anti-Patterns

• ❌ "It's a design thing, you wouldn't understand"
• ❌ Over-designing before validating problem
• ❌ Presenting only one option as fait accompli
• ❌ Ignoring technical or business constraints
• ✅ Justify decisions, offer options, collaborate

Response Principles

• Outcomes over outputs — focus on what users achieve, not what screens look like
• Both sides have expertise — PMs know business, designers know users/craft
• Constraints are creative — limitations often produce better solutions
• Show, don't tell — mockups and prototypes beat long discussions
• Critique the work, not the person — "This design" not "You designed"