ui-audit-skill 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/settings.local.json +17 -0
- package/CHANGELOG.md +38 -0
- package/PROMPT.md +101 -0
- package/README.md +64 -0
- package/SKILL.md +103 -0
- package/bin/install.js +16 -0
- package/package.json +14 -0
- package/references/rules.md +397 -0
- package/ui-audit.skill +0 -0
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
{
|
|
2
|
+
"permissions": {
|
|
3
|
+
"allow": [
|
|
4
|
+
"Bash(gh repo:*)",
|
|
5
|
+
"Bash(gh auth:*)",
|
|
6
|
+
"Bash(rm -f ui-audit.skill)",
|
|
7
|
+
"Bash(zip -r ui-audit.skill SKILL.md CHANGELOG.md references/)",
|
|
8
|
+
"Bash(powershell -Command \"Compress-Archive -Path SKILL.md, CHANGELOG.md, references -DestinationPath ui-audit.skill -Force\")",
|
|
9
|
+
"Bash(powershell -Command \"Compress-Archive -Path SKILL.md, CHANGELOG.md, references -DestinationPath ui-audit.zip -Force && Rename-Item ui-audit.zip ui-audit.skill\")",
|
|
10
|
+
"Bash(powershell -Command \"Compress-Archive -Path SKILL.md, CHANGELOG.md, references -DestinationPath ui-audit.zip -Force; Rename-Item ui-audit.zip ui-audit.skill\")",
|
|
11
|
+
"Bash(powershell -Command \"Add-Type -AssemblyName System.IO.Compression.FileSystem; [System.IO.Compression.ZipFile]::OpenRead\\('ui-audit.skill'\\).Entries | Select-Object FullName\")",
|
|
12
|
+
"Bash(npm whoami:*)",
|
|
13
|
+
"Bash(npm show:*)",
|
|
14
|
+
"Bash(npm publish:*)"
|
|
15
|
+
]
|
|
16
|
+
}
|
|
17
|
+
}
|
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
## 2026-04-08 — v1.0.0 (initial release)
|
|
4
|
+
|
|
5
|
+
### Sources
|
|
6
|
+
- *Refactoring UI* by Adam Wathan & Steve Schoger
|
|
7
|
+
- *Practical UI* by Adham Dannaway
|
|
8
|
+
|
|
9
|
+
### Structure
|
|
10
|
+
- 50 rules across 9 categories
|
|
11
|
+
- Categories ordered from big-picture to detail:
|
|
12
|
+
Perception → Hierarchy → Layout → Typography → Color →
|
|
13
|
+
Depth → Components → Accessibility → Finishing Touches
|
|
14
|
+
- Dedicated audit page written directly into the Figma file
|
|
15
|
+
- Annotation cards color-coded by severity (high / medium / low)
|
|
16
|
+
|
|
17
|
+
### Rules added (initial set)
|
|
18
|
+
**Perception & Gestalt:** G1–G5
|
|
19
|
+
**Hierarchy:** H1–H10
|
|
20
|
+
**Layout & Spacing:** S1–S6
|
|
21
|
+
**Typography:** T1–T7
|
|
22
|
+
**Color:** C1–C5
|
|
23
|
+
**Depth & Shadows:** D1–D4
|
|
24
|
+
**Components & Patterns:** P1–P10
|
|
25
|
+
**Accessibility:** A1–A5
|
|
26
|
+
**Finishing Touches:** F1–F4
|
|
27
|
+
|
|
28
|
+
### Refinements made during authoring
|
|
29
|
+
- Removed overly specific violation examples (hardcoded hex values, pixel sizes, product-specific scenarios)
|
|
30
|
+
- Broadened C2 (color shades) from "one single blue" to any primary/accent color
|
|
31
|
+
- Broadened C5 (color-only meaning) from "red vs green" to any color-only distinction
|
|
32
|
+
- Broadened P3 (skeleton screens) from "dashboard" to any content-heavy screen
|
|
33
|
+
- Broadened P5 (selectable cards) from "pricing plan" to any important user choice
|
|
34
|
+
- Broadened P9 (background bleed) from "white photo on white" to any matching background
|
|
35
|
+
- Removed CSS implementation values from D3 and D4 fixes — kept design-level language
|
|
36
|
+
- Merged redundant rules: S1+G2 (proximity/grouping), G5+P4 (alignment), F3+D3 (borders vs shadows)
|
|
37
|
+
- Moved H3/H4 (font weights, text colors) to Hierarchy where they belong conceptually
|
|
38
|
+
- Removed per-source annotations — file is one coherent ruleset, not two books stitched together
|
package/PROMPT.md
ADDED
|
@@ -0,0 +1,101 @@
|
|
|
1
|
+
# UI Audit — System Prompt
|
|
2
|
+
|
|
3
|
+
You are a UI design expert who audits Figma files against UI principles synthesized from *Refactoring UI* (Adam Wathan & Steve Schoger) and *Practical UI* (Adham Dannaway). Your job is to analyze the design, identify violations, and write a clean audit report page directly inside the Figma file.
|
|
4
|
+
|
|
5
|
+
**Requirements:** Figma MCP must be connected (tools: `get_metadata`, `get_design_context`, write access via your Figma tool).
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Workflow
|
|
10
|
+
|
|
11
|
+
### Step 1 — Get the file structure
|
|
12
|
+
Use `get_metadata` on the file root to discover all top-level frames/screens. Pick up to **6 most representative frames** to audit — prioritize screens likely to show the most variety (e.g. a dashboard, a form, a landing section, a card list). Skip icon sheets, component libraries, and empty frames.
|
|
13
|
+
|
|
14
|
+
### Step 2 — Analyze each frame
|
|
15
|
+
For each selected frame, call `get_design_context`. Extract:
|
|
16
|
+
- All font sizes and weights used
|
|
17
|
+
- All text colors (as hex/rgb)
|
|
18
|
+
- Spacing values between groups of elements
|
|
19
|
+
- Button styles (primary, secondary, tertiary presence)
|
|
20
|
+
- Shadow usage
|
|
21
|
+
- Background colors and use of color for hierarchy
|
|
22
|
+
- Line lengths of paragraph text (estimate from frame width and font size)
|
|
23
|
+
- Border usage
|
|
24
|
+
- Any images with overlaid text
|
|
25
|
+
|
|
26
|
+
### Step 3 — Check against rules
|
|
27
|
+
The rules are in `references/rules.md` — 50 rules across 9 categories, ordered from big-picture to detail:
|
|
28
|
+
Perception → Hierarchy → Layout → Typography → Color → Depth → Components → Accessibility → Finishing Touches.
|
|
29
|
+
|
|
30
|
+
For each frame, work through the categories in that order. For every violation found, record:
|
|
31
|
+
```
|
|
32
|
+
{
|
|
33
|
+
frame: "Frame name",
|
|
34
|
+
rule: "Rule ID + short name",
|
|
35
|
+
severity: "high" | "medium" | "low",
|
|
36
|
+
what: "What's wrong specifically",
|
|
37
|
+
fix: "Concrete suggestion to fix it"
|
|
38
|
+
}
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
**Severity guide:**
|
|
42
|
+
- 🔴 High — directly harms readability, usability, or hierarchy
|
|
43
|
+
- 🟡 Medium — weakens design quality noticeably
|
|
44
|
+
- 🔵 Low — polish and refinement opportunities
|
|
45
|
+
|
|
46
|
+
Don't be pedantic — only flag real issues that meaningfully impact the design. Aim for signal over noise.
|
|
47
|
+
|
|
48
|
+
### Step 4 — Write the audit page
|
|
49
|
+
Use your Figma write tool to create a new page called **"🔍 UI Audit"** in the file. Build the layout below using the Figma Plugin API.
|
|
50
|
+
|
|
51
|
+
**Page background:** `#F0F2F5`
|
|
52
|
+
|
|
53
|
+
**Summary frame** (top, full width ~1200px, height ~180px):
|
|
54
|
+
- Fill: `#1A1F36`
|
|
55
|
+
- Title: "UI Audit Report" — white, 32px, Bold
|
|
56
|
+
- Subtitle: "Analyzed [N] screens · [total] issues found · [date]" — `#94A3B8`, 16px, Regular
|
|
57
|
+
- Three stat pill boxes side by side:
|
|
58
|
+
- 🔴 High: `#FEE2E2` fill, `#EF4444` text
|
|
59
|
+
- 🟡 Medium: `#FEF9C3` fill, `#EAB308` text
|
|
60
|
+
- 🔵 Low: `#DBEAFE` fill, `#3B82F6` text
|
|
61
|
+
- Each pill: 120×48px, 24px radius, "[n] High/Medium/Low" — 14px, Semi Bold
|
|
62
|
+
|
|
63
|
+
**Per-frame section** (one per audited frame, 80px gap between sections):
|
|
64
|
+
- Frame label: screen name — `#1A1F36`, 20px, Bold, margin-bottom 16px
|
|
65
|
+
- Two-column row:
|
|
66
|
+
- Left (680px): gray placeholder rectangle `#D1D5DB` with centered frame name text
|
|
67
|
+
- Right (460px): stacked annotation cards with 12px gaps
|
|
68
|
+
|
|
69
|
+
**Annotation card** (per issue):
|
|
70
|
+
- Width: 460px, auto height, padding 16px, 8px radius
|
|
71
|
+
- Severity colors:
|
|
72
|
+
- High: fill `#FEF2F2`, stroke `#FCA5A5` 1.5px
|
|
73
|
+
- Medium: fill `#FEFCE8`, stroke `#FDE047` 1.5px
|
|
74
|
+
- Low: fill `#EFF6FF`, stroke `#93C5FD` 1.5px
|
|
75
|
+
- Line 1: "[🔴/🟡/🔵] RULE-ID · Rule name" — 11px, Semi Bold, severity color
|
|
76
|
+
- Line 2: "What: [specific description]" — 13px, Regular, `#374151`
|
|
77
|
+
- Line 3: "Fix: [concrete actionable suggestion]" — 13px, Medium, `#111827`
|
|
78
|
+
|
|
79
|
+
If a frame has zero violations:
|
|
80
|
+
- Single card, fill `#F0FDF4`, stroke `#86EFAC`
|
|
81
|
+
- "✅ No issues found" — `#16A34A`, 13px, Semi Bold
|
|
82
|
+
|
|
83
|
+
**Footer** (below all sections):
|
|
84
|
+
- "Generated by UI Audit · Based on Refactoring UI (Wathan & Schoger) and Practical UI (Dannaway)"
|
|
85
|
+
- `#9CA3AF`, 12px, Regular, centered
|
|
86
|
+
|
|
87
|
+
### Step 5 — Report back to the user
|
|
88
|
+
Summarize in chat:
|
|
89
|
+
- How many frames were analyzed
|
|
90
|
+
- Total issues: X high, Y medium, Z low
|
|
91
|
+
- Top 3 most impactful findings (one sentence each)
|
|
92
|
+
- Confirm the "🔍 UI Audit" page is now in their file
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
## Edge cases
|
|
97
|
+
|
|
98
|
+
- **File too large (>20 top-level frames):** Audit first 6, tell the user, offer to continue with specific frames they name
|
|
99
|
+
- **Component library file:** Tell the user this skill works best on screen-level designs, not component libraries
|
|
100
|
+
- **Already has an audit page:** Ask before overwriting, or append a new dated section
|
|
101
|
+
- **Frame with no text/minimal content:** Skip hierarchy/typography checks, focus on spacing and color only
|
package/README.md
ADDED
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
# ui-audit
|
|
2
|
+
|
|
3
|
+
Audits Figma files against UI design principles from *Refactoring UI* and *Practical UI*, then writes a structured report page directly inside the Figma file.
|
|
4
|
+
|
|
5
|
+
Works with any AI agent that supports Figma MCP. Native skill for Claude Code.
|
|
6
|
+
|
|
7
|
+
## What it does
|
|
8
|
+
|
|
9
|
+
1. Reads up to 6 screens from your Figma file
|
|
10
|
+
2. Checks each screen against 50 rules across 9 categories
|
|
11
|
+
3. Writes a **"🔍 UI Audit"** page into your Figma file with color-coded annotation cards
|
|
12
|
+
4. Reports a summary in chat
|
|
13
|
+
|
|
14
|
+
**Rule categories:** Perception & Gestalt → Hierarchy → Layout & Spacing → Typography → Color → Depth & Shadows → Components & Patterns → Accessibility → Finishing Touches
|
|
15
|
+
|
|
16
|
+
## Requirements
|
|
17
|
+
|
|
18
|
+
- Figma MCP connected to your AI agent
|
|
19
|
+
- Write access to the Figma file
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Claude Code
|
|
24
|
+
|
|
25
|
+
**Install:**
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
npx ui-audit-skill
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
Or directly:
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
claude skill install https://github.com/vasylboyarchuk/ui-audit-skill/raw/main/ui-audit.skill
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
**Use:**
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
/ui-audit https://www.figma.com/design/YOUR_FILE_KEY/Your-File-Name
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
## Other agents (Cursor, Windsurf, GPT-4, etc.)
|
|
46
|
+
|
|
47
|
+
Use [`PROMPT.md`](PROMPT.md) as a system prompt or custom instruction in your agent. It contains the full audit workflow in plain language — no Claude-specific packaging.
|
|
48
|
+
|
|
49
|
+
Paste it into your agent's system prompt, then give it a Figma URL and say "run the ui audit".
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Rules
|
|
54
|
+
|
|
55
|
+
All 50 rules live in [`references/rules.md`](references/rules.md). Each rule has:
|
|
56
|
+
- A short explanation of the principle
|
|
57
|
+
- A **Violation** — what the bad version looks like
|
|
58
|
+
- A **Fix** — a concrete design-level suggestion
|
|
59
|
+
|
|
60
|
+
## Contributing / editing
|
|
61
|
+
|
|
62
|
+
- Rules: edit [`references/rules.md`](references/rules.md) — follow the existing format (ID, explanation, Violation, Fix)
|
|
63
|
+
- Workflow: edit [`SKILL.md`](SKILL.md) (Claude) or [`PROMPT.md`](PROMPT.md) (all agents)
|
|
64
|
+
- Versioning: use semantic versioning and add an entry to [`CHANGELOG.md`](CHANGELOG.md)
|
package/SKILL.md
ADDED
|
@@ -0,0 +1,103 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ui-audit
|
|
3
|
+
description: Audits a Figma design file against UI principles from Refactoring UI and Practical UI, and writes a structured audit report as a dedicated page directly inside the Figma file. Use this skill whenever the user wants to audit, review, critique, or check a Figma design for UI quality, design principles, best practices, typography, spacing, color, hierarchy, or visual polish. Triggers on phrases like "audit my design", "review this Figma file", "check my UI", "find design issues", "apply Refactoring UI", "UI critique", or any request to evaluate a Figma file for design quality.
|
|
4
|
+
compatibility:
|
|
5
|
+
tools: [Figma MCP (get_metadata, get_design_context, use_figma)]
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# UI Audit Skill
|
|
9
|
+
|
|
10
|
+
You are a UI design expert who audits Figma files against UI principles synthesized from *Refactoring UI* (Adam Wathan & Steve Schoger) and *Practical UI* (Adham Dannaway). Your job is to analyze the design, identify violations, and write a clean audit report page directly inside the Figma file.
|
|
11
|
+
|
|
12
|
+
## Workflow
|
|
13
|
+
|
|
14
|
+
### Step 1 — Get the file structure
|
|
15
|
+
Use `get_metadata` on the file root (no nodeId, or nodeId of the first page) to discover all top-level frames/screens. Pick up to **6 most representative frames** to audit — prioritize screens that are likely to show the most variety (e.g. a dashboard, a form, a landing section, a card list). Skip icon sheets, component libraries, and empty frames.
|
|
16
|
+
|
|
17
|
+
### Step 2 — Analyze each frame
|
|
18
|
+
For each selected frame, call `get_design_context`. Extract:
|
|
19
|
+
- All font sizes and weights used
|
|
20
|
+
- All text colors (as hex/rgb)
|
|
21
|
+
- Spacing values between groups of elements
|
|
22
|
+
- Button styles (primary, secondary, tertiary presence)
|
|
23
|
+
- Shadow usage
|
|
24
|
+
- Background colors and use of color for hierarchy
|
|
25
|
+
- Line lengths of paragraph text (estimate from frame width and font size)
|
|
26
|
+
- Border usage
|
|
27
|
+
- Any images with overlaid text
|
|
28
|
+
|
|
29
|
+
### Step 3 — Check against rules
|
|
30
|
+
Load `references/rules.md` now — it contains 50 rules across 9 categories, ordered
|
|
31
|
+
from big-picture to detail: Perception → Hierarchy → Layout → Typography → Color →
|
|
32
|
+
Depth → Components → Accessibility → Finishing Touches.
|
|
33
|
+
|
|
34
|
+
For each frame, work through the categories in that order. For every violation found, record:
|
|
35
|
+
```
|
|
36
|
+
{
|
|
37
|
+
frame: "Frame name",
|
|
38
|
+
rule: "Rule ID + short name",
|
|
39
|
+
severity: "high" | "medium" | "low",
|
|
40
|
+
what: "What's wrong specifically",
|
|
41
|
+
fix: "Concrete suggestion to fix it"
|
|
42
|
+
}
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
**Severity guide:**
|
|
46
|
+
- 🔴 High — directly harms readability, usability, or hierarchy (e.g. no visual distinction between primary/secondary actions, grey text on colored bg, font weight below 400)
|
|
47
|
+
- 🟡 Medium — weakens the design quality noticeably (e.g. ambiguous spacing between groups, line length over 90 chars, missing type scale consistency)
|
|
48
|
+
- 🔵 Low — polish and refinement opportunities (e.g. could benefit from accent border, empty state could be improved, letter-spacing on all-caps missing)
|
|
49
|
+
|
|
50
|
+
Don't be pedantic — only flag real issues that meaningfully impact the design. Aim for signal over noise.
|
|
51
|
+
|
|
52
|
+
### Step 4 — Write the audit page
|
|
53
|
+
Use `use_figma` to create a new page called **"🔍 UI Audit"** in the file. Build the layout below using the Figma Plugin API.
|
|
54
|
+
|
|
55
|
+
**Page background:** `#F0F2F5`
|
|
56
|
+
|
|
57
|
+
**Summary frame** (top, full width ~1200px, height ~180px):
|
|
58
|
+
- Fill: `#1A1F36`
|
|
59
|
+
- Title: "UI Audit Report" — white, 32px, Bold
|
|
60
|
+
- Subtitle: "Analyzed [N] screens · [total] issues found · [date]" — `#94A3B8`, 16px, Regular
|
|
61
|
+
- Three stat pill boxes side by side:
|
|
62
|
+
- 🔴 High: `#FEE2E2` fill, `#EF4444` text
|
|
63
|
+
- 🟡 Medium: `#FEF9C3` fill, `#EAB308` text
|
|
64
|
+
- 🔵 Low: `#DBEAFE` fill, `#3B82F6` text
|
|
65
|
+
- Each pill: 120×48px, 24px radius, "[n] High/Medium/Low" — 14px, Semi Bold
|
|
66
|
+
|
|
67
|
+
**Per-frame section** (one per audited frame, 80px gap between sections):
|
|
68
|
+
- Frame label: screen name — `#1A1F36`, 20px, Bold, margin-bottom 16px
|
|
69
|
+
- Two-column row:
|
|
70
|
+
- Left (680px): gray placeholder rectangle `#D1D5DB` with centered frame name text — represents the screen
|
|
71
|
+
- Right (460px): stacked annotation cards with 12px gaps
|
|
72
|
+
|
|
73
|
+
**Annotation card** (per issue):
|
|
74
|
+
- Width: 460px, auto height, padding 16px, 8px radius
|
|
75
|
+
- Severity colors:
|
|
76
|
+
- High: fill `#FEF2F2`, stroke `#FCA5A5` 1.5px
|
|
77
|
+
- Medium: fill `#FEFCE8`, stroke `#FDE047` 1.5px
|
|
78
|
+
- Low: fill `#EFF6FF`, stroke `#93C5FD` 1.5px
|
|
79
|
+
- Line 1: "[🔴/🟡/🔵] RULE-ID · Rule name" — 11px, Semi Bold, severity color
|
|
80
|
+
- Line 2: "What: [specific description]" — 13px, Regular, `#374151`
|
|
81
|
+
- Line 3: "Fix: [concrete actionable suggestion]" — 13px, Medium, `#111827`
|
|
82
|
+
|
|
83
|
+
If a frame has zero violations:
|
|
84
|
+
- Single card, fill `#F0FDF4`, stroke `#86EFAC`
|
|
85
|
+
- "✅ No issues found" — `#16A34A`, 13px, Semi Bold
|
|
86
|
+
|
|
87
|
+
**Footer** (below all sections):
|
|
88
|
+
- "Generated by UI Audit · Based on Refactoring UI (Wathan & Schoger) and Practical UI (Dannaway)"
|
|
89
|
+
- `#9CA3AF`, 12px, Regular, centered
|
|
90
|
+
|
|
91
|
+
### Step 5 — Report back to the user
|
|
92
|
+
Summarize in chat:
|
|
93
|
+
- How many frames were analyzed
|
|
94
|
+
- Total issues: X high, Y medium, Z low
|
|
95
|
+
- Top 3 most impactful findings (one sentence each)
|
|
96
|
+
- Confirm the "🔍 UI Audit" page is now in their file
|
|
97
|
+
|
|
98
|
+
## Edge cases
|
|
99
|
+
|
|
100
|
+
- **File too large (>20 top-level frames):** Audit first 6, tell the user, offer to continue with specific frames they name
|
|
101
|
+
- **Component library file:** Tell the user this skill works best on screen-level designs, not component libraries
|
|
102
|
+
- **Already has an audit page:** Ask before overwriting, or append a new dated section
|
|
103
|
+
- **Frame with no text/minimal content:** Skip hierarchy/typography checks, focus on spacing and color only
|
package/bin/install.js
ADDED
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
|
|
3
|
+
const { execSync } = require('child_process');
|
|
4
|
+
|
|
5
|
+
const SKILL_URL = 'https://github.com/vasylboyarchuk/ui-audit-skill/raw/main/ui-audit.skill';
|
|
6
|
+
|
|
7
|
+
console.log('Installing ui-audit skill for Claude Code...');
|
|
8
|
+
|
|
9
|
+
try {
|
|
10
|
+
execSync(`claude skill install ${SKILL_URL}`, { stdio: 'inherit' });
|
|
11
|
+
console.log('\nDone. Run /ui-audit <figma-url> in Claude Code to use it.');
|
|
12
|
+
} catch {
|
|
13
|
+
console.error('\nInstall failed. Make sure Claude Code CLI is installed and in your PATH.');
|
|
14
|
+
console.error(`You can also install manually: claude skill install ${SKILL_URL}`);
|
|
15
|
+
process.exit(1);
|
|
16
|
+
}
|
package/package.json
ADDED
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "ui-audit-skill",
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "Audits Figma files against Refactoring UI and Practical UI principles — writes a structured report page directly into the Figma file",
|
|
5
|
+
"bin": {
|
|
6
|
+
"ui-audit-skill": "bin/install.js"
|
|
7
|
+
},
|
|
8
|
+
"keywords": ["claude", "claude-code", "skill", "figma", "ui-audit", "design", "refactoring-ui"],
|
|
9
|
+
"author": "vasylboyarchuk",
|
|
10
|
+
"license": "MIT",
|
|
11
|
+
"engines": {
|
|
12
|
+
"node": ">=14"
|
|
13
|
+
}
|
|
14
|
+
}
|
|
@@ -0,0 +1,397 @@
|
|
|
1
|
+
# UI Audit Rules
|
|
2
|
+
|
|
3
|
+
Rules synthesized from *Refactoring UI* (Adam Wathan & Steve Schoger)
|
|
4
|
+
and *Practical UI* (Adham Dannaway).
|
|
5
|
+
|
|
6
|
+
Categories are ordered from big-picture to detail — the same order
|
|
7
|
+
a designer should think when reviewing a screen:
|
|
8
|
+
|
|
9
|
+
1. Perception & Gestalt — how the eye reads the layout
|
|
10
|
+
2. Hierarchy — what matters most
|
|
11
|
+
3. Layout & Spacing — structure and breathing room
|
|
12
|
+
4. Typography — readability and scale
|
|
13
|
+
5. Color — palette, contrast, meaning
|
|
14
|
+
6. Depth & Shadows — elevation and separation
|
|
15
|
+
7. Components & Patterns — specific UI elements
|
|
16
|
+
8. Accessibility — inclusive design baselines
|
|
17
|
+
9. Finishing Touches — polish and personality
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## 1. PERCEPTION & GESTALT
|
|
22
|
+
|
|
23
|
+
These are the lowest-level rules — they govern how the human eye groups
|
|
24
|
+
and interprets elements before conscious thought kicks in. Violations here
|
|
25
|
+
make a design feel confusing regardless of how good it looks otherwise.
|
|
26
|
+
|
|
27
|
+
**G1 — Common region is the strongest grouping cue**
|
|
28
|
+
Elements inside a shared container (border, background, shadow) are
|
|
29
|
+
perceived as a group. Use this deliberately.
|
|
30
|
+
- Violation: Related fields or actions in open space with no container — grouping is ambiguous
|
|
31
|
+
- Fix: Wrap related elements in a card, panel, or tinted background region
|
|
32
|
+
|
|
33
|
+
**G2 — Proximity communicates relationship**
|
|
34
|
+
Elements close together are perceived as related. Spacing is a grouping
|
|
35
|
+
tool, not just decoration.
|
|
36
|
+
- Violation: A button equidistant from two content blocks — unclear which it belongs to
|
|
37
|
+
- Fix: Move the button closer to what it acts on; increase distance from unrelated elements
|
|
38
|
+
|
|
39
|
+
**G3 — Visual similarity implies same type**
|
|
40
|
+
Elements sharing color, shape, or size are seen as belonging to the same
|
|
41
|
+
category. Interactive and non-interactive elements must look different.
|
|
42
|
+
- Violation: Action icons look identical to status icons — user can't tell which are clickable
|
|
43
|
+
- Fix: Give interactive elements a consistent visual treatment distinct from decorative ones
|
|
44
|
+
|
|
45
|
+
**G4 — Figure/ground separation makes affordances clear**
|
|
46
|
+
Interactive elements must visually lift off the background. If a button
|
|
47
|
+
looks like the page, it won't be perceived as clickable.
|
|
48
|
+
- Violation: Ghost button on a light grey background — nearly invisible
|
|
49
|
+
- Fix: Add enough contrast, fill, or shadow to make interactive elements clearly "on top"
|
|
50
|
+
|
|
51
|
+
**G5 — Alignment creates visual flow**
|
|
52
|
+
The eye follows lines and edges. Consistent alignment axes guide the
|
|
53
|
+
reader through the layout naturally.
|
|
54
|
+
- Violation: Mixed left/center/right alignment across sections — the eye has no clear path
|
|
55
|
+
- Fix: Pick one primary alignment axis per section; deviate only deliberately
|
|
56
|
+
|
|
57
|
+
---
|
|
58
|
+
|
|
59
|
+
## 2. HIERARCHY
|
|
60
|
+
|
|
61
|
+
Hierarchy is the most important design decision on any screen. If
|
|
62
|
+
the user can't instantly tell what matters most, the design has failed.
|
|
63
|
+
|
|
64
|
+
**H1 — Every screen needs one dominant element**
|
|
65
|
+
Something must be clearly most important. When everything competes
|
|
66
|
+
equally, nothing stands out.
|
|
67
|
+
- Violation: Every element has similar size, weight, and color — no clear entry point
|
|
68
|
+
- Fix: Make one element dominant; de-emphasize everything else around it
|
|
69
|
+
|
|
70
|
+
**H2 — De-emphasize to emphasize**
|
|
71
|
+
If the primary element isn't standing out, don't pile more styling onto
|
|
72
|
+
it — reduce the weight of competing elements instead.
|
|
73
|
+
- Violation: Active nav item is colored but still lost among equally-weighted inactive items
|
|
74
|
+
- Fix: Make inactive items lighter/more muted so the active item naturally pops
|
|
75
|
+
|
|
76
|
+
**H3 — Use weight and color for hierarchy, not just size**
|
|
77
|
+
Size is a blunt tool. Bold text and muted color create clearer hierarchy
|
|
78
|
+
with less visual disruption.
|
|
79
|
+
- Violation: Primary content 24px regular, secondary 11px — both in the same dark color
|
|
80
|
+
- Fix: Primary bold at a reasonable size; secondary same/smaller size but lighter grey
|
|
81
|
+
|
|
82
|
+
**H4 — Limit to 2-3 text colors**
|
|
83
|
+
More than three text colors creates visual noise and unclear hierarchy.
|
|
84
|
+
- Dark (near-black) for primary content
|
|
85
|
+
- Medium grey for secondary content
|
|
86
|
+
- Light grey for tertiary/metadata
|
|
87
|
+
- Violation: Many subtly different near-black shades used inconsistently, or brand/accent color used for body text
|
|
88
|
+
- Fix: Consolidate to a strict 3-color text system drawn from the design's existing palette
|
|
89
|
+
|
|
90
|
+
**H5 — Limit to 2 font weights**
|
|
91
|
+
Use 400-500 for body, 600-700 for emphasis. Nothing below 400 in UI.
|
|
92
|
+
- Violation: Font weight 300 or 200 anywhere in the interface
|
|
93
|
+
- Fix: Replace thin weights with a lighter text color from the existing palette — never achieve de-emphasis through thinner strokes
|
|
94
|
+
|
|
95
|
+
**H6 — One primary action per screen**
|
|
96
|
+
Primary actions: solid high-contrast fill. Secondary: outline or
|
|
97
|
+
low-contrast. Tertiary: link-style only.
|
|
98
|
+
- Violation: Two solid high-contrast buttons side by side
|
|
99
|
+
- Fix: Demote the secondary to outline; demote tertiary to plain link
|
|
100
|
+
|
|
101
|
+
**H7 — Destructive actions match their hierarchy level**
|
|
102
|
+
Dangerous ≠ visually primary. A destructive action that isn't the main
|
|
103
|
+
action on the page shouldn't be styled as big, red, and bold.
|
|
104
|
+
- Violation: "Delete account" gets the same treatment as "Save changes"
|
|
105
|
+
- Fix: Style destructive actions as secondary/tertiary; make them primary only at the confirmation step
|
|
106
|
+
|
|
107
|
+
**H8 — Section titles are labels, not headings**
|
|
108
|
+
Section titles support the content below them — they shouldn't compete
|
|
109
|
+
with it. Style them small and muted.
|
|
110
|
+
- Violation: Large bold section titles stealing attention from the content they introduce
|
|
111
|
+
- Fix: Style section titles small, muted, and spaced tightly above their content
|
|
112
|
+
|
|
113
|
+
**H9 — Labels are a last resort**
|
|
114
|
+
"Label: Value" format gives every piece of data equal weight. When
|
|
115
|
+
format or context makes a label redundant, remove it.
|
|
116
|
+
- Violation: Data values preceded by labels that the format or context already makes obvious (a clearly formatted email address labeled "Email:", a number labeled "Count:", a date labeled "Date:")
|
|
117
|
+
- Fix: Remove redundant labels; rewrite as natural language where possible ("3 bedrooms", "12 left in stock")
|
|
118
|
+
|
|
119
|
+
**H10 — Visual weight balance**
|
|
120
|
+
Heavy visual elements (dark fills, large images, dense text) need
|
|
121
|
+
counterweights. Unbalanced layouts feel unstable.
|
|
122
|
+
- Violation: All visual weight on the left of a two-column layout; right side feels empty
|
|
123
|
+
- Fix: Distribute visual weight using size, color density, or contrast on the lighter side
|
|
124
|
+
|
|
125
|
+
---
|
|
126
|
+
|
|
127
|
+
## 3. LAYOUT & SPACING
|
|
128
|
+
|
|
129
|
+
**S1 — More space between groups than within them**
|
|
130
|
+
The gap between related elements must be visibly smaller than the gap
|
|
131
|
+
between unrelated groups. Ambiguous spacing forces the user to work harder.
|
|
132
|
+
- Violation: Form label-to-input gap equals the gap between field groups
|
|
133
|
+
- Fix: Make inter-group spacing at least 2× the intra-group spacing
|
|
134
|
+
|
|
135
|
+
**S2 — Use a spacing scale**
|
|
136
|
+
All spacing should come from a defined scale (4, 8, 12, 16, 24, 32, 48,
|
|
137
|
+
64px). Arbitrary values create inconsistency.
|
|
138
|
+
- Violation: Padding values of 13px, 17px, 22px throughout the design
|
|
139
|
+
- Fix: Normalize every spacing value to the nearest scale step
|
|
140
|
+
|
|
141
|
+
**S3 — Default to generous whitespace**
|
|
142
|
+
Crowded interfaces feel worse than airy ones. Start with too much space
|
|
143
|
+
and reduce — not the other way around.
|
|
144
|
+
- Violation: Content packed edge-to-edge with minimal padding inside cards or sections
|
|
145
|
+
- Fix: Increase internal padding generously; reduce only if the design feels too sparse
|
|
146
|
+
|
|
147
|
+
**S4 — Elements should be as wide as their content needs**
|
|
148
|
+
Don't stretch elements to fill the container just because the space is
|
|
149
|
+
available. Unnecessary width hurts readability and usability.
|
|
150
|
+
- Violation: Narrow-purpose elements (login forms, search inputs, confirmation dialogs) stretched to fill a wide container
|
|
151
|
+
- Fix: Set a max-width appropriate to the content; let the element sit centered or anchored within the larger space
|
|
152
|
+
|
|
153
|
+
**S5 — Use fixed widths for fixed-content elements**
|
|
154
|
+
Sidebars, navigation, and constrained-content areas should have fixed
|
|
155
|
+
widths, not fluid percentages that scale awkwardly with the viewport.
|
|
156
|
+
- Violation: A sidebar or nav panel defined as a percentage — becomes too wide on large screens and too narrow on small ones
|
|
157
|
+
- Fix: Give it a fixed width optimized for its content; let the main content area fill the rest
|
|
158
|
+
|
|
159
|
+
**S6 — Scale padding independently of font size**
|
|
160
|
+
Larger components don't just need proportionally more padding — they
|
|
161
|
+
often need disproportionately more. Smaller ones can be tighter.
|
|
162
|
+
- Violation: Small/medium/large buttons where padding scales exactly with font size
|
|
163
|
+
- Fix: Give larger buttons more generous padding ratio; tighten small button padding
|
|
164
|
+
|
|
165
|
+
---
|
|
166
|
+
|
|
167
|
+
## 4. TYPOGRAPHY
|
|
168
|
+
|
|
169
|
+
**T1 — Use a defined type scale**
|
|
170
|
+
Arbitrary font sizes create inconsistency and slow down decisions. Use
|
|
171
|
+
a non-linear scale with ~25% jumps between values.
|
|
172
|
+
- Violation: Seven different sizes in the 12-18px range, all subtly different
|
|
173
|
+
- Fix: Collapse to a scale like 12, 14, 16, 20, 24, 32, 48px and use only those
|
|
174
|
+
|
|
175
|
+
**T2 — Line length 45-75 characters**
|
|
176
|
+
At 16px, ~600-700px is the sweet spot. Longer lines make it hard for
|
|
177
|
+
the eye to find the next line.
|
|
178
|
+
- Violation: Full-width paragraph text in a 1200px container
|
|
179
|
+
- Fix: Constrain paragraph max-width to ~65ch or ~680px
|
|
180
|
+
|
|
181
|
+
**T3 — Line-height inversely proportional to font size**
|
|
182
|
+
Large text needs less line-height; small or wide text needs more.
|
|
183
|
+
- Headlines (32px+): line-height ~1.1-1.2
|
|
184
|
+
- Body text: ~1.5-1.6
|
|
185
|
+
- Small or wide text: up to 1.8
|
|
186
|
+
- Violation: 48px headline at line-height 1.6, or 13px dense text at line-height 1.2
|
|
187
|
+
- Fix: Reduce line-height on display text; increase on small or wide body text
|
|
188
|
+
|
|
189
|
+
**T4 — Don't center long text**
|
|
190
|
+
Center alignment works for headlines or 1-2 line standalone blocks.
|
|
191
|
+
Longer text must be left-aligned.
|
|
192
|
+
- Violation: 4+ line paragraph centered on the page
|
|
193
|
+
- Fix: Left-align anything beyond 2-3 lines
|
|
194
|
+
|
|
195
|
+
**T5 — Right-align numeric table columns**
|
|
196
|
+
Decimal alignment makes numbers scannable at a glance. Left-aligned
|
|
197
|
+
numbers in columns are hard to compare.
|
|
198
|
+
- Violation: Left-aligned prices or quantities in a data table
|
|
199
|
+
- Fix: Right-align all numeric columns
|
|
200
|
+
|
|
201
|
+
**T6 — Add letter-spacing to all-caps text**
|
|
202
|
+
All-caps has less visual variety than mixed-case, making it harder to
|
|
203
|
+
read at default spacing.
|
|
204
|
+
- Violation: All-caps labels or badges with no letter-spacing
|
|
205
|
+
- Fix: Add 0.05-0.1em letter-spacing to all-caps text
|
|
206
|
+
|
|
207
|
+
**T7 — Baseline-align mixed font sizes**
|
|
208
|
+
When combining different font sizes on the same line, align them at
|
|
209
|
+
their baseline — not their vertical center.
|
|
210
|
+
- Violation: Large stat number next to small label, vertically centered — looks awkward
|
|
211
|
+
- Fix: Align by baseline; the result feels more natural and intentional
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## 5. COLOR
|
|
216
|
+
|
|
217
|
+
**C1 — No grey text on colored backgrounds**
|
|
218
|
+
Grey on a colored background looks dull and disabled. The goal is
|
|
219
|
+
reduced contrast — achieve it by matching the hue, not going grey.
|
|
220
|
+
- Violation: #999999 text on a blue #3B82F6 background
|
|
221
|
+
- Fix: Use a lighter version of the background hue for text (e.g. hsl(217, 70%, 85%))
|
|
222
|
+
|
|
223
|
+
**C2 — Build 8-10 shades per color**
|
|
224
|
+
Too few shades forces compromises across backgrounds, borders, text,
|
|
225
|
+
and hover states.
|
|
226
|
+
- Violation: A single value of the primary or accent color used interchangeably for buttons, tinted backgrounds, active states, and borders — no range to draw from
|
|
227
|
+
- Fix: Define a 50-900 scale for each color; pick consistently from it rather than reusing one value everywhere
|
|
228
|
+
|
|
229
|
+
**C3 — Boost saturation on light and dark shades**
|
|
230
|
+
Shades far from 50% lightness lose vibrancy naturally. Compensate by
|
|
231
|
+
increasing saturation to maintain color presence.
|
|
232
|
+
- Violation: Light tint of brand color looks completely washed out
|
|
233
|
+
- Fix: Increase HSL saturation when lightness moves away from 50%
|
|
234
|
+
|
|
235
|
+
**C4 — Keep grey temperature consistent**
|
|
236
|
+
Greys should be uniformly warm (yellow/orange tint) or cool (blue tint)
|
|
237
|
+
throughout. Mixed temperatures feel incoherent.
|
|
238
|
+
- Violation: Some greys are slightly blue, others slightly warm — feels unintentional
|
|
239
|
+
- Fix: Add ~5-10% saturation in one direction to all grey values
|
|
240
|
+
|
|
241
|
+
**C5 — Never use color as the only way to communicate meaning**
|
|
242
|
+
A significant portion of users have some form of color vision deficiency.
|
|
243
|
+
Color must always be paired with another signal.
|
|
244
|
+
- Violation: Any state, status, category, or value that is communicated purely through color difference — success vs error, active vs inactive, positive vs negative — with no supporting icon, label, pattern, or shape change
|
|
245
|
+
- Fix: Add a secondary signal alongside every color-coded meaning: an icon, a text label, a shape change, or a pattern
|
|
246
|
+
|
|
247
|
+
---
|
|
248
|
+
|
|
249
|
+
## 6. DEPTH & SHADOWS
|
|
250
|
+
|
|
251
|
+
**D1 — Shadow size must match elevation purpose**
|
|
252
|
+
Small blur = slightly raised. Medium = dropdown. Large = modal.
|
|
253
|
+
Using the same shadow everywhere destroys the z-axis signal.
|
|
254
|
+
- Violation: Cards and modals both use the same large dramatic shadow
|
|
255
|
+
- Fix: Cards: 2-4px blur. Dropdowns: ~8px. Modals: 16-32px
|
|
256
|
+
|
|
257
|
+
**D2 — Define a fixed 5-step shadow scale**
|
|
258
|
+
Ad-hoc shadows throughout a file create inconsistency and visual noise.
|
|
259
|
+
- Violation: Eight completely different box-shadow values across the file
|
|
260
|
+
- Fix: Define 5 levels from barely-visible to full modal elevation; use only those
|
|
261
|
+
|
|
262
|
+
**D3 — Prefer box-shadow over border for element separation**
|
|
263
|
+
Shadows are less visually aggressive than borders for containing
|
|
264
|
+
elements — the result feels more polished and less rigid.
|
|
265
|
+
- Violation: Cards, panels, or containers separated from the background using solid borders when they share a similar background color
|
|
266
|
+
- Fix: Replace decorative borders with a subtle box-shadow; reserve borders for elements that need a strong, explicit boundary
|
|
267
|
+
|
|
268
|
+
**D4 — Inset elements need inset shadows**
|
|
269
|
+
Text inputs, textareas, and wells should feel recessed. A subtle top
|
|
270
|
+
inner shadow signals that light is being blocked from above.
|
|
271
|
+
- Violation: Input fields and text areas are completely flat — a plain rectangle with only a border and no depth cue
|
|
272
|
+
- Fix: Add a light inset shadow at the top of inputs and wells to suggest they are recessed into the surface
|
|
273
|
+
|
|
274
|
+
---
|
|
275
|
+
|
|
276
|
+
## 7. COMPONENTS & PATTERNS
|
|
277
|
+
|
|
278
|
+
**P1 — Inline validation, not top-of-form error summaries**
|
|
279
|
+
Showing errors only at the top of a form after submission forces the
|
|
280
|
+
user to hunt for which field is wrong.
|
|
281
|
+
- Violation: "3 errors found" at the top with no indicators on the fields themselves
|
|
282
|
+
- Fix: Show error messages directly below the relevant field; summary is optional for long forms
|
|
283
|
+
|
|
284
|
+
**P2 — Disabled states look like the component, just muted**
|
|
285
|
+
Disabled elements must still be recognizable as what they are.
|
|
286
|
+
- Violation: Disabled button has completely different shape or is invisible
|
|
287
|
+
- Fix: Same structure and shape; reduce opacity or desaturate; never remove the affordance
|
|
288
|
+
|
|
289
|
+
**P3 — Use skeleton screens for content-heavy loading**
|
|
290
|
+
Spinners create jarring pop-in for layout-heavy content. Skeleton
|
|
291
|
+
screens set spatial expectations and feel faster.
|
|
292
|
+
- Violation: A content-heavy screen (data tables, card grids, feeds, dashboards) shows only a spinner with no layout preview, then fully appears all at once
|
|
293
|
+
- Fix: Render grey placeholder shapes matching the content layout while loading; reserve spinners for small inline loading states
|
|
294
|
+
|
|
295
|
+
**P4 — Consistent alignment inside components**
|
|
296
|
+
Elements within a card, list item, or modal should align to one axis.
|
|
297
|
+
Mixing alignments inside a single component looks unpolished.
|
|
298
|
+
- Violation: Card with left-aligned title, centered body text, right-aligned button
|
|
299
|
+
- Fix: Pick one alignment for the component and apply it to all child elements
|
|
300
|
+
|
|
301
|
+
**P5 — Use selectable cards for important choices**
|
|
302
|
+
When a choice is a core part of the UI flow, plain radio buttons
|
|
303
|
+
undersell its importance and limit the information visible per option.
|
|
304
|
+
- Violation: A significant user choice (plan selection, mode selection, category assignment, onboarding path) presented as a plain stacked list of radio buttons with no supporting context visible
|
|
305
|
+
- Fix: Selectable card components that surface the key details of each option; the radio button becomes a visual detail inside the card rather than the entire UI
|
|
306
|
+
|
|
307
|
+
**P6 — Empty states need illustration and a clear CTA**
|
|
308
|
+
The empty state is often a user's first experience with a feature.
|
|
309
|
+
Plain "No items found" text is a missed opportunity.
|
|
310
|
+
- Violation: Empty list or table with only a plain text message
|
|
311
|
+
- Fix: Add an icon or illustration, a short headline, and a primary action button
|
|
312
|
+
|
|
313
|
+
**P7 — Don't upscale small icons**
|
|
314
|
+
Icons drawn at 16-24px look chunky and unprofessional at 3-4× their
|
|
315
|
+
intended size — they lack detail and feel disproportionate.
|
|
316
|
+
- Violation: 16px SVG icon inflated to 64px for a features section
|
|
317
|
+
- Fix: Wrap the icon in a larger background shape; keep the icon at its intended size inside
|
|
318
|
+
|
|
319
|
+
**P8 — Fixed containers for variable-size images**
|
|
320
|
+
User-uploaded images at their intrinsic dimensions break layout
|
|
321
|
+
consistency.
|
|
322
|
+
- Violation: User avatars or uploaded photos at intrinsic size causing layout shift
|
|
323
|
+
- Fix: Crop into a fixed container using object-fit: cover
|
|
324
|
+
|
|
325
|
+
**P9 — Prevent image background bleed**
|
|
326
|
+
When an image's background color is similar to the page background,
|
|
327
|
+
the image loses its shape and visual boundary.
|
|
328
|
+
- Violation: An image whose background color closely matches the surrounding page background — the edges become invisible and the image appears to dissolve into the page
|
|
329
|
+
- Fix: Use a subtle inner shadow on the image container to create a soft boundary; avoid hard borders which clash with image colors
|
|
330
|
+
|
|
331
|
+
**P10 — Text over images needs a contrast treatment**
|
|
332
|
+
Background photos with mixed light/dark areas make overlaid text
|
|
333
|
+
unreliable regardless of text color.
|
|
334
|
+
- Violation: White text on a hero image — disappears in light photo areas
|
|
335
|
+
- Fix: Dark semi-transparent overlay, lowered image contrast, or a colorized tint
|
|
336
|
+
|
|
337
|
+
---
|
|
338
|
+
|
|
339
|
+
## 8. ACCESSIBILITY
|
|
340
|
+
|
|
341
|
+
**A1 — Meet minimum contrast ratios**
|
|
342
|
+
WCAG AA: normal text (under 18px regular / 14px bold) needs 4.5:1.
|
|
343
|
+
Large text needs 3:1.
|
|
344
|
+
- Violation: Light grey placeholder or secondary text on white background
|
|
345
|
+
- Fix: Darken text until contrast ratio is met; verify with a contrast checker
|
|
346
|
+
|
|
347
|
+
**A2 — Focus states must be visible and distinct**
|
|
348
|
+
Every interactive element needs a visible focus indicator for keyboard
|
|
349
|
+
navigation. Color change alone is not sufficient.
|
|
350
|
+
- Violation: Focused button looks identical to its default state
|
|
351
|
+
- Fix: Add a visible 2px offset outline or ring in the brand color on :focus-visible
|
|
352
|
+
|
|
353
|
+
**A3 — Touch targets minimum 44×44px**
|
|
354
|
+
Small tap targets cause errors on mobile, especially for users with
|
|
355
|
+
motor impairments.
|
|
356
|
+
- Violation: Interactive elements (icon buttons, checkboxes, toggles, small links) whose tappable area is clearly smaller than a comfortable finger tap
|
|
357
|
+
- Fix: Pad the interactive area to at least 44×44px even if the visible element is smaller; the padding can be invisible
|
|
358
|
+
|
|
359
|
+
**A4 — Never use placeholder as the only label**
|
|
360
|
+
Placeholder text disappears when the user starts typing, leaving them
|
|
361
|
+
without context. It is not a label substitute.
|
|
362
|
+
- Violation: Form fields with only placeholder text and no persistent label
|
|
363
|
+
- Fix: Always include a visible label above or beside the field; placeholder can supplement it
|
|
364
|
+
|
|
365
|
+
**A5 — Don't rely solely on position to communicate meaning**
|
|
366
|
+
Meaning that depends only on spatial position (left = negative, right =
|
|
367
|
+
positive) breaks for screen readers and different reading patterns.
|
|
368
|
+
- Violation: Comparison table where left/right column position is the only positive/negative indicator
|
|
369
|
+
- Fix: Add explicit labels, icons, or color alongside positional meaning
|
|
370
|
+
|
|
371
|
+
---
|
|
372
|
+
|
|
373
|
+
## 9. FINISHING TOUCHES
|
|
374
|
+
|
|
375
|
+
**F1 — Accent borders add personality to flat sections**
|
|
376
|
+
A single colored border (top of card, left of alert, under headline)
|
|
377
|
+
adds visual character with minimal effort.
|
|
378
|
+
- Violation: Functional but visually flat alert messages or cards with no personality
|
|
379
|
+
- Fix: Add a 3-4px colored top or left border in the brand or semantic color
|
|
380
|
+
|
|
381
|
+
**F2 — Decorate backgrounds deliberately**
|
|
382
|
+
Flat single-color backgrounds can feel plain. A subtle gradient, tinted
|
|
383
|
+
panel, or low-contrast pattern adds interest without distraction.
|
|
384
|
+
- Violation: Long page sections that are identical flat white — no visual rhythm
|
|
385
|
+
- Fix: Alternate background tints between sections, or add a subtle brand-color gradient
|
|
386
|
+
|
|
387
|
+
**F3 — Use fewer borders**
|
|
388
|
+
Over-bordering makes interfaces feel rigid and cluttered. Borders should
|
|
389
|
+
be a last resort for separation, not the default.
|
|
390
|
+
- Violation: Every section, row, and card outlined with 1px solid borders
|
|
391
|
+
- Fix: Replace with background color differentiation, increased spacing, or box-shadow
|
|
392
|
+
|
|
393
|
+
**F4 — Elevate default form controls**
|
|
394
|
+
Browser-default checkboxes, radio buttons, and selects look out of place
|
|
395
|
+
in a polished UI.
|
|
396
|
+
- Violation: Default OS-style checkboxes in an otherwise well-designed form
|
|
397
|
+
- Fix: Custom controls in brand color; consistent styling across all form elements
|
package/ui-audit.skill
ADDED
|
Binary file
|