Staff access for a group of pharmacies
A concept piece for a fictional client, built to show how I approach this kind of project.
The brief
Five pharmacy locations, around forty staff, and one shared login per counter. Every new starter was given a copy of someone else's access, nobody could say who was able to open the controlled medicines register, and the inspector's question "who changed this, and why?" took a day of digging.
They wanted named accounts for everyone, roles that say what they allow, a safe way to give extra access for a shift, and a record they could hand to an inspector. Everything here works: invite someone, change a role, approve a request, then find it all in the audit log. It all runs from the keyboard too, with labelled controls, real tables and announcements for screen readers.
What I focused on
- Least privilege, by defaultNew roles start with nothing, invites expire, inactive accounts are suspended, and two-step verification is required for every role that touches controlled medicines. Admin always keeps every permission, so the organization can never lock itself out.
- Permissions in plain wordsNobody should have to decode "rx.void". Every permission is a sentence ("cancel a prescription so it can't be dispensed"), the invite form says what the person will and won't be able to do as you pick their role, and any two roles can be compared side by side.
- See the impact before you saveSwitches don't apply on their own. Changes collect in a bar that says how many people they affect, dependencies switch on or off together with a note saying why, sensitive ones ask for a reason, and a review lists every change and every person before anything is saved.
- Extra access that ends on its ownStaff ask for what they need, for how long and why. Approvers can shorten it, nobody can approve their own request, and approved access counts down and ends by itself. Emergency access lets people in at once, then puts the use in front of a reviewer.
- An audit trail people can trustEvery invite, role change, approval and policy change in this demo writes a real entry, with before and after values for permission changes. It can be filtered and exported, and nothing in it can be edited or deleted: undoing something adds a new entry.
- A screen that fits the person using itSwitch who you're viewing as. A location manager only manages their own location, a pharmacist's admin screens are locked with a reason and who to ask, and an auditor can see everything but change nothing. Hidden or disabled controls always say why.
Skills
- Admin UX
- Roles and permissions
- Security UX
- Information design
- Form design and validation
- Interaction states
- Keyboard interaction
- Accessibility
- Responsive tables
- Vanilla JavaScript