What happens after you request an exam accommodation?
It looks simple on the surface. But behind it, multiple teams review, decide, and make sure everything is in place before your test.
ROLE: I focused on shaping the end to end flow, working through how approvals should function, and aligning with teams to make the experience smooth.
TIMELINE: 8 weeks · July to August 2025
TEAM: Senior Product Manager, Accommodation Review Team, Scheduling Team, Clients
And me — driving the design end to end
What happens after someone requests an exam accommodation? 🤔
It sounds simple — select what you need and move on. But behind that request, multiple teams review documentation, make decisions, and coordinate approvals before a candidate can even schedule their exam.
At Pearson, this process was spread across emails and spreadsheets — slow, fragmented, and hard to track.
Quick TL;DR of the case study
The Problem
Everything ran on emails + spreadsheets → delays, duplicate work, no visibility
What I did
Designed a centralized system that brings all teams into one unified flow, adapts based on roles and approvals, and efficiently handles both simple and complex requests.
Key idea
Instead of building multiple flows, I designed one system that changes based on who’s using it.
Now, let’s get into the details
#1 Overview
The goal was to digitize how accommodation requests like extra time, assistive tools, or special setups are reviewed and approved before scheduling.
This led to delays, inconsistent data, and poor visibility. I worked on turning this into a centralized system that reduces delays and keeps everyone aligned.
#2 The Problem
Accommodation approvals weren’t just slow, they were unpredictable.
As a result, candidates faced delays in booking exams, and teams spent more time coordinating than reviewing.
This wasn’t a single flow.
#3 The Challenge
The process changed based on:
🤔
Who created the request?
✅
Who had approval authority?
❓
Whether the request was standard or non-standard.
#4 Understanding the Existing System
Before designing anything, I mapped how the current process actually worked. A typical request looked like this:
#1
#2
#3
#4
#5
Consequently, teams faced:
Processing Delays
This ultimately led to delays of approximately 3–4 days for each individual request, slowing down overall turnaround time.
Data Duplication
It also resulted in duplicate data entries and frequent version conflicts across teams, creating confusion and unnecessary rework.
Lack of Visibility
There was no clear visibility into scheduling, making coordination across teams difficult and often inconsistent.
The system wasn’t just inefficient — it lacked a shared source of truth.
#4 Research & Discovery
I conducted contextual inquiry sessions with 12 reviewers and schedulers. What I kept hearing:
Amy | Head of Review Team
We spend more time fixing incomplete data than reviewing.
Candidates keep asking for status updates.
Larissa | One of our client
Eden | Head of Scheduling Team
We don’t know what’s finalized without checking emails.
Mapping Workflow Complexity
#5 Userflow
What looked like one process turned out to be four different scenarios. Depending on who created and approved the request, the flow changed. To make sense of this, I mapped four core flows:
Designing for all four meant thinking in terms of states, permissions, and transitions not just screens. There are four core flows here — it might feel like a lot at first, but this is what helped simplify the system later.
Designing the System
Before jumping into UI, I broke the system into two key categories:
Standard Requests
Predefined accommodations that can be approved quickly.
Non-standard Requests
More complex cases that require additional planning and multiple approvals.
This distinction shaped how the system behaves.
Key Design Decisions
#6 Research & Discovery
Across all scenarios, the system follows a consistent structure:
Designing for States, Not Screens
Instead of focusing on screens, I designed around how requests move.
Each request transitions through states: Pending → In Review → Approved → Completed
This made it possible to support multiple teams, maintain consistency across flows, and reduce confusion.
Round 1 — Mid-fidelity testing
#7 Usability Testing & Iteration
Reviewers struggled to track which accommodation types were completed, often missing pending ones or assuming everything was approved due to the lack of a clear progress indicator.
Iteration — Introducing the Stepper
I replaced side navigation with a stepper. Each step showed what was complete and what was pending, making the process more traceable and reducing missed steps.
Round 2 — Cross-team validation
#7 Usability Testing & Iteration
We tested the updated design with review, scheduling, and client teams.
Amy | Head of Review Team
Now every action leads somewhere — nothing gets lost.
Stronger flow understanding and execution
90% found the flow easier to understand. 8/10 completed tasks without help.
Bringing all pieces together
#8 Final Design Highlights
Centralized dashboard for all teams
Guided request creation flow
Structured stepper for multi-accommodation handling
Context-aware inputs
Clear determination and decision tracking
Built-in validation at every step
Review layer before submission
Real-time system updates across teams
Clear determination and decision tracking
Scaling the system for efficiency
#9 Future Development
A few things we’re building next to make the system more scalable and easier to manage:
Together, these improvements will elevate the Approval App from a process tool into a scalable platform that accelerates operations, reduces turnaround time, and strengthens collaboration across Pearson’s ecosystem.