Figma User Flow Planner Skill
Plan user flows and screen states for a Figma design before any designing starts.
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/figma-user-flow-planner. - Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit mohitagw15856/pm-claude-skills/skills/figma-user-flow-planner#main ~/.claude/skills/figma-user-flow-plannerFor one project only, change the path to .claude/skills/figma-user-flow-planner.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Source of Figma User Flow Planner Skill
Show the full text84 lines
| name | description |
|---|---|
| figma-user-flow-planner | Plan user flows and screen states for a Figma design before any designing starts. Use when asked to plan a user flow, map out screens for a feature, define screen states, plan a Figma file structure, or work out what needs to be designed before opening Figma. Produces a complete flow map with all screens, states, entry/exit points, and a suggested Figma page structure. |
Figma User Flow Planner Skill
Plans what needs to be designed before a pixel is touched — mapping all screens, states, entry points, and edge cases so designers do not discover missing states mid-build.
Required Inputs
- Feature or task being designed
- User type (who performs this flow?)
- Platform (iOS / Android / Web / Multi-platform)
- Starting point (where does the user begin?)
- Known edge cases (optional)
Output Structure
1. Flow Overview
Feature, user, goal, entry points, success exit, failure exits.
2. Screen Map
| # | Screen name | Type | Triggered by | Notes |
|---|---|---|---|---|
| 1 | [Screen] | New/Modal/Drawer/Toast | [What triggers] | [Considerations] |
Screen types to cover: entry, happy path, loading, success, error (network/validation/permission), empty, first-time/onboarding, edge cases.
3. State Matrix
[Screen name]
| State | Trigger | Visual change | Action available |
|---|---|---|---|
| Default | Page load | [Description] | [What user can do] |
| Loading | User taps action | Skeleton/spinner | None |
| Error | API failure | Error message | Retry/Go back |
| Empty | No data | Empty state | [CTA] |
4. Decision Points
Decision: [Name]
- If yes: [Screen N]
- If no: [Screen X]
5. Suggested Figma File Structure
Feature name/
- Cover
- Flow Map
- Happy Path
- Error States
- Empty States
- Edge Cases
- Handoff
6. What Not to Design Yet
[Explicit out-of-scope items — prevents scope creep]
Quality Checks
- All three state types covered: loading, error, empty
- All decision points mapped with both branches
- Entry points include all realistic user paths
- Out-of-scope section is explicit
- Figma file structure matches screen map
Anti-Patterns
- Do not plan only the happy path — all error states, empty states, and edge cases must be mapped before designing starts
- Do not produce a flow map that doesn't match the Figma file structure — the page structure must reflect the flow map
- Do not define screens without specifying all required states — a screen without its variants is an incomplete design scope
- Do not start designing before entry and exit points are fully documented — unclear boundaries cause scope creep
- Do not plan user flows without tying each step back to a user goal — every screen must justify its existence
Example Trigger Phrases
- "Plan the user flow for [feature] in Figma"
- "What screens do I need to design for [feature]?"
- "Map out the states for [feature] before we start designing"
- "Help me structure my Figma file for [feature]"
- "What do we need to design before handing this to the developer?"
| 1 | |
| 2 | name figma-user-flow-planner |
| 3 | description "Plan user flows and screen states for a Figma design before any designing starts. Use when asked to plan a user flow, map out screens for a feature, define screen states, plan a Figma file structure, or work out what needs to be designed before opening Figma. Produces a complete flow map with all screens, states, entry/exit points, and a suggested Figma page structure." |
| 4 | |
| 5 | |
| 6 | # Figma User Flow Planner Skill |
| 7 | |
| 8 | Plans what needs to be designed before a pixel is touched — mapping all screens, states, entry points, and edge cases so designers do not discover missing states mid-build. |
| 9 | |
| 10 | ## Required Inputs |
| 11 | |
| 12 | **Feature or task being designed** |
| 13 | **User type** (who performs this flow?) |
| 14 | **Platform** (iOS / Android / Web / Multi-platform) |
| 15 | **Starting point** (where does the user begin?) |
| 16 | **Known edge cases** (optional) |
| 17 | |
| 18 | ## Output Structure |
| 19 | |
| 20 | ### 1. Flow Overview |
| 21 | Feature, user, goal, entry points, success exit, failure exits. |
| 22 | |
| 23 | ### 2. Screen Map |
| 24 | |
| 25 | | # | Screen name | Type | Triggered by | Notes | |
| 26 | |---|---|---|---|---| |
| 27 | | 1 | [Screen] | New/Modal/Drawer/Toast | [What triggers] | [Considerations] | |
| 28 | |
| 29 | Screen types to cover: entry, happy path, loading, success, error (network/validation/permission), empty, first-time/onboarding, edge cases. |
| 30 | |
| 31 | ### 3. State Matrix |
| 32 | |
| 33 | **[Screen name]** |
| 34 | |
| 35 | | State | Trigger | Visual change | Action available | |
| 36 | |---|---|---|---| |
| 37 | | Default | Page load | [Description] | [What user can do] | |
| 38 | | Loading | User taps action | Skeleton/spinner | None | |
| 39 | | Error | API failure | Error message | Retry/Go back | |
| 40 | | Empty | No data | Empty state | [CTA] | |
| 41 | |
| 42 | ### 4. Decision Points |
| 43 | |
| 44 | **Decision: [Name]** |
| 45 | If yes: [Screen N] |
| 46 | If no: [Screen X] |
| 47 | |
| 48 | ### 5. Suggested Figma File Structure |
| 49 | |
| 50 | |
| 51 | Feature name/ |
| 52 | - Cover |
| 53 | - Flow Map |
| 54 | - Happy Path |
| 55 | - Error States |
| 56 | - Empty States |
| 57 | - Edge Cases |
| 58 | - Handoff |
| 59 | |
| 60 | |
| 61 | ### 6. What Not to Design Yet |
| 62 | [Explicit out-of-scope items — prevents scope creep] |
| 63 | |
| 64 | ## Quality Checks |
| 65 | [ ] All three state types covered: loading, error, empty |
| 66 | [ ] All decision points mapped with both branches |
| 67 | [ ] Entry points include all realistic user paths |
| 68 | [ ] Out-of-scope section is explicit |
| 69 | [ ] Figma file structure matches screen map |
| 70 | |
| 71 | ## Anti-Patterns |
| 72 | |
| 73 | [ ] Do not plan only the happy path — all error states, empty states, and edge cases must be mapped before designing starts |
| 74 | [ ] Do not produce a flow map that doesn't match the Figma file structure — the page structure must reflect the flow map |
| 75 | [ ] Do not define screens without specifying all required states — a screen without its variants is an incomplete design scope |
| 76 | [ ] Do not start designing before entry and exit points are fully documented — unclear boundaries cause scope creep |
| 77 | [ ] Do not plan user flows without tying each step back to a user goal — every screen must justify its existence |
| 78 | |
| 79 | ## Example Trigger Phrases |
| 80 | "Plan the user flow for [feature] in Figma" |
| 81 | "What screens do I need to design for [feature]?" |
| 82 | "Map out the states for [feature] before we start designing" |
| 83 | "Help me structure my Figma file for [feature]" |
| 84 | "What do we need to design before handing this to the developer?" |
Discussion
Frontend designGuidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.ImpeccableUse when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks.Apple designApple's approach to interface design and fluid, physical motion, translated for the web. Use when building or reviewing gesture-driven UI, spring animations, drag/swipe/sheet interactions, momentum and interruptible transitions, translucent materials and depth, typography (optical sizing, tracking, leading), reduced-motion, or the design foundations (feedback, spatial consistency, restraint) behind Apple-style interfaces.Building AnimationsBuild an animation from scratch, making the decisions in the order that determines whether it feels right — should it animate at all, what purpose, which tool, which properties, which curve and duration, how it interrupts, how it exits. Writes the implementation. Use when asked to animate something, add motion, make a component feel alive, or build a transition. For critiquing existing motion use review-animations; for auditing a whole codebase use improve-animations.
Browse more free Claude skills or everything in Design.


