Multi-surface product · HID Global

One product, four surfaces

Physical access, issued to a phone and a watch.

One pass, two people: the admin who sets it up, and the employee who carries it on a phone.

Role: Product designer, admin and employee experiences
Team: Design, product, engineering, platform partners
Year: 2022-2026
Platforms: Web admin, iOS, Android, Apple Watch
Methods: Lifecycle mapping, flows, specs, edge-case review
Outcome: One pass designed across admin tools and phone wallets

Screens and data are representative. Platform rules and production policy logic are left out.

Why this case matters

This case shows I can keep one product coherent across two kinds of user and several devices. The design problem was the pass lifecycle: issue, deliver, use, pause, end, and replace.

Problem

A pass isn't a single screen. An admin sets it up. An employee has to use it on day one, on a phone or a watch. Those are different jobs, and a shrunken admin screen wouldn't serve the employee.

What goes wrong without it

The pass fails on day one. A paused pass gets treated as an ended one. Or a rule makes sense only to the person who wrote it.

Users and jobs

Three jobs, across two kinds of user.

Admin, day one

When: an admin sets up a new employee,
They need to: get the pass onto their phone before they arrive,
So: it works the first time,
Without: a manual workaround.

Admin, rules

When: an admin writes a rule for where and when,
They need to: read back what they're about to save,
So: the rule does what they meant,
Without: learning a policy language.

Employee, lost phone

When: an employee loses their phone,
They need to: have the old pass ended and a new one issued,
So: the lost phone can't open doors.

Principles I used

Design for the person on the receiving end.
The admin makes the decision. The employee lives with it, so they get a pass, not a console.
Call each status the same thing everywhere.
Issued, provisioned, in use, suspended, revoked, reissued. Suspended never means revoked.
Show what will happen before people commit.
The rule summary is exactly what the admin agrees to.
Start with the job, not the screen.
Day-one delivery is the main flow. Lost phones, expiry, role changes, and offline use branch from it.

Approach

Two experiences, on purpose. Admins get a console for the lifecycle and rules. Employees get a pass on their phone, watch, and wallet. The watch shows only what fits in a glance.

Lifecycle

Issue
Provision
Use
Suspend
Revoke
Reissue

Decisions

Admins write rules as plain sentences they can read back.
Suspend and revoke stay separate. Suspend is temporary; revoke ends the pass.
Replacing a lost pass is one flow that ends the old pass and issues the new one.

Design

These frames are still to be drawn. Production screens aren't shown, so each placeholder names the decision it will show.

Representative frameLifecycle on an employee record
Status is a stage, not a color.
Representative frameDelivery to phone, watch, and wallet
The admin needs to know whether the pass arrived.
Representative frameRule writing with a plain-language summary
The summary is what the admin agrees to.
Representative frameLost phone
One flow ends the old pass and issues the new one.
Representative frameThe pass on a phone and a watch
The employee sees the pass, not the policy.

Outcome

What I delivered: I designed the admin and employee flows for mobile access passes. They cover the lifecycle and location rules in Apple Wallet, Apple Watch, and Google Wallet.
What I'd do next: Watch a real setup week. It will show whether admins actually decide from the rule summary.