October 2026 · 13 min read · 32 skills, free

32 Claude Skills for Product Designers, From Problem Framing to the Portfolio Case Study

Frame the problem, compare real options and record why one won. Give Claude your design system and product before it designs, prototype one question, test with real users, hand off with nothing to guess, then show what design delivered.

01What these skills are

One piece of design work, from the problem framing brief to the portfolio case study, as installable Claude skills

This pack is for product designers, UX designers, UI designers, and designers who do their own research.

The skills follow one piece of design work in order, in eight stages, from framing the problem behind the request to the impact write-up and the portfolio case study.

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.

Research findings, user quotes and numbers come only from what you paste. Anything missing stays a bracketed placeholder, “not researched” or “not measured”.

Every output a user, customer or stakeholder will see has a check a person runs first, and each template closes with what a named person decides next, and by when.

Download all 32 skills

One zip: ready-to-install skill zips, readable SKILL.md files, and the sources behind every method. Free, no signup. The same 32 skills live in our open repo, if you would rather read them before you install them.

Download the zip Browse on GitHub

Install in Claude Code

Two lines, and every skill in the pack loads at once.

/plugin marketplace add polar-bear-org/claude-skills
/plugin install product-designers-pack@polar-bear-skills

Using Claude on the web instead? Download the zip above and upload each skill from its install folder under Customize → Skills.

02The catalog

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

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

03How to use it

Pick the workflow that matches your week

Start with the problem framing brief, before you open a design file. After that, bring the one real thing in front of you.

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

04Setup guide

Install it in five minutes

In Claude Code · two lines

/plugin marketplace add polar-bear-org/claude-skills
/plugin install product-designers-pack@polar-bear-skills

In Claude.ai or Claude Desktop · seven clicks

Download the pack, then open Settings
Unzip the pack: its skills folder holds all 32 skills. In Claude, click your name at the bottom left, then Settings.
Download the zip
Open Skills and click Add
Under Customize, choose Skills. Click Add, then Upload a skill.
Drop in a skill file
Drag the skill's file into the box, or click to browse. You can add several at once.
Pick the skill from the pack
In the pack folder, open skills, then the skill you want, and select its SKILL.md — pdes-problem-framing-brief is a good first one.
Check the preview and upload
Claude shows the skill's name and what it does. Click Upload.
Make sure it is switched on
The skill opens on its own page. Its toggle should be on.
Try it in a new chat
Type / and the skill's name, then say what you need.

Then try one

Run pdes-problem-framing-brief on the request exactly as it reached you and the evidence behind it: [paste the ticket and the evidence here]

Run pdes-ui-states-and-edge-cases on the screens of one flow: [paste or describe the frames here]

Run pdes-usability-findings on your session notes and the success criteria you set before testing: [paste them here]

Lantern for designers

Turn your design process into posts people follow

Lantern drafts a week of posts from your notes and call transcripts, in your voice. You review them and publish the ones you like.

100 free credits, about ten posts. No card needed.

Try for free

05Quick reference

Where to start

Your situation	Skill to run
Handed a feature and a deadline, and nobody has said what problem it solves?	Problem Framing Brief
Nobody agreed what design success will look like?	HEART Metrics Plan
Stakeholders saw one design and think it is the only one?	Design Options Trade-off Table
Asked “why is it like this?” in every meeting?	Design Rationale Doc
Claude keeps inventing values and components you do not have?	Design System Rules File
Every chat starts from zero on your product?	Product Context File
The happy path is the only path anyone has described?	User Flow
Need every state and edge case accounted for?	UI States and Edge Cases
Told to “just prototype it” and nobody has said what the prototype is for?	Prototype Brief
The review is tomorrow and you want the obvious problems found first?	Design Self-Critique
Need a design-stage accessibility check?	Accessibility Review
Left crit with twenty comments, half of them contradicting each other?	Critique Notes to Actions
Sessions are booked and the script is a guided tour?	Usability Test Plan
Need engineering to build it without guessing?	Design Handoff Spec
Asked to ship a change you believe will hurt users?	Design Pushback Brief
Asked what the redesign delivered and you have screens, not outcomes?	Design Impact Write-Up

06Standards

The quality bar

Every skill in the pack holds the same standard:

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

07FAQ

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.

08Who made this

Lantern, by Polar Bear

These skills were written by Polar Bear, a people ops consultancy that runs its own company on Claude. The pack is free, and the same skills are open on GitHub.

Lantern is Polar Bear's content workspace. It turns your notes, documents and call transcripts into drafts for LinkedIn and other networks. You review them and publish the ones you like.