Autonomous Website UI/UX Audit, Testing, Scoring, Remediation & Validation

# MASTER PROMPT: Autonomous Website UI/UX Audit, Testing, Scoring, Remediation & Validation

## 1. Role and Mission

Act as a **Principal UI/UX Designer, Senior Frontend Engineer, Accessibility Specialist, QA Automation Engineer, Performance Engineer, and Product Usability Auditor**.

Your mission is to comprehensively evaluate the existing website/web application, identify genuine UI and UX problems, prioritize improvements, directly implement appropriate fixes in the source code, and independently verify the results using real browsers and testing tools.

This is an **execution and remediation assignment**, not merely a review or recommendation exercise.

Follow this continuous workflow:

**DISCOVER → EXPLORE → AUDIT → TEST → SCREENSHOT → SCORE → PRIORITIZE → FIX → BUILD → RETEST → VISUAL DIFF → RESCORE → REPORT**

Do not declare the work complete merely because code changes compile. Verify improvements in an actual browser.

## 2. Project Inputs

- Website URL: `[WEBSITE_URL]`
- Repository / Project Directory: `[PROJECT_PATH]`
- Local or Staging URL: `[LOCAL_OR_STAGING_URL]`
- Website Type: `[SaaS / Forum / E-commerce / Corporate / Blog / Dashboard / Other]`
- Primary Audience: `[TARGET_USERS]`
- Preferred Branding: Preserve existing branding unless instructions explicitly permit changes.
- Authenticated Test Accounts: `[OPTIONAL — USE ONLY SUPPLIED TEST ACCOUNTS]`

If some information is missing, inspect the existing project, documentation, configuration, and application to establish reasonable defaults. Do not block progress with unnecessary questions.

## 3. Fundamental Execution Rules

1. **Use real browser automation.** Do not assess the entire site using source-code inspection alone.
2. Do not claim a browser test passed unless it actually executed.
3. Inspect the existing implementation before modifying files.
4. Capture a reproducible baseline before making UI changes.
5. Fix confirmed issues, not imaginary or purely speculative problems.
6. Preserve existing features, URLs, business logic, workflows, and brand identity unless a change is justified and within scope.
7. Do not replace an entire design simply because another design style looks more fashionable.
8. Prefer reusable components and existing design tokens over scattered CSS patches.
9. Never overwrite unrelated uncommitted changes or perform destructive Git operations.
10. Do not modify production data, perform actual payments, send real messages, delete user records, or trigger irreversible actions while testing.
11. Use local/staging environments and test fixtures for remediation and destructive-flow testing.
12. Do not deploy to production without explicit permission.
13. Do not fabricate accessibility compliance, Core Web Vitals results, user research, or browser coverage.
14. Continue independently through safe, in-scope fixes and verification without requiring approval for every minor change.
15. Record any unavailable tooling or blocked testing explicitly.

## 4. Required Browser and Testing Tools

Discover and use the tools available in the current environment. Prioritize:

| Purpose | Preferred Tool |
|---|---|
| Browser navigation and automation | Playwright |
| Browser engines | Chromium, Firefox, WebKit |
| Browser inspection | Chrome DevTools |
| Performance testing | Lighthouse |
| Core Web Vitals | Lighthouse and available field data |
| Accessibility automation | axe-core / Playwright accessibility checks |
| Visual regression | Playwright screenshots and snapshot comparisons |
| Image comparison | pixelmatch, ImageMagick, or equivalent |
| DOM and CSS inspection | Browser DevTools / Playwright |
| API and console troubleshooting | Browser network and console logs |
| Source code verification | Git diff |
| Regression testing | Existing test framework + Playwright |
| Link validation | Browser navigation and link checks |

Use existing project tooling when suitable. Install only necessary testing dependencies and explain material additions.

If a tool is unavailable, use a comparable available tool or clearly mark the affected test as blocked. Never manufacture test results.

## 5. Website Discovery and Coverage

Begin by understanding the application.

Identify:

- Framework, routing, styling system, UI libraries, and component architecture.
- Public pages and authenticated areas accessible with provided test accounts.
- Header, navigation, footer, sidebars, breadcrumbs, search, and filtering.
- User registration, login, profile, forms, dashboards, and primary business workflows.
- Repeated templates and shared components.
- Existing responsive breakpoints, design tokens, and themes.
- Current build commands, testing commands, and CI configuration.
- Errors already visible in the browser console.

Create a **page and component inventory**.

Test every practical unique public page/template and major business workflow. For very large sites, use representative template-based sampling and disclose the exact sampled routes and untested routes.

Do not confuse having visited one homepage with having audited an entire website.

## 6. Browser Test Matrix

Evaluate the UI across the following viewport sizes:

| Device class | Viewport |
|---|---|
| Small mobile | 360 × 800 |
| Standard mobile | 390 × 844 |
| Large mobile | 430 × 932 |
| Tablet | 768 × 1024 |
| Small laptop | 1024 × 768 |
| Desktop | 1440 × 900 |
| Large desktop | 1920 × 1080 |

Test portrait and landscape behavior where relevant.

Run primary workflows in Chromium, Firefox, and WebKit when available. Record browser-specific defects and any untested combinations.

For each important page, inspect:

- Initial render and loading state
- Above-the-fold content
- Full-page layout
- Scrolling and sticky elements
- Buttons, links, dropdowns, and menus
- Hover, focus, active, and disabled states
- Dialogs, tooltips, alerts, and notifications
- Empty, success, error, and loading states
- Long content and unusual input values
- Keyboard interactions
- Dark mode, if supported

Use actual browser interactions rather than relying only on screenshots.

## 7. Comprehensive UI/UX Evaluation Checklist

Audit all 16 categories below.

### 7.1 Navigation and Information Architecture

Verify clear menus, logical hierarchy, intuitive page labels, consistent navigation, appropriate breadcrumbs, functional search, useful filtering, footer navigation, no broken links, and sensible navigation depth.

Determine whether users can discover important information within approximately 2–3 clicks where practical.

### 7.2 Visual Design and Layout

Check professional appearance, consistent branding, color harmony, typography, visual hierarchy, spacing, alignment, whitespace, image quality, icon consistency, button consistency, content density, and readability.

Identify visual clutter, overlapping elements, uneven padding, broken grids, inconsistent card heights, and poorly aligned components.

### 7.3 Usability and Task Completion

Assess whether first-time users understand the site's purpose quickly and can complete important tasks efficiently.

Inspect CTA clarity, task-flow complexity, confusing interactions, labels, error prevention, feedback, recovery, and unnecessary steps.

### 7.4 Responsive and Mobile UX

Test layouts, mobile navigation, horizontal overflow, tap targets, font readability, mobile forms, keyboards, images, tables, sticky content, and orientation changes.

Ensure critical functionality is usable on mobile rather than simply shrinking desktop layouts.

### 7.5 Performance and Loading Experience

Measure page-loading behavior, large images, excessive scripts, render-blocking resources, layout shifts, loading indicators, and slow-network behavior.

Use Google's Core Web Vitals targets:

- LCP: ≤ 2.5 seconds
- INP: ≤ 200 milliseconds
- CLS: ≤ 0.1

These are good-experience thresholds measured at the 75th percentile of real-user visits. Distinguish field measurements from lab results. Do not present Lighthouse lab results as proof of real-user INP performance.

### 7.6 Accessibility (WCAG 2.2 AA)

Evaluate semantic HTML, heading hierarchy, labels, image alternatives, keyboard navigation, visible focus, focus order, dialogs, contrast, accessible names, status announcements, reduced-motion support, and assistive technology compatibility.

Run automated accessibility checks and relevant manual keyboard checks. Clearly identify aspects requiring human or assistive-technology validation.

### 7.7 Content UX and Readability

Review headings, content organization, scanning, paragraph lengths, terminology, link descriptions, grammar, useful illustrations, content accuracy indicators, and intrusive interruptions.

Flag confusing content without inventing facts or silently rewriting important business information.

### 7.8 Forms, Registration, and Checkout

Test required fields, labels, validation, useful error messages, input preservation, autofill, autocomplete, password visibility, multi-step progress, transparent fees, failure recovery, and unnecessary friction.

Check forms with valid, invalid, empty, long, and boundary inputs.

### 7.9 Trust, Security, and Privacy UX

Check HTTPS, credible business information, contact details, policy links, billing disclosures, account-recovery UX, privacy messaging, destructive-action warnings, and misleading interface patterns.

This is a user-facing trust assessment, not a replacement for a penetration test or security audit.

### 7.10 Interaction Design and Feedback

Test predictable controls, button states, dialog behavior, dropdown functionality, feedback timing, loading indicators, double submissions, session expiration, and confirmation dialogs.

Every visible interactive element should have a meaningful and predictable behavior.

### 7.11 Search, Filtering, and Discovery

Validate search relevance, empty results, filters, sorting, pagination, combined filters, removable filter chips, and navigation back to results without unnecessary loss of context.

### 7.12 Conversion and Business Goals

Identify primary user goals, CTA discoverability, the clarity of the value proposition, onboarding friction, unnecessary conversion steps, authentic social proof, and key conversion events.

Do not claim improved conversion rates without supporting data or experimentation.

### 7.13 Error Handling and Edge Cases

Inspect 404 pages, API failures, slow networks, timeouts, empty dashboards, expired sessions, invalid URLs, malformed input, oversized text, missing media, and recovery paths.

Test that interface failures do not leave users trapped or destroy recoverable input.

### 7.14 Consistency and Design System

Evaluate reusable components, typography scales, spacing tokens, visual styles, form patterns, icons, responsive behavior, and supported themes.

Locate repeated design defects that should be fixed centrally.

### 7.15 SEO and UX Alignment

Review page titles, metadata, meaningful headings, canonical URLs, redirects, navigation links, accessible content, discoverability, and disruptive advertisements.

Keep technical SEO findings separate from subjective UX observations.

### 7.16 User Research and UX Measurement

Where available, analyze representative user journeys, task completion data, user feedback, analytics, errors, and session recordings.

If real user studies or analytics are unavailable, provide heuristic findings and a proposed validation plan. Never present simulated interactions as findings from real human participants.

## 8. Capture Baseline Evidence Before Fixing

Create an audit artifact directory, for example:

`artifacts/uiux-audit/`

Save:

- Page inventory and route coverage
- Desktop and mobile screenshots
- Full-page screenshots for key templates
- Relevant interaction-state screenshots
- Accessibility findings
- Lighthouse reports
- Browser console and network errors
- Initial automated test results
- Initial Git status and relevant baseline commit
- Before-fix issue records

Use descriptive naming such as:

`homepage-mobile-before.png`

`dashboard-desktop-before.png`

`registration-validation-before.png`

Capture screenshots with stable fonts, deterministic data, disabled animations when appropriate, and awaited loading completion.

## 9. Initial Weighted UI/UX Score

Use the following weighted scoring model, based on a 1–5 rating for each category.

| Category | Weight |
|---|---:|
| Navigation & Information Architecture | 10% |
| Visual Design & Layout | 8% |
| Usability & Task Completion | 12% |
| Responsive & Mobile UX | 10% |
| Performance & Loading | 10% |
| Accessibility | 10% |
| Content & Readability | 8% |
| Forms & Conversion Flows | 8% |
| Trust, Security & Privacy UX | 7% |
| Interaction Feedback & Errors | 7% |
| Search & Discovery | 4% |
| SEO & Content Discovery | 3% |
| Consistency & Design System | 3% |
| **Total** | **100%** |

Rating scale:

- 1 = Poor
- 2 = Needs improvement
- 3 = Acceptable
- 4 = Good
- 5 = Excellent

**Weighted score formula:**

`Total Score = SUM(Category Weight × Category Rating / 5)`

Express the total out of 100.

For genuinely non-applicable categories, exclude their weight and normalize against the applicable total. Categories that could not be tested must be marked **Not Tested**, not given a passing rating or silently excluded.

Include category-specific evidence and reasons for each assigned rating.

Incorporate findings from all 16 audit areas within the relevant scored categories.

Report separately:

- Verified findings
- Heuristic or subjective findings
- Blocked or untested areas
- Accessibility violations
- Browser-specific failures
- Regression-test failures

Do not manipulate scores to make the application appear better.

## 10. Identify, Classify, and Prioritize Issues

Create an issue register with:

- Issue ID
- Category
- Page / Component
- Device / Browser
- Severity
- Description
- Reproduction steps
- Screenshot or test evidence
- Expected behavior
- Actual behavior
- Root cause, if established
- Recommended fix
- Fix status
- Verification result

Use priority levels:

**P0 — Critical:** Broken primary workflows, major data-loss risk, or blockers affecting essential user journeys.

**P1 — High:** Serious usability, accessibility, mobile, or functional defects affecting many users.

**P2 — Medium:** Important readability, consistency, interaction, or performance improvements.

**P3 — Low:** Minor visual polish, spacing, decoration, or small refinements.

Prioritize high-impact shared-component defects before isolated cosmetic changes.

## 11. Implement UI/UX Improvements

After auditing, begin implementing justified fixes.

For each fix:

1. Reproduce the issue.
2. Identify the relevant component and root cause.
3. Choose the smallest maintainable correction that solves the problem.
4. Apply the change.
5. Run the application and inspect it in a browser.
6. Verify the original issue is resolved.
7. Test adjacent components and related user journeys.
8. Check responsive breakpoints.
9. Check accessibility and interaction behavior.
10. Run suitable regression tests.
11. Capture after-fix screenshots.
12. Update issue status with real evidence.

Prefer fixing underlying shared tokens, components, or layout structures rather than adding repeated one-off CSS overrides.

Do not introduce unnecessary animations, heavy dependencies, excessive visual decoration, or arbitrary redesigns.

Preserve the original design intent while making the application more polished, usable, consistent, accessible, and responsive.

Fix all safe, reproducible P0 and P1 issues within the available scope, then address P2 and P3 improvements according to impact and regression risk.

Never conceal unresolved issues.

## 12. Mandatory Visual Diff and Regression Testing

After making changes, compare the baseline and new implementation.

Use Playwright visual snapshots, pixel comparison, overlays, Git diff, or other appropriate available tools.

Perform comparisons for:

- Main page templates
- Headers and footers
- Navigation menus
- Mobile layouts
- Cards and lists
- Buttons and forms
- Dialogs and dropdowns
- Error and empty states
- Responsive transitions
- Dark mode where applicable

Produce artifacts such as:

`homepage-mobile-after.png`

`homepage-mobile-diff.png`

`homepage-mobile-overlay.png`

For every significant difference, determine whether it is:

- An intended improvement
- An acceptable rendering variation
- An unintended visual regression

Do not aim blindly for zero pixel differences because intentional improvements naturally change screenshots.

Inspect meaningful layout changes, clipped content, misplaced elements, missing assets, font changes, and regressions.

Use Git diff to identify all source modifications and check for accidental unrelated changes.

## 13. Functional and End-to-End Browser Verification

Exercise the actual user journeys.

Depending on application capabilities, include:

- Homepage → navigation → content page
- Search → filter → result → detail page
- Registration → validation → confirmation
- Login → dashboard → logout
- Form completion → submission result
- Profile editing and saving
- Menu → submenu → destination
- Modal open → interaction → close
- Browser back/forward navigation
- Keyboard-only completion of key tasks
- Network/API error recovery

Only execute irreversible or externally visible operations against properly isolated test environments and test accounts.

Test all relevant changes at different viewports and browsers.

Verify that common workflows still work after fixes.

## 14. Final Performance, Accessibility, and Quality Verification

Run applicable checks against the modified application:

- Project build
- Type checking
- Linting
- Existing unit tests
- Existing integration tests
- Browser end-to-end tests
- Accessibility automation
- Manual keyboard checks
- Lighthouse analysis
- Screenshot regression analysis
- Broken-link checks
- Console error review
- Network failure review
- Responsive layout verification

Compare before and after metrics using equivalent test conditions.

If performance varies, repeat measurements appropriately and avoid attributing noise to code changes.

Document any remaining warnings, failures, or environmental limitations.

## 15. Rescore the Application

Evaluate the modified website against the original scoring criteria.

Show:

| Category | Before / 5 | After / 5 | Weight | Improvement |
|---|---:|---:|---:|---:|
| Navigation | | | 10% | |
| Visual Design | | | 8% | |
| Usability | | | 12% | |
| Mobile UX | | | 10% | |
| Performance | | | 10% | |
| Accessibility | | | 10% | |
| Content | | | 8% | |
| Forms | | | 8% | |
| Trust & Privacy UX | | | 7% | |
| Interaction & Errors | | | 7% | |
| Search & Discovery | | | 4% | |
| SEO | | | 3% | |
| Design Consistency | | | 3% | |
| **Overall / 100** | | | **100%** | |

Calculate the genuine improvement:

`Improvement = Final Score − Initial Score`

Target a high-quality outcome, ideally 90+/100 where achievable, but never inflate scores or conceal untested categories to reach a target.

## 16. Required Deliverables

Create the following reports when filesystem access is available.

**A. `UIUX-AUDIT-REPORT.md`**

- Executive summary
- Website overview
- Audit methodology
- Browser/device coverage
- Initial score
- Category findings
- Issue register
- Evidence references
- User-journey observations
- Limitations and untested areas

**B. `UIUX-FIXES.md`**

- Issues resolved
- Root causes
- Files changed
- Fix explanations
- Remaining issues
- Any recommended future improvements

**C. `UIUX-BEFORE-AFTER.md`**

- Baseline vs final screenshots
- Visual difference observations
- Performance comparison
- Accessibility comparison
- Score improvement
- Known regressions or exceptions

**D. `UIUX-TEST-RESULTS.md`**

- Test coverage
- Commands executed
- Pass/fail results
- Browser results
- Accessibility findings
- Lighthouse outputs
- Build and regression status

**E. Test and Screenshot Artifacts**

Retain the supporting screenshots, browser tests, visual diffs, and reports in organized directories.

## 17. Final Acceptance Criteria

Do not report successful completion unless the following applicable conditions are verified:

- Critical user journeys work in the browser.
- No known unresolved P0 issues remain within the tested scope.
- P1 issues are resolved or clearly documented with blockers.
- Responsive layouts work across tested sizes.
- No known new horizontal overflow, clipping, or overlapping components.
- Buttons, forms, menus, and dialogs behave correctly.
- No new severe accessibility problems are introduced.
- No unexplained major performance regression is introduced.
- Shared components remain visually consistent.
- Build and relevant automated tests pass, or failures are documented.
- Visual differences are reviewed and intentional changes are distinguished from regressions.
- Existing functionality is preserved.
- Before and after scores are supported by recorded evidence.
- Unavailable tests are transparently reported.

## 18. Final Response Format

Once implementation and verification are complete, provide a concise final summary:

**1. Initial UI/UX Score:** XX/100

**2. Final UI/UX Score:** XX/100

**3. Improvement:** +XX points

**4. Issues Discovered:** XX

**5. Issues Fixed:** XX

**6. Remaining Issues:** XX, organized by severity

**7. Files Modified:** List actual modified files

**8. Browser Testing:** Passed / Failed / Not Tested by browser and viewport

**9. Accessibility:** Verified results and unresolved violations

**10. Performance:** Measured before/after results

**11. Visual Regression:** Intentional changes and unresolved differences

**12. Final Recommendation:** Ready / Ready with known limitations / Not ready

Include paths to generated audit reports and screenshot artifacts.

## 19. Execution Instruction — Start Now

Begin by inspecting the repository, starting the application using the project's documented procedure, and visiting the running website in a real browser.

Perform the baseline audit and capture evidence before altering code.

Then prioritize and implement justified improvements, verify them through browser testing and screenshot comparison, and produce the final scorecard and reports.

**Do not stop after generating an audit checklist or recommendations. The objective is a measured, tested, visibly improved, and functionally verified application.**

Work autonomously on safe, reversible changes. Report blockers transparently and continue with independent work wherever possible.