user-flows-and-guided-paths

Name: user-flows-and-guided-paths
Author: dembrandt

283installs5forks

How to install user-flows-and-guided-paths?

dembrandt/dembrandt-skills/user-flows-and-guided-paths

$npx -y skills add dembrandt/dembrandt-skills --skill user-flows-and-guided-paths

Installs into the current project.

Summary

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, s

Files · 1

View on GitHub

SKILL.md

1	# User Flows and Guided Paths
2
3	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.
4
5	## When to Guide vs. When to Let Users Explore
6
7	\| Scenario \| Pattern \|
8	\|---\|---\|
9	\| Linear process with a clear end goal (checkout, signup, setup) \| Guided step-by-step flow or wizard \|
10	\| Complex task that benefits from breaking into stages \| Wizard with progress indicator \|
11	\| Feature discovery across an existing product \| Contextual tooltips or coach marks \|
12	\| User returning to complete something they started \| Resume prompt with clear re-entry point \|
13	\| Open-ended exploration (dashboard, settings) \| Free navigation — do not force a flow \|
14
15	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.
16
17	## The Wizard Pattern
18
19	Use a wizard when:
20	- The task has 3 or more sequential steps
21	- Later steps depend on decisions made in earlier steps
22	- Doing all steps on one screen would overwhelm the user
23
24	### Wizard anatomy
25
26	```
27	[Step indicator: 1 of 4]
28
29	Step title
30
31	[Form content for this step]
32
33	[Back] [Continue →]
34	```
35
36	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.
37
38	Back navigation: Always available. Users must be able to go back and change earlier decisions without losing their progress on later steps.
39
40	Forward navigation: Disabled until the current step is complete. Validate on Continue, not on Submit at the end.
41
42	Exit path: Make it clear how to abandon the flow without losing partial progress. Autosave drafts where possible.
43
44	### Step design principles
45	- One primary decision or input group per step — don't overfill steps
46	- Step titles should describe the user's goal, not the system's: "Your delivery address" not "Address input"
47	- Optional steps should be clearly marked and skippable
48	- The final step should show a summary before committing
49
50	## Purchase and Conversion Flows
51
52	Purchase flows have an additional constraint: every unnecessary step reduces conversion. Design for the shortest path to completion.
53
54	- Collect only what is required at each stage — defer optional information
55	- Show a persistent order summary so the user always sees what they are buying
56	- Surface trust signals near payment steps (security badges, return policy)
57	- Confirmation step before payment: show total, delivery, items — one last review
58	- Post-purchase: immediate confirmation with clear next steps ("Your order is confirmed. We'll email you when it ships.")
59
60	## Fitting Flows into the Product Hierarchy
61
62	A guided path should feel like it belongs to the product — not like it has opened a separate experience.
63
64	- The visual style, typography, and components inside a flow should match the rest of the product
65	- Navigation chrome (sidebar, top nav) can be hidden during a flow to reduce distraction, but the brand header should remain visible
66	- After completing a flow, return the user to a meaningful place in the hierarchy — not to a generic home screen
67	- Deep-linking into a flow should work: a user who arrives at step 3 via email link should see step 3, not step 1
68
69	## Review Checklist
70
71	- [ ] Does the flow have a clear start, a logical step order, and a definite end?
72	- [ ] Is a progress indicator visible at every step?
73	- [ ] Can the user go back to any previous step without losing later progress?
74	- [ ] Is each step focused on one decision or i

People who liked this also viewed

6 picks

Type

user-flows-and-guided-paths

283installs5forks

View on GitHub

How to install user-flows-and-guided-paths?

dembrandt/dembrandt-skills/user-flows-and-guided-paths

$npx -y skills add dembrandt/dembrandt-skills --skill user-flows-and-guided-paths

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# User Flows and Guided Paths
2
3	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.
4
5	## When to Guide vs. When to Let Users Explore
6
7	\| Scenario \| Pattern \|
8	\|---\|---\|
9	\| Linear process with a clear end goal (checkout, signup, setup) \| Guided step-by-step flow or wizard \|
10	\| Complex task that benefits from breaking into stages \| Wizard with progress indicator \|
11	\| Feature discovery across an existing product \| Contextual tooltips or coach marks \|
12	\| User returning to complete something they started \| Resume prompt with clear re-entry point \|
13	\| Open-ended exploration (dashboard, settings) \| Free navigation — do not force a flow \|
14
15	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.
16
17	## The Wizard Pattern
18
19	Use a wizard when:
20	- The task has 3 or more sequential steps
21	- Later steps depend on decisions made in earlier steps
22	- Doing all steps on one screen would overwhelm the user
23
24	### Wizard anatomy
25
26	```
27	[Step indicator: 1 of 4]
28
29	Step title
30
31	[Form content for this step]
32
33	[Back] [Continue →]
34	```
35
36	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.
37
38	Back navigation: Always available. Users must be able to go back and change earlier decisions without losing their progress on later steps.
39
40	Forward navigation: Disabled until the current step is complete. Validate on Continue, not on Submit at the end.
41
42	Exit path: Make it clear how to abandon the flow without losing partial progress. Autosave drafts where possible.
43
44	### Step design principles
45	- One primary decision or input group per step — don't overfill steps
46	- Step titles should describe the user's goal, not the system's: "Your delivery address" not "Address input"
47	- Optional steps should be clearly marked and skippable
48	- The final step should show a summary before committing
49
50	## Purchase and Conversion Flows
51
52	Purchase flows have an additional constraint: every unnecessary step reduces conversion. Design for the shortest path to completion.
53
54	- Collect only what is required at each stage — defer optional information
55	- Show a persistent order summary so the user always sees what they are buying
56	- Surface trust signals near payment steps (security badges, return policy)
57	- Confirmation step before payment: show total, delivery, items — one last review
58	- Post-purchase: immediate confirmation with clear next steps ("Your order is confirmed. We'll email you when it ships.")
59
60	## Fitting Flows into the Product Hierarchy
61
62	A guided path should feel like it belongs to the product — not like it has opened a separate experience.
63
64	- The visual style, typography, and components inside a flow should match the rest of the product
65	- Navigation chrome (sidebar, top nav) can be hidden during a flow to reduce distraction, but the brand header should remain visible
66	- After completing a flow, return the user to a meaningful place in the hierarchy — not to a generic home screen
67	- Deep-linking into a flow should work: a user who arrives at step 3 via email link should see step 3, not step 1
68
69	## Review Checklist
70
71	- [ ] Does the flow have a clear start, a logical step order, and a definite end?
72	- [ ] Is a progress indicator visible at every step?
73	- [ ] Can the user go back to any previous step without losing later progress?
74	- [ ] Is each step focused on one decision or i

People who liked this also viewed

6 picks

Type