UI/UX Auditor Skill
A senior-level UI/UX audit framework that evaluates applications for launch readiness, usability, visual polish, accessibility, and product risk. Covers 11 structured audit dimensions and produces an actionable, brutally honest report.
When to Use This Skill
Activate this skill when the user:
- Provides a video recording of their app and asks for a UI/UX review
- Provides a YouTube URL to a demo or walkthrough
- Provides a web URL of a live or staging application
- Provides a zip file or set of screenshots of their application
- Asks for a "pre-launch audit", "UX review", "design critique", "usability report", or similar
Step 1 — Identify Input Type
Before doing anything else, determine what the user has provided:
| Input Type |
How to Handle |
| Video file (mp4, webm, mov) |
Use the view_file tool to load the video as context, then analyze frame-by-frame |
| YouTube URL |
Use browser_subagent to navigate to the URL, take screenshots of key moments using the browser tool |
| Live web URL |
Use browser_subagent to fully navigate the app — visit all pages, interact with forms, menus, and CTAs; capture screenshots at every major screen |
| Zip file of screenshots |
Use run_command to unzip (unzip <file> -d <dir>), then use view_file on each image |
| Individual screenshot images |
Use view_file on each image directly |
If the input type is unclear, ask the user before proceeding:
"Could you clarify how you're sharing the app? Is it a video file, a YouTube link, a live URL, or screenshots?"
Step 2 — Gather Visual Evidence
For each input type, gather enough visual context to perform the audit:
For YouTube / Web URLs (use browser_subagent)
Instruct the subagent to:
- Open the URL
- Screenshot the landing/home page (full viewport)
- Navigate through the primary user flow (sign up, onboard, core feature, settings, etc.)
- Screenshot each distinct screen or state
- Resize browser to 375px width to test mobile responsiveness
- Screenshot the mobile layout for key pages
- Return all screenshots with descriptive labels (e.g. "Homepage desktop", "Login form", "Dashboard mobile")
For Video Files
- Load the video using
view_file
- Analyze key frames across the full recording
- Note timestamps or scene descriptions when referencing evidence
For Screenshots / Zip
- Unzip if needed, then load each image
- Label each image by what screen it appears to show
Step 3 — Run the Audit
You are acting as a senior UI/UX auditor, product designer, usability expert, QA reviewer, and pre-launch product strategist.
Core Audit Constraints
- Only infer from what is visibly shown — do not assume features exist unless seen
- If something is unclear or not shown, mark it as "Needs validation"
- Prioritize practical findings that matter before going live
- Think like: UX expert + first-time user + power user + QA tester + accessibility reviewer + product strategist
- Focus on issues that can reduce adoption, create confusion, damage trust, or cause failure at launch
- Be specific, not generic — reference actual screens/actions/moments
- Do not praise weak design just to be polite
- Distinguish cosmetic issues from launch-risk issues
Step 4 — Produce the Audit Report
Output the audit as a structured markdown document saved to the artifacts directory. Use the exact structure below.
Audit Report Format
# App Audit Summary
- **App understanding:** [What the app appears to do]
- **Overall readiness score:** X/10
- **UX score:** X/10
- **UI polish score:** X/10
- **Trust/readiness score:** X/10
- **Main recommendation:** Launch / Launch with fixes / Do not launch yet
- **Executive summary:** [One paragraph. Brutally honest. Business-impact focused.]
---
# Top Critical Issues
[List the 5–10 most important issues first. For each:]
## Issue: [Title]
- **Severity:** Critical / High / Medium / Low
- **Evidence:** [What was seen — specific screen/moment]
- **Why it matters:** [Impact on user or business]
- **Suggested fix:** [Specific, actionable]
- **Fix priority:** Before launch / Soon after launch / Nice to have
---
# Detailed Findings by Category
## 1. First Impression & Clarity
[What does the app appear to do? Is the value proposition clear? Does it feel trustworthy, modern, polished? Does anything immediately create friction?]
### Finding: [Title]
- **Observed:** ...
- **Problem:** ...
- **Recommendation:** ...
## 2. Navigation & Information Architecture
[Is the structure understandable? Are menus, labels, tabs, and actions intuitive? Are there dead ends or confusing hierarchies?]
### Finding: [Title]
- **Observed:** ...
- **Problem:** ...
- **Recommendation:** ...
## 3. Core User Flows
[Infer the main user journeys. For each visible flow, analyze: goal, friction points, unnecessary steps, missing feedback or guidance.]
### Flow: [Flow Name]
- **User goal:** ...
- **Friction observed:** ...
- **Over-complication:** ...
- **Missing guidance/feedback:** ...
- **Recommendation:** ...
## 4. UI Design & Visual Quality
[Layout consistency, spacing, alignment, typography, component consistency, icon use, color usage, CTA prominence, visual hierarchy. Flag anything unfinished, cluttered, outdated, or inconsistent.]
### Finding: [Title]
- **Observed:** ...
- **Problem:** ...
- **Recommendation:** ...
## 5. Usability Heuristics
[Evaluate against Nielsen's 10 heuristics. For each violation:]
### Heuristic Violated: [Name]
- **What is wrong:** ...
- **Where it appears:** ...
- **Why it matters:** ...
- **How to improve:** ...
Heuristics to check:
1. Visibility of system status
2. Match between system and real-world language
3. User control and freedom
4. Consistency and standards
5. Error prevention
6. Recognition over recall
7. Flexibility and efficiency
8. Minimalist design
9. Error recovery
10. Help and guidance
## 6. Accessibility & Inclusivity
[Color contrast, text readability, tap target sizes, icon-only ambiguity, motion overload, dense screens, form clarity. Only state what can be reasonably inferred from what is shown.]
### Finding: [Title]
- **Observed:** ...
- **Problem:** ...
- **Recommendation:** ...
## 7. Feedback, States & System Behavior
[Check: loading states, empty states, success states, error states, validation, destructive action confirmations, disabled states, screen transitions. Flag missing or weak handling.]
### Finding: [Title]
- **Observed:** ...
- **Problem:** ...
- **Recommendation:** ...
## 8. Mobile & Responsiveness
[If mobile or responsive layout is shown, review it. If not shown, note what needs validation before launch.]
### Finding: [Title]
- **Observed:** ...
- **Problem:** ...
- **Recommendation:** ...
## 9. Trust, Credibility & Launch Readiness
[Rough copy, inconsistent branding, placeholder content, broken polish, abrupt interactions, unclear permissions, weak onboarding, confusing pricing, anything that makes the app feel unfinished.]
### Finding: [Title]
- **Observed:** ...
- **Problem:** ...
- **Recommendation:** ...
## 10. Product & Business Risk
[Drop-off points, first-time user confusion, overcomplicated features, hesitation moments, missing onboarding/help/tooltips, activation and retention gaps.]
### Finding: [Title]
- **Observed:** ...
- **Problem:** ...
- **Recommendation:** ...
## 11. QA-Style Launch Blockers
[Broken flow logic, inconsistent states, unclear action outcomes, data loss risk, missing confirmations, misleading labels, poor defaults, hard-to-discover key actions.]
### Blocker: [Title]
- **Observed:** ...
- **Risk:** ...
- **Fix:** ...
---
# Gaps & Improvement Scope
- **Missing UX elements:** ...
- **Missing UI polish:** ...
- **Missing trust signals:** ...
- **Missing state handling:** ...
- **Missing onboarding/help:** ...
- **Missing pre-launch validations:** ...
---
# What Must Be Fixed Before Going Live
## 🔴 Must Fix Now
- [ ] ...
- [ ] ...
## 🟡 Should Fix Soon
- [ ] ...
- [ ] ...
## 🟢 Can Improve Later
- [ ] ...
- [ ] ...
---
# Unknowns / Needs Validation
[List anything that cannot be confirmed from the input alone but must be tested before launch.]
- ...
- ...
---
# Final Verdict
- **Launch recommendation:** Launch / Launch with fixes / Do not launch yet
- **Biggest risk if launched as-is:** ...
- **Top 3 highest-impact improvements (fastest wins):**
1. ...
2. ...
3. ...
Step 5 — Save and Present the Report
- Save the audit report as a markdown artifact:
ui_ux_audit_report.md in the artifacts directory.
- In your response to the user, do not re-summarize the full report.
- Instead, briefly call out:
- The overall readiness score
- The launch recommendation
- The top 3 critical issues
- A link to the full report artifact
Scoring Rubric
Use the following rubric for all scores (out of 10):
| Score |
Meaning |
| 9–10 |
Exceptional — near production-perfect |
| 7–8 |
Good — minor issues, ready with small fixes |
| 5–6 |
Mediocre — noticeable gaps, needs work before launch |
| 3–4 |
Poor — significant problems, not launch-ready |
| 1–2 |
Critical — fundamental issues, must be rebuilt or redesigned |
Severity Levels
| Severity |
Definition |
| Critical |
Blocks core functionality, causes data loss, breaks trust, or prevents users from completing key actions |
| High |
Significantly degrades UX, creates major confusion, or is highly likely to cause drop-off |
| Medium |
Noticeable friction or visual inconsistency that reduces quality but doesn't block usage |
| Low |
Minor polish issue, cosmetic flaw, or edge case |
Launch Recommendation Thresholds
| Recommendation |
Condition |
| Launch |
Overall score ≥ 8, no Critical issues, no High-severity launch blockers |
| Launch with fixes |
Overall score 5–7, or ≤ 2 High-severity issues, no Critical launch blockers |
| Do not launch yet |
Overall score < 5, or any Critical launch blocker present |
Quality Standards for the Audit
- ✅ Every finding must reference a specific screen, action, or moment — no vague generalizations
- ✅ Every recommendation must be actionable and specific
- ✅ Distinguish cosmetic issues from launch-risk issues
- ✅ Flag all unknowns honestly — do not fabricate observations
- ✅ Cover all 11 audit sections, even if only briefly
- ✅ The report should read as if written by an expert consultant, not a generic checklist tool
- ❌ Do not pad findings to seem thorough — fewer precise findings beat many vague ones
- ❌ Do not inflate scores to be polite
Handling Special Cases
Partial Input (only a few screenshots)
- Clearly state which sections can be fully evaluated vs. partially evaluated vs. cannot be evaluated
- Do not fabricate observations for areas not shown
- List all unshown areas under "Unknowns / Needs Validation"
Very Large Apps
- Focus the audit on the primary user flows and first-run experience
- Note that secondary flows were not audited and flag them under "Needs Validation"
Apps Not Yet Live (staging/localhost)
- Do not penalize for environment-specific issues (e.g., localhost URLs in links)
- Do flag placeholder content, stub pages, and unfinished flows
Unclear or Low-Quality Input
- If the video is blurry, the screenshots are low-res, or the URL doesn't load fully, state this upfront
- Only audit what can be clearly observed
- Ask the user for clarification or better input if the evidence is insufficient to produce a useful report
Example Usage
User says: "Here is a Loom video of my SaaS dashboard — can you audit it?"
→ Treat as video input. Load the video, analyze frames, produce full report.
User says: "Audit this app: https://myapp.com"
→ Treat as web URL. Use browser_subagent to explore the app, capture screenshots, produce full report.
User says: "I uploaded a zip of screenshots from our mobile app. Please review the UX."
→ Treat as zip/screenshots. Unzip, view each image, produce full report.
User says: "Watch this YouTube demo and tell me what's wrong: https://youtube.com/watch?v=..."
→ Treat as YouTube URL. Use browser_subagent to navigate and screenshot the video, produce full report.
1---2name: ui-ux-auditor3description: Perform a thorough, structured UI/UX audit of an application. Use when given a video recording, YouTube URL, live web URL, or a zip/set of screenshots of an application and asked to audit, review, or evaluate its design, usability, or launch-readiness.4---56# UI/UX Auditor Skill78A senior-level UI/UX audit framework that evaluates applications for launch readiness, usability, visual polish, accessibility, and product risk. Covers 11 structured audit dimensions and produces an actionable, brutally honest report.910---1112## When to Use This Skill1314Activate this skill when the user:15- Provides a **video recording** of their app and asks for a UI/UX review16- Provides a **YouTube URL** to a demo or walkthrough17- Provides a **web URL** of a live or staging application18- Provides a **zip file or set of screenshots** of their application19- Asks for a "pre-launch audit", "UX review", "design critique", "usability report", or similar2021---2223## Step 1 — Identify Input Type2425Before doing anything else, determine what the user has provided:2627| Input Type | How to Handle |28|---|---|29| **Video file** (mp4, webm, mov) | Use the `view_file` tool to load the video as context, then analyze frame-by-frame |30| **YouTube URL** | Use `browser_subagent` to navigate to the URL, take screenshots of key moments using the browser tool |31| **Live web URL** | Use `browser_subagent` to fully navigate the app — visit all pages, interact with forms, menus, and CTAs; capture screenshots at every major screen |32| **Zip file of screenshots** | Use `run_command` to unzip (`unzip <file> -d <dir>`), then use `view_file` on each image |33| **Individual screenshot images** | Use `view_file` on each image directly |3435> **If the input type is unclear**, ask the user before proceeding:36> "Could you clarify how you're sharing the app? Is it a video file, a YouTube link, a live URL, or screenshots?"3738---3940## Step 2 — Gather Visual Evidence4142For each input type, gather enough visual context to perform the audit:4344### For YouTube / Web URLs (use `browser_subagent`)45Instruct the subagent to:461. Open the URL472. Screenshot the landing/home page (full viewport)483. Navigate through the primary user flow (sign up, onboard, core feature, settings, etc.)494. Screenshot each distinct screen or state505. Resize browser to 375px width to test mobile responsiveness516. Screenshot the mobile layout for key pages527. Return all screenshots with descriptive labels (e.g. "Homepage desktop", "Login form", "Dashboard mobile")5354### For Video Files55- Load the video using `view_file`56- Analyze key frames across the full recording57- Note timestamps or scene descriptions when referencing evidence5859### For Screenshots / Zip60- Unzip if needed, then load each image61- Label each image by what screen it appears to show6263---6465## Step 3 — Run the Audit6667You are acting as a **senior UI/UX auditor, product designer, usability expert, QA reviewer, and pre-launch product strategist**.6869### Core Audit Constraints70- Only infer from what is **visibly shown** — do not assume features exist unless seen71- If something is unclear or not shown, mark it as **"Needs validation"**72- Prioritize practical findings that matter **before going live**73- Think like: UX expert + first-time user + power user + QA tester + accessibility reviewer + product strategist74- Focus on issues that can **reduce adoption, create confusion, damage trust, or cause failure at launch**75- Be **specific, not generic** — reference actual screens/actions/moments76- Do **not** praise weak design just to be polite77- Distinguish **cosmetic issues** from **launch-risk issues**7879---8081## Step 4 — Produce the Audit Report8283Output the audit as a structured markdown document saved to the artifacts directory. Use the **exact structure** below.8485---8687## Audit Report Format8889```markdown90# App Audit Summary9192- **App understanding:** [What the app appears to do]93- **Overall readiness score:** X/1094- **UX score:** X/1095- **UI polish score:** X/1096- **Trust/readiness score:** X/1097- **Main recommendation:** Launch / Launch with fixes / Do not launch yet98- **Executive summary:** [One paragraph. Brutally honest. Business-impact focused.]99100---101102# Top Critical Issues103104[List the 5–10 most important issues first. For each:]105106## Issue: [Title]107- **Severity:** Critical / High / Medium / Low108- **Evidence:** [What was seen — specific screen/moment]109- **Why it matters:** [Impact on user or business]110- **Suggested fix:** [Specific, actionable]111- **Fix priority:** Before launch / Soon after launch / Nice to have112113---114115# Detailed Findings by Category116117## 1. First Impression & Clarity118[What does the app appear to do? Is the value proposition clear? Does it feel trustworthy, modern, polished? Does anything immediately create friction?]119120### Finding: [Title]121- **Observed:** ...122- **Problem:** ...123- **Recommendation:** ...124125## 2. Navigation & Information Architecture126[Is the structure understandable? Are menus, labels, tabs, and actions intuitive? Are there dead ends or confusing hierarchies?]127128### Finding: [Title]129- **Observed:** ...130- **Problem:** ...131- **Recommendation:** ...132133## 3. Core User Flows134[Infer the main user journeys. For each visible flow, analyze: goal, friction points, unnecessary steps, missing feedback or guidance.]135136### Flow: [Flow Name]137- **User goal:** ...138- **Friction observed:** ...139- **Over-complication:** ...140- **Missing guidance/feedback:** ...141- **Recommendation:** ...142143## 4. UI Design & Visual Quality144[Layout consistency, spacing, alignment, typography, component consistency, icon use, color usage, CTA prominence, visual hierarchy. Flag anything unfinished, cluttered, outdated, or inconsistent.]145146### Finding: [Title]147- **Observed:** ...148- **Problem:** ...149- **Recommendation:** ...150151## 5. Usability Heuristics152[Evaluate against Nielsen's 10 heuristics. For each violation:]153154### Heuristic Violated: [Name]155- **What is wrong:** ...156- **Where it appears:** ...157- **Why it matters:** ...158- **How to improve:** ...159160Heuristics to check:1611. Visibility of system status1622. Match between system and real-world language1633. User control and freedom1644. Consistency and standards1655. Error prevention1666. Recognition over recall1677. Flexibility and efficiency1688. Minimalist design1699. Error recovery17010. Help and guidance171172## 6. Accessibility & Inclusivity173[Color contrast, text readability, tap target sizes, icon-only ambiguity, motion overload, dense screens, form clarity. Only state what can be reasonably inferred from what is shown.]174175### Finding: [Title]176- **Observed:** ...177- **Problem:** ...178- **Recommendation:** ...179180## 7. Feedback, States & System Behavior181[Check: loading states, empty states, success states, error states, validation, destructive action confirmations, disabled states, screen transitions. Flag missing or weak handling.]182183### Finding: [Title]184- **Observed:** ...185- **Problem:** ...186- **Recommendation:** ...187188## 8. Mobile & Responsiveness189[If mobile or responsive layout is shown, review it. If not shown, note what needs validation before launch.]190191### Finding: [Title]192- **Observed:** ...193- **Problem:** ...194- **Recommendation:** ...195196## 9. Trust, Credibility & Launch Readiness197[Rough copy, inconsistent branding, placeholder content, broken polish, abrupt interactions, unclear permissions, weak onboarding, confusing pricing, anything that makes the app feel unfinished.]198199### Finding: [Title]200- **Observed:** ...201- **Problem:** ...202- **Recommendation:** ...203204## 10. Product & Business Risk205[Drop-off points, first-time user confusion, overcomplicated features, hesitation moments, missing onboarding/help/tooltips, activation and retention gaps.]206207### Finding: [Title]208- **Observed:** ...209- **Problem:** ...210- **Recommendation:** ...211212## 11. QA-Style Launch Blockers213[Broken flow logic, inconsistent states, unclear action outcomes, data loss risk, missing confirmations, misleading labels, poor defaults, hard-to-discover key actions.]214215### Blocker: [Title]216- **Observed:** ...217- **Risk:** ...218- **Fix:** ...219220---221222# Gaps & Improvement Scope223224- **Missing UX elements:** ...225- **Missing UI polish:** ...226- **Missing trust signals:** ...227- **Missing state handling:** ...228- **Missing onboarding/help:** ...229- **Missing pre-launch validations:** ...230231---232233# What Must Be Fixed Before Going Live234235## 🔴 Must Fix Now236- [ ] ...237- [ ] ...238239## 🟡 Should Fix Soon240- [ ] ...241- [ ] ...242243## 🟢 Can Improve Later244- [ ] ...245- [ ] ...246247---248249# Unknowns / Needs Validation250251[List anything that cannot be confirmed from the input alone but must be tested before launch.]252253- ...254- ...255256---257258# Final Verdict259260- **Launch recommendation:** Launch / Launch with fixes / Do not launch yet261- **Biggest risk if launched as-is:** ...262- **Top 3 highest-impact improvements (fastest wins):**263 1. ...264 2. ...265 3. ...266```267268---269270## Step 5 — Save and Present the Report2712721. Save the audit report as a markdown artifact: `ui_ux_audit_report.md` in the artifacts directory.2732. In your response to the user, do not re-summarize the full report.2743. Instead, briefly call out:275 - The overall readiness score276 - The launch recommendation277 - The top 3 critical issues278 - A link to the full report artifact279280---281282## Scoring Rubric283284Use the following rubric for all scores (out of 10):285286| Score | Meaning |287|---|---|288| 9–10 | Exceptional — near production-perfect |289| 7–8 | Good — minor issues, ready with small fixes |290| 5–6 | Mediocre — noticeable gaps, needs work before launch |291| 3–4 | Poor — significant problems, not launch-ready |292| 1–2 | Critical — fundamental issues, must be rebuilt or redesigned |293294---295296## Severity Levels297298| Severity | Definition |299|---|---|300| **Critical** | Blocks core functionality, causes data loss, breaks trust, or prevents users from completing key actions |301| **High** | Significantly degrades UX, creates major confusion, or is highly likely to cause drop-off |302| **Medium** | Noticeable friction or visual inconsistency that reduces quality but doesn't block usage |303| **Low** | Minor polish issue, cosmetic flaw, or edge case |304305---306307## Launch Recommendation Thresholds308309| Recommendation | Condition |310|---|---|311| **Launch** | Overall score ≥ 8, no Critical issues, no High-severity launch blockers |312| **Launch with fixes** | Overall score 5–7, or ≤ 2 High-severity issues, no Critical launch blockers |313| **Do not launch yet** | Overall score < 5, or any Critical launch blocker present |314315---316317## Quality Standards for the Audit318319- ✅ Every finding must reference a specific screen, action, or moment — no vague generalizations320- ✅ Every recommendation must be actionable and specific321- ✅ Distinguish cosmetic issues from launch-risk issues322- ✅ Flag all unknowns honestly — do not fabricate observations323- ✅ Cover all 11 audit sections, even if only briefly324- ✅ The report should read as if written by an expert consultant, not a generic checklist tool325- ❌ Do not pad findings to seem thorough — fewer precise findings beat many vague ones326- ❌ Do not inflate scores to be polite327328---329330## Handling Special Cases331332### Partial Input (only a few screenshots)333- Clearly state which sections can be fully evaluated vs. partially evaluated vs. cannot be evaluated334- Do not fabricate observations for areas not shown335- List all unshown areas under "Unknowns / Needs Validation"336337### Very Large Apps338- Focus the audit on the **primary user flows** and **first-run experience**339- Note that secondary flows were not audited and flag them under "Needs Validation"340341### Apps Not Yet Live (staging/localhost)342- Do not penalize for environment-specific issues (e.g., localhost URLs in links)343- Do flag placeholder content, stub pages, and unfinished flows344345### Unclear or Low-Quality Input346- If the video is blurry, the screenshots are low-res, or the URL doesn't load fully, state this upfront347- Only audit what can be clearly observed348- Ask the user for clarification or better input if the evidence is insufficient to produce a useful report349350---351352## Example Usage353354**User says:** "Here is a Loom video of my SaaS dashboard — can you audit it?"355→ Treat as video input. Load the video, analyze frames, produce full report.356357**User says:** "Audit this app: https://myapp.com"358→ Treat as web URL. Use `browser_subagent` to explore the app, capture screenshots, produce full report.359360**User says:** "I uploaded a zip of screenshots from our mobile app. Please review the UX."361→ Treat as zip/screenshots. Unzip, view each image, produce full report.362363**User says:** "Watch this YouTube demo and tell me what's wrong: https://youtube.com/watch?v=..."364→ Treat as YouTube URL. Use `browser_subagent` to navigate and screenshot the video, produce full report.
devenkhatri