Designing course visibility rules at scale with Enhanced Enrollment Rules
Helping Brightspace admins manage course visibility at scale, saving an at risk client, and increasing usage of Discover and Enrollment Rules.
My Role: Senior Product Designer
1 Product Manager, 1 Dev Manager, 6 Developers
Feb. 2023-Sept. 2023
Brightspace, Discover, Enhanced Enrollment Rules, and a client who really needed all of this
Brightspace is a learning management system that manages online learning. Discover is a tool within Brightspace that enables learners to self-enroll in courses.
Enrollment rules manage the visibilty of Discover courses. They use custom attributes, roles, and permissions in Brightspace to decide who can see which courses in Discover. For example, if a school only wanted first-year Math students to self-enroll in Math 101, a user would make an enrollment rule with the condition "Year = First Year".
The challenge was that admins could only set rules one course at a time. So if a school had 50 Math courses, they had to recreate the same rule 50 times. For clients with thousands of courses in Discover, that was impossible to manage. We also had a client who needed this feature as a condition of renewing their contract… when I joined, I learned we were already behind 😅
Steps: Set up user attributes in Brightspace or use Brightspace roles, create a course, go to the Discover settings of that course and add an Enrollment Rule, set conditions based on user attributes or role, then create the rule!
My goal with Enhanced Enrollment Rules was to fix that by giving admins a way to create a rule once and apply it across many courses.
My Process
Align: Understanding the technical complexity with rules, attributes, and roles
When I joined the team, I thought this project would be easy. I didn't even think it would be that portfolio-worthy. My solution going in was to take the rules people were creating on individual courses, turn them into a reusable list, and let admins either choose one during course creation or create a new one that could be reused in subsequent courses. If I could figure out how the tech behind visibility worked, it should be easy.
Then all the technical constraints appeared.
First constraint: Adding rules during course creation was not going to work. Course creation was under construction as part of a separate multi-year project that wouldn't be delivered in time for the client’s deadline. So instead of “adding rules to courses,” we had to flip the model and work with “adding courses to rules.”
Second constraint: Storing rules was complicated.
An entitlement was a group of rules. A rule was a group of conditions, and conditions were what pointed to user attributes (e.g. "favourite colour = RED"). A user never saw the entitlement piece, but rules always lived in entitlements in the back-end. The biggest constraint in all of this: Each course could only be associated to one entitlement. On an individual course level, this was perfect, but as soon as we started scaling rules outside of courses, we'd have to think about handling rules living in different entitlements. If a user wanted to add two different rules stored in two different entitlements, our system couldn't handle that.
Third constraint: I realized I didn't know enough about how admins actually used Discover outside of this client. I didn't know general admin workflows, how admins thought about Enrollment Rules, or how they would interpret the language and structure I was starting to design.
At that point, it was clear I had two problems to solve at once: the technical constraints and the user empathy gap. To move forward, I decided we needed to conduct a conceptual walkthrough of Enhanced Enrollment Rules with real users before going deeper into exploration.
Exploration through Conceptual UX Research: Using a low fidelity prototype to test a conceptual model
My first instinct was to keep Enhanced Enrollment Rules as close to the current experience as possible. I designed a rule creation workflow where admins could add user attributes as conditions and attach courses to that rule. The structure stayed similar to the existing Enrollment Rules workflow, which made it more approachable for admins and gave us a chance to reuse familiar front-end patterns if the backend could support it.
This is first workflow I ever created for Enhanced Enrollment rules. I prioritized the workflows based on product, design, and development alignment (the top two are the most aligned in terms of "everyone agrees these are the steps"). The pins on this page represent areas of the solution where I wanted user input (there were a lot of pins!).
To test that assumption, I built a mid-fidelity prototype using a set of low-fi components I had created for our design team, nicknamed Twilight, a spin-off of our Daylight design system. This let me move quickly and keep the focus on concepts rather than polished UI. The other bonus was that we tested our design with the client. The early involvement brought confidence that we were aiming to meet their needs.
We ran sessions with Brightspace admins to see how they interpreted the flow and language.
One of things we learned from testing was that having only "Go to Enrollment Rules" was confusing for admins who were used to adding enrollment rules here. This Add Existing button allows them to add rules that already exist to their courses without going to another page.
A few key things came out of testing:
It was a mental shift to think about “rules applied to courses” instead of “courses where you apply rules. I couldn't change this due to the technical constraints, but I did update the design to get to familiar parts faster.
The right language for admin users was important and could make or break the workflow. For example, “conditions” caused confusion, but “rule conditions” was clearer.
Admins were comfortable with more technical workflows than I expected, but some launch points still needed to be adjusted.
A slideshow of the early prototype that we tested with Brightspace admin users.
Easing technical concerns, building the high fidelity design and implementing Enhanced Enrollment Rules
Before I finished testing the mid-fidelity prototype, I brought it to the development team for an early feasibility check. Their reaction was concern. A new workflow plus changes to our entitlement service would blow up our timeline (they needed double the time, at least). I left those conversations wondering if I had to start over.
A small piece of the many explorations I made to adjust to technical constraints and user research feedback.
Explore (again): Going back through the design
With research insights in one hand and severe technical constraints in the other, I went back through the design inch by inch. I worked closely with the front-end developer to make nearly all of the workflow use existing components, cutting anything that was not essential. That made the team more open to the backend changes I was pushing hard for. I presented pages of evidence to suggest that users wouldn't understand a solution with our entitlements constraints. I narrowed in specifically on courses having multiple entitlements. With some extra spiking, they were able to change that service and support the design.
Make: Detailed Figma hand-off and hands-on development support
A large chunk of the design spec that I handed to developers. In this case, the development team was very "Figma savvy", so I was able to go pretty large and detailed with my design specifications. For other development teams, I scale up or down the documentation depending on how well they use Figma and how much information they prefer when bringing everything together.
Once the design was finalized, I documented everything in a detailed Figma spec and kept it updated throughout implementation. That gave the team a clear source of truth for workflows, edge cases, copy, and accessibility details as the feature was built.
Enrollment Rules is shipped! Results, client response and usage of Discover
We released Enrollment Rules in September 2023. The client was happy and renewed their contract with Brightspace. We also saw steady growth in Discover and Enrollment Rules usage over the next few months, and the feature made it easier for European education providers to use Discover for course enrollment.
This project pushed me to get much more confident in understanding the system behind the experience, because in a workflow this technical, even one wrong assumption can throw the whole design off. The close collaboration with developers, product, and other designers was a huge part of making it work, and that level of system analysis is something I have brought into every project since.
