How to Design Permissions for SaaS products

In the early days of building a SaaS product you may be targeting a specific niche. A SaaS product for dentists may start by targeting dentists only. A SaaS product for dog owners may target folks who have recently adopted a pet.

But as your product grows, so too does the range of people who use it. The dentist product may eventually include dental nurses, receptionists and patients. The dog owner product may eventually include family members or veterinary staff.

And in order to allow users of your product to manage the people who use it you’ll need to build some form of permissions system. But building permissions sounds a lot easier than it is.

So let’s explore some of the considerations you need to think about when you’re designing a permissions system for your SaaS product.

The overcomplication of permissions

We’ve all seen those hideous versions of permissions systems where you can customise every last inch of who can do what. It’s often extremely overwhelming for users who have no clue where to start.

If you’re designing and introducing a permissions based system for the first time in your product, simplicity is an important principle to stick to if possible. Try to avoid building for every single potential combination and instead prioritise a simple way to get most things done.

This is much easier to do when you’re building permissions from scratch as part of zero-to-one products, but even if you’re working on older products with a bunch of legacy designs based on previous decisions, it’s still possible to inject simplicity into your permissions by migrating users onto new, simpler roles.

Understanding what your users actually need to do

Before designing anything, your starting point should be to understand what exactly your users are trying to do with your product and how a permissions system could help.

We’ll use an example of a HR management tool to help us.

With something as sensitive as a HR management platform, you can understand why permissions play such a central role. Employees should not be able to see other employees’ records, managers might want to approve holidays and HR managers and execs might want to be able to see and do pretty much everything.

With such a complex bunch of requirements, how might you approach this?

Research your users’ jobs and needs

First up, conducting research sessions with your users will help you to understand who needs to do what. You might discover that HR managers should be able to do and see everything, but employees should be able to only see and view their own information.

For your product, before implementing any permissions, work with your users to understand their needs and what each of the different target segments might need to get their work done with your product.

We’re using a pretty extreme example of a HR management platform to illustrate the point, but it may be that your product can get by with few, if any, permission types.

Once you’ve built a solid picture of the types of jobs these users do, you can then link these back to the features your product offers and decide which of these features should become a ‘permissionable’ feature. Clearly, some features and functionality are standard and should never be grouped into a permission-based role (registering or resetting a password). But others might qualify to become a feature-based permission.

Grouping user needs helps you to understand them better.

Group user needs

With your core users needs listed, try grouping them into different buckets so that you start to build a visual representation of their needs – and the cross overs between the different groups. You may start to see that many users share the same needs, or that a specific sub category of users have very unique needs that might need to be catered to.

But before you decide on any permissions, one thing I’ve found that works really well in orienting the discussion back into the real world is to ask your users to plot out their org chart.

Why? Let’s find out.

Ask your users to plot out their org chart

Asking your users to plot out their org chart helps you in a few ways. Firstly, it orients the discussion firmly in the real world. This means that whilst you’re having a discussion about a specific feature or functionality, your users will think about the real world person who may or may not ultimately use the feature. This is more powerful than anecdotal conversations that aren’t rooted in reality.

Secondly, plotting out the org chart of a business helps you to visualise the users of a business and understand who might need a specific permission level.

Let’s take a different example and consider a product like Notion. They have two simple permission levels:

A workspace owner who can do everything and a workspace member who can do a few things.

This is simple – and it can afford to be simple since a product like Notion doesn’t really require much else when it comes to permissions management.

A HR management tool, or something like Google Analytics or Adwords though, might be a bit more complicated.

Using the org chart to understand permission levels

Once your users have plotted out their org chart, try asking them to bucket the users into different permission levels.

A powerful way to do this at the start to avoid unnecessary complexity is to limit the permission levels to two:

• Admins
• Standards

These, like the Notion example, are the two extremes of permission levels. Admins who can do everything (have access to all features) and Standard users, who can only do a set number of basic things.

What you’ll find is that when you ask your users to take their org chart and bucket it into these two groups, the vast majority of people well end up as a standard user

What this means in absolute terms

And for a small business of around 30 employees using a SaaS HR product, in absolute user numbers, this means something like this:

Visualising permissions in this way is useful because it helps you remember that the vast majority of your users won’t need any special treatment; they’ll be standard users. Admins will likely make up a very small proportion of your overall users and so too will the users who have custom permission needs.

How to deal with complex custom permission needs

Even though users with specific needs that don’t fall neatly into either an ‘Admin’ or a ‘Standard’ may be small in numbers, these doesn’t mean they can be ignored.

Many SaaS products, once they become big or complex enough, will be forced to move beyond the ‘admin / standard’ binary and into more customisable permission based roles.

The simplest way to do this is to avoid unnecessary complexity as much as possible and to create ‘custom’ permission functionality.

• 80% of users will be standard users
• 10% will be admins
• 10% will be ‘custom’

A custom permission functionality will allow admins to create a custom permission set for unique users with unique needs.

In a HR context, this might be the Chief Financial Officer who needs access to salary information, but not sensitive employee data, for example.

It is tempting to think that allowing users to save these custom roles as new, separate permission types might be a good idea. But I’d argue against this.

A word of warning on the creation of custom roles

The reality of custom permission roles is that they’re often unique to a specific individual (otherwise there’s no need for them in the first place!).

And what this means is that there’s rarely shared custom roles between 2 or more users.

In our HR example, it might be tempting to allow users to be able to create a ‘Chief Financial Officer’ permission role, for example.

But this is a bad idea. Firstly, because you end up with a huge number of badly named permission roles that nobody can remember the purpose of. And secondly, there’s only one Chief Financial Officer and their permission needs are likely to be unique to the individual – and not ones that can be shared across multiple roles.

If there are genuine examples of more than one user who may get value from a custom permission role, it may be better to create that role and offer it to all users in a controlled way, rather than allowing users to create and save a bunch of random roles.

Permissions design UI – key considerations

So we’ve discussed how to broadly approach the conceptual design of permission levels in SaaS products, but now let’s get a bit more specific by digging into some UI considerations for you and your product team.

Use lists for relative understanding

Users want to be able to see at a glance who has what permission level. Setting permissions is often a task which involves assessing access based on users in relation to one another.

If the CEO is only granted Standard access but the design team manager has Admin rights for a product you’re using, this forces you to pause and consider which permission level might be correct for the person you’re granting permissions to.

In other words, setting permissions is often done by assessing users needs in relation to one another.

This means when you’re building out permissions for your own product, try to ensure there’s always a list of users that your users can scan so that they can easily understand what powers they’re granting to their users in relation to one another.

Use columns for permission comparison

Columns also help users to understand what a permission level actually means. Sure, I’m making someone an Admin or a Standard user, but in reality, what does this mean?

A column with a bunch of bullets outlining what features are granted when a specific permission level is granted, can be extremely helpful.

Just as users need columns to understand pricing tables on SaaS pricing pages, creating a permissions table – particularly for larger, more complex products – can help users understand the appropriate permission level to grant.

Craft easy to understand explanations

‘Don’t Make me Think’ is still as relevant today as it ever has been, and this principle should also apply to designing permissions. Unless there’s a really strong reason to deviate away from it, stick to Admin and Standard as your names for all access and basic permission levels.

And aside from the naming of permission levels, the addition of a brief summary when setting a permission level also helps users understand more about the permission set.

In our Notion example, the dropdown contains explanatory text underneath each permission level, for example:

These brief summaries neatly help users to understand what the permission level does without having to scan a summary table.

Incorporate the deliberate use of friction

Finally, since permissions fundamentally impact the way users actually use your product – and the access they have based on the features they’re allowed to use, it should go without saying that changing someone’s permissions materially impacts their experience.

And in use cases like this, it often helps to incorporate a healthy dose of friction.

If changing a permission level from Admin to Standard means that a manager can no longer approve holidays, access their teams data or performance reviews for example, it probably helps to use an interstitial pop up to neatly summarise the impact of the change – before the user makes it.

Friction isn’t always a bad thing, and your users will thank you for adding friction when it helps them to make better informed decisions.