UX/UI Foundations for Course-Level User Group Management
This document presents a refined UX/UI proposal for the user grouping functionality in Open edX. It aims to align technical goals with a user experience that is clear, scalable, and easy to use for course teams. The proposal reflects the current conceptual stage of the project and will continue evolving as it incorporates feedback and progresses toward design and implementation.
Table of Contents
What This Document Covers
The main problems the design aims to solve.
The core principles and requirements guiding the user experience.
The essential UI components of the solution.
The scope of this version (what is included now and what may be introduced later).
Key questions for engineering and product teams regarding feasibility and implementation.
Core Design Principles
These principles define the foundation of the user experience for course-level group management. They are intended to guide decision-making, prioritization, and validation throughout the design process. Including them in the project’s Design Brief and applying them as review criteria during key milestones will help ensure consistency and usability.
In addition, these principles help identify broader UX challenges and connect user needs with technical feasibility.
High-Level UX Requirements
Outlined below are initial UX requirements drawn from early discussions and anticipated user needs. These will be refined through prototyping and testing:
Instructors should be able to create user groups without needing to understand technical or logical expressions.
The interface should provide clear visual feedback when rules are added, edited, or removed.
Users should be able to view active criteria and understand their effect on group membership.
Simple preconfigured templates should help address common use cases (e.g., “inactive learners”).
Where possible, a preview of group impact should be provided.
The system should display clear group statuses (e.g., active, disabled, outdated).
Error states (e.g., sync failures or missing data) should be clearly communicated.
The UI must be accessible for users relying on keyboard navigation or screen readers.
Design Goals by Principle
1. Make Group Logic Understandable
Users should always understand why someone belongs to a group.
Design Response:
Include a “Why is this user here?” explanation feature
Use categories to group criteria (e.g., performance, engagement) for easier navigation
2. Keep the Interface Simple
Managing complex logic like AND/OR can be overwhelming.
Design Response:
Introduce a rule builder with a step-by-step interface
Limit to AND logic in the MVP to reduce initial complexity
Provide ready-to-use templates for common cases
3. Show Clear Feedback
Users need confirmation that group changes or syncs were successful.
Design Response:
Display sync status with timestamps
Use on-screen messages to confirm success or flag errors
Warn users of potential logic conflicts between rules
Key Interface Components
Group Builder Wizard
Scope is pre-set to course level in this version, but the design allows for future expansion to organization or instance-level.
Users can create groups in two ways:
Upload a CSV with user emails or IDs
Define rules using drop-down criteria selectors (operators adjust based on the data type selected)
Users can optionally exclude members based on specific rules
Group Dashboard
A table lists each group with its name, creation method, status, and size
Status types include:
Active: syncing regularly
Disabled: frozen and not updating
Error: sync issue present
Group Detail View
View all current criteria for the group
Where technically feasible, users may preview estimated group size and see warnings if no matches are found
Display a list of members and last update timestamp
Include filters and export options as needed
Users can rename the group from this view
Helper text will explain what enabling or disabling a group does (e.g., "Disabling stops automatic updates but retains current members.")
Where Will This Live in Open edX?
The initial implementation will live in the Instructor tab of the LMS. This version will only support course-level user grouping.
In future phases, user grouping at broader scopes (organization or platform level) may be managed in a new, centralized admin console.
Ideas for the Future
Visual Logic Mapping: Help users interpret nested AND/OR rules through a visual tree or block structure
Nested Groups: Create subgroup relationships (e.g., teams inside departments)
Membership Analytics: Show group size changes over time
Tool Integrations: Allow use of groups in messaging tools or content targeting
Membership Change History: A full timeline of when users are added or removed based on rule updates may be explored in future iterations
UX Comparative Table (Moodle, Canvas and Open edX)
Criteria | Canvas | Moodle | Open edX Now |
|---|---|---|---|
Location & Access | Groups live under “People” → “Groups”. Clear path, accessible. | Found under “Participants” → “Groups”, but slightly buried for new users. | No unified interface. Group management is split between Teams, Cohorts, and Enrollment Tracks in different areas. |
Labels / Terminology | Uses accessible terms: “Groups”, “Group Sets”. | Uses “Groups”, “Groupings”, “Cohorts” (overlapping). | Uses “Cohorts”, “Teams”, “Enrollment Tracks” lacks consistency and clarity. |
Group Creation (Manual & Auto) | Manual, automatic, CSV supported. | Manual, auto-create based on number/size. | Manual, CSV supported. Basic auto-assignment to cohorts based on content visibility (not user attributes). |
Creation Steps | Guided step-by-step inside Group Set. | Multi-click, less guided. Some features hidden. | Requires navigating through multiple admin panels. No centralized UX flow. |
Confirmation Messages | Clear visual confirmation. | No clear success feedback. | Minimal or no feedback on creation. Changes are reflected only after reload or enrollment sync. |
Member Assignment | Manual or auto-assign with drag-and-drop. | Manual or filtered auto-assign. | Only supports basic auto-assignment to cohorts based on course structure (content visibility). No support for attribute-based assignment via UI. |
Exclude specific profiles | Must be done manually. | Supports filtering when auto-creating. | Not supported via UI. Requires backend logic or manual intervention. |
Preview group before saving | Yes, while building. | No preview before creation. | Not available. You must assign users and then observe the effect manually. |
Group Visibility | Students see group members. | Visibility is configurable by instructor. | Cohorts are hidden from learners. Teams are visible if associated with team-based activities. |
Group state/status | None. | None. | None. |
Feedback & Sync Info | None. | None. | None in UI. Sync or refresh depends on backend logic; status is not visible to instructors. |
Visual Design & Hierarchy | Clean layout, icons for structure. | Dense layout, mostly text. | Very functional and admin-like. Studio UI is dated and not optimized for grouping workflows. |
Component Opportunity Map
Based on the comparative analysis above, the following component opportunities were identified to address Open edX gaps and align with best practices.
UX/UI Component | Canvas | Moodle | Open edX (Now) | Opportunity in the Proposal |
|---|---|---|---|---|
Group Creation Flow | Clear wizard (manual, auto, CSV import) | Auto-create by number or size | Fragmented between LMS and Studio. No dynamic grouping or unified experience. | Design a single, guided wizard with two entry points: CSV upload or rule-based criteria, fully inside LMS. |
Rule Builder (Dynamic Groups) | Not available | Not available | No UI support for dynamic logic. Everything is static or done via APIs. | Introduce a visual rule builder with condition blocks (AND for MVP, OR as future enhancement). |
Group Dashboard + Status | Table view, no statuses | Same: no visual status feedback | No health/status indicators. Syncing and errors are invisible to instructors. | Create a dashboard with badges like Active / Disabled / Error / Stale and bulk actions (disable, export). |
Group Detail View | Per-group list of members, basic info | Structured but lacks logic view | Cohorts and Teams are managed in separate locations. No logic traceability or timeline. | Build a Group Detail View showing logic, filters, last sync timestamp, member list, and export options. |
Visual Feedback / Sync Info | Almost none | Minimal | No confirmations, error messages, or sync timestamps. | Add toast confirmations, error states, and visual warnings (e.g., stale data or sync failures). |
Categorized Criteria Library | Not present | Not present | No groupable criteria in UI. Manual selection only. | For the MVP, criteria will be grouped visually in the UI by category (e.g., engagement, performance, profile), to support quicker scanning and reduce cognitive load. |
Accessible UI / Visual Hierarchy | Clean and intuitive | Text-heavy, dense | Studio is functional but not optimized for workflows. LMS is slightly more usable. | Apply clear visual hierarchy. |
What This UX/UI Proposal Assumes from the Technical Side
This proposal is designed with the following technical assumptions in mind, based on current MVP requirements and feasibility discussions:
Group refresh behavior: Groups will be refreshed either once daily or manually via UI (e.g., a “Refresh” button).
Criteria logic: Only 3 dynamic criteria can be combined using AND logic. No OR/nested logic is expected in this MVP.
Sync feedback: Refresh actions will not be instant; delays may vary depending on Aspects or instance-specific plugins.
Criteria source availability: Only fields listed in MVP documentation (e.g., enrollment mode, grade, engagement) will be exposed in the UI.
Design Resources
Wireframes (High Fidelity) MVP Version
Wireframes (High Fidelity) Future Version
___________________________________________________________________
What’s Next
Engineering & Product:
Confirm technical feasibility of preview and sync feedback
Evaluate performance risks tied to rule complexity
Define backend support for membership audit logs and error messages
Design:
Produce wireframes for builder, dashboard, and group detail views
Reference design patterns from similar platforms (e.g., Moodle, Canvas)
Prepare usability tests with non-technical instructors
Documentation for MVP:
UI onboarding guide for instructors
Open edX documentation page with examples, definitions, and FAQs
Resolved Questions from Engineering & Product
This section documents key questions raised by the team during the review process and how they have been addressed in the current version of the proposal:
Can users name and rename groups?
→ Yes, users can name and edit the group name at any point (see Group Detail View).Can groups be disabled or frozen?
→ Yes, users can disable a group, which freezes its sync logic while retaining current members. This is explained via helper text.Should “manual” vs “dynamic” be shown to users?
→ No. The UI now uses user-friendly options: “Upload a list of users” or “Create a group based on criteria.”Will previews be available before saving a group?
→ Where feasible, the system will support estimated member counts. This may be limited to simple rules depending on performance constraints.Is a timeline needed to show membership changes?
→ The MVP includes timestamps for group updates. A full audit history is proposed as a future enhancement.Should status include Disabled?
→ Yes, “Disabled” has been added as a group status in the dashboard.Do we need to visualize AND/OR logic?
→ MVP supports AND only. Future support for OR logic will include a visual representation (see Ideas for the Future).
Questions for Tech & Product
Can we support previewing group membership before saving (for basic rules)?
How should we display or paginate large groups (e.g., 10,000+ users)?
Will the backend expose clear error messages for UI display?
Can we track when and why users are added/removed from dynamic groups?
How should the UI respond when external data sources are temporarily unavailable?