- Filtering by project and permission answers the original request. “Who has access to this tool” is a filter in the interface, not an export from the database.
- Access is changed in groups, not one by one. Permissions are granted or revoked for the selected people, a job title or a department in a single action.
- Invited and no access are working states. They show who has no access yet, and they narrow the list down to those people.
User & access management — game studio
Access management admin panel: employees, permissions, catalog.
Product overview
The studio’s internal access management system: the single place where a new hire is onboarded, given access to internal tools with the exact set of permissions inside each, and where the catalog those permissions come from is maintained.
Internal tools here means the admin panels and back offices the studio runs its games with: events and offers, game balance, tournaments, payments, player tickets. Behind every permission there is live data and money, so a wrong grant is expensive.
The primary users are admins: they run onboarding and offboarding, change permission sets on product managers’ requests, and answer security’s questions about who holds what.
The tool had accumulated features for years: navigation started somewhere other than the screen used daily, tools and permissions were named the way the database named them, and part of the catalog was obsolete. The redesign had to move the interface onto the product’s current design system and rebuild the admin’s flows at the same time.
Tasks
- Answering security meant leaving the interface. “Who has access to the billing back office” had to be resolved with a database query — the tool needed filters by project and permission.
- Revoking access from a group was done one person at a time. When people move between projects this is the most frequent operation — it had to become a bulk one.
- Navigation did not start where the work does. Admins work with people every day, while the project catalog is needed by a handful — the tab order said otherwise.
- The basic permission was a hidden condition. Nothing in the interface showed that a person only had entry to a tool and nothing more.
- The interface had fallen behind the platform. Components, states and density had to be brought onto the current design system.
How I worked
- A request from employees and managers is a hypothesis, not a brief. What arrived was a feature list: search, filters, bulk operations. I worked out the problem behind each ask — after interviews with admins, some of them were stated differently.
- Looked at the tool by frequency of use. What is opened daily, what once a quarter, where the path to an action is longer than the action itself. That set the tab order and the content of each screen.
- Designed whole flows, not separate screens. Onboarding, granting and revoking for one person, for a group by email list, for a job title and a department — with every state and confirmation, including empty and partial ones.
- Kept the solution inside the platform’s design system. The new states — staged edits, partial selection, bulk actions — are assembled from existing components, with no separate visual language for this tool.
- Part of the solution went into the process, not the interface. Access goes stale on HR events the tool cannot see — steps for those were added to the process instead.
- Design QA on staging. Checked the build against the specs state by state and handed fixes back to engineering.
Solutions
- The entry point is people, not the catalog. An admin’s day starts with a person; the project catalog is needed by a few and sits behind its own permission.
- Search and filters are the answer to an access question. By email or a list of emails, by project and permission, department and job title: “who has access to this tool” is resolved in the interface, not in the database.
- The unit of work is a group, not a person. Select what the search found and grant or revoke for all of them at once — by email list, by job title, by department.
- Permission edits are a draft until confirmed. A checkbox click changes nothing: edits apply in one action, while deleting or editing a person is confirmed separately.
- The basic permission became a visible permission. Entry to a tool used to be a hidden condition — now it sits in the list, together with a partial-access state.
- A job title segments people but grants nothing. Otherwise everyone assigned to it would inherit access; only the user-management owners can create job titles and departments.
Changes in the HR process
Access changes when a person’s job changes, not when someone remembers to look. The tool cannot see those events, so part of the solution went into the HR process rather than the interface: steps were added where the department’s access owner is notified and brings access back in line.
- Leaving the company — the person is deleted. A step in the HR process notifies the access owner that someone is leaving; otherwise permissions stay on a live account.
- A change of job title or department — access is revisited. The same step applies after a move: project access is updated to the current set instead of piling on top of the old one.
- Creating job titles and departments is its own permission. The lists are maintained by the user-management owners; if a title or department is missing, a helpdesk request is filed.
Screens
How access is put together
Each project declares its own permissions. What someone holds follows their tasks and seniority — not their job title or department.
- Permission edits stay a draft until Update. A checkbox click changes nothing: added and removed permissions are visible on the record, and access changes only on confirmation.
- The basic permission sits in the list with the others. It stopped being a hidden condition: it is visible that a person only has entry to the tool.
- Grants are personal, not role bundles. The studio has too many exceptions, and ready-made bundles would hide the actual access. The price is drift between people on the same job title.
- Each permission row shows who granted it and when. Most access questions are answered right there, without opening the audit log.
From a scope to live access
The scope comes from a product manager: which tools the person needs on day one. Everything after that happens in one flow — and the invite is the last step, not the first.
- A job title deliberately grants nothing. Otherwise everyone assigned to it would inherit access; it stays a way to segment people — and to revoke access from a whole group.
- The screen informs, it does not enforce. Drift inside a title and overly broad titles are computed from the permissions actually granted.
- Auto-aligning permissions to a title was rejected. It would revoke exceptions that exist for a reason, so the admin decides.
- Three levels: project → scope → permission. A deeper tree matched the backend more closely but was awkward to work in, while a flat list lost the grouping.
- Names state the action and the environment. “Can” is gone, tool names are shortened to the familiar ones, and permissions acting on live data say on production — that is the separate task in the second tab.
- Technical identifiers sit next to the names. Admins and engineers can see they are talking about the same permission.
- “Nobody” is the state that surfaces unused permissions. Cleaning the catalog became a routine task.
- The log is built from the same records the screens read. A separate log drifts away from the data over time.
- Export is for people without access to the tool. Security and compliance need a file of records, not a screenshot.
Collaboration
- Team lead
Owned the boundaries of the redesign at product level: what gets rebuilt now and what waits for the next stage. Design decisions went through review, where questions about the extent of the rework were settled.
- Coordinator
Owned the task flow: briefs came with context — who raised the request, why, what priority, who to talk to about details. The wording of a request was then tested against interviews with admins, and what came back were flows and the consequences of each option. Final review of the solution sat with him.
- Engineers
The authority on why the tool behaves the way it does: what the existing permission model supports and where its limits are. Solutions were validated for feasibility before detailed specs and signed off technically; where cost outweighed value, the design changed. Design QA on the build at the end of the sprint.
- QA
Involved from the spec stage, not after the build: cases were walked through together — which permissions are affected, what has to stay untouched. Renaming and deleting live permissions carries real risk, so every change shipped with scenarios and edge cases; from there, their standard testing cycle.
Task
The second task on the same tool: put the names in the catalog in order. Tools and permissions carried the names they were once given in the database — full formal titles — while the studio calls them by abbreviations, so search by name often missed. Some tools and permissions in the catalog were no longer in use.
A separate problem: permissions that act on live data. Nothing in the name distinguished a grant on staging from a grant on production, though real players and real money sit behind the latter.
Goals
- Rename tools to the short names people actually use, so search finds them from the first characters.
- Drop the filler “Can” from permission names and bring them under one rule.
- State production explicitly in the permissions that act on it.
- Remove obsolete tools, permissions and audiences from the catalog.
Naming rule
A permission name is built from three parts: action, object and environment. Filler words carry no meaning and are gone.
Shortening rule
A tool name is shortened the same way, part by part: what names the tool stays, filler goes, and “Back Office” becomes the abbreviation everyone uses.
What was renamed
- Tool names were shortened. Full formal titles gave way to the names used in daily work, so search finds them from the first characters.
- Production moved into the permission name. Every grant that touches live data — offers, rewards, packs, autotests, publishing — says on production.
- Unused entries left the catalog. Tools no longer in use or merged into another one, together with their permissions and audiences.
Next project
Atlas