Feedback from the UX/UI Working Group 21/08/2025
1. Presentation Objective:
Share the feedback received from the UX/UI Working Group on the RBAC MVP prototype, identify key pending decisions, and define the next steps for development.
2. Summary of the Presented Prototype:
Entry Flow: From a specific library -> "Manage Access" -> Console filtered by that library.
Main Screen: List of "Team Members" with permissions in the library.
Features: Add/Edit/Delete members, assign roles, view permission details.
Design Challenges Identified: Naming conventions, library filter, permission hierarchy, scalability.
3. Key Feedback from the UX/UI Working Group:
(A) Design (UI/UX) and User Experience:
Naming:
Confusion between terms: "User", "Team Member", "Library User".
Need to align role names between requirements and designs.
Context/Scope Clarity:
Concern about clearly indicating that the view is filtered by the context library.
Suggestion: If the context is clear (entry from a library), the interface could be simplified (e.g., remove the "Access to Libraries" column).
Need to improve the UI to clearly show the scope (specific library).
View Focus:
Debate on whether the current interface feels like a complete management tool or one focused on the specific library team.
Suggestion of simplified views for roles with limited scope (similar to GitHub, Confluence).
Specific library views could have fewer filters/columns.
Iconography:
Positive feedback on using icons (view, update, delete) to orient the user in complex screens.
Acknowledgment that scaling icons for many permissions can be complex, but their perceived value is high.
Visibility of Higher Roles:
Concern about potential disorientation from seeing higher-level team members (support, platform admins) in the library team list.
Need to define which roles are relevant to show in this specific context.
(B) Product (Functionality, Requirements, Scope):
Role Scope ("All Libraries"):
Confirmation that the requirement for assigning a role with "All Libraries" scope is still valid.
Technical confirmation: Permissions assigned to "All Libraries" automatically extend to new libraries.
Library Filter:
Debate on including it in the MVP.
Pro Argument: Facilitates permission validation and allows viewing a user's total scope (if permissioned).
Con Argument: Can complicate the interface if the context is already clear.
WG Trend: Focus the MVP solely on the context library.
Visibility of Higher Roles (Repeated from UX):
Discussion on whether to show platform roles in the library team member list.
Considered an edex-specific case that could be refined post-MVP.
Roles and Hierarchies:
Clarification of roles: Viewer, Author (with/without publish), Admin.
Exploration of nuances in existing roles.
MVP Focus:
Confirmation: The MVP focuses solely on libraries, not courses or other resources.
Proposal for a "persona" exercise to define which team members are most relevant for a library author.
(C) Technical and Scalability:
Scope Implementation ("All Libraries"):
Technical question about how automatic inclusion in new libraries will be managed.
Interface Scalability:
Concern about how the list would be displayed if a user has access to many libraries (beyond tags or comma-separated lists).
How to handle visualization if there are many team members (e.g., 40 support members).
Permission/Icon Scalability:
Future challenge in scaling iconography or categorization for an extensive list of permissions.
4. Key Pending Decisions / Points for RBAC Discussion:
Include the library filter in the MVP?
Pros: Facilitates permission validation, centralized view.
Cons: Complexity, MVP focus on specific library.
WG Trend: Focus on context library for MVP.
What roles/team members to show in a specific library's list?
Question: Only direct team members or also higher roles (support, org admins)?
Consideration: The core consideration is balancing total access transparency with the need for the interface to be clear, non-disorienting, and focused on the user's primary task (managing their direct library team).
Refine the view focus for roles with limited scope (simplified views)?
Question: Build a single, centralized interface or allow simplified, contextual views?
Impact: On usability and user perception.
How to handle role and user naming consistently?
Action: Align terms between requirements and designs.
Figma Comments
[nit] Some padding / spacing reductions in this header seem like they'd help make the back to libraries area feel like a subheading / breadcrumb, echoing other authoring views.
[Clarification] Are the counts on this roles tab filter aware? Or are they listing the counts for all admins / authors / collaborators / etc across the platform?
Thank you for the feedback! ❤️