Digital badgesand access control
The badge is the part of a building app that people use every day. We design its whole path, from the request to the green light at the reader, and connect it to the access control already in the building.
The path of a badge.
Four steps, each designed, prototyped and built by the same team.
Request
The tenant asks for a badge in the app with a photo and a few details, and checks everything before sending.
Approval
The request reaches the building team, who approve or deny it in a view of their own. A denial tells the tenant what to fix.
Activation
On approval the badge activates in the app: the reader rises, the badge lands and the light turns green.
Every day
From then on the phone carries the badge to the readers tenants already pass. On a campus, one badge can open every tower.
What it connects to.
A badge is only as good as the systems behind it. We work from the ones already in the building.
Access control
Credentials and access levels, issued and revoked in the system the building already runs.
The tenant directory
So the app knows a tenant’s company and floor before they type a thing.
Visitors and packages
Guest passes and package notices in the same app as the badge.
The building team
Approvals and revocations in one place, with a record of who decided what.
Questions.
Do we need new readers?
Not necessarily. It depends on what the readers on your doors support today. We start from the hardware you have and tell you plainly what it can do.
Who decides who gets a badge?
The building team. The app asks and shows; approvals and revocations stay with the people who run the property.
Why design the moment at the reader?
Because a tenant repeats it every working day. When the light turns green it should feel certain, and a little satisfying.
Start at
the door.
Tell us about the building, the people inside it and the systems already in the walls. We will tell you what we would build first.
Write to the studio