# Pm Designer Translation

> Bidirectional translation between Product Managers and Designers. Helps PMs articulate requirements in design-friendly terms, and helps Designers explain design rationale in business terms. Bridges product thinking and design thinking.

- Skill: `mcltyl/pm-designer-translation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mcltyl/pm-designer-translation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mcltyl/pm-designer-translation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mcltyl (https://skillmd.com/u/mcltyl)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mcltyl/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

```markdown
## 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

```markdown
## 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

```markdown
"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

```markdown
"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"