Building software for receptionists, guards, hosts and admins at the same time

A visitor management system has at least five kinds of user: receptionists, guards, hosts, supervisors and administrators. They are all looking at the same visit and they want completely different things from it.

The instinct is to build one visitor screen and hide parts of it per role. That produces something that is mediocre for everyone and actively bad for the role that matters most.

Start from the object#

Before designing any screen, answer: what is a visit?

It carries a visitor, a host, a type, possibly a vehicle, a pass, a state and a timeline. That object is shared. Every role reads and writes some part of it, at a different moment, for a different reason.

Getting that model right is most of the work. Once it is agreed, the interfaces become views over settled truth. If you design screens first, each role's screen encodes slightly different assumptions about what a visit is, and those assumptions collide later — usually in reporting, where the numbers do not reconcile and nobody can say why.

Roles differ in context, not just permissions#

This is the part that permission systems miss entirely.

• Reception is seated, under time pressure, watched by the visitor. Needs speed and zero ambiguity.
• Security is standing, possibly outdoors, verifying quickly. Needs a glanceable signal, not a data table.
• Host is at their desk doing something else. Needs a notification, and nothing more.
• Supervisor is answering a question after the fact. Needs search and a trail.
• Admin is configuring. Needs completeness and can tolerate density.

Those are not five permission levels. They are five contexts, and a permission system cannot express any of that. It can only hide things.

The hierarchy trap#

Roles look like a hierarchy — admin above supervisor above receptionist — and that framing quietly leads to giving the "senior" role the richest interface and the junior role a cut-down one.

But reception is where the system either works or fails. That is the interface that deserves the most design attention, and in a hierarchy-shaped design it gets the least.

What good looks like#

One model, several genuinely different interfaces, each designed around a task rather than around an access level.

It is more work than one screen with conditionals. It is the difference between software people use and software people work around, and in operational environments that difference determines whether the data is worth anything six months later.