UX / Product Design — Case Study
Employee experience app
One platform, four workflows, three personas, and two authentication models, designed to scale from enterprise campuses to public-sector organizations through configuration-driven experiences.
The Employee Experience app brings four workplace tasks into one product: finding a person or a space, booking a working space, booking a meeting space, and creating a service request. It's used by administrators, employees, and guests, and it's entered from a phone, a kiosk, a shared tablet, or a QR code attached to a desk or a door.
I designed the system so one codebase could serve very different deployments — a corporate campus that wants all four workflows open to everyone, and a municipal office that wants exactly one workflow open to the public and nothing else.
The challenge
No two organizations roll this out the same way. A corporate campus might want the full set — wayfinding, desk booking, meeting room booking, and service requests — available to every employee and guest. A smaller office might only care about wayfinding and desk booking. A municipal building might want a single workflow, service requests, open to anyone who walks in, with no login required at all.
Solving this problem began with defining the application's primary user groups. The platform serves employees, guests, and administrators, each with different levels of access and visibility. Those distinctions drive what users can see, which workflows they can access, and how they interact with the system.
Administrator
Sets the rules
Configures the organization’s rollout: which of the four workflows are live, which authentication mode applies, and what guests are allowed to see.
Employee
Signed in, full context
Authenticates through the organization’s SSO or basic login, and sees whichever workflows the organization has enabled for employees.
Guest
No account required
A visitor without a login of their own. Can act without signing in — and sees only what the organization has chosen to expose.
Entry & authentication
People reach the app from four places: their own phone through the responsive app, a QR code posted at a desk or a meeting room, a lobby kiosk, or a shared tablet. What happens next depends entirely on how the organization has configured authentication.
An organization on SSO requires sign-in before anyone can proceed — a person scanning a QR code outside a meeting room is sent to log in first, every time. An organization on basic authentication can let people skip login for lower-stakes actions, like booking a room or filing a request. That difference matters: the fewer steps between scanning a code and finishing a task, the more people actually use it.
How the entry point and the organization's authentication mode determine whether sign-in is required before someone reaches the booking workflow.
Configurable by design
Which of the four workflows a person sees isn't hard-coded — it's a set of application parameters an administrator sets per organization, independently for employees and for guests. A guest's menu can look completely different from an employee's: an office might give employees all four workflows while limiting guests to service requests only.
A second parameter, available for guests only, can hide location-specific information. Instead of choosing "Room 214 — Finance," a guest picks from a list of anonymized codes, with no access to the floor plan.
A third parameter works one level up, at the floor itself. An administrator can mark any individual floor as secured — an executive floor, a data center floor. Once it's secured, no Employee Experience user, employee or guest, can search for a person or a room on that floor or view its floor plan.
Applied: a municipal office
One scenario that shaped this: a government office required by policy to let any visitor report something broken — a leaking faucet, a flickering light — without creating an account, and without being handed a floor plan of the building.
Configured this way, a visitor scans the QR code taped to the fixture. Because the office runs basic authentication, they go straight into the service request flow with no login prompt. Every other workflow is switched off for guests, and the location parameter is set to hide room names, so they pick from a short list of codes instead of a directory of the building.
Outcome
Because the workflows, the persona-level access, and the authentication model are all configuration rather than branching code paths, the same app supports a campus that wants everything and an office that wants exactly one workflow open to the public — without either organization seeing a setting that doesn't apply to them. And because basic-auth organizations can let people act before they log in, the lowest-friction path — scan, request, done — stays available wherever an organization chooses it.