Rescuing a Failed Permissions System From The Pitfalls of Over Customization
This case study focuses on a course evaluation software product which is responsible for the collection and dissemination of student feedback on college campuses for the purpose of improved learning outcomes.
Permission assignment is a core feature within the course evaluation product which allows for the delegation of system tasks.
In 2018, the 'Distributed Permissions' system was introduced as a highly flexible alternative to the existing 'Classic Permissions' system, which employed a rigid role-based model that struggled to accommodate the diverse and complex role structures found across higher education institutions.
While the ‘Distributed Permissions’ system was a highly sought after concept, it struggled to be adopted by clients and was quickly abandoned.
Project Facts
Problem
Examine the reasons behind the failure of the 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.
I began thoroughly investigating the functionality of the 'Distributed Permissions' system including a review of the permission setup on client sites for those users who had adopted the system.
Permissions were assigned at the component level, allowing for fine-grained control over individual features within each page.
I uncovered that numerous dependencies existed between each controllable feature meaning that a permission would exist to grant access to a page and then separate permissions would exist to grant access to features on that page.
Our existing clients were inadvertently assigning incomplete permission access to their stakeholders because if all permissions associated with the task were not enabled the user was unable to perform the intended action.
For example, a user might be granted permission to "Manage Evaluations" but denied access to crucial sub-permissions like "Manage Core Questions" or "Manage Attribute Custom Questions," effectively preventing them from performing any meaningful actions within the evaluation management area.
This discovery raised critical questions:
How can we achieve flexibility without risking usability? What design changes are necessary to create a system that reflects our clients understanding of the system?
To answer these questions I organized focus groups, individual interviews, card sorting, and user testing.
I found a strong consensus among users that permissions were inherently linked to specific areas or sections of the software. In other words, users naturally associated permissions with the ability to access and interact with particular parts of the interface.
Ideation and Solutioning
This insight was crucial in informing our redesign.
By analyzing all 32 permission options and identifying dependencies, we consolidated them into 16 logical groups. This reduction in complexity significantly minimized the risk of unintended access states.
This streamlined approach resulted in a permission structure that better aligned with user expectations. Users naturally associated permissions with specific areas of the software, and this approach reflected that understanding.
However, users still required the ability to control the specific actions allowed for each task. To maintain flexibility, we introduced a dropdown menu that allows administrators to easily select the desired action type for each task (e.g., 'View Only,' 'Manage').
This simplified approach eliminated the risk of unintended access states and improved overall system stability. Additionally, we introduced the 'Data Access' setting to ensure data security and prevent unauthorized access to sensitive information across departments. (E.g. a user could be limited to viewing data only within their department or hierarchy level).