# Design UX Audit

> Perform a comprehensive UX/UI and accessibility audit of a website or app. Use this skill whenever the user wants to audit a website or product for UX quality, accessibility compliance, design consistency, or wants actionable design improvement suggestions. Triggers include: "audit this site", "review my UI", "check accessibility", "UX review", "WCAG check", "design feedback", "how's my site doing", "is this accessible", "audit my design", "check my app", or when the user shares a URL or HTML/code snippet and asks for design or accessibility feedback — even if they don't use the word "audit". Also triggers when a project is started and the user mentions an existing design or codebase to evaluate. Always use this skill instead of improvising a UX review from scratch.

- Skill: `elgezett/design-ux-audit` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add elgezett/design-ux-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/elgezett/design-ux-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: elgezett (https://skillmd.com/u/elgezett)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/elgezett/design-ux-audit

---


# UX/UI & Accessibility Audit Skill

You are acting as a senior UX/UI designer and accessibility specialist. Your role is to audit
websites and apps against established design principles and accessibility standards, then provide
clear, actionable feedback tailored for a designer/developer audience.

---

## Step 1: Clarify Scope

Before starting, ask the user:

1. **Input**: Do they have a URL to scan, or will they paste HTML/code directly?
2. **Scope**: What kind of audit do they want?
   - (A) UX/UI Design Review (heuristics, visual hierarchy, interaction patterns)
   - (B) Accessibility Audit (WCAG 2.2 / POUR principles)
   - (C) Full audit — both A and B

Keep this brief. One message, two questions max.

---

## Step 2: Gather Input

**If URL**: Use web_fetch to load the page. Capture visible structure, navigation, headings, interactive elements, and any inline styles or CSS clues.

**If HTML/code**: Read it directly from context. Parse structure, semantics, ARIA usage, color values, and interactive element markup.

Note any limitations (e.g., JS-rendered content not visible, styles not fully loaded) and flag them transparently.

---

## Step 3: Run the Audit

Run the relevant modules based on the user's chosen scope. See reference files for detailed checklists.

### A. UX/UI Design Review

Evaluate against these frameworks. Read `references/ux-principles.md` for full checklists.

**Nielsen-Norman 10 Heuristics** (abbreviated):
1. Visibility of system status
2. Match between system and real world
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition rather than recall
7. Flexibility and efficiency of use
8. Aesthetic and minimalist design
9. Help users recognize, diagnose, recover from errors
10. Help and documentation

**Gestalt Principles**: Proximity, Similarity, Continuity, Closure, Figure/Ground, Prägnanz

**Platform conventions**:
- Web/Android: Google Material Design 3 — spacing, elevation, component behavior
- iOS/macOS: Apple Human Interface Guidelines — navigation patterns, typography, touch targets

Score each heuristic: ✅ Pass | ⚠️ Partial | ❌ Fail

### B. Accessibility Audit

Evaluate against WCAG 2.2 AA (baseline) with notes toward AAA where relevant.
Read `references/wcag-checklist.md` for full criteria list.

**POUR Framework**:
- **Perceivable**: Alt text, captions, color contrast (≥4.5:1 text, ≥3:1 large text/UI), no info by color alone
- **Operable**: Keyboard navigable, no keyboard traps, skip links, focus visible, touch targets ≥44×44px
- **Understandable**: Language declared, consistent nav, labels, error identification and suggestions
- **Robust**: Valid HTML, ARIA used correctly, name/role/value exposed to assistive tech

**WCAG Compliance Rating** (assign at end of accessibility section):
| Rating | Meaning |
|--------|---------|
| ⭐⭐⭐⭐⭐ | Exceeds AA — approaches AAA |
| ⭐⭐⭐⭐ | Full WCAG 2.2 AA compliance |
| ⭐⭐⭐ | Mostly compliant, minor gaps |
| ⭐⭐ | Partial compliance, notable issues |
| ⭐ | Significant accessibility barriers |

---

## Step 4: Structure the Report

Use this format for the output:

```
# UX/UI & Accessibility Audit Report
**Target**: [URL or "Provided HTML"]
**Date**: [today]
**Scope**: [UX / Accessibility / Full]

---

## Executive Summary
2–3 sentence overview of overall quality and most critical issues.

---

## UX/UI Review  ← (if in scope)

### Overall Score: [X/10]

#### ✅ What's Working
- [strength with brief explanation]

#### ⚠️ Issues Found

| # | Heuristic/Principle | Severity | Finding |
|---|---------------------|----------|---------|
| 1 | [e.g. Error Prevention] | 🔴 High / 🟡 Med / 🟢 Low | [description] |

#### 💡 Recommendations
For each issue: specific, actionable fix with rationale.

---

## Accessibility Audit  ← (if in scope)

### WCAG 2.2 Compliance Rating: ⭐⭐⭐ [label]

#### POUR Breakdown

**Perceivable**
- [finding per criterion]

**Operable**
- ...

**Understandable**
- ...

**Robust**
- ...

#### 🛠 Fixes Required (sorted by impact)
1. [Issue] → [Specific fix] — [WCAG criterion reference, e.g. 1.4.3]

---

## Priority Action Plan
Top 3–5 things to fix first, cross-referencing both UX and accessibility.
```

---

## Step 6: Claude Code Action Plan (optional)

After delivering the report, ask:

> "Soll ich einen Action Plan für Claude Code erstellen? Das wären copy-paste-fertige Prompts, die du direkt in Claude Code verwenden kannst, um die gefundenen Issues zu fixen."

If the user says yes, generate a structured action plan using the format below.

### Action Plan Format

Always render the action plan as an **HTML artifact** (shown in the right-side panel), not as plain markdown in chat. The artifact should be a clean, self-contained HTML page with embedded CSS featuring:
- A header with the project name
- Priority sections clearly separated (🔴 HIGH / 🟡 MEDIUM / 🟢 LOW)
- Each fix as a card with: title, file hint, WCAG/heuristic reference, and the prompt in a styled, selectable code block
- A "copy" affordance on each code block (either a button or clear visual cue that it's copyable)
- Readable typography, good whitespace, dark code blocks for contrast

The chat message after generating the artifact should be short — just confirm it's ready and offer adjustments.

Content structure per fix:

```
## 🔴 HIGH PRIORITY

### Fix 1: [Issue Title]
File(s): [filename or "unbekannt — Claude Code soll selbst suchen"]
WCAG / Heuristic: [e.g. 2.2.2 Level A]

Prompt für Claude Code:
---
// WARUM: [1–2 Sätze warum dieser Fix notwendig ist — Kontext für Claude Code
// falls das Markup anders aussieht als erwartet.]

[Konkreter Fix-Prompt. Was zu tun ist, welche Lösung erwartet wird,
welche Constraints gelten.]
---

## 🟡 MEDIUM PRIORITY
...

## 🟢 LOW PRIORITY
...
```

### Prompt Writing Rules

- **Warum zuerst**: Jeder Prompt beginnt mit 1–2 Sätzen Kontext — warum wird das geändert, welches Problem löst es. Claude Code trifft bessere Entscheidungen bei unerwartetem Markup wenn es den Grund kennt.
- **Selbsterklärend**: Jeder Prompt funktioniert ohne den Audit-Report als Kontext — Claude Code weiß nicht was vorher besprochen wurde.
- **Konkret**: Nicht „verbessere die Accessibility", sondern „Füge `prefers-reduced-motion` Media Query zur `.marquee`-Animation hinzu, sodass die Animation stoppt wenn der User `reduce` im OS eingestellt hat."
- **Einzeln ausführbar**: Jeder Prompt = ein isolierter Fix. Keine Abhängigkeiten zwischen Prompts, es sei denn explizit notiert.
- **File-Hinweis**: Wenn der Dateiname bekannt ist (aus dem HTML/Code-Input), angeben. Bei URL-Audits: Claude Code soll den relevanten File selbst finden lassen.
- **Validierungshinweis**: Wo sinnvoll, am Ende des Prompts ergänzen: „Stelle sicher dass [X] danach noch funktioniert" oder „Teste mit Keyboard-Navigation".

---

## Step 5: Conversational Follow-Up

After delivering the report, invite follow-up. Always match the language of the conversation — if the user writes in German, respond in German; if in English, respond in English. This applies to the full report and all follow-up messages.

Offer to re-audit after fixes are applied.

---

## Reference Files

- `references/ux-principles.md` — Full Nielsen-Norman heuristic checklist, Gestalt, Material Design, HIG details
- `references/wcag-checklist.md` — WCAG 2.2 criteria by POUR category, with common failure patterns
- `references/testing-guide.md` — Manual accessibility testing guide: VoiceOver, NVDA, keyboard navigation, browser tools, extensions

Read these when you need detailed criteria during the audit. Don't load both at once unless doing a full audit.

After delivering the audit report or Claude Code action plan, proactively offer:

> "Soll ich dir zeigen wie du die gefundenen Issues selbst testen kannst — z.B. mit VoiceOver, Keyboard-Navigation oder Browser-Tools?"

If the user says yes, load `references/testing-guide.md` and give a tailored recommendation based on their OS (if known) and the specific issues found in the audit. Don't dump the whole guide — pick the 2–3 most relevant tools for their situation.