User flows and guided paths
Skill dembrandt/dembrandt-skills/skills/user-flows-and-guided-paths
Senior-level UX and design-system knowledge, packaged so your AI agent applies it automatically.
npx -y skills add dembrandt/dembrandt-skills --skill user-flows-and-guided-pathsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Related features and tasks — such as purchase flows, onboarding, or multi-step configuration — should be designed as natural, guided paths that feel coherent and fit the product hierarchy. Use wizards for complex sequential tasks. Use when designing flows, onboarding, checkout, setup sequences, or any multi-step user journey.
SKILL.md
5.2 KB, 856 tokens by cl100k_base, as published. Nobody here has run it
User Flows and Guided Paths
Related features that belong together should be experienced as a single coherent journey — not as separate screens the user has to navigate between manually. A well-designed flow feels inevitable: each step leads naturally to the next, the user always knows where they are and what comes next, and the path fits the product's information hierarchy.
When to Guide vs. When to Let Users Explore
| Scenario | Pattern |
|---|---|
| Linear process with a clear end goal (checkout, signup, setup) | Guided step-by-step flow or wizard |
| Complex task that benefits from breaking into stages | Wizard with progress indicator |
| Feature discovery across an existing product | Contextual tooltips or coach marks |
| User returning to complete something they started | Resume prompt with clear re-entry point |
| Open-ended exploration (dashboard, settings) | Free navigation — do not force a flow |
Only guide when the task genuinely has a natural order. Forcing a wizard onto a non-sequential task frustrates users who already know what they want.
The Wizard Pattern
Use a wizard when:
- The task has 3 or more sequential steps
- Later steps depend on decisions made in earlier steps
- Doing all steps on one screen would overwhelm the user
Wizard anatomy
[Step indicator: 1 of 4]
Step title
[Form content for this step]
[Back] [Continue →]
Step indicator: Always show the user where they are in the sequence and how many steps remain. A progress bar or numbered steps both work — numbered steps are clearer when step names are meaningful.
Back navigation: Always available. Users must be able to go back and change earlier decisions without losing their progress on later steps.
Forward navigation: Disabled until the current step is complete. Validate on Continue, not on Submit at the end.
Exit path: Make it clear how to abandon the flow without losing partial progress. Autosave drafts where possible.
Step design principles
- One primary decision or input group per step — don't overfill steps
- Step titles should describe the user's goal, not the system's: "Your delivery address" not "Address input"
- Optional steps should be clearly marked and skippable
- The final step should show a summary before committing
Purchase and Conversion Flows
Purchase flows have an additional constraint: every unnecessary step reduces conversion. Design for the shortest path to completion.
- Collect only what is required at each stage — defer optional information
- Show a persistent order summary so the user always sees what they are buying
- Surface trust signals near payment steps (security badges, return policy)
- Confirmation step before payment: show total, delivery, items — one last review
- Post-purchase: immediate confirmation with clear next steps ("Your order is confirmed. We'll email you when it ships.")
Fitting Flows into the Product Hierarchy
A guided path should feel like it belongs to the product — not like it has opened a separate experience.
- The visual style, typography, and components inside a flow should match the rest of the product
- Navigation chrome (sidebar, top nav) can be hidden during a flow to reduce distraction, but the brand header should remain visible
- After completing a flow, return the user to a meaningful place in the hierarchy — not to a generic home screen
- Deep-linking into a flow should work: a user who arrives at step 3 via email link should see step 3, not step 1
Review Checklist
- Does the flow have a clear start, a logical step order, and a definite end?
- Is a progress indicator visible at every step?
- Can the user go back to any previous step without losing later progress?
- Is each step focused on one decision or input group?
- Are step titles written in user language, describing their goal?
- Does the final step show a summary before the irreversible action?
- After completion, does the user land somewhere meaningful in the product?
- Does the flow visual style match the rest of the product?
Gives 0 of the 12 instructions most project setup skills give in 856 tokens
Counted across 999 of the 1,637 authors here whose files we hold, read 2026-08-06
- ask one question at a timein 29 of 999, across 28 files
- detect the package manager from lockfilesin 28 of 999, across 9 files
- present findings to the userin 25 of 999, across 4 files
- explore current repo statein 24 of 999, across 3 files
- update the agent skills block in place if it existsin 24 of 999, across 3 files
- install husky lint-staged and prettierin 23 of 999, across 4 files
- create the lintstagedrc filein 22 of 999, across 3 files
- commit all changed filesin 22 of 999, across 3 files
- run lint-staged to verify it worksin 22 of 999, across 3 files
- initialize huskyin 21 of 999, across 2 files
- create the husky pre-commit filein 21 of 999, across 2 files
- create a prettierrc file if missingin 21 of 999, across 2 files
Said here and by no other author read
- use wizards for complex sequential tasks
- show the user current step position and remaining steps
- enable back navigation without losing later progress
- disable forward navigation until the current step is complete
- validate input on continue not final submit
- show a summary before the final irreversible action
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.