Multi-Team Admin Platform
Design an organization administration system for teams, inherited permissions, shared billing, and auditable access changes.
The brief
Understand the problem
Background
A research platform is used by separate laboratories inside one university. Central administrators pay for the account, lab owners manage their own members, and some datasets are shared across teams.
User context
Evelyn administers six laboratories with 240 members. She must move a researcher between teams, preserve approved dataset access, and remove permissions inherited from the former lab.
Product problem
Organization-wide and team-level settings overlap, making it easy to grant excessive access or remove a permission that another legitimate role still provides.
Objective
Create information architecture and workflows that make membership, role inheritance, billing scope, and sensitive changes understandable before commitment.
What to design
Define the experience
Required experience
- Navigate from the organization to a specific team
- Inspect a member's effective access and its sources
- Move the member while reviewing permission changes
- Confirm the change and inspect the resulting audit event
Screens and states
- Organization overview
- Team and member directory
- Effective permission detail
- Change review and audit log
Core user flow
Follow the critical path
- 01
Evelyn opens the organization and selects the departing laboratory
- 02
She reviews the researcher's direct, team, and shared-project access
- 03
A transfer preview shows which permissions remain, end, or need approval
- 04
Evelyn confirms the move and verifies the audit entry
Product rules
Requirements and constraints
Requirements
- Distinguish organization, team, project, and direct access sources
- Preview effective permission changes before saving
- Support role comparison without relying on color
- Record actor, time, scope, and reason for sensitive changes
- Separate billing administration from data access
Constraints
- Team owners cannot grant organization-level roles
- At least two organization owners must remain active
- Restricted project names may be hidden from administrators without clearance
Reality check
States worth considering
Finish line
What to deliver
- Four desktop screens plus a role inheritance model
- Annotations for destructive-action review and restricted data
If you want more
Optional extensions
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.
Theory to review
UX principles for this brief
Use these as decision lenses, then validate the design with the people and context in the brief.
theoryCognitive LoadCognitive load describes demands placed on limited working-memory resources while a person learns or performs a task.
usability heuristicRecognition Rather Than RecallMake relevant objects, actions, and options visible or readily retrievable so people do not have to recall them unaided.