Enterprise Learning Administration Platform
Empowering enterprise learning administrators to assign courses to learners (and manage a budget, too)
Lead Product Designer
edX For Business
8 months
The background
edX For Business had recently launched a new purchase model for business customers called Learner Credit, allowing an expanded set of content product lines to be integrated under a single “currency.” Using Learner Credit, edX For Business customers could set an annual budget per catalog of content, and allow learners at their organization to access funds from that budget under certain set parameters.
While this largely automated methodology of distribution worked well for customers who valued easy learner access at scale, there was a clear product opportunity gap for customers who desired more control over learner access to content and budget spending.
The original Product pitch—a means of “top-down” assignment so enterprise administrators could enroll specific learners in specific content—felt straightforward enough. But as we began to better understand customer needs and establish requirements, the real magnitude (and impact!) of the project became clear.
Key challenges
The enormous scope of this project called for all hands on deck, with my team of three designers working across three engineering squads.
The feature would impact three distinct user types (enterprise administrators and learners as well as internal support team members), including two unique platforms (the enterprise Admin and Learner Portals) and associated email communications.
Tracking multiple user goals: while enabling course assignment got the most limelight, it was just as important that those assignments were represented intuitively in the customer’s budget, and that the customer could track and manage their assignments in the context of their overall Learner Credit spending utilization.
Learner Credit and its access methodologies were new both in product and concept, and lacked an established vocabulary let alone clear mental models (internally or externally).
Ensuring the feature could work across different content product lines with different business logic and keeping the user informed with the right amount of contextual help to navigate unavoidable complexity.
Getting into the right mindset
The edX For Business customer base is largely comprised of businesses and large enterprises, purchasing access to edX educational content for their workforce. While some customers purchase edX to promote employee retention and provide learning as a benefit, many other customers want to utilize their investment to service specific upskilling or reskilling needs in their organization.
While we regretfully lacked research-backed personas to reference (or time to create them in our discovery phase), we had one relevant resource up our sleeve. I had previously developed enterprise customer mindset segmentation utilizing a four-square framework for understanding user behavior based on two dimensions of contrasting user wants and needs that applied uniquely to our product.
The four enterprise customer archetypes created by the mindset segmentation framework.
In particular, the “Something for someone” archetype perfectly encapsulated the target customer for the feature we knew we needed to create. At the most fundamental level, this kind of customer needs ultimate control over who is learning what.
Moreover, following a recent analysis of customer data, we knew “Something for someone” customers represented a growing majority of our current base, especially as the business had expanded its offerings to include more premium, costly content.
This type of customer was not served well by the platform’s existing features. All previous work developing the Learner Credit purchase model had intentionally served only the “Everything for everyone” archetype well. It was time for a shift in mindset.
Just enough research
We already had strong signals of the customer need to assign courses going into the project through feedback received at almost every stage of the customer lifecycle, and the type of customer we knew we were targeting. It was also a known gap in the competitive landscape: every competitor’s platform we’d previously reviewed offered some way for learning administrators to assign content to specific people.
But this was to be an enormous investment in our product, and we wanted to understand better how administrators approached matching learners and content before settling on a user flow. In a series of six customer interviews with existing learning administrators, we learned more about existing processes and workarounds. These conversations revealed several valuable insights about our target users that would directly impact our project scope and design:
They almost universally start matching learners and content with content first.
In fact, content selections are usually informed by organizational (rather than individual learner) goals.
They are often returning to the same small handful of courses again and again.
Even if they purchased a catalog with hundreds or thousands of courses!
They have a frequent need to assign one course multiple learners.
But never multiple courses to one learner: learning administrators want learners to establish their commitment to completing their first course before investing in the cost of enrollment for another.
Wrangling complexity
As a net new function on both the back and front end of the platform, it was critical for the define phase of project planning to be collaborative and cross-functional. I wanted to make sure (as much as possible) design, engineering, and product were all speaking the same language and aligning on the same vision, especially when it came to how an assignment would impact a customer’s Learner Credit budget.
Borrowing many principles and activities from Object-Oriented UX, we started to define all the key ingredients of a course assignment and establish how the ingredients related to each other. This included aligning on a customer-facing vocabulary and agreeing the action the learning administrator should take would be “assign”—not “enroll.”
Using a simplified Object-Oriented UX system model, demonstrating how adding a new distribution mode (“push”) to complement the existing mode (“pull”) would impact critical objects in the customer experience.
While breaking down all the building blocks and driving cross-functional alignment was at times challenging, we were able to identify the most complex, gnarly questions needing answers early and ultimately save time. This quote from a Senior Product Manager on the team was truly the best testament to this collaborative, design-led approach:
“Wow, we just had a conversation in 5 minutes that [before we used Object-Oriented UX] would have taken an hour.”
Using what we’d learned from OOUX exercises and asking lots of questions, we documented how all the pieces fit together and how they overlapped with each individual customer mindset, laying the groundwork for large customers to ultimately have multiple budgets using multiple modes to serve diverse use cases.
As our understanding of what we needed to design increased in fidelity, we also participated in an engineering-led Event Storming workshop. We took much of the “what” we’d established using Object-Oriented UX and started to plot the “how” and “when.” This exercise helped further drive cross-functional alignment and ground our understanding of how assignment might work across our complex, interconnected systems.
Engineering, Product, and UX Event Stormed together to create a first vision of the holistic user flow.
Scope hammering
The initial requirements from the product team suggested different outcomes from a learning administrator’s course assignment action depending on the back-end logic coinciding with the content type and learner’s existing account status in the interest of cashing in the revenue from an assignment sooner. I pushed to reduce the complexity and potential for confusion for the user, and quickly diagrammed all the ways one course assignment could play out:
Course assignment potential outcomes as initially scoped, including two types of success outcomes and many indeterminate outcomes where partial success could be possible.
Reviewing the diagram together, the team quickly aligned on the value of a more streamlined approach, both from the user and technical perspectives. We were able to modify the scope before moving into design, saving lots of time by agreeing on one type of success outcome and reducing possible indeterminate outcomes by restricting learning administrators to assigning only one course at a time (also consistent with our research findings).
Dividing and conquering
To distribute the design work to be done across my team of three designers, I started by breaking down the project into manageable chunks.
First, by user domain:
The learning administrator’s domain — the user doing the assigning;
The learner’s domain — the user receiving the assignment;
Our internal team’s domain — the domain of users on our internal support teams who would be charged with configuring the right settings to “turn on” the new feature for each customer.
Then, by product impact: including a full inventory of the screens we knew would impacted across each product as well as net new screens. This included new email communications and Help Center articles needing to be created.
I worked with Product and Engineering to set expectations about how the design work would be tackled and discuss sequencing, developing a plan to deliver the most critical pieces of design first.
My portion of the design scope included four significant chunks of the learning administrator experience. I worked on each piece as its own smaller project, but maintaining alignment with the team’s vision for the holistic flow and the other pieces moving in parallel.
Ramping up fidelity
I followed the iterative process with all of my design work, wireframing first in low fidelity and reviewing frequently with Product and Engineering to make additional decisions regarding scope and implementation.
Signed, sealed, delivered
I wanted to ensure there was full transparency into who was doing what, but also maintain a single source of truth, especially for our engineering squads, so I led the structuring of a fastidiously organized master Figma file. This included a robust summary page providing visibility into the pieces of the project, status, and owner, and a tracker for ongoing open questions, action items, and dependencies. I worked with my team to make sure final designs were annotated with key decisions around design and functionality and any remaining open questions discussed during the iteration phase to speed implementation.
Finally, I represented the design team at regular Scrum of Scrums sessions to ensure smooth delivery of final designs to engineering, any blockers were resolved, and provide a voice for customer journey holistic thinking as project discussions progressed.
The new feature launched to over 90% of Learner Credit customers and quickly surpassed utilization expectations, in terms of both usage and revenue. Assignment revenue exceeded $50k in the first two weeks alone. Sales also quickly benefited from the release, enabling deals with larger customers interested in more premium content offerings.
Because of our due diligence during the define phase, we were able to hit the ground running while moving into the next phase of Learner Credit enhancements—allowing customers to manage multiple differently configured Learner Credit budgets targeting different audiences.