Enhancing A Digitised Check-In/Out Process
Enhancing A Digitised Check-In/Out Process
Embedded Files
Role: UX Designer
Context: Government / Defence (NDA‑safe)
Outcome: Reduced completion time by 36% and enabled escort officers to track visitor check‑in status in real time.
TL;DR
TL;DR
Escort officers lacked visibility into whether visitors had actually checked out of secure rooms, creating audit risk and security blind spots. Through field research across multiple military sites and usability testing with escort officers, I redesigned SwiftEntry from a visitor‑dependent system into a shared‑responsibility model. The new system empowers escort officers with real‑time visibility and assisted check‑out, reducing errors and improving compliance without adding friction.
Problem
Problem
Escort officers are accountable for who enters and exits secure rooms, but the existing system relied almost entirely on visitors remembering to check out.
This led to:
Visitors forgetting to check out
Browser refreshes resetting state
Poor connectivity in restricted zones
Manual fallbacks to physical logbooks
The result was inaccurate records, audit risk, and operational stress for escort officers.
My Role & Process
My Role & Process
I led end‑to‑end UX work for SwiftEntry Phase 2, including:
Field studies across multiple military compounds
Mapping end‑to‑end visitor and escort journeys
Synthesising research into system‑level insights
Designing and testing new escort‑centric workflows
The focus was not UI polish, but operational reliability under real constraints.
Research & Key Insights
Research & Key Insights
Insight 1 — Forgetting to check out is structural, not user error
Insight 1 — Forgetting to check out is structural, not user error
Observation
Across all sessions, escorts repeatedly mentioned that visitors “forget”, “slip out”, or lose the ability to check out due to refreshed pages, poor reception, or shared devices.
Pattern
Failures happen:
At the end of work, when attention shifts
In low-connectivity zones
When multiple contractors are managed at once
Insight
A system that relies on visitors to remember check-out will always fail in secure environments.
Design implication
Responsibility must shift from visitor-only → shared accountability with escort officers and the system.
Insight 2 — Escort officers already manage security, but the system ignores them
Insight 2 — Escort officers already manage security, but the system ignores them
Observation
Escorts physically manage:
Who enters
Which rooms are accessed
When work is completed
Yet previously, they had zero system visibility.
User quote (Escort)
“Can’t possibly chase everyone to ensure they check out.”
Insight
Escort officers are already accountable for security, but the system treats them as passive observers.
Design implication
Make escort officers first-class system users, not edge cases.
Insight 3 — Mobile‑first assumptions break down in restricted zones
Insight 3 — Mobile‑first assumptions break down in restricted zones
Observation
Across sessions, escorts highlighted:
No camera phones allowed
Shared phones among contractors
Poor signal inside CSRs
Returning to hardcopy logs when digital fails
Insight
A digital system must survive moments when personal devices are unavailable or unreliable.
Design implication
Design flows that work without perfect connectivity and without visitor-owned devices.
Solution Strategy
Solution Strategy
Instead of improving reminders for visitors, I reframed SwiftEntry around shared accountability.
Design principles:
Reduce reliance on visitor memory
Support low‑signal and zero‑device moments
Empower escort officers with visibility and control
Preserve audit integrity without adding friction
This shifted SwiftEntry from a visitor‑dependent system to a distributed check‑out model.
Strategic shift
From a visitor-dependent check-out model → to a distributed check-out system supported by escort officers and system safeguards.
The New System - How It Works
The New System - How It Works
Escort‑Centric Dashboard
Escort‑Centric Dashboard
Escort officers can now:
View all assigned visitors and their check‑in status
Assist with individual or bulk check‑out
Instantly identify unresolved check‑ins
This aligns system visibility with real‑world responsibility.
Persistent Visitor State
Persistent Visitor State
The system now:
Retains state even if a browser refreshes
Prevents duplicate check‑ins across locations
Avoids silent midnight auto‑check‑outs
Audit accuracy is preserved without relying on memory or perfect behaviour.
Location‑Aware Permissions
Location‑Aware Permissions
Actions are scoped to the entrance an escort is physically checked into, preventing accidental cross‑location manipulation while reinforcing real‑world constraints.
Usability Testing
Usability Testing
I conducted moderated usability testing with 5 escort officers across multiple scenarios:
Changing assigned rooms
Assisting visitor check in/out
Managing multiple entrances
Retrospective login without prior check‑in
Results:
All participants successfully completed assisted check in/out
Ease‑of‑use ratings ranged from 7–9 / 10
The escort‑assisted model was universally accepted
Key feedback informed improvements to system messaging and reminders.
Validation
Validation
Retrospective Login
Insight: Escort officers expect access to reflect real-time status
Response: Only checked-in entrances are shown, with a clear refresh prompt reinforcing that check-in grants authority
Mental model
Insight: “No actions = I’m not checked in” was unclear
Response: Improved instructional banners
Trust & audit
Insight: Users worried about timestamps
Response: Locked timestamps, clarified audit trail
Outcomes & Impact
Outcomes & Impact
Operational
Operational
36% reduction in completion time for check-in/out flows
Faster resolution of unresolved visitor states
Security & Compliance
Security & Compliance
Reduced blind spots during audits
Clear accountability for who was present, where, and when
Organisational
Organisational
Escort officers transitioned from passive enforcers → active system operators
Reduced reliance on physical logbooks
Trade-offs & Constraints
Trade-offs & Constraints
Offline mode was requested but not feasible due to security policies
Timestamp edits were restricted despite PO requests, to preserve audit integrity
Some flexibility was intentionally sacrificed for compliance correctness
Reflection
Reflection
If given more runway:
Add proactive “You’re still checked in” nudges for escorts
Explore badge/NFC-assisted presence validation
Stress-test flows for emergency evacuation scenarios
Page updated
Report abuse