Designing for Roles

The same SaaS product should feel purpose-built for every role that uses it --- admin, manager, and member should each see what they need, nothing more.

Why This Matters

Most SaaS products serve multiple roles within an organization. A billing admin, a project manager, and a team member all log into the same app but have completely different goals, permissions, and mental models. Treating them the same way guarantees you serve none of them well.

Role	Why You Should Care
🏢 Owner	Enterprise deals require granular roles and permissions. Without them, you lose the deal.
💻 Dev	Permission logic touches every API endpoint and UI component. Bad architecture here means security holes and spaghetti conditionals.
📋 PM	Feature specs must account for "who sees what." Missing a role consideration mid-sprint causes rework.
🎨 Designer	You are designing multiple experiences in one product. Each role needs its own user journey.

The Concept (Simple)

Think of roles like security badges in an office building. Everyone enters through the same front door, but your badge determines which floors you can access, which rooms you can enter, and which controls you can operate. A visitor sees the lobby. An employee sees their floor. A building manager sees the control room.

Your SaaS app works the same way. The codebase is one product, but the experience adapts based on who is logged in.

┌──────────────────────────────────────────────┐
│              SAME APPLICATION                 │
│                                               │
│   ┌─────────┐  ┌──────────┐  ┌──────────┐   │
│   │  ADMIN  │  │ MANAGER  │  │  MEMBER  │   │
│   │         │  │          │  │          │   │
│   │ Full    │  │ Team     │  │ Own work │   │
│   │ control │  │ overview │  │ only     │   │
│   │         │  │          │  │          │   │
│   │ Billing │  │ Reports  │  │ Tasks    │   │
│   │ Users   │  │ Assign   │  │ Profile  │   │
│   │ Config  │  │ Approve  │  │ Submit   │   │
│   └─────────┘  └──────────┘  └──────────┘   │
│                                               │
└──────────────────────────────────────────────┘

How It Works (Detailed)

Role Hierarchy

Most SaaS products follow a hierarchical role model. Understanding this hierarchy is the foundation for every UI decision.

ASCII Role Hierarchy Diagram:

                    ┌──────────────┐
                    │  SUPER ADMIN │  Platform-level (your team)
                    │  (internal)  │  Can impersonate, access all tenants
                    └──────┬───────┘
                           │
                    ┌──────┴───────┐
                    │    OWNER     │  Tenant-level
                    │              │  Full access, billing, can delete org
                    └──────┬───────┘
                           │
                    ┌──────┴───────┐
                    │    ADMIN     │  Org-level management
                    │              │  Manage users, settings, integrations
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
       ┌──────┴──────┐ ┌──┴───┐ ┌─────┴─────┐
       │   MANAGER   │ │EDITOR│ │  VIEWER   │
       │             │ │      │ │           │
       │ Team mgmt,  │ │Create│ │ Read-only │
       │ reports,    │ │edit, │ │ access    │
       │ approvals   │ │delete│ │           │
       └─────────────┘ └──────┘ └───────────┘

Permission Matrix:

Capability	Owner	Admin	Manager	Editor	Viewer
View own data	Yes	Yes	Yes	Yes	Yes
View team data	Yes	Yes	Yes	Yes	Yes
View all org data	Yes	Yes	Yes	No	No
Create content	Yes	Yes	Yes	Yes	No
Edit own content	Yes	Yes	Yes	Yes	No
Edit others' content	Yes	Yes	Yes	No	No
Delete content	Yes	Yes	Yes	No	No
Manage team members	Yes	Yes	Yes	No	No
Manage all users	Yes	Yes	No	No	No
Change org settings	Yes	Yes	No	No	No
Manage billing	Yes	No	No	No	No
Delete organization	Yes	No	No	No	No
Transfer ownership	Yes	No	No	No	No

Admin vs Regular User Experiences

The admin experience and the regular user experience often need fundamentally different layouts.

Admin Dashboard:

┌──────────────────────────────────────────────────────┐
│  [Logo]   Dashboard   Users   Settings   Billing     │
├────────────┬─────────────────────────────────────────┤
│            │                                         │
│  ADMIN     │  ┌──────────┐ ┌──────────┐ ┌────────┐ │
│  SIDEBAR   │  │ Active   │ │ MRR      │ │ Seats  │ │
│            │  │ Users    │ │ $24.8k   │ │ 38/50  │ │
│  Overview  │  │ 142      │ │ +8% ▲    │ │ 76%    │ │
│  Users     │  └──────────┘ └──────────┘ └────────┘ │
│  > All     │                                         │
│  > Pending │  ┌────────────────────────────────────┐ │
│  > Roles   │  │  RECENT USER ACTIVITY              │ │
│  Teams     │  │                                    │ │
│  Audit Log │  │  jane@co  Invited 3 members  2m   │ │
│  Security  │  │  bob@co   Changed plan       15m  │ │
│  Billing   │  │  alice@co Exported report    1h   │ │
│  ────────  │  │  john@co  Failed login (3x)  2h   │ │
│  Settings  │  │                                    │ │
│            │  └────────────────────────────────────┘ │
└────────────┴─────────────────────────────────────────┘

Regular User Dashboard:

┌──────────────────────────────────────────────────────┐
│  [Logo]   Dashboard   Projects   Reports    [Avatar] │
├────────────┬─────────────────────────────────────────┤
│            │                                         │
│  MY WORK   │  Good morning, Sarah                    │
│            │                                         │
│  Dashboard │  ┌────────────────────────────────────┐ │
│  My Tasks  │  │  YOUR TASKS TODAY           3 of 7 │ │
│  Projects  │  │                                    │ │
│  > Active  │  │  [ ] Review Q3 proposal    HIGH    │ │
│  > Archive │  │  [ ] Update client brief   MED     │ │
│  Calendar  │  │  [x] Send weekly report    DONE    │ │
│  ────────  │  └────────────────────────────────────┘ │
│  Help      │                                         │
│  Profile   │  ┌──────────────┐ ┌───────────────────┐ │
│            │  │ MY PROJECTS  │ │ TEAM UPDATES      │ │
│            │  │              │ │                   │ │
│            │  │ Project A    │ │ Bob added 3 tasks │ │
│            │  │ Project B    │ │ Design review @2pm│ │
│            │  │ + Join more  │ │ Sprint ends Fri   │ │
│            │  └──────────────┘ └───────────────────┘ │
└────────────┴─────────────────────────────────────────┘

Key differences between admin and user views:

Aspect	Admin View	Regular User View
Navigation	Org-wide sections (Users, Billing, Audit)	Personal sections (My Tasks, My Projects)
Dashboard KPIs	Org metrics (MRR, seats, active users)	Personal metrics (tasks done, deadlines)
Data scope	All users, all teams, all data	Own data, team data (if permitted)
Settings access	Full org configuration	Personal preferences only
Tone	Operational, monitoring	Productive, action-oriented

Permission-Based UI Patterns

There are three approaches to handling features a user does not have access to. Each has trade-offs.

PATTERN 1: HIDE
════════════════
Remove the element entirely.

Admin sees:      [Dashboard] [Users] [Settings] [Billing]
Member sees:     [Dashboard]

✓ Clean, uncluttered
✗ User doesn't know the feature exists
✗ Support confusion ("I don't see a Settings tab")


PATTERN 2: DISABLE
═══════════════════
Show the element but make it non-interactive.

Admin sees:      [Dashboard] [Users] [Settings] [Billing]
Member sees:     [Dashboard] [Users] [Settings] [Billing]
                                         ↑ grayed out, tooltip: "Admin only"

✓ User knows the feature exists
✓ Reduces support tickets
✗ Cluttered for low-permission users


PATTERN 3: GATE WITH UPGRADE PATH
═══════════════════════════════════
Show the element, but clicking it shows an upgrade or request-access prompt.

Member clicks [Billing] →  "You don't have access to Billing.
                            Request access from your admin."
                            [ Request Access ]

✓ Discovery + conversion opportunity
✓ User can self-serve the request
✗ Can feel like a bait-and-switch if overused

When to use each pattern:

Pattern	Use When
Hide	Feature is irrelevant to the role (member doesn't need audit logs)
Disable	Feature is relevant but restricted (editor can see reports but not export)
Gate	Feature is a plan upgrade opportunity or access is commonly requested

Team Management Interfaces

Team management is one of the most complex UX challenges in SaaS. It touches roles, permissions, invitations, and org structure.

Invite Flow:

TEAM MANAGEMENT FLOW
=====================

Admin clicks "Invite Member"
         │
         ▼
┌─────────────────────────────────┐
│  INVITE NEW MEMBER              │
│                                 │
│  Email: [________________]      │
│                                 │
│  Role:  [ Manager      ▼ ]     │
│                                 │
│  Teams: [x] Engineering         │
│         [ ] Marketing           │
│         [x] Product             │
│                                 │
│  [ Cancel ]     [ Send Invite ] │
└─────────────────────────────────┘
         │
         ▼
  Invite email sent
         │
         ▼
  User clicks link → Sign up → Lands in workspace
  with assigned role and team access

Team members list pattern:

┌──────────────────────────────────────────────────────────┐
│  Team Members                            [ + Invite ]    │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  Search: [_______________]    Filter: [All Roles ▼]      │
│                                                          │
│  ┌────────────────────────────────────────────────────┐  │
│  │ [AV]  Alice Vance        alice@company.co          │  │
│  │       Owner              Last active: 2 hours ago  │  │
│  │                                          [Manage ▼]│  │
│  ├────────────────────────────────────────────────────┤  │
│  │ [BK]  Bob Kim            bob@company.co            │  │
│  │       Admin              Last active: 1 day ago    │  │
│  │                                          [Manage ▼]│  │
│  ├────────────────────────────────────────────────────┤  │
│  │ [CL]  Carol Lee          carol@company.co          │  │
│  │       Editor             Last active: 5 min ago    │  │
│  │                                          [Manage ▼]│  │
│  ├────────────────────────────────────────────────────┤  │
│  │ [  ]  dave@company.co    PENDING INVITE            │  │
│  │       Manager            Sent: 3 days ago          │  │
│  │                                  [Resend] [Revoke] │  │
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  Showing 4 of 38 members              [1] [2] [3] [>]   │
└──────────────────────────────────────────────────────────┘

Role-Based Dashboards

Rather than one dashboard with permission checks scattered throughout, consider designing distinct dashboard experiences per role.

Decision framework:

Are your roles' daily workflows fundamentally different?
│
├── YES (e.g., admin monitors org, user does tasks)
│   │
│   └──> Design SEPARATE dashboards per role
│        Admin: /admin/dashboard
│        User:  /dashboard
│
└── NO (e.g., everyone works on projects, admins just see more)
    │
    └──> Design ONE dashboard with CONDITIONAL sections
         Show/hide cards and sections based on permissions

Conditional dashboard sections:

Section	Owner	Admin	Manager	Editor	Viewer
Welcome + quick actions	Yes	Yes	Yes	Yes	Yes
Personal task list	Yes	Yes	Yes	Yes	Yes
Team overview	Yes	Yes	Yes	No	No
Org-wide metrics	Yes	Yes	No	No	No
Billing summary	Yes	No	No	No	No
Security alerts	Yes	Yes	No	No	No
Pending invites	Yes	Yes	No	No	No

In Practice

Common Patterns for Role-Based UI

Pattern 1: Role Indicator

Always show the user which role they currently hold. This prevents confusion, especially for users who belong to multiple workspaces with different roles.

┌────────────────────────┐
│  [Avatar]              │
│  Sarah Chen            │
│  Admin · Acme Corp     │   ← Role displayed clearly
│  ──────────────────    │
│  Switch workspace      │
│  Profile settings      │
│  Log out               │
└────────────────────────┘

Pattern 2: Inline Permission Feedback

When a user tries an action they cannot perform, explain why inline --- do not just fail silently.

BAD:   Button is gone. User wonders why.
BAD:   "Error: Permission denied."      ← No context

GOOD:  Button is visible but grayed out.
       Tooltip: "Only Admins can export data. Contact your admin."

GOOD:  User clicks "Delete" →
       "You need Manager permissions to delete projects.
        [ Request Access ]"

Pattern 3: Role Switcher for Multi-Role Users

Some users hold different roles in different workspaces. A few may even have multiple roles within one workspace (rare but common in small teams where the founder is both admin and user).

┌────────────────────────────────────────┐
│  WORKSPACES                            │
│                                        │
│  ● Acme Corp          Admin            │
│    acme.app.com                        │
│                                        │
│  ○ Side Project        Editor          │
│    sideproject.app.com                 │
│                                        │
│  ○ Client Inc          Viewer          │
│    client.app.com                      │
│                                        │
│  + Create new workspace                │
│  + Join a workspace                    │
└────────────────────────────────────────┘

Multi-Role Design Checklist

Use this checklist when designing any new feature.

Before Design:

[ ] List every role that will interact with this feature
[ ] For each role, define: what can they see? What can they do?
[ ] Identify the highest-risk permission (e.g., delete, export sensitive data)
[ ] Decide pattern: hide, disable, or gate for each restricted action

During Design:

[ ] Design the feature for the LOWEST permission role first (viewer/member)
[ ] Layer additional capabilities on top for higher roles
[ ] Design the empty/restricted state as carefully as the full state
[ ] Ensure role indicators are visible in relevant contexts
[ ] Test navigation: can each role find what they need within 2 clicks?

After Design:

[ ] Review with engineering to confirm permission checks match the design
[ ] Test with actual users of each role (not just admins)
[ ] Verify that permission errors surface helpful messages, not raw error codes
[ ] Ensure the audit log captures permission-sensitive actions (see security considerations)
[ ] Document which API endpoints each role can access

Common Mistakes

Mistake	Consequence	Prevention
Designing only for admin	Regular users get a confusing, overpowered interface	Design for the lowest role first, then add layers
Hard-coding roles	Adding a new role requires touching every component	Use a permission system, not role checks (`can('edit')` not `role === 'admin'`)
No escalation path	Users with insufficient permissions hit dead ends	Always provide a "Request Access" or "Contact Admin" option
Inconsistent patterns	Some features hide, some disable, some gate	Choose one pattern per feature category and document it
Ignoring role transitions	What happens when a user is promoted or demoted?	Design for role changes: cache invalidation, UI refresh, notifications
No audit trail	Admins cannot see who did what	Log every permission-sensitive action with actor, action, target, and timestamp

Key Takeaways

Roles are not just a backend concern --- they fundamentally shape the UI each user sees
Design for the lowest-permission role first, then layer capabilities upward
Choose consistently between hide, disable, and gate patterns for restricted features
Use permission-based checks (can('edit')) rather than role-based checks (isAdmin) in code for flexibility
Every restricted action should surface a helpful message explaining why and what the user can do about it
Team management UI (invites, role changes, member lists) is deceptively complex --- invest design time proportional to its importance

Action Items

Role	Next Step
🏢 Owner	Define your product's role hierarchy. Start with 3-4 roles max --- you can always add more later.
💻 Dev	Implement a permission system (`can('action', 'resource')`) rather than checking role names directly. This makes adding new roles a configuration change, not a code change.
📋 PM	Create a permission matrix (like the one above) for your top 10 features. Share it with design and engineering before the next sprint.
🎨 Designer	Audit your current product: for each feature, what does a viewer see? If the answer is "the same as admin but broken," prioritize a role-aware redesign. Review UX patterns in Chapter 16 and ensure your role-based components use the design system from Chapter 17.

Previous: Chapter 17 --- Design System Basics | Related: Chapter 16 --- SaaS UX Principles

Designing for Roles ​

Why This Matters ​

The Concept (Simple) ​

How It Works (Detailed) ​

Role Hierarchy ​

Admin vs Regular User Experiences ​

Permission-Based UI Patterns ​

Team Management Interfaces ​

Role-Based Dashboards ​

In Practice ​

Common Patterns for Role-Based UI ​

Multi-Role Design Checklist ​

Common Mistakes ​

Key Takeaways ​

Action Items ​