ux-design

Name: ux-design
Author: f0d010c

19stars0forks

How to install ux-design?

f0d010c/stark/ux-design

$npx -y skills add f0d010c/stark --skill ux-design

Installs into the current project.

Summary

Use when the user asks for UX, product flow, user journey, wireframes, usability, conversion, onboarding, checkout, signup, navigation, forms, state design, dashboard workflows, command palettes, settings, permissions, long-running task progress, admin/internal tools, activation,

Files · 1

View on GitHub

SKILL.md

1	# ux-design - product flow before pixels
2
3	Use this skill when the product has to be understandable and usable, not just attractive. The output should make the user path clearer, reduce unnecessary decisions, and define states that survive real use.
4
5	## What This Skill Can Do
6
7	- Map core user journeys, task paths, branching flows, and recovery paths.
8	- Define information architecture, navigation, labels, content groups, and page/screen inventory.
9	- Design onboarding, activation, checkout, signup, forms, settings, dashboards, command palettes, and internal workflows.
10	- Specify empty, loading, error, permission, success, stale, retry, resume, and audit states.
11	- Audit an existing UI for usability, hierarchy, conversion, repeated-use friction, accessibility risks, and missing states.
12	- Hand a compact UX decision brief to platform skills so visual design does not erase the product job.
13
14	## Step 1 - Identify the job and user mode
15
16	Before designing screens, state the smallest useful context:
17
18	- Primary job: what the user is trying to finish.
19	- User mode: first-time, returning, power user, admin, buyer, creator, operator, or support.
20	- Frequency: one-time, occasional, daily, or high-volume repeated use.
21	- Risk: low-risk browse, reversible edit, money/data/security impact, or destructive action.
22
23	If any of these are unclear and materially affect the flow, ask one short question. If the answer is easy to infer from the request, infer it and continue.
24
25	Do not interrogate the user with a product-strategy questionnaire before helping. The skill should make useful assumptions, name them briefly, and move.
26
27	## Step 2 - Map the flow
28
29	Write the minimum useful path:
30
31	1. Entry point
32	2. First meaningful action
33	3. Required decision
34	4. Feedback after action
35	5. Success state
36	6. Recovery path when something fails
37
38	Prefer fewer screens when the user is trying to finish one job. Prefer separate steps when the user is making risky, costly, or hard-to-reverse decisions.
39
40	## Step 2.5 - Produce the UX decision brief
41
42	Before visual design or code, write a compact brief. Keep it short enough to pass into another skill:
43
44	```md
45	UX decision brief
46	- Job: ...
47	- User mode: ...
48	- Frequency/risk: ...
49	- Pattern: ...
50	- Primary action: ...
51	- Secondary actions: ...
52	- Core path: entry -> action -> feedback -> success
53	- Recovery path: ...
54	- Required states: empty, loading, partial, error, permission, success, long-running
55	- Handoff constraints: ...
56	```
57
58	This brief is the contract. The platform skill may change visual treatment, but it must not erase the chosen job, action hierarchy, state coverage, or recovery path.
59
60	## Step 3 - Design the states
61
62	Every production UI needs these states:
63
64	- Empty: what the user sees before data exists.
65	- Loading: what changes while the system is working.
66	- Partial: some data exists, some is missing.
67	- Error: what failed, why it matters, and the next action.
68	- Permission: what is blocked and how to request access.
69	- Success: what happened and what the user can do next.
70	- Long-running: progress, cancellation, retry, and resume behavior.
71
72	Do not ship only the happy path.
73
74	For public demos and generated proof projects, include at least one non-happy state in the visible UI: an empty state, blocked permission, failed sync, queued job, retry panel, stale data banner, or partial result. This makes the output feel like a real product instead of a polished poster.
75
76	## Step 4 - Reduce cognitive load
77
78	Apply these rules:
79
80	- Put the next action where the user's eye already is.
81	- Use one primary action per surface.
82	- Group by task, not by database object.
83	- Prefer progressive disclosure over dense first screens.
84	- Keep labels concrete: "Invite teammate", not "Manage".
85	- Make defaults safe and visible.
86	- Keep destructive actions separated, confirmed, and undoable when possible.
87	- Make repeated actions faster than first-time actions.
88
89	For high-frequency tools, optimize scan speed, keyboard flow, saved filters, bulk actions, and stable layout. For consumer onboarding, optimize motivation, trust, and the shortest path to first value.
90
91	## Step 4.5 - Match the product type
92
93	Use the product type to decide what "good UX" means:
94
95	\| Product type \| Optimize for \| Avoid \|
96	\|---\|---\|---\|
97	\| SaaS dashboard \| fast scanning, saved filters, drilldowns, clear priority, visible operational

People who liked this also viewed

6 picks

Type

ux-design

19stars0forks

View on GitHub

How to install ux-design?

f0d010c/stark/ux-design

$npx -y skills add f0d010c/stark --skill ux-design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# ux-design - product flow before pixels
2
3	Use this skill when the product has to be understandable and usable, not just attractive. The output should make the user path clearer, reduce unnecessary decisions, and define states that survive real use.
4
5	## What This Skill Can Do
6
7	- Map core user journeys, task paths, branching flows, and recovery paths.
8	- Define information architecture, navigation, labels, content groups, and page/screen inventory.
9	- Design onboarding, activation, checkout, signup, forms, settings, dashboards, command palettes, and internal workflows.
10	- Specify empty, loading, error, permission, success, stale, retry, resume, and audit states.
11	- Audit an existing UI for usability, hierarchy, conversion, repeated-use friction, accessibility risks, and missing states.
12	- Hand a compact UX decision brief to platform skills so visual design does not erase the product job.
13
14	## Step 1 - Identify the job and user mode
15
16	Before designing screens, state the smallest useful context:
17
18	- Primary job: what the user is trying to finish.
19	- User mode: first-time, returning, power user, admin, buyer, creator, operator, or support.
20	- Frequency: one-time, occasional, daily, or high-volume repeated use.
21	- Risk: low-risk browse, reversible edit, money/data/security impact, or destructive action.
22
23	If any of these are unclear and materially affect the flow, ask one short question. If the answer is easy to infer from the request, infer it and continue.
24
25	Do not interrogate the user with a product-strategy questionnaire before helping. The skill should make useful assumptions, name them briefly, and move.
26
27	## Step 2 - Map the flow
28
29	Write the minimum useful path:
30
31	1. Entry point
32	2. First meaningful action
33	3. Required decision
34	4. Feedback after action
35	5. Success state
36	6. Recovery path when something fails
37
38	Prefer fewer screens when the user is trying to finish one job. Prefer separate steps when the user is making risky, costly, or hard-to-reverse decisions.
39
40	## Step 2.5 - Produce the UX decision brief
41
42	Before visual design or code, write a compact brief. Keep it short enough to pass into another skill:
43
44	```md
45	UX decision brief
46	- Job: ...
47	- User mode: ...
48	- Frequency/risk: ...
49	- Pattern: ...
50	- Primary action: ...
51	- Secondary actions: ...
52	- Core path: entry -> action -> feedback -> success
53	- Recovery path: ...
54	- Required states: empty, loading, partial, error, permission, success, long-running
55	- Handoff constraints: ...
56	```
57
58	This brief is the contract. The platform skill may change visual treatment, but it must not erase the chosen job, action hierarchy, state coverage, or recovery path.
59
60	## Step 3 - Design the states
61
62	Every production UI needs these states:
63
64	- Empty: what the user sees before data exists.
65	- Loading: what changes while the system is working.
66	- Partial: some data exists, some is missing.
67	- Error: what failed, why it matters, and the next action.
68	- Permission: what is blocked and how to request access.
69	- Success: what happened and what the user can do next.
70	- Long-running: progress, cancellation, retry, and resume behavior.
71
72	Do not ship only the happy path.
73
74	For public demos and generated proof projects, include at least one non-happy state in the visible UI: an empty state, blocked permission, failed sync, queued job, retry panel, stale data banner, or partial result. This makes the output feel like a real product instead of a polished poster.
75
76	## Step 4 - Reduce cognitive load
77
78	Apply these rules:
79
80	- Put the next action where the user's eye already is.
81	- Use one primary action per surface.
82	- Group by task, not by database object.
83	- Prefer progressive disclosure over dense first screens.
84	- Keep labels concrete: "Invite teammate", not "Manage".
85	- Make defaults safe and visible.
86	- Keep destructive actions separated, confirmed, and undoable when possible.
87	- Make repeated actions faster than first-time actions.
88
89	For high-frequency tools, optimize scan speed, keyboard flow, saved filters, bulk actions, and stable layout. For consumer onboarding, optimize motivation, trust, and the shortest path to first value.
90
91	## Step 4.5 - Match the product type
92
93	Use the product type to decide what "good UX" means:
94
95	\| Product type \| Optimize for \| Avoid \|
96	\|---\|---\|---\|
97	\| SaaS dashboard \| fast scanning, saved filters, drilldowns, clear priority, visible operational

People who liked this also viewed

6 picks

Type