01
One-glance network state at the top of the tablet.
A three-dot indicator for site server, cloud, and last sync is always visible. The test administrator never has to guess which tier is working.
Biometric Admissions
·
Pearson VUE · Biometrics
An offline-capable, certificate-pinned tablet workflow designed for rooms where WiFi can fail.
A fixed-workstation biometric admissions flow was being reimagined as an administrator-operated tablet experience. I designed the technical experience across biometric capture, identity context, local operations, connectivity, and recovery while partnering closely with engineering. This public case presents technical interaction design and prototype evidence; it does not claim a completed production pilot or broad rollout.
// BEFORE / AFTER
From tethered desktop admissions to tablet-first biometric capture.
// RoleSenior Product Designer · IC
// ScopeTablet UX · recovery paths
// SurfaceNative Android tablet
// SecurityCert-pinned · offline-capable
// UsersTest Administrators
// StatusTechnical design · prototype evidence
TechnicalInteraction and
recovery design
recovery design
PrototypeScenario-based
evidence
evidence
No claimOf a completed
production pilot
production pilot
// PROTOTYPE WALKTHROUGH
See the tablet admissions flow.
01
// Context map
Tablet, LAN, and cloud form three rings of trust with two distribution modes and one offline fail-safe.
The tablet does not live on the open internet. It joins a high-security admissions site, discovers a local site server over LAN through mDNS, validates against pinned certificates, and syncs to Azure only when conditions allow. Distribution differs by site type, and telemetry is split between analytics and crash channels. This is the architecture I designed the UX around.
FIGURE 01
// Cert-pinned offline-capable architecture
Tablet → native plugin chain → local site server (LAN) → Azure (cloud), with offline-mode fallback
The topology has three tiers, explicit trust boundaries, distribution-mode forks, and a routine app-check loop that pings both local and cloud services. When needed, the app degrades to offline mode.
Tablet · LAN · Azure tier
Offline-mode + distribution fork
Failure mode
// READ AS
Three trust tiers. Two distribution modes. One non-negotiable design principle: the test administrator needs a clear recovery path. Every connectivity condition has a designed state, and the prototype shows what can continue, what is preserved, and what requires a human decision.
02
// The problem
Move from a desktop Java tool to a native tablet without losing offline reliability.
The legacy admissions tool was a Java desktop app that was aging, hard to ship, and ill-suited to handheld use. The replacement was a tablet workflow built on Angular, Ionic, and Capacitor that wrapped a vendor palm-biometric SDK. The tablet had to work in an admissions room where the network was the most likely failure mode, and a test administrator could not be told to wait for IT.
Constraints that ruled the design: certificate pinning for every API surface, LAN-only service discovery via mDNS so the tablet would find its site server without configuration, palm templates never leaving the site server, two distribution modes (Intune MDM for owned sites, Play Store for partner sites), and routine application checks that ping both the local server and Azure so the tablet always knows what tier it can currently reach.
03
// Research
Use the legacy workflow and failure inventory as the research surface.
This public case does not claim a completed field pilot. Discovery focused on evidence the team could substantiate: the existing administrator sequence, the transition from fixed workstation to tablet, device and service dependencies, secure-handoff requirements, known interruption categories, and the operational consequence of losing candidate or capture context.
I translated that evidence into scenarios and reviewed the interaction consequences with cross-functional partners. Each scenario asked what the administrator knew, which layer could confirm it, what state was safe to retain and which action remained available, and how the next role would receive the work.
Every interruption needed an owner, an explanation, and a next action that preserved permitted context. Design principle · failure-first operating model
04
// Recovery model
Five failure modes and five recovery paths were designed as a state machine.
The recovery model treats every failure mode as a named state with an explicit response. The state machine below is the model I designed against. The invariant is that the tablet always offers the test administrator a forward action.
FIGURE 02
// Compatibility & recovery
Five failure modes, five recovery paths
Each failure has a named state, a TA action, and a sync-on-recovery contract.
// READ AS
No row routes the test administrator to a dead end. Even the worst case, when both local and cloud services are down, keeps the line moving with manual ID verification and a reconciliation contract for when the network returns.
05
// Design response
Six interaction decisions made the tablet survivable in the room.
02
QR or PIN handoff, one button each.
QR scan and six-digit PIN are equal-weight entry paths. The encrypted host.p12 binds the tablet to its site, and reuse on the wrong site fails closed with an explanatory state.
03
Palm enrolment + match shown as one phase.
The TA sees a single labeled phase with a progress indicator. The vendor SDK's raw outputs are translated into TA-readable language.
04
Offline mode is a state, not an error.
The tablet does not crash, spam retries, or show a generic red banner. It changes its label to OFFLINE, narrows the available actions, and shows that it is queued for sync.
05
Distribution-aware behavior.
The same screens behave slightly differently depending on whether the tablet was deployed through Intune for owned sites or the Play Store for partner sites. Admin controls, update timing, and crash-report routing all adapt.
06
Every recovery state has a TA-facing label and a documented next move.
SITE MISMATCH, OFFLINE LOCAL, DEGRADED LAN-ONLY, OFFLINE MANUAL, and BLOCKED UPDATE each have a labeled state, a recommended action, and a sync-on-recovery contract.
06
// Architecture deep-cut
What lives on the device, what does not, and why.
| Concern | Tablet | Site server (LAN) | Azure (cloud) |
|---|---|---|---|
| Palm template | Captured · transmitted, not stored | Stored · matched locally | Never |
| Candidate roster | Cached for offline | Authoritative for the day | Authoritative master |
| ID validation | UI only | Validation service | Sync of validation results |
| Audit log | Captured locally | Persisted locally · synced | Authoritative archive |
| Telemetry | Emits Firebase events | Not applicable | Firebase Analytics + Crashlytics |
| Distribution / updates | Receives | Not applicable | Intune (PPC) · Play Store (non-PPC) |
| Cert pinning | PVUE CA + *.pearsonvue.com | Validates inbound | Validates inbound |
07
// Validation
Prototype and validation direction, not a production-pilot claim.
The prototype was used to inspect preparation, successful capture, poor positioning, device or sensor interruption, waiting, reconnection, and fallback. The validation direction calls for representative test-center conditions, approved security review, and observability across device, connectivity, capture, service, and operator events before any pilot outcome can be claimed.
// PROTOTYPE · SCENARIO → RESPONSE → NEXT STEP
// Scenario// Design response// Evidence
Capture or device state is difficult to interpret.
Use persistent, high-contrast state labels and in-the-moment coaching.
Prototype
Pairing or entry information needs correction.
Keep clear retry and alternate-entry paths available without losing candidate context.
Prototype
A device or software dependency is unavailable.
Separate update, alternate-device, and administrator-escalation actions.
Prototype
Connectivity or a service is interrupted.
Explain what can continue, what is safely preserved, and what must wait.
Prototype
Work resumes after an interruption.
Keep pending state, ownership, and the next synchronization action visible.
Prototype
08
// Outcome
An implementation conversation grounded in operational failure.
The work produced a coherent tablet interaction model, explicit recovery vocabulary, detailed prototype behavior, and a shared way for product and engineering to reason about hardware, network, service, identity, and operator consequences. Its value was technical resilience: the team could inspect failure before treating the happy path as complete. This case does not claim a completed production pilot, broad rollout, or production efficiency outcome.
// THE LESSON I CARRY FORWARD
In high-security environments, the goal is not flawless operation. It is graceful degradation. The product that survives is the product that refuses to be one outage away from useless.
09
// What this enabled next
Patterns that traveled with me.
// PATTERN
Offline-first as a state
Not an error banner. A first-class operational state with its own UI and its own sync contract.
// PATTERN
Three-tier trust topology
Tablet, LAN, and cloud each have an explicit handoff and fallback. The pattern can be reused for any device-in-room product.
// PATTERN
Cert-pinning + LAN discovery
The trust boundary is secure by default, and the setup is zero-config from the test administrator's perspective.
// PATTERN
Test-administrator recovery vocabulary
Every failure mode has a name, a state, and a documented next move. The design avoids silent failure and dead ends.