Case 02 · Product UX · Region Admin
Scoped admin rights on a many-role platform
Each region runs its own stores, budgets and people, and nobody is left guessing why something is off-limits.
Business changed · NDA
The real product is under NDA, so this portfolio moves the work into a different business: a fictional supermarket chain stands in for the real client and product. The screens are heavily simplified illustrative adaptations, and the business, the rules and the data are invented. The design problem and the reasoning behind each decision are mine.
- 0open items left in the developer spec at hand-off
- 3documents inside the prototype: What’s New, Dev and QA, and the CSD Matrix
- 1click from any documented flow step to the prototype in that exact state
The fictional product
Shelf, the fictional name I use here, is the back office of Almare Markets, a made-up supermarket chain. It’s a large internal web platform, built for desktop, where store, regional and head-office teams look after stores, campaign budgets, people and weekly checklists. It’s dense: wide tables, filters, drawers and many user roles, each seeing its own slice of the data. The real product belongs to a different business, and the chain stands in for it to keep the client confidential. I joined the real project in May 2026, when it had already been running for years.
This case is about its admin area: who can manage the regions, their campaign budgets and the people in them.
Problem
None of the platform’s roles could say "this person runs one region". The client wanted a new one, the Region Admin: someone who manages the budgets and the people of their own regions, and nothing else.
Regions become the bridge between people and money: a Region Admin looks after regions, and each region holds its stores and their Campaign Budgets. These screens are shared, so the same table has to show each person exactly what they can change, and say why when they can’t.
Constraints
- The epic spanned four prototypes: one new page and changes to three existing ones.
- The screens were shared. One screen alone served several roles, each allowed to change different fields, so I couldn’t rebuild any of them for a single role.
- Rules changed meeting by meeting. One meeting reversed several certainties at once.
- This project gives me no direct access to end users, so every rule went through the client’s stakeholders.
- Each prototype went through several rounds of review before hand-off. The tech leads validated the technical side and the rules first; then the client’s stakeholders reviewed it and gave their sign-off. Only then did it go to the development team.
Key decisions
-
01
The region becomes a record of its own
A new admin page lists each region with the people who run it, its Campaign Budgets and their owners. Ownership used to be implicit. Now it’s a row anyone can read, and the other screens point back to it.
The new Regions page, seen by a system administrator: click a region to open its drawer, then Edit to change it. -
02
Edit mode only shows what you can edit
When a Region Admin edits a budget, the form shows only the fields they can change. Blocked fields leave edit mode entirely instead of sitting there disabled, so the form never offers what it will refuse. View mode still shows every field, and when a whole record is out of reach, the Edit button says why.
-
03
Pickers show what you can’t pick, and why
Regions outside your scope stay in the list, below the ones you can choose, each marked Not your Region. That bends a common UX rule, don’t show people what they can’t act on, and it was the client’s direct request: for now, everyone should see every region, so anyone who spots something wrong can ask the system administrator to fix it. My job was to make those regions read as visible but out of reach. Hidden, a region would look missing. Greyed out with no reason, it would look broken.
Editing a Campaign Budget as a Region Admin: the drawer names the budget, and the region picker lists the regions you manage first and the rest below, each marked Not your Region. -
04
Unlisted, not deleted
When other records depend on a record, it comes off the lists instead of being deleted, so nothing that points at it breaks. And the label says what it does: the old one read as "this still works", so I renamed it to say what it hides.
Campaign Budgets, listed items only: unlisted ones step out of the list without being deleted. -
05
Who is editing decides what can be granted
On the People & Access page, what you can grant depends on who you are. Values outside your scope stay visible but locked, not removed, so the matrix reads the same for everyone and nobody wonders where a column went.
People & Access, with an open question pinned to the Edit roles button: should a locked role say why, right on the checkbox?
In the room
Stakeholder review
I walked into the review with the rules the prototype enforced on my reading alone, each pinned to the screen it governed. Most were settled in the room, and one of them overturned what I had built. By that evening, those pins were gone and the permissions had changed in the prototype’s code. The rest carried to the next session.
I still present each prototype before the client gets access. Now I present it with its open points, and ask each question in context: on the screen, at the control it’s about.
How the open points closed
At the start, most of these rules were my reading, not anyone’s decision. The process I use on every feature closed them before sign-off.
-
01
Map what’s decided
A matrix of certainties, suppositions and doubts, started on day one and tested in the kickoff with the dev leads. A meeting can move a card either way.
C
Certainties
Somebody decided it.
A saved view keeps a list’s filters and sort order.Anyone can save views of their own.S
Suppositions
I believe it and would defend it. Nobody has ruled on it.
Each list needs a default view.Teams will want to share their saved views.Could become a certainty or a doubt
D
Doubts
Nobody has answered yet.
Who can edit a view someone else shared?Does deleting a shared view delete it for everyone?Was a certainty, until a meeting reopened it
Columns are states, not filing. The example cards are invented, about a fictional saved-views feature (a list’s filters and sort order, kept to reopen later), to show how the matrix works. -
02
Pin each question to the screen it’s about
Each open point became a question on the button or field it concerns, with the reason and an owner role. A board gathers them all, one column per prototype: Regions, Campaign Budgets and People & Access, three of the epic’s four prototypes.
The questions board: one column per prototype (Regions, Campaign Budgets and People & Access, three of the epic’s four), and every post-it tied to a control on its screen. -
03
Settle it in the meeting
I ran the stakeholder meetings from the pins, noted each answer there, and prompted the AI to carry it into the matrix, the logs, the prototype and the docs.
-
04
Three documents, inside the prototype
The prototype’s Docs panel holds three documents: What’s New, a short tour of the feature for stakeholders; Dev and QA, the full spec that engineering and QA work from; and the CSD Matrix. The hand-off assistant, an agent I built for our AI framework, writes the first two from the matrix, the prototype and the meeting notes, stating each rule as it stands. The history stays in the design log.
They’re made to be read and used. People search them and click through their flows, and QA takes them as the base for its own documents, such as test cases.
Every What’s New opens with who can do what on each screen. The assistant rebuilds that matrix from the prototype’s own role rules every time it rebuilds the document, so the two can’t drift apart.
Capability System admin Region Admin Viewer Open the page Yes Yes Yes Star a record Yes Yes, regions they manage No Pin a record to the top Yes Yes No Export the table Yes Yes, regions they manage No Change the page’s default sort Yes No No The format of the matrix every What’s New opens with, filled in with invented rules. The What’s New: a short tour for stakeholders that opens with who can do what on each screen. The Dev and QA spec: every user story traced to numbered requirements. -
05
Flows you can click
Every procedure in the documents is a numbered flow, and each step opens with a chip that names the screen and the role. Click it and the prototype opens signed in as that person, in the exact state the step describes: the drawer open, the form filled in, the save and what it produces.
The prototype gets there by pressing its own buttons, never by faking a screen, and a check flags any step that points at a state the prototype can’t stage.
Dev and QA teams · Flow: add a Campaign Budget
Campaign Budgets · Region Admin Opens Add Campaign Budget.
Opens on the drawer, open
Campaign Budgets · Region Admin Fills in the form and picks a Region.
Opens on the form, filled in
Campaign Budgets · Region Admin Saves.
Opens on the new budget, saved, with its confirmation
A flow as the documents show it, redrawn with the fictional client’s names. Each chip opens the prototype in the state on its right.
AI layer
Where AI assisted
- Drafting the first matrix from the source material.
- Generating the What’s New and Dev and QA docs, the questions file and the anchor for each pin.
- Design reviews: dozens of the logged changes came from the agent’s suggestions. The call on each one was mine.
- Writing the code. I built the tools with an AI coding agent. The rules and the design are mine.
Where I overruled it
- Question wording. The last pass before a stakeholder sees it is mine.
- Change notes. The generated docs narrated every reversal ("this used to say…"), which reopened settled points. I banned them from the docs.
- Warnings. One generated doc carried ten times more warning marks than real open points. The mark is now reserved for open points only.
- Length. One section lost more than half its words with no rule lost.
What I got wrong
- I started with four kinds of open-item marker. One of them only said whether a requirement had a number yet: bookkeeping, not risk. It misfiled real items, so I cut it to three.
- I added a separate doc for other teams. The short guide already covered them, so I removed it.
Outcome
Nearly every question was pinned to the button or field it was about, and most of them closed before sign-off.
The developer spec went to hand-off with no open items left. One question stays parked for a later phase, in its doubts table.
Not measured: time saved, meeting length, or engineering questions after hand-off.
What I’d do next
- Use feature tracking’s answer step on a live feature. It carries an answer into every document in one step, and I built it after this feature closed.
- Store meeting answers somewhere shared, not in one browser.
- After hand-off, count the questions engineers bring back.