Every new user, role or permission change used to go through our support team. I designed a self-serve module where each client's admin sets up users, roles and teams on their own.
My scope: users, roles, teams and the delete flow · About 3 months, in 3 phases
Users, roles and teams in one module. Interface recreated with sample data.
When the platform was only Marine, most clients worked the same way. Our admin set up each client and created every user from the backend. Any change followed the same loop.
How a change happened
Even adding one new user followed this loop.
As new lines and clients arrived, each with its own roles and permissions, the loop could not keep up. Everyone felt it.
Clients
Our admin
Backend team
What it added up to
Every client change became our work
The more lines and clients we added, the more our admin and backend team became a bottleneck, and the longer clients waited for simple changes.
Before designing anything, I set four tests the module had to pass, one for each part of the problem.
First we worked out what the module had to contain. Then we made sure it worked for every line and every client.
We spoke with our internal teams and with clients about how they managed users today. It came down to three building blocks.
Some clients already worked in teams, but managed them outside the platform. They wanted to assign submissions to a team, and split teams by region or branch.
Marine, Aviation, PV&T and other lines each had their own roles and permissions. Inside each line, every client did it differently again.
Each line of business had its own set of roles.
One client's "Senior Underwriter" was another's "Lead Underwriter".
Some clients split work between a clearance team and underwriters. Others had underwriters do everything.
Clients wanted to decide who could do what, like who could bind a policy.
Same job, three clients
| Job | Client A | Client B | Client C |
|---|---|---|---|
| Senior underwriter | Senior Underwriter | Lead Underwriter | Underwriter II |
| Checks incoming data | Clearance Specialist | Submissions Analyst | Done by underwriters |
| Can bind a policy | Underwriting Head only | Senior and Head | All underwriters |
Illustrative examples, not real client data.
Could we ship a fixed set of default roles?
No. Fixed roles would never fit every line and every client. Each exception would send the client back to our admin, the same loop we set out to remove.
See the loop in section 01 ↑Instead of fixed roles, we built a flexible module. Each client designs its own setup inside it, and our team steps out after day one.
Who does what
| Task | Before | After |
|---|---|---|
| Set up a new client | Our admin, from the backend | Our admin creates one client admin |
| Add a user | Our admin | Client admin |
| Create or rename a role | Backend team | Client admin |
| Split a role into sub-roles | Not possible | Client admin |
| Change a role's permissions | Backend team | Client admin |
| Build teams by branch or region | Outside the platform | Client admin |
Each client now designs its own setup, with its own role names, permissions and teams. Our admin's work at onboarding became one step, and the backend team stepped out of role and permission changes.
I mapped the whole module as one flow. The order mattered: roles come first because they are assigned when a user is created, and teams are built from existing users.
1 · Roles
Open full size2 · Users
Open full size3 · Teams
Open full sizeThe module took the load off our admin and backend team. But it all landed on one client admin, and for clients working across many locations, that was too much for one person.
Who does what
The first client admin, created by our team. Has every permission. Creates other admins and decides what each can do.
Created by the super admin, for a branch, a region or any split the client wants. Permissions are set by the super admin, up to full access.
Run their own team with extra permissions, like managing members and assigning submissions.
Do the day-to-day work with the permissions their role gives them.
How the work is split is up to each client. We built the structure, and they decide how to use it.
Our admin, our backend team and now the client admin are all out of the bottleneck. Each client has a clear hierarchy, where everyone knows who does what.
Instead of rough sketches, I built working prototypes with Figma Make and Google AI Studio, connected to our design system so they looked like the real product. People could click through real flows from the first review.
From the prototypes
| Name | Role | Team | Status |
|---|---|---|---|
| Alex Morgan | Sr UW | North | Active |
| Priya Nair | Head | West | Active |
| Sam Lee | Clearance | North | Invited |
| Dana Cole | UW | South | Active |
Mid-fidelity recreations of the prototype screens.
Clickable prototypes meant product managers could test real flows against their own clients, and developers could flag technical limits before any final design work. Problems surfaced in days, not after build.
Before designing final screens, I walked through the first months of a client admin's life on the platform. At every awkward moment, I asked: what goes wrong here, and what should happen instead?
An illustrative client admin's first months.
Nobody could be added until the whole role structure was designed. Onboarding would stall on day one.
Every client starts with two roles, Admin and Member. New users become Members by default, so people can be added straight away and given custom roles later.
Never block the first day.
Adding them one by one would take days, with a typo waiting in every form.
Add users one by one, or in bulk. For bulk, the admin downloads a spreadsheet template, fills it in and uploads it.
Match the tool to the size of the job.
Every role built from scratch, one permission at a time, with small mistakes creeping in.
Duplicate a role, rename it and remove a few permissions. Head of Underwriting becomes Senior, then Junior, in minutes.
Make the second time faster than the first.
Their open submissions would sit with nobody, and a live deal could be missed.
Their open work is never lost. If they were in a team, it goes to the team manager. If not, it goes to the admin, who reassigns it.
Nothing a person owned gets lost.
People would be left holding a role that no longer exists, with broken access.
A pop-up shows everyone who holds the role. Once they are disconnected, they become Members until the admin gives them a new role.
No change happens silently.
The happy path is the easy part. The design work is in the moments nobody plans for.
Shown in the order an admin sets things up: roles first, because they are assigned when a user is created, then users, then teams.
How it shipped
About 3 months from first phase to last.
RolesScreen 1 · Roles list
Each role shows its users and permissions, so the admin can spot gaps before assigning anyone.
Screen 2 · Create role
Permissions are set once on the role, and every user with that role gets them.
Screen 3 · Users list
Role, region, team and status in one table, so the admin can find anyone without opening profiles.
Screen 4 · Add user
Region and country are captured here, which later lets teams and submissions be filtered by location.
Screen 5 · User profile
Every user's access can be checked by the client admin, without asking our team.
Screen 6 · Teams list
Manager, region and workload per team, so the admin can see where work is piling up.
Screen 7 · Create team
Teams can follow any split the client uses, such as region or branch.
Screen 8 · Team members
The team manager runs the roster, so the admin does not step in for every change.
Screen 9 · Team submissions
Each team only sees its own work, with no noise from other regions.
Deleting a user blocked until their work was manually reassigned elsewhere. A broken, multi-step dead end.
Brought reassignment inside the delete flow. The system surfaces active submissions and prompts inline reassignment before confirming deletion.
One guided flow handles both tasks, reassign and delete, without leaving the page.
Delete confirmation · inline reassignment
Reassignment lives inside the delete flow, so one action completes both tasks.
In section 03, I set four tests for the module. Here is how it did.
Client admins now create users, roles, permissions and teams on their own. Our admin's job at onboarding shrank to one step: creating the client's first admin.
Clients name their own roles, split them into sub-roles, build teams by branch or region, and add more admins for their locations.
Creating users, changing roles and permissions, and assigning teams used to be engineering tasks. Now they are settings the client controls. Tickets that still reach engineers are bugs, not setup requests.
The same module runs across all 5 lines of business, for every client.
By the numbers
It has to work for every client without feeling built for someone else. That takes ruthless abstraction and thoughtful defaults.
The inner details weren't in any brief. They came from understanding what a manager actually needs to do their job.
The admin wants to delete, so the flow helps them do it safely instead of standing in the way.
Region and country at creation felt minor. They became essential for smart team filtering down the line.
I designed this system so it would not need changing, however many new lines or clients join. For me, the real test of system design is how well it handles the cases you have not built yet.