Always run both
This skill and accessibility-review run together — every time, on every design output, regardless of who requested it. Neither is optional.
Order:
- Generate the design internally
- Run heuristic review (this skill) — fix all violations
- Run accessibility review (
accessibility-review skill) — fix all violations
- Present only the fully resolved output with both review logs appended
When to run this skill
Before presenting any design output, including:
- UI screens or wireframes
- User flows or task flows
- Component designs or specs
- Interaction patterns
- Empty states, error states, onboarding flows
- Forms, modals, confirmations
- Navigation structures
Do NOT wait to be asked. Run this automatically.
Process
- Generate the design output internally (do not show it yet)
- Run heuristic review against all 10 heuristics below — fix every violation
- Run accessibility review (
accessibility-review skill) — fix every WCAG 2.1 AA violation
- Repeat until both reviews pass cleanly
- Present the resolved design output
- Append both review logs — heuristic review first, accessibility review second
Nielsen's 10 Usability Heuristics
H1 — Visibility of System Status
Keep users informed about what is going on through appropriate feedback within reasonable time.
Check for:
- Does the user know where they are in the system?
- Is there feedback for every action (loading states, success, failure)?
- Are progress indicators shown for multi-step flows?
- Is the current state of any element (selected, active, disabled, loading) clearly communicated?
Fix violations by:
- Adding status labels, progress indicators, or state changes
- Making selected/active states visually distinct
- Adding loading skeletons or spinners where async actions occur
- Surfacing confirmation of completed actions
H2 — Match Between System and the Real World
Use words, phrases, and concepts familiar to the user. Follow real-world conventions.
Check for:
- Is any language technical, internal, or jargon-heavy?
- Do metaphors or icons match their real-world meaning?
- Is the information order logical and natural (not system-logic order)?
- Do labels match what users would call things?
Fix violations by:
- Replacing technical terms with plain language
- Using familiar metaphors (folder, inbox, trash)
- Reordering information to match natural reading and task flow
- Renaming labels to match user vocabulary
H3 — User Control and Freedom
Users often take wrong actions. Provide clearly marked emergency exits without extended dialogue.
Check for:
- Can users undo or redo actions?
- Is there a clear way to cancel or exit every flow?
- Are destructive actions reversible, or at least confirmed?
- Can users recover from mistakes without losing their work?
Fix violations by:
- Adding undo/redo where relevant
- Adding cancel buttons to every modal, form, and multi-step flow
- Moving destructive actions away from common actions
- Adding confirmation dialogs for irreversible actions
- Auto-saving where appropriate
H4 — Consistency and Standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Check for:
- Are the same actions labeled consistently throughout?
- Do similar components behave the same way everywhere?
- Does the design follow platform conventions (e.g. primary button on the right)?
- Are visual patterns consistent (same spacing, same hierarchy for similar content)?
Fix violations by:
- Aligning labels across all instances of the same action
- Making similar components behave identically
- Correcting deviations from established platform or design system patterns
- Fixing visual inconsistencies in spacing, color, or hierarchy
H5 — Error Prevention
Design carefully to prevent problems from occurring in the first place.
Check for:
- Can users submit invalid data without warning?
- Are irreversible or high-risk actions too easy to trigger?
- Are there ambiguous options that could lead to the wrong choice?
- Are required fields, formats, or constraints clearly communicated upfront?
Fix violations by:
- Adding inline validation before submission
- Showing format hints on form fields (e.g. "DD/MM/YYYY")
- Moving destructive actions behind confirmation or requiring deliberate input
- Disabling actions that aren't yet valid rather than letting them fail
- Distinguishing between similar options visually and in copy
H6 — Recognition Rather Than Recall
Minimize memory load. Make objects, actions, and options visible. Users should not have to remember information from one part to use in another.
Check for:
- Do users need to remember information from a previous screen to proceed?
- Are actions and options visible rather than hidden in menus or requiring recall?
- Are recently used items, defaults, or suggestions surfaced?
- Do forms and flows pre-fill known information?
Fix violations by:
- Surfacing relevant context inline (e.g. showing the item being deleted in the confirmation)
- Adding visible labels to icons
- Pre-filling known user data in forms
- Showing breadcrumbs or step summaries in multi-step flows
- Making options visible rather than requiring users to remember commands
H7 — Flexibility and Efficiency of Use
Allow accelerators for expert users while keeping the interface accessible for novices.
Check for:
- Is the flow optimised for first-time users only, ignoring frequent users?
- Are there keyboard shortcuts or quick actions for power users?
- Can frequent tasks be reached in fewer steps?
- Are defaults set to the most common use case?
Fix violations by:
- Setting smart defaults that work for most users
- Offering shortcuts for frequent actions without cluttering the main UI
- Reducing steps for common tasks
- Adding bulk actions where users regularly act on multiple items
H8 — Aesthetic and Minimalist Design
Interfaces should not contain irrelevant or rarely needed information. Every extra unit of information competes with relevant information.
Check for:
- Is any element present that doesn't serve the current task?
- Is there visual noise — unnecessary decoration, too many competing elements?
- Is the hierarchy clear — does the most important thing feel most important?
- Is any copy redundant or overly explained?
Fix violations by:
- Removing decorative elements that don't carry meaning
- Reducing the number of competing calls to action
- Simplifying copy — cut anything that doesn't add information
- Using visual weight to establish clear hierarchy
- Moving secondary information to progressive disclosure (tooltips, expandable sections)
H9 — Help Users Recognize, Diagnose, and Recover from Errors
Error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution.
Check for:
- Are error messages written in plain language (not error codes)?
- Do they explain what went wrong?
- Do they tell the user what to do next?
- Are errors shown close to where the problem occurred?
Fix violations by:
- Rewriting error messages: [what happened] + [why] + [what to do]
- ✅ "Incorrect password. Check your password and try again, or reset it."
- 🚫 "Authentication error (code 401)"
- Moving error messages inline, next to the relevant field
- Adding recovery actions directly in the error state (e.g. "Reset password" button)
- Using appropriate visual severity (warning vs. error vs. info)
H10 — Help and Documentation
Even though it's better if the system can be used without documentation, it may be necessary to provide help. Such information should be easy to search, focused on the task, list concrete steps, and not be too large.
Check for:
- Are complex features or first-time experiences self-explanatory?
- Is help available in context (tooltips, inline hints) rather than only in a separate help centre?
- Are empty states instructional — do they tell users what to do first?
- Is onboarding provided for new users or new features?
Fix violations by:
- Adding inline help text or tooltips to complex inputs
- Making empty states instructional ("No pipelines yet. Create your first pipeline.")
- Adding onboarding hints or coach marks for new workflows
- Linking to documentation contextually, not just globally
Output Format
Present the final, resolved design first. Then append:
Heuristic Review
| # |
Heuristic |
Finding |
Fix applied |
| H1 |
Visibility of system status |
[what was missing] |
[what was added] |
| H4 |
Consistency and standards |
[what was inconsistent] |
[how it was resolved] |
Only list heuristics where violations were found. If none were found for a heuristic, omit it.
If no violations were found at all, write: "No heuristic violations found."
1---2name: design-critique3description: Run this automatically before presenting ANY design output — UI screens, flows, components, wireframes, copy+layout combinations, or interaction specs. Review the planned design against Nielsen's 10 Usability Heuristics, fix all violations internally, then present only the resolved output. The person who requested the design should never see a version with heuristic violations.4---56## Always run both78This skill and `accessibility-review` run together — every time, on every design output, regardless of who requested it. Neither is optional.910**Order:**111. Generate the design internally122. Run heuristic review (this skill) — fix all violations133. Run accessibility review (`accessibility-review` skill) — fix all violations144. Present only the fully resolved output with both review logs appended1516---1718## When to run this skill1920Before presenting any design output, including:21- UI screens or wireframes22- User flows or task flows23- Component designs or specs24- Interaction patterns25- Empty states, error states, onboarding flows26- Forms, modals, confirmations27- Navigation structures2829Do NOT wait to be asked. Run this automatically.3031---3233## Process34351. **Generate** the design output internally (do not show it yet)362. **Run heuristic review** against all 10 heuristics below — fix every violation373. **Run accessibility review** (`accessibility-review` skill) — fix every WCAG 2.1 AA violation384. **Repeat** until both reviews pass cleanly395. **Present** the resolved design output406. **Append** both review logs — heuristic review first, accessibility review second4142---4344## Nielsen's 10 Usability Heuristics4546### H1 — Visibility of System Status47Keep users informed about what is going on through appropriate feedback within reasonable time.4849**Check for:**50- Does the user know where they are in the system?51- Is there feedback for every action (loading states, success, failure)?52- Are progress indicators shown for multi-step flows?53- Is the current state of any element (selected, active, disabled, loading) clearly communicated?5455**Fix violations by:**56- Adding status labels, progress indicators, or state changes57- Making selected/active states visually distinct58- Adding loading skeletons or spinners where async actions occur59- Surfacing confirmation of completed actions6061---6263### H2 — Match Between System and the Real World64Use words, phrases, and concepts familiar to the user. Follow real-world conventions.6566**Check for:**67- Is any language technical, internal, or jargon-heavy?68- Do metaphors or icons match their real-world meaning?69- Is the information order logical and natural (not system-logic order)?70- Do labels match what users would call things?7172**Fix violations by:**73- Replacing technical terms with plain language74- Using familiar metaphors (folder, inbox, trash)75- Reordering information to match natural reading and task flow76- Renaming labels to match user vocabulary7778---7980### H3 — User Control and Freedom81Users often take wrong actions. Provide clearly marked emergency exits without extended dialogue.8283**Check for:**84- Can users undo or redo actions?85- Is there a clear way to cancel or exit every flow?86- Are destructive actions reversible, or at least confirmed?87- Can users recover from mistakes without losing their work?8889**Fix violations by:**90- Adding undo/redo where relevant91- Adding cancel buttons to every modal, form, and multi-step flow92- Moving destructive actions away from common actions93- Adding confirmation dialogs for irreversible actions94- Auto-saving where appropriate9596---9798### H4 — Consistency and Standards99Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.100101**Check for:**102- Are the same actions labeled consistently throughout?103- Do similar components behave the same way everywhere?104- Does the design follow platform conventions (e.g. primary button on the right)?105- Are visual patterns consistent (same spacing, same hierarchy for similar content)?106107**Fix violations by:**108- Aligning labels across all instances of the same action109- Making similar components behave identically110- Correcting deviations from established platform or design system patterns111- Fixing visual inconsistencies in spacing, color, or hierarchy112113---114115### H5 — Error Prevention116Design carefully to prevent problems from occurring in the first place.117118**Check for:**119- Can users submit invalid data without warning?120- Are irreversible or high-risk actions too easy to trigger?121- Are there ambiguous options that could lead to the wrong choice?122- Are required fields, formats, or constraints clearly communicated upfront?123124**Fix violations by:**125- Adding inline validation before submission126- Showing format hints on form fields (e.g. "DD/MM/YYYY")127- Moving destructive actions behind confirmation or requiring deliberate input128- Disabling actions that aren't yet valid rather than letting them fail129- Distinguishing between similar options visually and in copy130131---132133### H6 — Recognition Rather Than Recall134Minimize memory load. Make objects, actions, and options visible. Users should not have to remember information from one part to use in another.135136**Check for:**137- Do users need to remember information from a previous screen to proceed?138- Are actions and options visible rather than hidden in menus or requiring recall?139- Are recently used items, defaults, or suggestions surfaced?140- Do forms and flows pre-fill known information?141142**Fix violations by:**143- Surfacing relevant context inline (e.g. showing the item being deleted in the confirmation)144- Adding visible labels to icons145- Pre-filling known user data in forms146- Showing breadcrumbs or step summaries in multi-step flows147- Making options visible rather than requiring users to remember commands148149---150151### H7 — Flexibility and Efficiency of Use152Allow accelerators for expert users while keeping the interface accessible for novices.153154**Check for:**155- Is the flow optimised for first-time users only, ignoring frequent users?156- Are there keyboard shortcuts or quick actions for power users?157- Can frequent tasks be reached in fewer steps?158- Are defaults set to the most common use case?159160**Fix violations by:**161- Setting smart defaults that work for most users162- Offering shortcuts for frequent actions without cluttering the main UI163- Reducing steps for common tasks164- Adding bulk actions where users regularly act on multiple items165166---167168### H8 — Aesthetic and Minimalist Design169Interfaces should not contain irrelevant or rarely needed information. Every extra unit of information competes with relevant information.170171**Check for:**172- Is any element present that doesn't serve the current task?173- Is there visual noise — unnecessary decoration, too many competing elements?174- Is the hierarchy clear — does the most important thing feel most important?175- Is any copy redundant or overly explained?176177**Fix violations by:**178- Removing decorative elements that don't carry meaning179- Reducing the number of competing calls to action180- Simplifying copy — cut anything that doesn't add information181- Using visual weight to establish clear hierarchy182- Moving secondary information to progressive disclosure (tooltips, expandable sections)183184---185186### H9 — Help Users Recognize, Diagnose, and Recover from Errors187Error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution.188189**Check for:**190- Are error messages written in plain language (not error codes)?191- Do they explain what went wrong?192- Do they tell the user what to do next?193- Are errors shown close to where the problem occurred?194195**Fix violations by:**196- Rewriting error messages: [what happened] + [why] + [what to do]197 - ✅ "Incorrect password. Check your password and try again, or reset it."198 - 🚫 "Authentication error (code 401)"199- Moving error messages inline, next to the relevant field200- Adding recovery actions directly in the error state (e.g. "Reset password" button)201- Using appropriate visual severity (warning vs. error vs. info)202203---204205### H10 — Help and Documentation206Even though it's better if the system can be used without documentation, it may be necessary to provide help. Such information should be easy to search, focused on the task, list concrete steps, and not be too large.207208**Check for:**209- Are complex features or first-time experiences self-explanatory?210- Is help available in context (tooltips, inline hints) rather than only in a separate help centre?211- Are empty states instructional — do they tell users what to do first?212- Is onboarding provided for new users or new features?213214**Fix violations by:**215- Adding inline help text or tooltips to complex inputs216- Making empty states instructional ("No pipelines yet. Create your first pipeline.")217- Adding onboarding hints or coach marks for new workflows218- Linking to documentation contextually, not just globally219220---221222## Output Format223224Present the final, resolved design first. Then append:225226---227**Heuristic Review**228229| # | Heuristic | Finding | Fix applied |230|---|---|---|---|231| H1 | Visibility of system status | [what was missing] | [what was added] |232| H4 | Consistency and standards | [what was inconsistent] | [how it was resolved] |233234Only list heuristics where violations were found. If none were found for a heuristic, omit it.235If no violations were found at all, write: "No heuristic violations found."