01
Three handoffs, one destination.
QR (default), SMS deep link (camera-fail fallback), and app-store search (final fallback) all converge on the same native or mobile-web check-in flow. Failure in any one path does not end the check-in.
OnVUE Remote Proctoring
·
Pearson VUE · Cross-device
Three platforms, three handoffs, ten journey anchors, one coherent check-in.
As founding designer, I led OnVUE from 0 to 1 and stewarded its experience through 300% growth. I designed across desktop web, mobile web, and native iOS / Android, including explicit handoff paths, state synchronization, recovery, and a shared journey model. The platform now serves 2.3 million exams annually, and the redesigned check-in contributed to approximately 25% fewer check-in failures.
// BEFORE / AFTER
From brittle fixed-pixel check-in to a responsive cross-device handoff.
// RoleSenior Product Designer · IC Lead
// ScopeEnd-to-end check-in UX
// SurfacesDesktop · Mobile Web · Native
// Scale2.3M exams annually
// UsersCandidates · Greeters · Proctors
// StatusShipped globally
300%Growth supported
through stewardship
through stewardship
~25%Fewer check-in
failures
failures
2.3MExams served
annually
annually
01
// Context map
Three platforms coordinated through three handoffs, one presence endpoint, and one recovery rail.
A candidate starts on desktop, authenticates identity using a phone, and may need to fall back to mobile web if the native app fails. Each transition is a state handoff. The system either synchronizes that state clearly or strands the candidate. The redesigned topology is below.
FIGURE 01
// Cross-device topology
The three-platform check-in topology
The topology connects three platforms, three handoff paths, one presence endpoint, and one manual-refresh fallback. Every fragile transition has a recovery route.
Platform / surface
Handoff bridge
State sync · recovery
// READ AS
The presence-polling endpoint is the architectural difference between "coordinated check-in" and "two disconnected products". The manual-refresh button is the architectural difference between "coordinated check-in" and "stranded candidate". Both had to exist.
02
// The problem
Adding steps was easy. Reducing cognitive load while enforcing non-negotiable security was not.
Remote check-in had to succeed for any candidate, anywhere in the world, regardless of age, occupation, technical proficiency, or familiarity with digital testing. Candidates typically arrived under strict time constraints, concerned about device or network failure, and anxious that a single misstep could invalidate the exam they were paying for.
Each step in the existing flow served a legitimate security or compliance need. Together, those steps created friction, confusion, and anxiety that drove failed check-ins, support escalations, and abandoned exams. The hard tradeoff was reducing cognitive load without compromising exam integrity or regulatory requirements.
The core design move was not adding functionality. It was making required steps feel intentional rather than punitive, helping candidates understand where they were and what came next, and ensuring every screen earned its place in the journey.
03
// Research
Mapping the journey before redesigning the screens.
The work started with a synthesized end-to-end journey map covering ten stages (Setup & Launch · Explore · Register · Commit · Prepare · Check-in · Test · Certify · Support) across three swimlanes (Candidate · Client · Employee). For each stage I documented goals, actions, sentiment, failure points, contextual systems, current data metrics, and prioritized opportunities.
The check-in segment surfaced ten distinct candidate failure modes. They ranged from access-code issues and country-list ordering on the ID-upload page to SSO-client candidates being unable to use self-service reschedule and drop-offs in unhappy paths with no clear recovery instruction. Each failure was traceable to a specific upstream cause.
"Remote proctoring is inherently stressful. The challenge was not adding steps. It was helping candidates feel confident navigating unavoidable ones. By reframing the check-in around progress, preparedness, and clear transitions, we reduced failure and anxiety while preserving exam integrity across a global platform." Design summary, in-house portfolio review
04
// Journey model
Ten anchors that turn ten interruptions into one coherent experience.
Each anchor was treated as a phase, not a screen. Some anchors compressed multiple existing screens; others split a single screen into clearer transitions. The journey map below is the artifact I used to align stakeholders.
FIGURE 02
// Journey model
The 10 check-in journey anchors, with failure points called out
Each anchor has an intent, a transition, and a recovery path. Red annotations mark the highest-risk failure points from research.
// READ AS
Six of ten anchors are high-risk failure surfaces. The redesign gives those moments more attention and keeps low-risk moments simple by not over-designing them.
05
// Design response
Six interaction decisions made cross-device check-in survivable.
02
Presence polling makes the handoff invisible.
Mobile posts to a presence endpoint as it advances. Desktop polls. The candidate sees one continuous flow rather than two products talking past each other.
03
Manual refresh is always available.
If polling fails because of a flaky network, browser quirks, or sleep state, a labeled refresh button on desktop lets the candidate force-sync. The system tolerates its own failure modes.
04
Mobile web has parity with native.
The same UI states cover camera permissions, orientation, framing, identity capture, ID capture, workspace, upload, and errors. A candidate who cannot install the app can still finish check-in.
05
Anchors compress; anchors split.
Government ID became one phase that moved from select to capture to confirm, rather than three disconnected screens. Diagnostics split into specific pass/fail readouts so candidates could self-resolve rather than escalate.
06
Self-service reschedule preserved as a recovery rail.
Self-service reschedule is available throughout check-in. Candidates who hit an unrecoverable issue can rebook themselves instead of abandoning entirely.
06
// Architecture deep-cut
What each system has to do at each anchor.
| Anchor | Desktop surface | Handoff | Mobile surface | Backend |
|---|---|---|---|---|
| Launch | Access code · download CTA | Not applicable | Not applicable | Secure browser auth |
| Overview | Requirements list | Not applicable | Not applicable | Not applicable |
| Diagnostics | Pass / fail per check | Not applicable | Not applicable | Diagnostic agent |
| Mobile select | Three-path picker · refresh fallback | QR · SMS · App store | Interstitial or native app launch | Branch.IO interstitial + deep link |
| Identity | Waiting state | Not applicable | Selfie capture | Presence endpoint posts state |
| Government ID | Waiting state | Not applicable | Select → capture → confirm | ID validation service |
| Testing space | Waiting state | Not applicable | Workspace photos / scan | AI vision (see AI-Guided Environment Validation) |
| Rules | Acceptance modal | Not applicable | Confirmation | Audit log |
| Queue | Wait indicator + SSR option | Not applicable | Not applicable | Capacity queue |
| Complete | Closure screen | Not applicable | Not applicable | Result / RTEN |
07
// Validation
Shipped and measured at global scale.
// PRODUCTION · OUTCOME → IMPLEMENTATION → STATUS
// Outcome// Implementation// Status
Coordinated cross-device check-in
Three handoff paths · presence endpoint · manual refresh fallback
Shipped
Reduced failed check-ins from confusion / missed steps
Re-anchored journey · clearer transitions · explicit progress
Shipped
Lower support escalation during exam day
Self-service reschedule available throughout check-in
Shipped
Reusable journey framework
10-anchor model with per-anchor failure surface; foundation for AI-assisted guidance
Shipped
Localized ID upload ordering
Country list re-sorted to local alphabetical order; gaps documented
Roadmap
08
// Outcome
The journey model became the canonical reference for everything downstream.
The shipped platform grew 300% and now serves 2.3 million exams annually. The redesigned cross-device check-in contributed to approximately 25% fewer check-in failures. Beyond the screens, the shared journey model gave adjacent product teams a reference for accommodations, proctoring features, and support modernization.
// THE LESSON I CARRY FORWARD
A coordinated cross-device experience works when state synchronization, recovery paths, and graceful fallback are designed together. Without all three, the product behaves like two disconnected products pretending to be one.
09
// What this enabled next
The check-in journey became the spine of every adjacent product.
// PATTERN
Anchor-based journey design
The model treats phases as the design unit, not individual screens. Each anchor has intent, transition, and recovery designed together.
// PATTERN
Three-path handoff
Default, fallback, and final fallback paths can be reused for any cross-device step where the primary path has friction.
// PATTERN
Presence polling + manual refresh
State sync is designed alongside its own failure mode. The user always has a way to force a resync.
// PATTERN
Mobile-web parity with native
The app install is never required. Mobile web carries the full check-in.