A complex roles-and-permissions UX crit, and the question behind the functionality: do you model a system around its own structure, or around the job the person is trying to do?
A designer brought a challenging roles-and-permissions redesign to crit this week. The current system stacks roles in ways that leak access, a scheduler who can see financial reports, that kind of thing, and the redesign lets a practice build custom roles: pick a base type, toggle scopes like billing and documentation and reporting, set client access, name it, invite people. It’s careful work and the structure is sound.
What I kept circling was the entry point. The flow starts by creating a role, an abstract container, and then deciding who goes in it. On a whiteboard I’d do the opposite. I’d circle the three people who handle billing and work outward to what they need to touch. Start with the people, then derive the rules. The designer’s counter was fair: the invite flow already starts with a person, and custom-role creation is a separate act by design. We left it open, which is the right place to leave it. The tension is the whole point.
There was a second moment in the crit worth calling out. Another designer framed a new permission grouping as a subcategory, one more item under an existing list. I interjected that it’s more of a super-category, something that spans multiple product types rather than nesting under one. The distinction is important because the list-growth problem doesn’t get solved by adding tidier rows. It gets solved by a layer above the rows, the way Figma’s seat levels sit above individual permissions. If every new product scope just extends the list, the system gets less usable with every feature you ship.
Underneath both moments rests the same question: do we model the system around its own structure, or around the job the person is trying to do?
Structure-first is easier to build and easier for engineers to reason about. It’s also how you end up with a roles matrix that’s accurate, complete, and impossible for an admin to navigate.
Nobody in the room could yet say what happens when someone creates a duplicate custom role, because the flow was designed from the container down, not the job up.
The teachable part
When you critique UX work around a permissions flow, an information architecture, any system with structure, notice where it starts. If it starts by asking the user to name an abstract container, that’s usually a tell that the model was built structure-first. The test I keep coming back to: could the person describe what they need in terms of who and what, before they learn your vocabulary for roles and scopes? If yes, start there. The structure can come after.