Runs a PM-perspective design critique focused on product outcomes and user goals, not aesthetics. Use when asked for a PM design critique, a product review of a Figma design, or feedback from a product perspective without needing to be a designer. Produces structured outcome-based feedback tied to user goals, business metrics, and requirement coverage.
Start a fresh conversation. Replace the highlighted placeholders.
Use figma-design-critique-pm to critique [design description or screen summary] against [user goal, business goal, and original requirements], using [key metric and constraints]; provide outcome-based evidence, questions for the next iteration, and one PM recommendation.
Required inputs
[design description or screen summary]
[user goal, business goal, and original requirements]
[key metric and constraints]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: figma-design-critique-pmdescription: "Runs a PM-perspective design critique focused on product outcomes and user goals, not aesthetics. Use when asked for a PM design critique, a product review of a Figma design, or feedback from a product perspective without needing to be a designer. Produces structured outcome-based feedback tied to user goals, business metrics, and requirement coverage."
Figma Design Critique — PM Perspective Skill
This skill is specifically for product managers critiquing designs — focused on whether the design achieves the user goal and business outcome, not whether it looks good. Different from the general design-critique skill which covers UX aesthetics; this one centres product thinking.
Not quite this? Use figma-design-qa when you need to check implementation fidelity against the spec rather than product outcomes.
Required Inputs
Design description or screen summary
User goal (what is the user trying to accomplish?)
Business goal (what outcome does the product need?)
Original requirements (what was this supposed to do?)
Key metric (what would move if this design works?)
Output Structure
1. PM Critique Summary
User goal, business goal restated.
Verdict: On track / Mostly on track / Needs rethinking
One-paragraph summary: what works from a product perspective, and the single most important thing to address.
2. Goal Alignment Check
Goal
Design supports it?
Evidence
[User goal]
Yes/Partial/No
[Specific observation]
[Business goal]
Yes/Partial/No
[Observation]
[Key requirement]
Yes/Partial/No
[Observation]
3. PM Feedback (Outcome-Focused)
Every concern must tie to an outcome. "I do not like this layout" is not PM feedback. "This layout puts the primary action below the fold, which will reduce mobile conversion" is PM feedback.
[Concern] — High/Medium/Low impact
Observation: [Neutral description of what the design does]
User impact: [What this means for the user goal]
Business impact: [What this means for the metric]
Evidence basis: [Research/data/analogous patterns/hypothesis — be honest]
Question for designer: [What to explore — not a directive]
4. What the Design Does Well
2-4 specific things working well from a product perspective — with evidence. Not "colours are nice" but "primary CTA is the most prominent element, aligning with conversion goal." Always include this section.
5. Questions Before Next Iteration
Question
Who answers
Why it matters
[Question]
Designer/PM/Eng
[Impact]
6. PM Recommendation
Approve / Approve with changes (list) / Revise and re-review (one focus area only)
PM Critique Rules
Never reference aesthetics as reason for feedback — only outcomes
"I prefer" is not feedback — "users are likely to" is feedback
Lead with what is working before what is not
Ask questions before giving directives
One primary recommendation — not a redesign in bullets
Quality Checks
Every concern tied to user or business outcome
What is working section is genuine and specific
Questions section included (not just directives)
PM recommendation is explicit
Evidence basis stated honestly
Anti-Patterns
Do not critique visual aesthetics — PM feedback must focus on product outcomes, user goals, and business requirements
Do not provide feedback without stating the evidence basis — distinguish between observed design facts and assumed user behaviour
Do not give vague feedback like "the flow feels confusing" — every concern must reference a specific screen state or interaction
Do not ignore what is working — balanced critique includes explicit acknowledgment of design decisions that are well-executed
Do not critique without knowing the design constraints — always ask about technical, time, or resource limitations before judging decisions
Example Trigger Phrases
"Give me a PM critique of this design"
"Review this design from a product perspective"
"What product feedback do I have on this Figma design?"