Figma User Flow Planner Skill

Plan user flows and screen states for a Figma design before any designing starts.

Figma User Flow Planner Skill — The Skill Playground: pick the Executive Update skill, fill in a few notes, hit run, and watch a structured executive… (from the mohitagw15856/pm-claude-skills README)

From the mohitagw15856/pm-claude-skills README — shows the whole collection, not only this skill. · view on GitHub

How to use it

Claude Code
  1. Run the line below. It pulls the whole folder into ~/.claude/skills/figma-user-flow-planner.
  2. 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-planner

For one project only, change the path to .claude/skills/figma-user-flow-planner.

Claude (web or desktop app)
  1. On this page open ⋯ → Download .md.
  2. Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
  3. Pick the file and Save. Claude shows the name and description and runs a security scan.
  4. Check the skill is switched on.
  5. Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
  1. ChatGPT: make a Project and paste it into Instructions.
  2. 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.
Step-by-step guide with screenshots · Ask in the forum

Paste into Claude, ChatGPT or Cursor.

Source of Figma User Flow Planner Skill

Show the full text84 lines
namedescription
figma-user-flow-plannerPlan 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---
2name: figma-user-flow-planner
3description: "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 
8Plans 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
21Feature, 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 
29Screen 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```
51Feature 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

Alternatives

Also in Interface designSee all 106 in Design →
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.Design & UI · Apache-2.0ImpeccableUse 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.Design & UI · Apache-2.0Apple 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.Design & UI · MITBuilding 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.Design & UI · MIT