# 32 Claude Skills for Product Designers, From Problem Framing to the Portfolio Case Study 32 Claude skills to frame, explore, design, prototype, critique, test, hand off and show the impact of one piece of design work. - Page: https://lantern.meet-polar-bear.com/skills/product-designers-pack - Download: https://lantern.meet-polar-bear.com/skills/product-designers-pack.zip - Source: https://github.com/polar-bear-org/claude-skills/tree/main/packs/product-designers-pack - Price: free ## Install in Claude Code ``` /plugin marketplace add polar-bear-org/claude-skills /plugin install product-designers-pack@polar-bear-skills ``` ## The 32 skills you get The set follows one piece of design work in eight stages: framing the problem, exploring and deciding, designing with context, prototyping, critique and quality, testing with real users, handing off, then defending the work and showing the impact. ### 1 · Frame the problem - **Problem Framing Brief** — use when: You were handed a feature and a deadline, and nobody has said what problem it solves. Output: The request as handed over, the problem with no fix in it, evidence and gaps, a "not solving" list, hypotheses placed by risk and value. - **User Journey Map** — use when: You design one screen of a journey nobody has drawn, and the team's picture of it is a guess. Output: One group, one scenario, stages, actions, thoughts, feelings, touchpoints and pain points, every cell tagged to its evidence. - **HEART Metrics Plan** — use when: The project starts and nobody agreed what design success will look like. Output: Chosen dimensions, goal, signal and metric for each, baselines or "baseline needed", instrumentation asks, guardrails. ### 2 · Explore and decide - **Design Principles** — use when: Every review turns into a taste argument because nothing written says what this product chooses. Output: Four to seven stands for this product, what each gives up, "this, not that" pairs, a conflict check. - **Design Options Trade-off Table** — use when: Stakeholders saw one design and think it is the only one, so every comment is a tweak. Output: Two to four options that differ in structure, criteria, consequences in words, what each option gives up. - **Design Rationale Doc** — use when: You are asked "why is it like this?" in every meeting. Output: The decision, why each option lost, evidence or visible gaps, trade-offs accepted, risks, the signal that reopens it. - **Design Decision Log** — use when: A decision made months ago is reopened and nobody remembers why it was made. Output: Numbered decision records with context, status, consequences, decider, revisit trigger and an index. ### 3 · Design with context - **Design System Rules File** — use when: Your design system reads well to people, and Claude still invents values and components you do not have. Output: Tokens by name and role, component rules and states, do and do not pairs, a list of what is missing, a five-prompt test. - **Product Context File** — use when: Every chat starts from zero and the first draft looks like a product for nobody in particular. Output: One file Claude reads first: users, jobs, voice, principles, constraints, what the product never does, where each fact came from. - **User Flow** — use when: You have a brief and a blank canvas, and the happy path is the only path anyone has described. Output: Entry points, steps with system responses, decision points, error and recovery branches, exits, open questions. - **UX Writing Copy Deck** — use when: The screens are done and the copy is still placeholder text and "Submit". Output: Every string for one flow in one table, errors that say what to do next, length limits, terms checked, approvals still needed. - **UI States and Edge Cases** — use when: Engineering asks "what happens when the list is empty?" on day three of the build. Output: Screens against states, an edge-case sweep per screen, each cell marked designed, missing or not needed with the reason. ### 4 · Prototype - **Prototype Brief** — use when: Someone says "just prototype it" and nobody has said what the prototype is for. Output: The one question, the audience, the lowest fidelity that answers it, real and faked parts, the pass line, what it does not prove. - **Claude Design Prototype Plan** — use when: You want a clickable prototype this afternoon and the first result looks like everyone else's. Output: The written brief for Claude Design, the look specified, three or more directions, what to fix by hand, saved copies, limits to plan around. - **Prototype Share Check** — use when: A prototype is about to go to users or a stakeholder, and it looks finished enough to be mistaken for the product. Output: A list a person runs before sharing: the label, what is faked, invented data only, link access, a contrast and keyboard look, the words to say. ### 5 · Critique and quality - **Design Quality Bar** — use when: "Raise the bar" is said every quarter and nobody has written the bar. Output: Yes or no checks by stage, a must-pass list proposed for the person who owns quality to confirm. - **Design Self-Critique** — use when: The review is tomorrow and you want to find the obvious problems before the room does. Output: Your pass and a second-opinion pass against ten heuristics, merged issues, trade-offs, what needs a real user, the fix list. - **Accessibility Review** — use when: Accessibility gets looked at after the build, or an automated check said everything passed. Output: Design-stage checks marked pass, fail or cannot tell from a design, the fixes, and what only code, assistive technology and disabled users can show. - **Design Sameness Check** — use when: The screen looks fine and could belong to any product. Output: An inventory of default choices, each chosen or inherited, three places for a real decision, what stays standard. - **Critique Session Brief** — use when: You present at crit on Thursday and "thoughts?" will get you opinions. Output: Numbered objectives, the stage, the one question for the room, out of scope, the walkthrough, a framing sentence. - **Critique Notes to Actions** — use when: You left crit with twenty comments, half of them contradicting each other. Output: Notes merged and sorted, your call on each, actions with owners and dates, a three-line reply. ### 6 · Test with real users - **Usability Test Plan** — use when: The prototype is ready, the sessions are booked, and the script is a guided tour. Output: Goals, task scenarios with the path unstated, success criteria set first, a moderator script, an observer grid, the sample, a pilot. - **Accessible Test Sessions** — use when: The accessibility review passed on paper and no disabled person has ever used the design. Output: How to invite disabled and older people, access needs asked in advance, their own technology, accessible consent, session adjustments. - **Usability Test Findings** — use when: The tests "went well" and your notes say four people failed the core task. Output: Task outcomes as "n of N", what people did beside what they said, issues with evidence and a proposed severity, clips to pull. ### 7 · Hand off - **Design Handoff Spec** — use when: The file is polished and engineering still cannot tell which design is final or what happens on error. Output: Which version is final, flows, rules next to screens, tokens by name, motion, focus order, copy status, open questions, a ready check. - **Design System Change Record** — use when: Your feature needs something the system does not have. Output: One proposed change, what exists and why it does not serve, the "build it from what exists" check, who is affected, the decision left blank for the owner. - **UX Debt Register** — use when: The broken empty state and the copy nobody rewrote never make the plan. Output: One row per issue as user impact, frequency from evidence, effort set with engineering, value against effort, a short list to propose. ### 8 · Defend and show the impact - **Design Review Deck** — use when: You present to stakeholders and the room argues about colours instead of the decision. Output: The decision asked on slide one, options and what the recommendation gives up, real evidence, feedback in scope, next steps. - **Stakeholder Feedback Log** — use when: Three stakeholders gave three opposite notes and the next round undoes the last. Output: Every comment by role and objective, duplicates merged, conflicts side by side for the decider, reply drafts you send. - **Design Pushback Brief** — use when: You are asked to ship a deceptive pattern or a change you believe will hurt users. Output: The request and its goal, the risk with evidence, two alternatives, what you will and will not do, who decides. - **Design Impact Write-Up** — use when: Someone asks what the redesign delivered and you have screens, not outcomes. Output: What design changed, before and after from your data, what else moved, a confidence level, results that got worse kept in. - **Portfolio Case Study** — use when: Your portfolio shows twenty polished frames and reads like every other case study. Output: One project told through three to five decisions, your role, what real users did, real outcomes, a confidentiality check. ## Workflows - **Frame the problem** (A feature and a deadline, and no stated problem.) Problem Framing Brief → User Journey Map → HEART Metrics Plan - **Decide and record why** (Every review turns into a taste argument.) Design Principles → Design Options Trade-off Table → Design Rationale Doc → Design Decision Log - **Give Claude the context** (Claude is about to draft screens for your product.) Design System Rules File → Product Context File → User Flow → UX Writing Copy Deck → UI States and Edge Cases - **Prototype one question** (Someone says “just prototype it”.) Prototype Brief → Claude Design Prototype Plan → Prototype Share Check - **Check it before crit** (The work goes in front of peers this week.) Design Quality Bar → Design Self-Critique → Accessibility Review → Design Sameness Check → Critique Session Brief → Critique Notes to Actions - **Test, then hand off** (Sessions are booked and engineering starts soon.) Usability Test Plan → Accessible Test Sessions → Usability Test Findings → Design Handoff Spec → Design System Change Record → UX Debt Register - **Defend and show impact** (A stakeholder review, then the question of what the work delivered.) Design Review Deck → Stakeholder Feedback Log → Design Pushback Brief → Design Impact Write-Up → Portfolio Case Study ## The quality bar - One method, applied properly: each skill uses the real mechanics of its source (the hypothesis placements, the question, options and criteria form, the decision record statuses, the ten heuristics, the 0 to 4 severity scale, goals to signals to metrics), not a generic “gather, analyse, recommend” - Real evidence or a visible gap: research findings, user quotes and numbers come only from what you paste. Anything missing stays a bracketed placeholder, “not researched” or “not measured” - A person checks before anything is shown: every output a user, customer or stakeholder will see has a check a person runs first, and a prototype is labelled as a prototype - Problems are rated, people are not: severity, effort and value describe issues in the work. Nothing rates a designer, a participant or a colleague - Every output ends with a decision: each template closes with what a named person decides next, and by when - Adviser points stay with an adviser: accessibility duties, consent, data and other legal points end with “check with a qualified adviser” - The red line: Claude drafts, checks and explains; you make the design decisions, real users test the work, and nothing is presented as tested, accessible or ready to ship that was not ## Questions people ask ### What is in the Claude for Product Designers pack? 32 Claude skills that follow one piece of design work in eight stages: frame the problem, explore and decide, design with context, prototype, critique and quality, test with real users, hand off, and defend and show the impact. Each skill is one named method or one artifact. ### How do I install these Claude skills? In Claude Code, two lines install all 32 at once. In Claude.ai or Claude Desktop, download the zip, open Settings, Skills, Add, and upload the skills you want. Either way it takes about five minutes. ### Do I need Claude Code to use them? No. The skills work in Claude.ai, Claude Desktop and Claude Code. In the app you upload them yourself; in Claude Code one command installs the whole pack. ### Do the skills work with ChatGPT or other assistants? They are built as Claude Skills, and installing them is a Claude feature. Each one is a plain Markdown file, so you can read it and reuse the method elsewhere, but it will not load and trigger by itself outside Claude. ### Can Claude say a design is tested or accessible? No. Claude drafts, checks and explains. You make the design decisions and real users test the work. Nothing is presented as tested, accessible or ready to ship that was not. ### Is the pack free? Yes. It is free to use inside your company and in client work, and not for resale. There is no signup: the download and the install command are on this page. ## About Written by Polar Bear (https://meet-polar-bear.com/). Published on Lantern (https://lantern.meet-polar-bear.com/), which turns your notes, documents and call transcripts into social post drafts you review and publish.