Improving the OSCE Examination Experience
Making a complex, high-stakes workflow feel clear.
Summary
Simplifying complex examination workflows and designing clearer experiences for administrators, examiners and students — connecting technical feasibility with real user needs.
Context
OSCE-style examinations (Objective Structured Clinical Examinations) involve a lot of moving parts: scheduling, stations, participants, examiners and results, all under time pressure and with little room for error. The people running them carry real cognitive load.
The challenge
Reduce the complexity experienced by administrators, examiners and students without removing the rigour these examinations require.
My role
- Framing the workflow problems across three distinct user groups
- Designing clearer experiences for administrators, examiners and students
- Improving scheduling and participant management
- Connecting technical feasibility with user needs
Approach
Map the whole workflow
Looked at the examination end to end rather than screen by screen, so complexity could be addressed where it actually originated.
Design per role
Recognised that administrators, examiners and students have very different jobs to do, and shaped clearer experiences around each rather than one generic interface.
Tame scheduling
Focused on scheduling and participant management as the highest-friction areas, simplifying them where the load was heaviest.
Stay feasible
Kept design decisions anchored to what was technically realistic, so improvements could actually be built and relied upon.
Key decisions
Simplify the surface, keep the rigour
Reduced perceived complexity in the interface while preserving the structure and control the examination process genuinely needs.
Clarity per audience
Accepted more design work up front to serve each role well, rather than one compromised experience serving none of them fully.
Outcome
- →Clearer, more purpose-built experiences for administrators, examiners and students.
- →Lower-friction scheduling and participant management in the highest-load parts of the workflow.
- →Design decisions grounded in technical feasibility, so improvements were real rather than aspirational.
What I learned
In high-stakes workflows, “simpler” never means “less capable”. The craft is removing incidental complexity while protecting the essential complexity that keeps people safe and the process trustworthy.
Next case study — 04
Product Portfolio & Decision Dashboard
Want to talk through a problem like this? Get in touch