Re-imagined A Permission Management System to Accomodate A Need For Customizable Site Access.

In the Education Technology sector, my focus has revolved around a course evaluations software product tailored for higher education institutions. It facilitates seamless collaboration among stakeholders for creating, administering, and analyzing student feedback to improve teaching and learning.

2 Broken Systems, 0 Good Options.

This case study explores the evolution of the course evaluations permission management system to meet the increasing need for Administrators to assign customized site access.

Our previous permission system proved inflexible and failed to adapt to the diverse needs of users across various roles and departments. This led to inadequate site access for stakeholders campus-wide.

In 2018 the Distributed Permission system was introduced as a hopeful replacement to allow flexible, customizable permissions. However, it faced many challenges, including low satisfaction, user errors, and low adoption rates.

Project Fast Facts

Problem

Examine the reasons behind the failure of the current Distributed Permission system and develop a solution that provides the needed flexibility without the complexity of the existing system.

Impacted Users

This problem impacted Full Site Administrators of the course evaluations product and extends to impact all site users who require access to the site.

My Role

In collaboration with one other designer and a team of developers, I designed the enhanced a site permissioning system, organized the release and supplied relevant support documentation for our client base.

Key Findings

The Distributed Permission system displayed every available permission on the screen, requiring Administrators to manually assign each permission to individual user accounts.

This method was giving users an unnecessary level of customization.

The system was fragmenting permissions into small components of a single task.

As an example, the ability to manage evaluations was broken down into 3 seperate permissions which made up the broader task (A, B, C shown).

However, the Administrator typically didn't need such detailed control, as site users generally required access to all components of a single task.

The Solution

We consolidated the visible permissions into logical groupings based on our findings during user research.

Each permission group is specifically curated on the backend to allow Site Administrators to grant access by identifying the area of the site which a user should be granted access to.

In the example referenced above, all permissions related to managing evaluations were grouped into a single permission titled “Evaluations” which can be turned on or off. This concept applies to all other permissions listed on the new screen.

The Administrator is able to customize access by selecting between "View Only" or "Manage" options and restricting access to specific organizational units (“aka” departments).

These flexible permissions enable the creation of distinct user roles across campus, ensuring simplicity and effectiveness in achieving user objectives.

How I Got There.

Studied Both Systems And Reviewed Distributed Permissions Usage Data.

FINDINGS


  • The granular nature of the distributed permission system allows massive room for user error thanks to hidden dependencies between the permissions which must all be enabled to work.

  • A huge number of users were assigned partial permissions. Meaning users were being granted access to half of what they needed resulting in an inability to perform their job function.

  • Existing user roles and their associated permissions did not align with user expectations which we discovered in subsequent research.

Conducted an in-depth analysis of existing systems to acquire feature knowledge. This involved auditing feature offerings, collaborating with the development team to grasp backend functions, engaging in manual trial and error for user experience visualization, and examining Distributed Permission clients' setups.

Compiled Existing User Research and Identified Trends.

  • Many users in the system could not access some of our most beneficial reporting tools.

  • Site Admins expressed frustration in being forced to grant users too much or too little permissions in order to perform their required job functions, causing issues with security and effeciency.

  • There was a need for greater visibility into who in the system had access to what.

FINDINGS


Conducted a Thematic Analysis on user feedback, pinpointing permission-related challenges. Identified major trends, including frustration with report access and the need to grant excessive access to low-level users for small tasks.

Organized a focus group activity, individual interviews, card sorting, and user testing to fill in the blanks.

FINDINGS


  • User Roles are incredibly diverse and have different meanings to different institutions

  • Identified a preference for referring to user roles based on ‘areas of the site’ meaning users were heavily influenced by the existing UI when referring to permission assignment.

  • Utilized card sorting to identify how each area of the site was being referred to.

  • Users communicated a desire for broader permission capabilities for user roles. However, there was a clear implication that the specific type of access, whether 'View Only' or 'Manage,' would be crucial in granting users access to new areas of the site.

Facilitated a focus group with 14 clients to explore users' perspectives on 'user roles' in a campus setting. Conducted a brainstorming activity where participants identified on-campus roles and discussed the corresponding areas of access needed on the Evaluate site.

RESULTS

Today, this solution has fully replaced the existing Distributed Permission system, however, in order to replace the curent Classic Permissions system there will need to be additional feature upgrades. Our next steps for the project will be to create bulk permission assignment to users and offer role templating capabilities.

This system has been fully adopted by all new implementation users (users being onboarded into the product). We have migrated about 5% of our existing users to the system all of whom do not require bulk permission assignment or who’s processes require this flexible solution.

LESSONS LEARNED

This project demanded a profound grasp of backend product knowledge to unravel a web of existing dependencies within permission systems.

While I've always valued starting projects with a comprehensive understanding, this experience taught me that some things cannot be understood solely through manual observation. Partnering with those who work within the backend system was critical for this project and taught me that teamwork is essential.