Digital Exam Invigilation Platform

Redesigning exam delivery software for high-stakes, real-world environments across the globe

Background

Global digital assessment software

Who: RM plc is a global provider of digital assessment software, supporting exam boards and schools to deliver high-stakes exams at scale.

Product: Invigilator is used by exam centres to run live exams, where invigilators are responsible for managing cohorts of up to 100 learners at a time.

Role: Led the end-to-end redesign of the next-generation Invigilator product, from in-school research through to design and delivery, in parallel to creation of design system (with wider design team).

Result: established a scalable, workflow-driven model for exam delivery, reducing reliance on training and improving clarity in high-pressure exam environments. MVP rollout across thousands of schools (Summer 2026).

Alignment & agreement

First challenge; defining the problem space

Why Invigilator needed tackling

  • The usability of the existing system was so poor that a key client, representing a contract worth over £28m, indicated they would not renew unless Invigilator was significantly improved by summer 2026.

  • This made the project commercially critical, with high visibility across senior stakeholders.

Deciding how to tackle it

  • Despite a wider mission to pursue scalable SaaS solutions, there was ongoing pressure to to prioritise short-term client demands.

  • This created tension; the core challenge was gaining buy-in for a client-agnostic approach that could scale across regions and exam boards.

Acquiring buy-in and maintaining trust

  • Through stakeholder and expert interviews, I built confidence that immediate client needs could be met without compromising the long-term product strategy.

  • Throughout, consistent communication and strong visibility were a crucial components to ensure successful delivery.

Research & discovery

Understanding real workflows

With alignment in place, I conducted deeper discovery. RM had historically shaped its products around individual client demands, with little independent validation, limiting their ability to obtain new clients, or deliver products that actually worked in practice.

Working closely with a UX Researcher we sought to define not just the product, but the underlying system model;

How does RM define live exams?

How should digital exam delivery function as a system?

Cross-client and cross-region analysis - how does exam delivery differ?

Approach;

  • 10 in-depth user interviews across invigilators and related roles.

  • Contextual inquiry, from South London to South Wales, shadowing live exams (UK only).

Defining the problem

Data without direction

The current implementation presented data in a table, but didn’t support decision-making, forcing invigilators to interpret and prioritise actions in real-time, high-pressure situations.

Where it broke down

  • No clear workflow for running a live exam

  • Poor system feedback, uncertainty whether actions had worked

    • Invigilators were often retirees, with varying levels of technical confidence.

  • Overwhelming number of notifications (100s per exam session)

  • Heavy reliance on training (500+ page user guide)

  • Workarounds outside the system (e.g. Whatsapp for centre comms), no reliable audit trail.

User impact

  • Low confidence during live exams

  • High cognitive load at critical moments

  • Increased likelihood of errors, compromising audit trail, risk to exam integrity

Existing implementation: main learner table and ‘bulk actions’ modal

Defining the system model

Discovery artifacts

Outputs tailored to audience and purpose; from formal research reports for senior stakeholders to evolving Figma artefacts used in day-to-day delivery.

Personas

Rather than segmenting by client or job title, I defined personas based on responsibility within the system;

  • Direct Invigilator (in-room, operational)

  • Indirect Invigilator (out-of-room, escalation and oversight)

This clarified ownership, reduced overlap, and allowed the model to flexibly scale across different clients and contexts.

Core journeys

  • Happy Path vs Incident Management

  • Mapped across both personas to reflect variations in responsibility and cross-over touch-points.

‘Living’ artefacts

To support consistency and long-term scalability, I created shared artefacts;

  • Standardised glossary and terminology across RM products

  • Shared incident severity model

  • Learner status model linking system state to user actions

These acted as reusable foundations, aligning multiple product teams and providing clear justification for changes that impacted legacy behaviour.

Ideation & concept development

Opportunity mapping

I translated prioritised research themes into opportunity areas, using “How might we” questions to guide workshops with the wider design team.

How might we surface and resolve an in-room incident with minimal disruption?

We explored multiple approaches to the key ‘incident handling’ workflow, investigating ways incidents could be raised and handled with a) minimal stress b) an accurate audit trail c) minimal disruption to the exam.

Iterative process

  • Concepts were rapidly prototyped and iterated using Figma Make, and initial validation with the Product Owner and Lead Engineer to ensure they balanced usability with what was technically achievable.

  • From there, I could prioritise where we wanted to target further refinement and validation with users.

Key decisions

  • In-room model over individual mobile controls: mobile approaches were deprioritised; invigilators couldn’t reliably use personal devices. We had to proceed with a single shared dashboard per room.

  • Seating plans deprioritised: would have improved spatial awareness in large rooms, especially when invigilators are unfamiliar with learners by name, but cut due to scope and legacy constraints.

  • Learner context limited: more detailed accessibility data and freeform notes would support invigilator confidence and decision-making, but were not viable due to issues with GDPR.

  • Structured incident flow adopted: a Kanban-style model improved visibility of the incident life cycle, but was targeted for testing due to concerns for users with lower technical confidence.

Key decision - 01

XYZ

Replacing a table with a workflow

The legacy product treated exam delivery as static data. I redesigned the experience around live workflows, aligning the interface with how invigilators think and act in real time.

  • Clear progression: holding → in progress → completed

  • Actions tied to system state

  • Prioritisation based on urgency

  • This reduced interpretation and enabled faster, more confident decision-making.

Key decision - 02

XYZ

Designing the incident lifecycle

Incident handling was previously fragmented and inconsistent. I introduced a structured lifecycle:

  • Incident creation → triage → escalation → resolution

  • Clear distinction between incident vs escalation

  • Shared severity model to guide prioritisation

  • Audit trail for accountability and review

  • This enabled consistent decision-making across centres and reduced ambiguity in high-stakes scenarios.

Key decision - 03

XYZ

Making system state visible

A critical failure in the legacy system was lack of feedback. Users often didn’t know if an action had worked. I redesigned interactions to provide:

  • Immediate, visible state changes

  • Status-driven UI (what’s happening now)

  • Contextual actions based on system state

  • Clear constraints (e.g. when actions are not possible)

  • This significantly improved trust in the system during live use.

Key decision - 04

XYZ

Supporting scaling through ‘zones’

Exam setups vary widely across centres.

  • To support this, I introduced Zones as a flexible abstraction layer:

  • Represents rooms, groups, or subjects

  • Allows invigilators to focus on a manageable subset

  • Enables scalable oversight at centre level

This balanced flexibility for clients with consistency for a SaaS product.

Trade-offs and constraints

Reframing delivery under emerging constraints

Delivery was driven by two questions;

Is this a direct client requirement?

Does this need changes to legacy?

Often at the expense of usability and long-term scalability.

I pushed back by reframing decisions around what needed to be consistent for the system to work at scale. This meant introducing lightweight validation cycles to ensure I had evidence for all design decisions, and any potential trade-offs.

I worked closely with engineering to align on feasibility early, adapt solutions as constraints became clearer, and use the emerging design system to introduce consistency. Feasibility and scope shifted throughout delivery, but I worked hard to ensure that decisions were anchored in supporting reliable, usable exam delivery.

Impact & Outcome

International rollout Summer 2026

Although still in development, the redesign has;

  • Given enough confidence to allow for current client renewal

  • Been used to upsell to 2 further existing clients who were not previously using Invigilator

  • Used by the sales team to attract new client bids

  • And importantly, for the initial testing, improved clarity and confidence for Invigilators in high-pressure scenarios as they prepare for the summer exam session, impacting >100,000 learners.

Unexpected validation

Client involvement was a challenge throughout this process. At one point, a Figma prototype was informally shared with the client ahead of development. The client independently created training materials directly from the designs, accurately explaining core workflows and Invigilator actions without guidance. Although this sat outside the agreed process, it demonstrated that the system was intuitive enough to be understood without formal training.

Driving product thinking in a legacy organisation

Working within a 50-year-old organisation in a period of transition provided an opportunity to influence how digital products are defined and delivered. This included;

  • Introducing product-led thinking and the value of user insight to senior stakeholders

  • Establishing early design system principles and ways of working with a newly formed engineering team

  • Defining a clearer model for digital exam delivery, moving beyond assumptions rooted in paper-based processes. These outcomes extended beyond this product, informing thinking across the wider assessment platform.