One app, three users: why permission layers matter.

Design · 6 min read

Almost every app I design has more than one type of user. There's the person using the service. There's the person delivering the service. There's the person managing the business. And sometimes there are family members, carers, or other stakeholders who need partial access. Each of these people needs to see different things, do different things, and be prevented from doing certain things.

That's where permission layers come in. Get them right, and your app feels simple for everyone because each user only sees what's relevant to them. Get them wrong, and you end up with an overwhelming interface, confused users, or worse, a security problem where people can access information they shouldn't.

A real example: the NDIS life management app

I recently designed an app for NDIS life management that had to serve three distinct user types. The participant themselves, who needed to manage their daily activities, appointments, and goals. A family member or carer, who needed to see the participant's progress and provide support. And a service provider, who needed to log service delivery and access relevant participant information.

Each of these users needed a fundamentally different view of the same underlying data. The participant sees their own tasks and activities. The family member sees a summarised view of how the participant is going, but doesn't need to see every detail. The service provider sees only the information relevant to the services they deliver.

Without clear permission layers, you'd either have to build three separate apps, which triples your cost, or build one app where everyone sees everything, which creates confusion and privacy concerns. Permission layers let you build one app that adapts to who's using it.

The principle behind it: role-based access control

In software architecture, this concept is called role-based access control, or RBAC. It's been a foundational principle in security and systems design since the 1990s. Research published in ACM proceedings and IEEE established RBAC as the standard approach for managing user permissions in complex systems.

The principle is straightforward: instead of giving each individual user specific permissions, you define roles (like "participant," "carer," "provider") and assign permissions to those roles. When a new user is added, you assign them a role, and they automatically get the right level of access. This is more manageable, more secure, and easier to maintain than managing permissions user by user.

For app founders, the practical takeaway is this: think about your user types early. If your app serves multiple types of people, you need to define who sees what and who can do what before you start designing screens. Bolting permission logic onto an app after it's built is expensive and error-prone.

Simpler for users, not more complex

The counterintuitive thing about permission layers is that they make your app feel simpler, not more complex. When each user type only sees the screens, features, and data relevant to their role, the interface becomes cleaner. There are fewer options to parse, fewer buttons to wonder about, and a clearer path to the task at hand.

This ties directly into Hick's Law: the more choices you present to someone, the longer it takes them to decide. By filtering the interface based on the user's role, you're reducing choices to only the relevant ones. A service provider doesn't need to see the participant's personal goal-setting tools. A family member doesn't need to see the provider's service logging forms. Removing those options isn't restricting anyone. It's respecting their time and attention.

The Nielsen Norman Group has written extensively about this: showing users only what's relevant to their current context reduces errors and improves task completion. Permission layers are a design tool, not just a security measure.

Privacy and trust

In industries like NDIS, aged care, and health, permission layers aren't just about usability. They're about privacy and legal compliance. Participants have a right to control who sees their personal information. Carers need access to support the participant, but that access should be bounded. Providers need service-related information, not personal details that aren't relevant to their role.

Getting this right builds trust. When a participant can see that their service provider only has access to appointment details and service notes, not their personal goals or private communications, they feel safer using the app. When a family member can see that the provider can't access everything they share in the family view, they're more likely to use it honestly and consistently.

Trust isn't just a nice-to-have in these contexts. It's the difference between an app people use daily and an app they abandon because they don't feel comfortable with who's seeing their information.

Plan for it before you design

The most important thing to know about permission layers is that they need to be planned before a single screen is designed. If you start designing an app without knowing who your user types are and what each one needs to see and do, you'll end up redesigning major parts of the app later.

During the research phase, I work with clients to map out every user type, what data they need access to, what actions they can take, and what they should never see. This mapping informs the entire design. It affects navigation, screen layouts, what appears on dashboards, how notifications work, and how data flows between user types.

It also affects your development cost. A well-documented permission model makes the developer's job clearer and faster. A vague one leads to endless back-and-forth, scope changes, and a build that takes longer than it should.

Sources
ACM Digital Library - Foundational research on role-based access control (RBAC) as the standard for managing user permissions in complex systems.
IEEE Xplore - Engineering and computer science research on RBAC implementations and security architecture.
Nielsen Norman Group - Showing users only what's relevant to their context reduces errors and improves task completion.

Related blog posts:

Case study: NDIS life management app →

Designing for the person who can't read your app →

The difference between a feature and a solution →