Canada Post · DIA Mobile
Role
Experience Designer
Timeline
June – July 2026
Team
~15 stakeholders
Platforms
Honeywell CT40 · CT45 · Zebra TC57
The recovery flow: a previous session is found, work is restored by category with live progress, and the outcome is confirmed.
Overview
Client
Canada Post Corporation
Delivery Partner
Deloitte Digital
My Role
Experience Designer
Timeline
June – July 2026
Team
~15 cross-functional stakeholders
Platforms
Honeywell CT40, CT45 · Zebra TC57
Users
~14,000 delivery agents
Outcome
Approved by Canada Post
Scope
Design a mobile recovery experience that lets a delivery agent resume work on a replacement device after a hardware failure — without redoing critical activities like scans, pickups, and vehicle checks.
The Challenge
Canada Post runs one of the largest last-mile operations in the country — roughly 14,000 delivery agents, 40,000 handheld devices, and 25,000 routes moving every day. Agents depend on the DIA Mobile app to scan parcels, log pickups, complete vehicle checks, and manage their route from the depot to the last doorstep.
Rugged devices still fail. Batteries die, screens crack, and units get swapped — up to 150 device swaps on a typical day. When an agent picks up a replacement device, everything they’d already done that morning was effectively gone: re-scan, re-log, re-check. A few minutes lost per incident, multiplied across thousands of agents, became a genuine operational cost — and a daily source of friction in the field.
The Real Problem
Engineering could restore a session from the backend. The design question was different: would an agent — standing in a depot with a line forming behind them — trust an unfamiliar recovery screen enough to act on it quickly and correctly?
Recovery introduces risk in both directions. Recover the wrong session and you corrupt someone’s route. Skip recovery by mistake and the morning’s work is gone for good. The interface had to make the safe choice the obvious one, and answer three questions before the agent even asked them:
01
Is this mine?
Confirm the session belongs to this agent — before anything is restored.
02
What happens if I tap this?
Spell out the consequence of every action, especially the destructive ones.
03
Did it actually work?
Show proof that work was restored — not just a spinner and a hope.
Constraints
Rugged hardware
Glove-friendly targets on Honeywell CT40 / CT45 and Zebra TC57 — used outdoors, one-handed, in a hurry.
An existing app language
DIA Mobile already had an established visual system. A new one would mean retraining thousands of agents.
A near-atomic recovery API
Backend recovery was largely all-or-nothing. Partial recovery was an edge case the UI still had to handle with grace.
Time pressure at shift start
Recovery happens at the depot with a queue behind you. Every extra tap or moment of doubt has a cost.
My Role
I owned the end-to-end recovery experience — from framing the problem to the final approved screens — working alongside ~15 stakeholders across product, engineering, and Canada Post operations. My core contributions:
Reframed recovery from a data problem into a trust-and-decision problem
Mapped the full recovery state machine — found, recovering, complete, partial, failed
Designed the complete, partial, and failure-state workflows
Made recovery progress visible by work category, not a generic spinner
Removed unnecessary dialogs and technical jargon from the flow
Presented multiple concepts to support stakeholder decision-making
Process
I started by mapping every state the system could be in, then designed the moments where an agent has to make a decision. Concepts were explored and reviewed with stakeholders before converging on the approved direction.
Map the states
→
Frame the decisions
→
Explore concepts
→
Review with Canada Post
→
Approved direction
Key Design Decisions
Each screen in the flow answers a question the agent is already asking. These are the decisions that shaped it.
Decision 01
Skipping recovery is irreversible: tap it and the previous session is gone for good. Early on, Skip looked as harmless as every other control on the screen.
I gave the destructive path its own confirmation, in plain language — “Your previous work session will no longer be available for recovery” — so no one loses a morning’s work by reflex.
Principle
Make destructive actions impossible to take by accident.
The Skip confirmation spells out exactly what is lost.
Context up front: whose session, which route, what’s recoverable.
Decision 02
The first thing an agent sees isn’t a yes/no prompt — it’s evidence. Employee ID, route, work centre, last login time, and the exact items available to recover.
Confirming identity and context first turns a leap of faith into an obvious decision.
Principle
Trust is earned with context, not confirmation dialogs.
Decision 03
Instead of a generic loading state, the recovery screen exposes progress by work category — Vehicle Check, Assigned Pickups, OFD Scans, RSMC Log Sheet, Key Ring Checkout — each with item counts and status.
An overall percentage and a realistic “up to 60 seconds” expectation let agents watch their morning come back and verify it as it happens.
Principle
Visibility builds trust faster than speed.
Recovery progress, itemised by work category.
Three designed outcomes: complete, partial, and failure.
Decision 04
Most enterprise apps stop at “Recovery complete.” I designed all three realities. Complete recovery lists exactly what came back. Partial recovery shows recovered vs. not-recovered side by side — even though the API was largely all-or-nothing.
Failure recovers nothing, but never strands the agent: it offers a clear retry and an alternative way to continue the shift.
Principle
Never leave the user in an ambiguous state.
Decision 05
Rather than introduce a new visual system, I built recovery inside DIA Mobile’s existing language — large type, oversized controls, minimal decoration.
Matching the app agents use every day minimised retraining and reduced cognitive load in a time-sensitive moment at the depot.
Principle
The best recovery UI feels like it was always there.
Recovery lives inside the native DIA Mobile experience.
One pattern, repeated on every screen
1 · Status
What just happened?
2 · Evidence
What was recovered?
3 · Action
What should I do next?
Final Solution
From signing in on a replacement device to a fully restored route — every state the agent can land in, designed end to end.
01 · Sign in & arrive
Starting a shift on a new device
Agent sign-in
Arriving at the depot
02 · Review & decide
Confirming the session, then choosing
Session found — recover all
Session found — choose what to recover
Selecting items to recover
03 · Recover
Restoring work, visibly
Recovery in progress — by work category
04 · Resolve
An honest ending for every outcome
Full recovery complete
Partial recovery
Recovery failed
Failure dialog with retry
Skip confirmation
Work-centre mismatch warning
Deliverables
Recovery state machine
Mapped and designed the found, recovering, complete, partial, and failure states.
End-to-end flows
Recover-all, selective recovery, and skip paths — from sign-in to a restored route.
Progress & status system
Category-level recovery visibility with item counts and overall percentage.
Error & edge-case handling
Failure, partial recovery, and work-centre mismatch warnings.
Concept exploration
Multiple directions explored to support stakeholder decision-making.
Native-language spec
Built to match existing DIA Mobile patterns for a near-zero-retraining rollout.
Outcome
The final recovery experience was approved by Canada Post stakeholders in the final review and carried forward as the direction for implementation — balancing operational speed, real system constraints, and user confidence while fitting seamlessly into the existing DIA Mobile ecosystem.
delivery agents supported
handheld devices in the field
device swaps handled per day
Key contributions
Reframed recovery as a trust-and-decision problem, not a data problem
Designed complete, partial, and failure-state workflows
Established recovery transparency through progress and item-level visibility
Simplified the experience by removing unnecessary dialogs and jargon
Presented multiple concepts to support stakeholder decision-making
Reflection
The most valuable move on this project was refusing to treat recovery as a backend feature with a screen attached. Reframing it as a trust-and-decision problem changed which screens mattered — and where the design effort belonged.
Designing for a depot — gloves, glare, a queue forming, a rugged device — was a reminder that enterprise UX is judged in seconds, under pressure. Clarity here isn’t a nicety; it’s the whole product.
Harry Fatukasi
Canada Post · DIA Mobile — Session Recovery