80 lines
4.6 KiB
Markdown
80 lines
4.6 KiB
Markdown
|
# UX/UI Audit of SchoolCompare.co.uk — Design
|
|||
|
|
|
|||
|
|
**Date:** 2026-07-02
|
|||
|
|
**Status:** Approved design, awaiting execution
|
|||
|
|
**Output of execution:** a prioritized audit report (this spec defines how that report is produced)
|
|||
|
|
|
|||
|
|
## Goal
|
|||
|
|
|
|||
|
|
A comprehensive UX and design audit of the live site (schoolcompare.co.uk) that answers:
|
|||
|
|
|
|||
|
|
- **(a)** Can parents reach the relevant information quickly and intuitively?
|
|||
|
|
- **(b)** Is the site visually and experientially cohesive end-to-end, not just at component level?
|
|||
|
|
- **(c)** Does it comply with current design standards and best practices (incl. WCAG 2.2 AA)?
|
|||
|
|
|
|||
|
|
Every recommendation must be argued from evidence — no change for change's sake — and carry an indication of potential uplift. Primary success lens: **engagement and task completion** (parents who land actually reach a school page or comparison); SEO benefits noted secondarily.
|
|||
|
|
|
|||
|
|
## Analytics baseline (30 days, informing all weighting)
|
|||
|
|
|
|||
|
|
- ~2.3k visitors; 87% UK; 83% Google organic.
|
|||
|
|
- Devices: **56% mobile**, 41% laptop, 2% desktop → mobile is the primary viewport.
|
|||
|
|
- Page views: `/` 52%, `/compare` 27%, `/rankings` 12%, `/admissions` 5%, school pages a long tail (~1% each).
|
|||
|
|
- Entries: `/` 63%, `/compare` 20%, `/rankings` 6%, individual school pages a small but real SEO tail.
|
|||
|
|
- Exits: `/` 46% (biggest leak), `/compare` 32%, `/rankings` 13%.
|
|||
|
|
|
|||
|
|
## Method
|
|||
|
|
|
|||
|
|
**Environment:** live production site via Playwright browser tools. Two viewports: **390×844 (mobile, weighted primary)** and **1440×900 (desktop)**. Chrome engine (matches 41% Chrome + 11% Edge majority); iOS/WebKit-specific rendering is out of scope (cannot be emulated faithfully).
|
|||
|
|
|
|||
|
|
**Journey-led walk-through, in traffic order:**
|
|||
|
|
|
|||
|
|
1. **Home → find my school** (63% of entries; 46% of exits). Can a parent with a school name or postcode reach the right school page in under ~15 seconds? What competes for attention?
|
|||
|
|
2. **Google → school detail page → next step** (SEO long tail). Landing cold: is site identity obvious, is performance data comprehensible to a non-specialist parent, is there a clear path to "compare with nearby schools"?
|
|||
|
|
3. **Building a comparison** (27% of views, 32% of exits). Adding/removing schools, chart legibility on mobile, metric comprehension.
|
|||
|
|
4. **Rankings → shortlist** (12% of views). Filtering by local authority, scanning, jumping to school pages.
|
|||
|
|
5. **Admissions content** (5% — light pass, mainly cohesion with the rest of the site).
|
|||
|
|
|
|||
|
|
**Per journey, record:** friction points with screenshot evidence; what works well (explicitly kept); axe-core accessibility scan of each page state visited.
|
|||
|
|
|
|||
|
|
**Cross-cutting cohesion pass** (after journeys): typography scale, spacing rhythm, colour usage, component variants (buttons, chips, cards, nav, empty/loading states) compared **across** pages; consistency check of recent additions (map-blended hero, characteristic chips, admissions cross-links).
|
|||
|
|
|
|||
|
|
## Evaluation criteria
|
|||
|
|
|
|||
|
|
A finding is valid only if it cites at least one of:
|
|||
|
|
|
|||
|
|
- a violated usability heuristic (Nielsen/NN-g),
|
|||
|
|
- a WCAG 2.2 AA failure (axe result or manual check: contrast, touch targets ≥24px, keyboard/focus, labels),
|
|||
|
|
- a mobile-usability standard,
|
|||
|
|
- a concrete task-flow obstruction observed in the walk-through.
|
|||
|
|
|
|||
|
|
No "I'd prefer it differently" findings. Each finding: **evidence → argument (why it hurts parents) → recommendation**.
|
|||
|
|
|
|||
|
|
## Prioritization
|
|||
|
|
|
|||
|
|
Scored on traffic-weighted impact × severity:
|
|||
|
|
|
|||
|
|
- **P0 Urgent** — blocks or badly degrades a core task on a high-traffic path, or a clear WCAG failure on a main page.
|
|||
|
|
- **P1 High** — meaningful friction on a main journey; strong expected funnel uplift.
|
|||
|
|
- **P2 Medium** — cohesion/polish issues that erode trust but don't block tasks.
|
|||
|
|
- **P3 Nice-to-have** — low-traffic pages or marginal refinements.
|
|||
|
|
|
|||
|
|
**Uplift indication per finding:** which analytics number it should move (e.g. "home 46% exit rate", "share of sessions reaching a school page"), direction, and a magnitude band (small/moderate/large) with reasoning. Honest bands, not invented percentages — there is no baseline funnel instrumentation.
|
|||
|
|
|
|||
|
|
## Deliverable
|
|||
|
|
|
|||
|
|
One audit report at `docs/superpowers/specs/2026-07-02-ux-audit-report.md` containing:
|
|||
|
|
|
|||
|
|
1. Method summary.
|
|||
|
|
2. **"What works today — keep"** list.
|
|||
|
|
3. Findings grouped by tier (P0–P3), each with evidence, argument, recommendation, uplift indication.
|
|||
|
|
4. Suggested implementation sequence grouping related fixes.
|
|||
|
|
|
|||
|
|
The report is the plan requested. Implementation of any fixes is a separate follow-up with its own plan.
|
|||
|
|
|
|||
|
|
## Out of scope
|
|||
|
|
|
|||
|
|
- Performance/Core Web Vitals auditing (explicitly excluded by choice of scope).
|
|||
|
|
- iOS/Safari-specific rendering verification.
|
|||
|
|
- Changes to data content or backend behaviour.
|
|||
|
|
- Actually implementing fixes.
|