When should design be involved?

Design should be involved at the problem definition stage and in user research conversations to shape the right solution, not just at the final handoff.

What are common anti-patterns to avoid?

Avoid late involvement, handing a finished spec to design, design by committee, pixel-level feedback, and ignoring design debt or system polish.

working-with-design

Scanned

npx machina-cli add skill Dragoon0x/Product-Skills/working-with-design --openclaw

Files (1)

SKILL.md

2.6 KB

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

Source

git clone https://github.com/Dragoon0x/Product-Skills/blob/main/skills/collaboration/working-with-design/SKILL.mdView on GitHub

Overview

This skill guides PMs to collaborate with design to solve user problems, not just aesthetics. It covers when to involve design, how to frame feedback, and how to respect the design process, helping teams avoid late involvement and unproductive critiques. Following these practices reduces rework and aligns product outcomes with user and business goals.

How This Skill Works

Begin by involving design at problem definition and in user research conversations, giving design time to explore before converging on a solution. Share the user problem, constraints, and success metrics with design, along with data and competitive context, so they can evaluate options. When giving feedback, focus on user goals and business outcomes, separate personal taste from product judgment, and establish a regular review cadence to protect design time.

When to Use It

PM-design handoffs feel clunky or unfinished
Design feedback conversations are unproductive or focused on visuals rather than outcomes
Design is brought in too late in the process
You need to define the user problem, constraints, and success metrics with design
You are prioritizing work and need design input on trade-offs

Quick Start

Step 1: Involve design early in problem definition and in user research conversations
Step 2: Provide context (user problems, constraints, success metrics, data) and give design time to explore
Step 3: Establish a regular review cadence and give feedback focused on outcomes, not aesthetics

Best Practices

Involve design early in problem definition and ensure they participate in user research conversations alongside PM
Frame feedback in terms of user goals and business outcomes, not personal preferences
Provide design with user research, data, and competitive context to enable informed decisions
Set up a regular design review cadence and protect design time from disruptive requests
Avoid anti-patterns: don’t hand a finished spec to design, don’t involve design late, avoid pixel-level critiques, and resist design-by-committee approaches

Example Use Cases

PM and design co-create the problem statement, constraints, and success metrics during discovery, then design explores several concepts before locking in a direction
Feedback is framed as 'I’m worried users won’t find this because X' rather than 'make the button bigger,' grounded in user goals and data
Design is included in prioritization discussions to assess user impact and trade-offs, preventing over- or under-investment
Designers participate in user interviews and share findings with the PM, ensuring decisions are evidence-based
The team avoids the wireframe PM pattern by letting design lead exploration and iteration before any execution handoff

Frequently Asked Questions

Add this skill to your agents