Product Design

Design a Navigation System for a Role-based Access Control Platform

Creating a navigation system for the integration of role-based portal and a non-role-based portal, ensuring user accessibility without disrupting the current workflow

Position /

UX Designer

Timeline /

Aug 2022 - Oct 2022

Tool Used /

Figma

Sketch

Miro

Notion

Contributions /

User Research

Ideation Workshop

Wireframing

User Interface Design

Prototyping

Usability Testing

What is Role-based Access Control (RBAC)?

Role-based access control (RBAC) is a security model used to restrict access to resources based on the security roles of users within an organization.

Introduction

Our client envisions an all-in-one ecosystem to unify both non-role-based apps and the current role-based portal.

My task involves designing a navigation system that seamlessly blends the role-based access control of the team portal with the diverse array of non-role-based applications in the larger portal

Results

Successfully realized a remarkable 56% reduction in time spent on role switching, streamlining user interactions and boosting productivity

Achieved an outstanding 84% increase in user satisfaction, reflecting the enhanced user experience within the integrated ecosystem

Current Role Selection Logic

The role-based portal caters to two user groups: single-role users and multi-role users.

To efficiently handle these access permissions, the portal includes a role-selection feature. This feature guarantees that each security role is limited to viewing their individual user roles and the corresponding applications they can access.

SINGLE

USER ROLE

MUTIPLE

USER ROLES

Role A

Role B

Role C

Role D

✅

❌

Challenge: Portal Integration

The company was in the process of integrating two portals into a unified ecosystem

Problem Statement

How can the integration of apps without role-based navigation with another portal that features role-based selection be achieved without disrupting the user's current workflow?

Select a role

Addressing Stakeholder Concerns About Initial Iteration's Business Requirements

The feedback we received from both the business and the users indicated the following:

The design introduced new patterns that necessitate additional training, which the stakeholders lacked the capacity to provide.
The existing role-selection mechanism could display applications that were inaccessible to the current role, potentially leading users to inadvertently work under the wrong role.
The design necessitated an increased number of clicks, which resulted in a less efficient user experience.

I was assigned to this project to conduct thorough research before proceeding with the design refinement phase. The primary objective is to address the unresolved issues that remained unattended during the initial iteration.

Before

1st Iteration

The former designer aimed to simplify the role-selection process by displaying all apps to users, regardless of their assigned user role, and automatically defaulting to the first available user role when navigating to an app. However, this approach caused confusion as users were unaware that they had been switched to another user role.

SSO Sign in ↓

Main Portal

App

After

Redesign

I kept the default first role feature intact. However, instead of dissecting the team portal and displaying all apps directly in the main portal's top-level navigation, I placed the team portal in the main menu. Upon selecting the team portal, users are directed to another page that exclusively displays accessible apps. This approach ensures that the integration has a minimal impact on our team and allows users to seamlessly continue their existing workflow.

SSO Sign in ↓

Main Portal

Sub-portal

App

1️⃣ Reflections

I initiated the process by examining the previous resources. The objective was to identify the issues that occurred and understand what went wrong in order to avoid repeating the same mistakes.

So....what went wrong?

While UX best practices can be a valuable resource, they can sometimes overshadow the business requirements, leading to a potential disconnect.
A significant amount of time was dedicated to proving the correctness of our design thinking, rather than actively listening to stakeholders and users to understand their needs, resulting in additional design time.

1st Iteration Feedback:

The first iteration aimed to solve the problem of repetitive role selection on landing after user login by displaying all the apps based on the assigned security role

However,

this approach created new issues:

The pattern of displaying apps that the current role-selection did not have access to resulted in confusion among users.

When a user clicked on an app that the current role selection did not have access to, the system automatically switched to the first user role that had access to that app.

This pattern also brought about a significant change in the way roles are selected, which is likely not favored by the stakeholders.

Due to the pattern employed, where each role had different access to apps, it became challenging for users to identify the specific user role they were currently on. This situation could potentially lead to users unknowingly working on tasks under the wrong user role.

As a result, the client has requested us to maintain the role selection navigation pattern while also exploring alternative methods for role selection

MUTIPLE

USER ROLES

Default to first available user role

2️⃣ Get feedback from Actual User on the First Iteration

To comprehend why the previous design was not effective for the users, we organized a feedback session with the actual users. The following are the key findings derived from the meeting:

Pros:

Users appreciate the default first role idea, and it can be customized to align with the user's preferred initial role

Cons:

The new pattern requires additional clicks.
Displaying inaccessible apps in the current role selection.
Non-persistent roles can lead to mistakes

Needs:

Retain the old role-selection pattern.
Persist the role selection at all times unless the user changes it.
Display the current role selection (role indicator) at all times

Refined Problem Statement

01

02

How might we enable multi-role users to complete tasks accurately across different roles?

How can we preserve the original navigation pattern that the stakeholders want to keep while avoiding any negative impact caused by the modernization effort?

3️⃣ Wireframe & Wireflow

With all the insights in mind, I explored three different ways to display role switcher

Select a role

Opt A: Switch inside the app

Select a role

Opt B: Switch in the nav menu

Link to team Portal

Opt C: Include sub-portal links in the main portal's menu

I used wireflows to test the user scenarios with various types of users to determine their effectiveness. Option C turned out to be the best solution that meets both user needs and business requirements