Roles & Permissions

This case is about the ITSM Roles & Permissions improvement process, long decision discussions, and allowing customers to make their own choices.

CASE STUDY • 2024

Roles & Permissions

This case is about the ITSM Roles & Permissions improvement process, long decision discussions, and allowing customers to make their own choices.

CASE STUDY • 2024

Roles & Permissions

This case is about the ITSM Roles & Permissions improvement process, long decision discussions, and allowing customers to make their own choices.

CASE STUDY • 2024

Roles & Permissions

This case is about the ITSM Roles & Permissions improvement process, long decision discussions, and allowing customers to make their own choices.

CASE STUDY • 2024

Roles & Permissions

This case is about the ITSM Roles & Permissions improvement process, long decision discussions, and allowing customers to make their own choices.

CASE STUDY • 2024

Roles & Permissions

This case is about the ITSM Roles & Permissions improvement process, long decision discussions, and allowing customers to make their own choices.

CASE STUDY • 2024

Background

ITSM is a complex platform with numerous restrictions and legacy pages, and it was developed many years ago using HAML. While the most frequently used user-facing pages have been modernized in React, other pages deemed lower priority have remained outdated.

One such page is Roles & Permissions, a critical interface where Administrators can create new roles, assign permissions, set restrictions, and assign roles to users or groups. Despite its importance, this page has been neglected for years, as the VP of Product assumed users rarely visited it. As a result, no updates or improvements were prioritized.

Problem

At some point, our customers started actively complaining about the page's outdated look and feel, excessive scrolling, poor performance, and limited functionality.

Outdated UI

The interface looks outdated and does not meet modern usability standards, making it less intuitive for users.

Excessive Scrolling

Users must scroll excessively to access key functionalities, leading to inefficiency and frustration.

Poor Performance

The page loads slowly or responds sluggishly, negatively impacting the user experience.

Requirements

Functionality

Roles Index/Table View

Add index/table view for the Roles in the system (existing table components).

Filters Management

Implement role view filters and enable filtering, sorting, and setting column appearance in the view. The default view will be "All Roles".

Index Columns

Include the fields in the view columns to display the following information: Name, Description, User License Type, Type, Action, Subject, Scope.

Role Actions

Add actions to implement all the existing buttons associated with each Role: View users, Clone Role, Restore to default, Add permissions, and Delete action for out-of-the-box roles. Implement the "New Role" button in the index.

Permission Management

Implement the Add restriction, Edit permission, and Delete permission buttons for each permission associated with the Role.

Navigation Enhancements

Maintain drag & drop functionality to manage the permissions order associated with each Role.

Search Enhancements

Add a search box in the roles index.

UI and Consistency Improvements

Consider showing a question mark "?" instead of the "Show Help" link for consistency.

Keep the current functionality

Benefits

Better User Experience

The roles and permissions user interface will be more convenient user friendly and provide a better user experience.

Role Search and Easy Updates

Administrators will be able to search for the Roles and apply updates and changes easily.

Research

Upon reviewing the requirements, I quickly realized that adding an index to the Roles & Permissions page would not be an effective solution for several reasons:

Existing Single-Page Efficiency

Our users can already view all permissions and restrictions on a single page and manage them without navigating to another page, which streamlines their workflow.

Index Limitations

Our existing index components cannot display all the necessary data at once and provide an existing view, making it less user-friendly.

Development Complexity and Prioritization

Creating a new index component is not a current priority and would require significant development time, delaying progress on more critical tasks.

I discussed these concerns with the Product Manager regarding this ticket. After presenting my points, he agreed with my assessment. After further research, we decided to revisit this idea to ensure the best approach is taken.

I analyzed several competing platforms to understand the landscape better, searching for solutions to support complex multi-role management. Surprisingly, 98% of our competitors or other complex platforms have default limited roles with already added permissions. While these solutions simplify user management, my mission remains to preserve and improve our existing functionality.

Support ESM (Boyond IT) and thereby:

• Satisfy existing customers' requests and needs
• Drive Business Growth

• Engaging new customers
• Enable Innovation

Shaping

After exploring various options, I found it challenging to implement a modern approach to the Roles & Permissions page due to the constraints of our multifunctionality. For example, using a checkbox-based approach for selecting permissions and setting scopes is a promising solution. However, excessive scrolling persisted, making the user experience less efficient.

Additionally, any proposed changes had to align with our existing ITSM components, which had inherent limitations. These restrictions demanded thoughtful consideration and innovative solutions to balance maintaining functionality and enhancing usability.

SWSD configuration is performed once and done at the IT level. The account’s master (often the initial user, usually coming from IT) can create and manage new service providers at the IT level and configure their unique service setups.

Service Providers:
Add a Service Providers area to ITSM where a list of service providers can be defined. The minimum specifications for each provider should include the name, owner, default email alias, and ticket name (e.g., Tickets vs. Incidents).

Permissions:

When a service provider is created, an owner must be identified. The owner becomes the only user accessing the new service provider space and can assign roles and permissions to additional users.

Users & Groups Management:

Users and Groups can only be created and managed at the ITSM level. Once created, users can be viewed and edited at the Service Provider level.

Allow users to be assigned to more than one role.

Solution

The solution I proposed to the Product Manager leveraged existing components, with some adaptations required to align them with the specific content and replace some elements for optimal usability. Importantly, before finalizing the solution, I consulted with the development team to ensure feasibility and alignment with technical constraints.

The key elements of the solution are:

The solution I proposed to the Product Manager leveraged existing components, with some adaptations required to align them with the specific content and replace some elements for optimal usability. Importantly, before finalizing the solution, I consulted with the development team to ensure feasibility and alignment with technical constraints.

The key elements of the solution are:

Collapsible Card Component for Roles

Each Role appears as a collapsible card containing all relevant data.

Side Panel for Editing Roles

Clicking "Edit" opens a side panel where users can:
- Add permissions or restrictions to the Role.
- Add or modify scope as needed.
Permissions and restrictions have drag-and-drop functionality for an intuitive user experience.

Panel for Creating Roles

Creating a new Role also opens a side panel with a form that includes:
- Default permissions are pre-populated based on the License Type.

Flexible Views

The default view displays all Roles, with an option to filter and view Roles by License Type.

Filters Integration

A filter feature has been added to ensure users can quickly locate Roles or permissions within any solution.

Solution Demonstration

Several stakeholders were involved in the initial stages of this improvement before implementation, including myself as the Designer, the Product Owner who defined the requirements, and the VP of Product, who typically approves changes before deployment to our customers.

Several stakeholders were involved in the initial stages of this improvement before implementation, including myself as the Designer, the Product Owner who defined the requirements, and the VP of Product, who typically approves changes before deployment to our customers.

I presented the proposed flows to the VP of Product, who shared strong confidence in his perspective on the solution:

Customer Needs

He believed an index was what our customers needed.

Page Traffic

He maintained that customers rarely visited this page, making it unworthy of investment.

Design Consistency

He was concerned that the updated page would not align with the design of other pages in the system.

In response, I made the following points:

User Experience Impact

Hiding essential information within an inner page would compromise the user experience. Currently, users can see and manage all relevant data on one page, which is more convenient and aligned with their needs. Moving this functionality elsewhere would only add friction.

Quality of Changes

If we decide to make changes, it's crucial to implement them as effectively and thoughtfully as possible. Delivering a solution that doesn't fully address user needs diminishes the update's value.

Consistency vs. Usability

The Roles & Permissions page does not need to look identical to other pages, such as ticket or asset lists. It is enough for the behavior and components to feel familiar to users without making them feel out of place within the system.

The discussion was lengthy and spanned multiple meetings. After a thorough debate, we ultimately decided to create an alternative version incorporating an index and existing patterns from object creation and management to compare the two versions.

The discussion was lengthy and spanned multiple meetings. After a thorough debate, we ultimately decided to create an alternative version incorporating an index and existing patterns from object creation and management to compare the two versions.

Index Version

Using the template already implemented in other areas of our platform, I created a second version of the Roles & Permissions page that includes the following:

Index on the Roles & Permissions Page

The index displays only the Role's name, description, license type, assigned users, and available actions.

Actions Within the Role Page

The actions, creating, editing, and managing Roles, are performed inside the dedicated Role page.

Permissions Management

Permissions and restrictions are managed directly from the Role page.
A popup on the page allows users to set scopes for permissions and restrictions.

Drag-and-Drop Functionality

This feature remains unchanged to ensure familiarity and ease of use.

Workflow for Changes

Whenever users want to update any details, they must navigate to the specific Role page, make the necessary changes, and then return to the main index page.

A/B Testing

The Product Owner and I compared the two versions, and it was immediately clear that the second version was more complex. However, since we were not the only ones involved in the decision-making process, we had to make another attempt to convince the VP of Product not to implement the second version with the index.

Despite our efforts, we were unsuccessful. As a result, I proposed conducting A/B testing to gather feedback directly from our customers and let them decide which version they preferred. I was confident in the strength of my proposed solution.

I created a set of primary flows for each version to prepare for the testing. The Product Owner and I collaborated to compile questions related to these flows. I sent the content to the copywriter for review and, once finalized, uploaded everything to Maze.

Before sending the test to customers, we shared a non-live version with the VP of Product for review and sought feedback from the Customer Success team. Most of the CSMs supported my version, and I was not surprised.

Once the Maze test was ready and approved by stakeholders, I published it. The Product Owner and the Customer Success Management (CSM) team shared the link with our customers. The team decided to focus on our most important and largest companies.

I carefully created the flows to ensure the questionnaire was quick, engaging, and focused on answering our key questions without being long or tedious.

A - index version suggested by Product

B - card version suggested by me

The Product Owner and I compared the two versions, and it was immediately clear that the second version was more complex. However, since we were not the only ones involved in the decision-making process, we had to make another attempt to convince the VP of Product not to implement the second version with the index.

Despite our efforts, we were unsuccessful. As a result, I proposed conducting A/B testing to gather feedback directly from our customers and let them decide which version they preferred. I was confident in the strength of my proposed solution.

I created a set of primary flows for each version to prepare for the testing. The Product Owner and I collaborated to compile questions related to these flows. I sent the content to the copywriter for review and, once finalized, uploaded everything to Maze.

Before sending the test to customers, we shared a non-live version with the VP of Product for review and sought feedback from the Customer Success team. Most of the CSMs supported my version, and I was not surprised.

Once the Maze test was ready and approved by stakeholders, I published it. The Product Owner and the Customer Success Management (CSM) team shared the link with our customers. The team decided to focus on our most important and largest companies.

I carefully created the flows to ensure the questionnaire was quick, engaging, and focused on answering our key questions without being long or tedious.

A - index version suggested by Product

B - card version suggested by me

Outcome

After a few weeks, I reviewed the A/B testing report and was thrilled to see that most of our largest clients chose my version. It was a validating moment, knowing that I successfully understood and logically addressed our clients' challenges while introducing a new solution that preserved existing functionality.

I hope to see the results in production soon!

After a few weeks, I reviewed the A/B testing report and was thrilled to see that most of our largest clients chose my version. It was a validating moment, knowing that I successfully understood and logically addressed our clients' challenges while introducing a new solution that preserved existing functionality.

I hope to see the results in production soon!

Solarwinds

ESM

Reach out anytime

Let's Connect

Call me

Reach out anytime

Let's Connect

Call me

Reach out anytime

Let's Connect

Call me