A model end-to-end UX case study · BCSAI · IE University
This is what the group project from Sessions 19–24 looks like when it's done well: research before pixels, every decision traceable to an HCI principle, and a measurable usability gain at the end. No code — just the deliverables a UX team actually produces.
The brief, the constraint, and the deliverable — the "Strategy plane" stated in one breath before any design begins.
CityHop is a fictional mid-size city's official transit app. Riders can see times and routes, but buying a ticket is where they bail: 41% of sessions that reach the purchase screen end without a completed payment. Our job is to redesign the buy-a-ticket experience so that an anxious, time-pressured rider on a crowded platform can buy the right ticket in under 30 seconds — and trust that they did.
From 41% to under 20% at the payment step, without removing options power-users rely on.
Bright sun, poor signal, a train arriving. The design must survive its worst-case environment, not its best.
Personas, journey map, IA, lo-fi → hi-fi wireframes, a usability study with a SUS score, an accessibility audit, and an iteration log.
Median time-to-purchase and System Usability Scale score, measured before and after redesign.
Before deciding what to build (Scope), we found out who we're building for and why the current app fails them. Methods chosen with the NN/g research-method framework in mind.
9 contextual interviews at three stations across the morning peak (qualitative, attitudinal — why people struggle).
Analytics funnel review of 12 weeks of sessions (quantitative, behavioural — where they drop).
5 moderated usability sessions on the existing app (behavioural — what people do, not what they say).
1 heuristic evaluation against Nielsen's 10 (expert review, cheap signal before recruiting users).
Interviews tell us why; analytics tell us how much; usability sessions catch problems users can't articulate. Krug's point in Rocket Surgery Made Easy: five users surface most serious issues, so we tested small and often rather than running one big study late.
7/9 interviewees couldn't tell a single ride from a day pass without reading dense text. Zone names meant nothing to them.
Price only appears after selecting payment. Users abandoned rather than risk an unknown charge — a violation of visibility of system status.
The ticket-type selector used 28px text links spaced 6px apart. On a moving train, mis-taps were constant (a Fitts's Law failure).
After paying, users weren't sure it worked. They re-opened the app repeatedly at the gate — anxiety, not confidence.
The app demanded an account before showing any fares, adding friction for the most time-critical task (the single ride).
Active vs. expired tickets differed only by a green/red dot — invisible to ~8% of male riders with colour-vision deficiency.
| Priority | Requirement | Why it's here |
|---|---|---|
| MUST | Show fare up-front, before payment | Directly fixes the #1 abandonment cause (Finding 02). |
| MUST | Plain-language ticket types with a recommended default | Removes the "which ticket?" paralysis (Finding 01). |
| MUST | Large, well-spaced tap targets (≥48px) | Survives the moving-train context (Finding 03, Fitts). |
| MUST | Unmistakable post-purchase confirmation + active-ticket screen | Builds confidence at the gate (Finding 04). |
| SHOULD | Guest checkout for single rides | Removes the sign-in wall for the most urgent task (Finding 05). |
| SHOULD | Status shown by icon + label, never colour alone | Accessibility baseline (Finding 06, WCAG 1.4.1). |
| COULD | Saved favourite routes; Apple/Google Pay | Speeds up repeat users; not blocking the core goal. |
| WON'T | Social features, trip gamification, in-app chat | Out of scope this release — pure scope-creep risk. |
Two personas distilled from the interviews — concrete people to design for, not a vague "the user". Then a journey map of the primary persona buying a ticket on today's app, exposing the emotional low points.
Commuter · primary persona
"I just want the right ticket before the train comes — I don't want to think."
Occasional rider · secondary persona
"I take the tram twice a month. I forget how it works every single time."
Mapping the existing experience makes the pain points impossible to ignore — and tells us exactly where to intervene.
| Stage | 1 · Open app | 2 · Find tickets | 3 · Choose type | 4 · Pay | 5 · At the gate |
|---|---|---|---|---|---|
| Action | Unlocks phone on the platform, opens CityHop | Hunts for the "Buy" entry point among route info | Reads ticket names, guesses which zone she's in | Forced to sign in, then enter card, then sees price | Opens app again to show the ticket, unsure it's valid |
| Thinking | "Train's in 3 min." | "Where's the buy button?" | "Is 'Zone A' me? What's a day pass cost?" | "Why do I need an account to buy one ticket?" | "Did that even work?" |
| Emotion | 🙂 | 😐 | 😟 | 😣 | 😰 |
| Pain point | — | Buy action buried (Finding 02) | Jargon + no recommended default (Finding 01) | Sign-in wall + hidden fare (Findings 02, 05) | No confident confirmation (Finding 04) |
| Opportunity | Resume to a "Buy" home | Persistent primary "Buy a ticket" CTA | Recommend "Single ride – €2.40" by default | Guest checkout, fare shown first | Big active-ticket screen with live validity |
💡 The emotional curve dips hardest at stages 3–5 — exactly where our four MUST requirements land. The journey map didn't just describe the problem; it prioritised the work.
The Structure plane. A card sort with 8 participants told us how riders actually group functions — so the navigation matches their mental model, not the transit authority's org chart.
Open card sort (8 participants, 18 cards) converged on three top-level groups: Buy, My tickets, and Travel info. "Account" was consistently seen as settings, not a primary destination — confirming that the sign-in wall was an IA mistake.
The primary task (buy) is reachable in one tap from anywhere. Depth is kept to two levels so users never feel lost — supporting recognition rather than recall (Nielsen #6).
Four taps, fare visible from tap one, no mandatory sign-in. Compare to the old flow's seven steps with a sign-in detour.
The Skeleton plane, then the Surface plane. We sketch arrangement first (low fidelity, deliberately ugly so feedback targets layout not colour), validate it, then layer visual design on the validated structure.
Lo-fi · Buy screen — paper-grade wireframe. The point is hierarchy and tap-target size, not aesthetics.
┌─────────────────────────────┐ │ ☰ CityHop ⓘ │ ← lightweight header ├─────────────────────────────┤ │ │ │ Buy a ticket │ ← H1, plain language │ │ │ ┌───────────────────────┐ │ │ │ ● Single ride │ │ ← RECOMMENDED, pre-selected │ │ Valid 90 min │ │ big card, full-width tap target │ │ € 2.40 │ │ ← FARE VISIBLE NOW (fixes Finding 02) │ └───────────────────────┘ │ │ ┌───────────────────────┐ │ │ │ ○ Day pass € 6.00 │ │ │ └───────────────────────┘ │ │ ▸ More ticket types │ ← progressive disclosure │ │ │ ┌───────────────────────┐ │ │ │ Confirm & pay → │ │ ← 56px primary CTA, thumb zone │ └───────────────────────┘ │ │ Continue as guest │ ← no sign-in wall └─────────────────────────────┘
Lo-fi · Active ticket screen — the confidence payoff. Fixes Finding 04.
┌─────────────────────────────┐ │ ← Active ticket │ ├─────────────────────────────┤ │ ✓ VALID │ ← icon + WORD, never colour alone │ │ │ Single ride │ │ ███████████ 23:41 left │ ← live countdown = system status │ │ │ [ animated validity band ]│ ← hard to screenshot/forge │ │ │ Show this to the inspector│ └─────────────────────────────┘
The primary CTA is a 56px full-width button at the bottom — large W, short D for a thumb. Ticket cards are full-width too. On a moving train this is the difference between a tap and a mis-tap (Finding 03).
Only two ticket types show by default; the rest hide behind "More". Fewer options → faster decision. Decision time grows with the number of alternatives, so we reduced them for the common case.
Fare sits inside the same card as the ticket name, so they read as one unit. Generous gaps separate distinct choices, so users perceive discrete options at a glance.
Price appears the instant a ticket is highlighted; the active ticket shows a live countdown. Nielsen heuristic #1 — the system keeps the user informed at every moment.
With structure validated, we apply the design tokens: a single brand hue, an 8px spacing scale, 12px corner radius, and a type ramp topping out at 28px for the H1 so Tomás can read it in sunlight. Described hi-fi:
A moderated usability test of the hi-fi prototype with 8 participants (5 Nadia-type, 3 Tomás-type). Three task scenarios, think-aloud protocol, success/time/error recorded, followed by the 10-item System Usability Scale questionnaire.
| # | Task scenario | Success criterion |
|---|---|---|
| T1 | "You need to get into town now. Buy a single ride." | Valid single-ride ticket purchased |
| T2 | "You'll be sightseeing all day. Get the cheapest ticket that covers that." | Day pass selected & purchased |
| T3 | "An inspector asks for your ticket. Show it's valid." | Reaches active-ticket screen unprompted |
| Metric | Old app | Redesign | Change |
|---|---|---|---|
| T1 success rate | 63% | 100% | +37 pts |
| T1 median time-to-purchase | 71 s | 22 s | −69% |
| T2 success rate | 50% | 88% | +38 pts |
| T3 success (found proof of validity) | 38% | 100% | +62 pts |
| Mean errors / participant | 2.4 | 0.5 | −79% |
| Simulated purchase abandonment | 41% | 14% | goal met (<20%) |
SUS converts ten 1–5 agree/disagree items into a 0–100 score. ~68 is the industry average; 80+ is the top ~10% of products (the "A" range).
old app · grade F
redesign · grade A
+28 points — crossing from "below average / not acceptable" to "excellent".
Accessibility isn't a phase at the end — Tomás's needs shaped the design from §03 onward. This checklist is the formal verification against WCAG 2.2 Level AA. "Not extra; the baseline."
All body text ≥ 4.5:1 and large text/CTA ≥ 3:1 against their backgrounds. Transit-blue CTA on white measures 5.9:1.
Ticket validity uses a ✓/✕ icon + the word "VALID"/"EXPIRED", not colour alone — fixes Finding 06.
Every interactive control is ≥ 48×48px with ≥ 8px spacing — comfortably above the 24px AA minimum (and aligned with Fitts).
Layout reflows without loss of content up to 200% OS text size — verified for Tomás's larger-type setting.
Ticket cards are labelled radio controls; the CTA announces "Confirm and pay, button" to screen readers (VoiceOver/TalkBack tested).
A declined payment states what went wrong in text and offers a fix ("Card declined — try another card") — Nielsen #9, help users recover.
Initial prototype lost the keyboard focus ring on the custom cards. Added a 2px high-contrast focus outline in iteration. Resolved.
Countdown was announced as raw digits. Added an aria-live label ("23 minutes remaining"). Resolved in iteration.
UX is a loop, not a line. The test surfaced two residual problems; here's what changed in round two, plus where the project goes next.
Re-test the day-pass hint with occasional riders; A/B the guest-vs-account conversion in production.
Promote the COULD requirements now the core flow is proven — shave more seconds off repeat purchases.
Instrument the real funnel to confirm the lab's 14% abandonment holds in the wild across signal conditions.
Explore a watch "active ticket" complication for the at-the-gate moment (Sessions 17–18, multi-platform).
Every learning objective from the syllabus, and the exact section of this project where it's demonstrated. This is the "show, don't tell" half of the assessment.
Understand the foundations & user-centred design principles of HCI.
Structured the whole project on Garrett's 5 planes — see §1.Conduct user research with appropriate methods.
Interviews, analytics, heuristic eval, MoSCoW synthesis — §2.Design and run usability evaluations.
Task-based moderated test + SUS, before/after metrics — §6.Apply accessibility & inclusive design.
WCAG 2.2 AA audit; inclusive design shaped the core, not a bolt-on — §7.Reflect, iterate, and communicate results.
Iteration log, next steps, and this entire documented case study — §8.The course's core sources that ground each decision above.