--- name: nielsen-heuristics-audit description: > Conduct a structured usability audit against Jakob Nielsen's 10 Usability Heuristics. Use when the user asks to evaluate usability, run a heuristic evaluation, check UX quality, or audit an interface against Nielsen's principles. Triggers on: "heuristic evaluation", "Nielsen audit", "usability review", "UX audit", "evaluate usability", "check heuristics", "usability problems". Does NOT cover visual design (Refactoring UI) or accessibility (WCAG) — those are separate skills. --- # Nielsen's 10 Heuristics Audit Conduct a structured heuristic evaluation of the target UI files against Jakob Nielsen's 10 Usability Heuristics (Nielsen Norman Group, 1994). Produce a written report organized by heuristic. For each finding: describe the violation, identify the heuristic it breaks, assess severity, and suggest a specific remedy. **Behavior: ANALYZE AND REPORT ONLY. Do not modify any files unless explicitly instructed by the user.** --- ## Severity Scale Rate each finding using Nielsen's standard severity scale: - **0** — Not a usability problem - **1** — Cosmetic only; fix if time permits - **2** — Minor; low priority - **3** — Major; important to fix - **4** — Usability catastrophe; imperative to fix --- ## The 10 Heuristics ### H1 — Visibility of System Status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Check for: - Loading states with no visual indicator (spinner, progress bar, skeleton) - Form submissions with no confirmation or error feedback - Background processes running with no status communication - Active/selected states that are ambiguous or absent - Navigation that doesn't indicate current location - Async operations with no acknowledgment that the request was received --- ### H2 — Match Between System and the Real World The system should speak the user's language — words, phrases, and concepts familiar to the user, rather than system-oriented terms. Check for: - Technical jargon, error codes, or system terminology exposed to users - Metaphors that don't map to real-world mental models - Date, time, or number formats inconsistent with user locale conventions - Icon choices that don't map to universally understood concepts - Labels that describe system behavior rather than user goals --- ### H3 — User Control and Freedom Users often choose system functions by mistake and need a clearly marked "emergency exit" to leave the unwanted state without extended dialogue. Check for: - Destructive actions with no undo or confirmation step - Modal dialogs or flows with no clear exit path - Multi-step processes with no back navigation - Form data lost on accidental navigation away - No way to cancel an in-progress operation - Forced flows where users cannot skip or defer --- ### H4 — Consistency and Standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Check for: - Same action labeled differently across views (e.g., "Save" vs "Submit" vs "Confirm") - Inconsistent button placement across similar screens - Interaction patterns that differ without reason (e.g., some modals close on Escape, others don't) - Inconsistent use of color to communicate state (e.g., red used for both errors and destructive actions and decorative elements) - Platform conventions violated without clear rationale (e.g., non-standard form behavior) --- ### H5 — Error Prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Check for: - Forms that only validate on submit rather than inline - Irreversible actions with no confirmation dialog - Inputs that accept invalid formats without constraint or guidance - Ambiguous UI that leads users toward likely mistakes - Defaults that frequently need to be changed by most users - Cluttered interfaces that increase chance of mis-click --- ### H6 — Recognition Rather Than Recall Minimize the user's memory load by making objects, actions, and options visible. Check for: - Options or commands hidden behind non-obvious interactions (hover, right-click) - Search or filter interfaces with no visible query history or suggestions - Multi-step flows where earlier context is not surfaced in later steps - Icons used without labels in non-standard contexts - Settings or features discoverable only through documentation - Empty inputs with no placeholder or example content --- ### H7 — Flexibility and Efficiency of Use Accelerators — unseen by the novice user — may speed up interaction for the expert so that the system can cater to both inexperienced and experienced users. Check for: - No keyboard shortcuts for frequent actions - Repetitive tasks with no batch operation or shortcut path - No way to save or reuse common configurations or inputs - Pagination-only navigation with no jump-to or filtering for power users - Dense forms with no smart defaults or auto-fill support - Workflows optimized only for first-time use --- ### H8 — Aesthetic and Minimalist Design Dialogues should not contain irrelevant or rarely needed information. Every extra unit of information competes with relevant information and diminishes relative visibility. Check for: - Interfaces surfacing low-priority information at the same visual weight as primary content - Modal dialogs or alerts containing excessive explanatory text - Dashboards or views attempting to show everything at once - Decorative elements that add visual noise without communicating meaning - Redundant labels, tooltips, or helper text that state the obvious - Competing calls to action on a single view --- ### H9 — Help Users Recognize, Diagnose, and Recover from Errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Check for: - Generic error messages ("Something went wrong", "Error 500") - Error states that disappear before the user can read them - Validation errors that identify the field but not the specific issue - Error messages that blame the user rather than guide them - No recovery path suggested alongside the error - Success and error states styled similarly (no clear visual differentiation) --- ### H10 — Help and Documentation Even though it is 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 user's task, list concrete steps, and not be too large. Check for: - Complex features with no contextual help or tooltip - Help content that exists but is not surfaced at the point of need - Onboarding flows that dump all information upfront rather than progressively - Error states that don't link to relevant help content - Empty states with no guidance on how to get started --- ## Output Format ``` # Nielsen Heuristics Audit — [Component or View Name] Date: [today] Files reviewed: [list] ## Summary [2–3 sentence overview of overall usability health] ## Findings by Heuristic ### H1 — Visibility of System Status - [Finding]: [Description] — Severity: 0/1/2/3/4 Remedy: [Specific actionable suggestion] ### H2 — Match Between System and the Real World ... [Continue for all 10 heuristics] ## Priority Recommendations [Top 3 highest-severity findings, ranked] ## What's Working [Note heuristics where no violations were found] ``` --- ## Scope Guidance - Audit the component or view the user references - If no file is named, ask: "Which component or view should I audit first?" - Skip generated/vendor files (node_modules, dist, build) - Focus on user-facing behavior and copy, not implementation details --- ## Constraints - REPORT ONLY unless user explicitly asks for changes - This skill does not cover visual design — use the Refactoring UI audit skill for that - This skill does not cover WCAG accessibility — that is a separate skill - Flag accessibility overlaps but keep remediation scoped to usability - Use Nielsen's severity scale (0–4), not Critical/Moderate/Minor