nielsen-usability-heuristics

Name: nielsen-usability-heuristics
Author: dembrandt

308installs5forks

How to install nielsen-usability-heuristics?

dembrandt/dembrandt-skills/nielsen-usability-heuristics

$npx -y skills add dembrandt/dembrandt-skills --skill nielsen-usability-heuristics

Installs into the current project.

Summary

UI design and review should apply Nielsen's 10 Usability Heuristics — the foundational principles for evaluating and improving usability. Use when auditing an interface, designing interaction flows, writing error messages, or reviewing any UI for usability issues.

Files · 1

View on GitHub

SKILL.md

1	# Nielsen's 10 Usability Heuristics
2
3	Foundational principles for evaluating and designing usable interfaces. Apply these as a review checklist and as design constraints from the start — not only as a post-hoc audit tool.
4
5	---
6
7	## 1. Visibility of System Status
8
9	The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.
10
11	Users cannot make good decisions without knowing the current state of the system. Trust is built through clear, timely feedback.
12
13	In practice:
14	- Show loading states, progress indicators, and completion confirmations
15	- Indicate where the user is in a multi-step process
16	- Reflect state changes immediately (optimistic UI or loading spinners)
17	- Never leave a user wondering whether an action was registered
18
19	Review question: After any user action, is the outcome visible within 1 second?
20
21	---
22
23	## 2. Match Between System and Real World
24
25	The design should speak the users' language — words, phrases, and concepts familiar to the user, not internal jargon or system terminology.
26
27	Follow real-world conventions and natural mapping so the interface feels intuitive rather than requiring translation.
28
29	In practice:
30	- Use terminology the target audience uses, not what the engineering team uses
31	- Icons should match real-world objects or widely established web conventions
32	- Spatial metaphors should match real-world expectations (e.g. "trash" for deletion)
33	- Avoid exposing internal system concepts (IDs, error codes, process names) to end users
34
35	Review question: Would a user unfamiliar with this product understand every label and term?
36
37	---
38
39	## 3. User Control and Freedom
40
41	Users often perform actions by mistake. They need a clearly marked emergency exit to leave an unwanted state without going through an extended process.
42
43	Easy undo and escape paths foster confidence and prevent users from feeling trapped.
44
45	In practice:
46	- Always provide Undo for destructive or irreversible actions
47	- Modals and dialogs need an obvious close/cancel action
48	- Multi-step flows need a way to go back
49	- Destructive actions (delete, publish, send) should be reversible where possible — or require explicit confirmation
50
51	Review question: Can the user get out of any state without losing their work or needing to contact support?
52
53	---
54
55	## 4. Consistency and Standards
56
57	Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.
58
59	Consistency reduces cognitive load by meeting expectations users have built from other products.
60
61	In practice:
62	- Use the same label for the same action across the entire product
63	- Follow platform conventions (e.g. left-swipe to delete on mobile, Cmd+Z for undo)
64	- Design system components should look and behave identically everywhere they appear
65	- Do not rename standard web patterns (e.g. calling a "breadcrumb" a "path trail")
66
67	Review question: Does the same action always look and behave the same way throughout the product?
68
69	---
70
71	## 5. Error Prevention
72
73	Good error messages matter, but the best designs prevent errors from occurring in the first place.
74
75	Prevention addresses both slips (unintentional actions) and mistakes (misunderstanding of design intent).
76
77	In practice:
78	- Use constraints to make wrong inputs impossible (e.g. disable a Submit button until required fields are complete)
79	- Confirm before destructive or irreversible actions
80	- Use input masks, validation, and sensible defaults to guide correct input
81	- Design forms so the happy path is the obvious path
82
83	Review question: For every destructive or irreversible action, is there a confirmation step or an undo path?
84
85	---
86
87	## 6. Recognition Rather Than Recall
88
89	Minimi

People who liked this also viewed

6 picks

Type

nielsen-usability-heuristics

308installs5forks

View on GitHub

How to install nielsen-usability-heuristics?

dembrandt/dembrandt-skills/nielsen-usability-heuristics

$npx -y skills add dembrandt/dembrandt-skills --skill nielsen-usability-heuristics

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Nielsen's 10 Usability Heuristics
2
3	Foundational principles for evaluating and designing usable interfaces. Apply these as a review checklist and as design constraints from the start — not only as a post-hoc audit tool.
4
5	---
6
7	## 1. Visibility of System Status
8
9	The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.
10
11	Users cannot make good decisions without knowing the current state of the system. Trust is built through clear, timely feedback.
12
13	In practice:
14	- Show loading states, progress indicators, and completion confirmations
15	- Indicate where the user is in a multi-step process
16	- Reflect state changes immediately (optimistic UI or loading spinners)
17	- Never leave a user wondering whether an action was registered
18
19	Review question: After any user action, is the outcome visible within 1 second?
20
21	---
22
23	## 2. Match Between System and Real World
24
25	The design should speak the users' language — words, phrases, and concepts familiar to the user, not internal jargon or system terminology.
26
27	Follow real-world conventions and natural mapping so the interface feels intuitive rather than requiring translation.
28
29	In practice:
30	- Use terminology the target audience uses, not what the engineering team uses
31	- Icons should match real-world objects or widely established web conventions
32	- Spatial metaphors should match real-world expectations (e.g. "trash" for deletion)
33	- Avoid exposing internal system concepts (IDs, error codes, process names) to end users
34
35	Review question: Would a user unfamiliar with this product understand every label and term?
36
37	---
38
39	## 3. User Control and Freedom
40
41	Users often perform actions by mistake. They need a clearly marked emergency exit to leave an unwanted state without going through an extended process.
42
43	Easy undo and escape paths foster confidence and prevent users from feeling trapped.
44
45	In practice:
46	- Always provide Undo for destructive or irreversible actions
47	- Modals and dialogs need an obvious close/cancel action
48	- Multi-step flows need a way to go back
49	- Destructive actions (delete, publish, send) should be reversible where possible — or require explicit confirmation
50
51	Review question: Can the user get out of any state without losing their work or needing to contact support?
52
53	---
54
55	## 4. Consistency and Standards
56
57	Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.
58
59	Consistency reduces cognitive load by meeting expectations users have built from other products.
60
61	In practice:
62	- Use the same label for the same action across the entire product
63	- Follow platform conventions (e.g. left-swipe to delete on mobile, Cmd+Z for undo)
64	- Design system components should look and behave identically everywhere they appear
65	- Do not rename standard web patterns (e.g. calling a "breadcrumb" a "path trail")
66
67	Review question: Does the same action always look and behave the same way throughout the product?
68
69	---
70
71	## 5. Error Prevention
72
73	Good error messages matter, but the best designs prevent errors from occurring in the first place.
74
75	Prevention addresses both slips (unintentional actions) and mistakes (misunderstanding of design intent).
76
77	In practice:
78	- Use constraints to make wrong inputs impossible (e.g. disable a Submit button until required fields are complete)
79	- Confirm before destructive or irreversible actions
80	- Use input masks, validation, and sensible defaults to guide correct input
81	- Design forms so the happy path is the obvious path
82
83	Review question: For every destructive or irreversible action, is there a confirmation step or an undo path?
84
85	---
86
87	## 6. Recognition Rather Than Recall
88
89	Minimi

People who liked this also viewed

6 picks

Type