OnlineMedEd

·

Lead UX/UI Designer

·

2018 - 2022

From Content Library to Learning System

From Content Library to Learning System

From Content Library to Learning System

How a prioritization system turned years of curriculum investment into measurable behavior change

Lift in non-video content engagement

Lift in non-video content engagement

150k+

Active accounts analyzed

130+

Beta testers reporting improved organization

01

Business context

OnlineMedEd built its reputation on free, exam-focused video lessons, then expanded into a full curriculum — PACE — that paired videos with peer-reviewed notes, board-style question banks, and companion flashcard decks. The thesis: students who learn across modalities retain more, score higher on boards, and become evangelists for the platform.

The behavior didn't follow. Most traffic stopped at the free videos. The non-video content was the substance of the paid curriculum and the thing that justified subscriptions and institutional contracts. Students weren't reaching it. Paid conversion stalled. Institutional sales were difficult to defend without evidence of structured engagement. The platform risked being perceived as a video library rather than a learning system.

OnlineMedEd built its reputation on free, exam-focused video lessons, then expanded into a full curriculum — PACE — that paired videos with peer-reviewed notes, board-style question banks, and companion flashcard decks. The thesis: students who learn across modalities retain more, score higher on boards, and become evangelists for the platform.

The behavior didn’t follow. Most traffic stopped at the free videos. The non-video content was the substance of the paid curriculum and the thing that justified subscriptions and institutional contracts. Students weren’t reaching it. Paid conversion stalled. Institutional sales were difficult to defend without evidence of structured engagement. The platform risked being perceived as a video library rather than a learning system.

02

Problem Definition

Surface Problem

Not enough content discovery opportunities

Not enough content discovery opportunities

The surface diagnosis was content discovery: students weren't finding non-video material, so the answer seemed to be better navigation or more prominent promotion. That framing was wrong.

Students weren't failing to find the content. They were failing to decide what to do next in a curriculum too large to navigate without structure, on a schedule too constrained for exploration. Medical students balance coursework, rotations, and exam prep simultaneously. They don't have time to assemble a study plan from a content library. They need the system to tell them what to study today.

The surface diagnosis was content discovery: students weren’t finding non-video material, so the answer seemed to be better navigation or more prominent promotion. That framing was wrong.

Students weren’t failing to find the content. They were failing to decide what to do next in a curriculum too large to navigate without structure, on a schedule too constrained for exploration. Medical students balance coursework, rotations, and exam prep simultaneously. They don’t have time to assemble a study plan from a content library. They need the system to tell them what to study today.

Real Problem

Users need prioritization under constraint

Users need prioritization under constraint

Users need prioritization under constraint

The real problem was prioritization under constraint. No dashboard polish would fix it, the missing artifact wasn't a better interface to the library, it was a system that converted the library into a daily plan. That reframe set the scope: the Scheduler couldn't be a feature bolted onto the existing dashboard. It had to become the primary surface of the product.

The real problem was prioritization under constraint. No dashboard polish would fix it, the missing artifact wasn’t a better interface to the library, it was a system that converted the library into a daily plan. That reframe set the scope: the Scheduler couldn’t be a feature bolted onto the existing dashboard. It had to become the primary surface of the product.

03

Goals & Success Metrics

Design Goals

Convert the content library into a personalized, prioritized daily study plan

Make non-video modalities part of the study workflow, not separate destinations

Support individual students and institutional users without fragmenting the system

Reduce decision overhead at the point of study, not the point of planning

Establish a content delivery surface future features could build on without redesign

Business Goals

Demonstrate the full PACE curriculum’s value to drive paid subscription conversion

Strengthen the institutional product line by giving faculty a deployable,
syllabus-aligned study system

Establish a content delivery surface that future personalization, marketing,
and curriculum features could plug into without redesign

Success Metrics

Schedule creation rate · Non-video modality engagement frequency · Return-visit cadence · To-do completion rate · Institutional adoption

Schedule creation rate · Non-video modality engagement frequency · Return-visit cadence · To-do completion rate · Institutional adoption

04

Research & insights

Quantitative baseline.
Four numbers framed the opportunity before any qualitative work: 76% of U.S. medical students used OnlineMedEd, and 89% used multiple study tools elsewhere in their routine — cross-modality behavior wasn't a foreign concept; it just wasn't happening on this platform. Only 18% of users completed the full PACE curriculum for their lessons. Only 8% of institutions used the platform for structured lesson plans. The audience was there, the behavior existed elsewhere, and the curriculum was built. The structural connection between them was missing.

Behavioral analysis. Working with the data team, I analyzed usage patterns across roughly 200,000 active accounts, focusing on navigation paths, modality crossover, and session structure. Students who consumed multiple modalities did so in tightly coupled sequences — a video, then its notes, then its flashcards — but only a small minority reached that coupling without external prompting. Most stopped at the video.

Session recording review. Using HotJar, I reviewed hours of session recordings to understand how students moved through the platform. Reaching modalities for the same topic required multiple clicks and page loads. The information architecture was organized around content type rather than around the unit of learning, which actively fought cross-modality behavior.

Survey design across student beta cohorts. I shaped the survey questionnaires used with student beta cohorts recruited through the product manager — structured to surface mental models around study planning, not feature preferences.

What the research established. Five findings shaped the system: Students needed a next action, not more content. Solo and institutional users needed different starting points. Strong defaults drove more behavior than customization options. The existing dashboard summarized the past when students needed to see what came next. The unit of work wasn't a calendar event — it was today's to-do list.

Quantitative baseline.
Four numbers framed the opportunity before any qualitative work: 76% of U.S. medical students used OnlineMedEd, and 89% used multiple study tools elsewhere in their routine — cross-modality behavior wasn’t a foreign concept; it just wasn’t happening on this platform. Only 18% of users completed the full PACE curriculum for their lessons. Only 8% of institutions used the platform for structured lesson plans. The audience was there, the behavior existed elsewhere, and the curriculum was built. The structural connection between them was missing.

Behavioral analysis. Working with the data team, I analyzed usage patterns across roughly 200,000 active accounts, focusing on navigation paths, modality crossover, and session structure. Students who consumed multiple modalities did so in tightly coupled sequences — a video, then its notes, then its flashcards — but only a small minority reached that coupling without external prompting. Most stopped at the video.

Session recording review. Using HotJar, I reviewed hours of session recordings to understand how students moved through the platform. Reaching modalities for the same topic required multiple clicks and page loads. The information architecture was organized around content type rather than around the unit of learning, which actively fought cross-modality behavior.

Survey design across student beta cohorts. I shaped the survey questionnaires used with student beta cohorts recruited through the product manager — structured to surface mental models around study planning, not feature preferences.

What the research established. Five findings shaped the system: Students needed a next action, not more content. Solo and institutional users needed different starting points. Strong defaults drove more behavior than customization options. The existing dashboard summarized the past when students needed to see what came next. The unit of work wasn’t a calendar event — it was today’s to-do list.

Quantitative baseline.
Four numbers framed the opportunity before any qualitative work: 76% of U.S. medical students used OnlineMedEd, and 89% used multiple study tools elsewhere in their routine — cross-modality behavior wasn't a foreign concept; it just wasn't happening on this platform. Only 18% of users completed the full PACE curriculum for their lessons. Only 8% of institutions used the platform for structured lesson plans. The audience was there, the behavior existed elsewhere, and the curriculum was built. The structural connection between them was missing.

Behavioral analysis. Working with the data team, I analyzed usage patterns across roughly 200,000 active accounts, focusing on navigation paths, modality crossover, and session structure. Students who consumed multiple modalities did so in tightly coupled sequences — a video, then its notes, then its flashcards — but only a small minority reached that coupling without external prompting. Most stopped at the video.

Session recording review. Using HotJar, I reviewed hours of session recordings to understand how students moved through the platform. Reaching modalities for the same topic required multiple clicks and page loads. The information architecture was organized around content type rather than around the unit of learning, which actively fought cross-modality behavior.

Survey design across student beta cohorts. I shaped the survey questionnaires used with student beta cohorts recruited through the product manager — structured to surface mental models around study planning, not feature preferences.

What the research established. Five findings shaped the system: Students needed a next action, not more content. Solo and institutional users needed different starting points. Strong defaults drove more behavior than customization options. The existing dashboard summarized the past when students needed to see what came next. The unit of work wasn't a calendar event — it was today's to-do list.

01

Clarity

Students don't lack content; they lack a next action.

Students don’t lack content; they lack a next action.

76% of U.S. medical students used OnlineMedEd. 89% already studied across multiple tools in their routine. The behavior existed elsewhere. The content existed here. What was missing was a system that told them what to do next.

Before any qualitative work, the quantitative landscape was clear: 76% of U.S. medical students used OnlineMedEd, and 89% used multiple study tools across their study routines — meaning cross-modality study behavior wasn’t a foreign concept to the audience. They already did it. They just didn’t do it on OnlineMedEd. Only 18% of users completed the full PACE curriculum for their lessons, and only 8% of institutions used the platform for structured remedial lesson plans. The audience was there, the behavior pattern existed elsewhere, and the curriculum was built — but the structural connection between them was missing.

02

Decision Fatigue

Different user types need different starting points.

Different user types need different starting points.

Solo students want a personalized plan; institutional users want a plan aligned to their syllabus and shareable across a cohort. A single onboarding flow couldn't serve both without compromise.

Solo students want a personalized plan; institutional users want a plan aligned to their syllabus and shareable across a cohort. A single onboarding flow couldn’t serve both without compromise.

03

Momentum

Defaults matter more than customization early on.

Defaults matter more than customization early on.

Beta testers wanted to be able to customize their schedules, but in practice they followed the system's recommendations. Strong defaults created momentum; the option to override created trust.

Beta testers wanted to be able to customize their schedules, but in practice they followed the system’s recommendations. Strong defaults created momentum; the option to override created trust.

04

Trust

The dashboard was the problem.

The dashboard was the problem.

The existing dashboard summarized account activity — a passive view of what the user had done. Students needed an active view of what came next.

The existing dashboard summarized account activity — a passive view of what the user had done. Students needed an active view of what came next.

05

Systems Thinking

The to-do list is the unit of work, not the schedule.

Students didn't think about their study plan as a calendar. They thought about it as today's list. The interface needed to match.

Students didn’t think about their study plan as a calendar. They thought about it as today’s list. The interface needed to match.

04

Constraints

Algorithm dependency.
The interface was only as good as the prioritization logic underneath it. Override patterns and recovery flows had to be designed before edge cases became technical debt.

Algorithm dependency.
The interface was only as good as the prioritization logic underneath it. Override patterns and recovery flows had to be designed before edge cases became technical debt.

Content model dependency.
Restructuring how lessons surfaced inside the Scheduler required content tagging and bundling changes — a dependency on the content team as much as engineering.

Content model dependency.
Restructuring how lessons surfaced inside the Scheduler required content tagging and bundling changes — a dependency on the content team as much as engineering.

Content model dependency.
Restructuring how lessons surfaced inside the Scheduler required content tagging and bundling changes — a dependency on the content team as much as engineering.

Content model dependency.
Restructuring how lessons surfaced inside the Scheduler required content tagging and bundling changes — a dependency on the content team as much as engineering.

05

Strategic Decisions

Decision 01

Make the Scheduler the dashboard, not a feature within it

Make the Scheduler the dashboard, not a feature within it

Make the Scheduler the dashboard, not a feature within it

The original dashboard organized around activity history, with the schedule as a secondary panel. Beta testing made the misalignment clear: students consistently ignored the activity summary and went straight to the schedule. They didn't want to see what they'd done. They wanted to see what to do next.

The original dashboard organized around activity history, with the schedule as a secondary panel. Beta testing made the misalignment clear: students consistently ignored the activity summary and went straight to the schedule. They didn’t want to see what they’d done. They wanted to see what to do next.

Why this choice

Treating the schedule as a tool students open is a different product than treating it as the surface they live in. The reframe was a product-judgment call, not a layout preference — and it set the architecture for everything else.

Treating the schedule as a tool students open is a different product than treating it as the surface they live in. The reframe was a product-judgment call, not a layout preference — and it set the architecture for everything else.

System impact

Weekly and monthly calendar views replaced the activity grid. A persistent global nav entry surfaced the next three days of scheduled work from anywhere on the site. The Scheduler became the frame everything else was organized around.

Decision 02

Design onboarding as preference capture, not data collection

Design onboarding as preference capture, not data collection

Design onboarding as preference capture, not data collection

Generating a usable plan required four inputs: target exam, exam date, weekly study capacity, and scoring goal. The path of least resistance was a single multi-field form.

Why this choice

Splitting each input into its own onboarding step reduced cognitive load — but more importantly, it let the interface explain why each input mattered. Students who understood how the system thought trusted its recommendations when those recommendations didn't match their initial expectations.

System impact

Onboarding became a trust-building surface, not a data-collection gate. Schedule creation became a routine first-session behavior for new users.

Decision 03

Separate the Editor from the calendar to design for scale, not MVP

Separate the Editor from the calendar to design for scale, not MVP

Separate the Editor from the calendar to design for scale, not MVP

The Editor, where students preview, adjust, and confirm their plan, could have been a single combined view. I designed it as two coupled panels: a collapsible editing rail alongside the calendar preview.

Why this choice

The Editor needed to support a growing operation set (drag-and-drop, day-type changes, custom tasks, rest days, multi-schedule, and eventually shared editing) without forcing a redesign each time. Decoupling controls from the calendar gave engineering room to add capability and gave the interface room to absorb it.

System impact

New Editor operations were added across several release cycles without structural changes to the surface. The architectural decision held.

Decision 04

Make the to-do list portable across the site

Make the to-do list portable across the site

Make the to-do list portable across the site

If students think in to-do lists rather than calendars, the to-do list shouldn't be locked inside one page.

Why this choice

A persistent drawer accessible from any context collapsed the navigation problem. Students no longer needed to return to the dashboard to find their next task. The to-do list became the connective tissue between planning and execution.

System impact

The to-do architecture was later reused to surface non-scheduled content (announcements, new releases, marketing messages) inside the same workflow students already trusted. It extended well past the Scheduler.

The to-do architecture was later reused to surface non-scheduled content (announcements, new releases, marketing messages) inside the same workflow students already trusted. It extended well past the Scheduler.

Decision 05

Treat the content architecture as a structural prerequisite

Treat the content architecture as a structural prerequisite

Treat the content architecture as a structural prerequisite

The PACE curriculum's value depended on students moving fluidly between modalities for the same topic. The existing IA, organized by content type, fought that movement. With engineering and content leads, I helped restructure how lessons surfaced inside the Scheduler so each scheduled item bundled its associated modalities into a single unit of work.

Why this choice

This was a content-model change, not a navigation change. Navigation improvements would have papered over a structural mismatch between how content was organized and how students needed to consume it.

System impact

Students experienced a lesson as a complete object: video, notes, questions, flashcards. No separate destinations to locate and visit.

Students experienced a lesson as a complete object: video, notes, questions, flashcards. No separate destinations to locate and visit.

06

Cross-Functional Collaboration

The Scheduler couldn't have shipped as a sequenced design-then-build project. The prioritization logic, content model, and interface were too interdependent.

I worked embedded with engineering from discovery through QA, starting with event storming workshops that mapped system events and edge cases before anything was built. This let me design override patterns and recovery flows into the Editor before they became technical debt. Architectural decisions like decoupling the Editor were made directly with the lead engineer so the interface and the underlying system evolved in lockstep. I also worked alongside QA throughout build cycles, validating edge cases and walking through flows at the level of interaction detail, not just feature presence.

With product and our co-founder Dustyn, I translated learning-science principles into rules the algorithm could apply and the interface could expose. I shaped survey questions around the prioritization hypothesis; the product manager handled recruitment. The data analyst partnered on the post-launch measurement plan. I produced documentation for the content team so lesson tagging and bundling evolved in sync with the interface.

The Scheduler couldn’t have shipped as a sequenced design-then-build project. The prioritization logic, content model, and interface were too interdependent.

I worked embedded with engineering from discovery through QA, starting with event storming workshops that mapped system events and edge cases before anything was built. This let me design override patterns and recovery flows into the Editor before they became technical debt. Architectural decisions like decoupling the Editor were made directly with the lead engineer so the interface and the underlying system evolved in lockstep. I also worked alongside QA throughout build cycles, validating edge cases and walking through flows at the level of interaction detail, not just feature presence.

With product and our co-founder Dustyn, I translated learning-science principles into rules the algorithm could apply and the interface could expose. I shaped survey questions around the prioritization hypothesis; the product manager handled recruitment. The data analyst partnered on the post-launch measurement plan. I produced documentation for the content team so lesson tagging and bundling evolved in sync with the interface.

Product

Engineering

QA

Content Team

Executive Leadership

Data

07

Outcomes

30-40% increase

30-40% increase

Non-video
content traction

Non-video content traction

~18-20% increase

Premium subscription conversion

4.1 / 5

Beta cohort
satisfaction

Beta cohort satisfaction

Qualitative:

Schedule creation became routine first-session behavior for new users

130+ beta testers reported feeling more organized against clinical rotation and exam timelines

Internal teams aligned on a shared definition of what the product was for: a learning system, not a content library

The to-do list architecture extended into non-scheduled content surfaces across later releases

The Scheduler was demonstrated to institutional partners during the sales process and contributed to early partnership interest

OnlineMedEd was later acquired by Archer Review

Schedule creation became routine first-session behavior for new users

130+ beta testers reported feeling more organized against clinical rotation and exam timelines

Internal teams aligned on a shared definition of what the product was for: a learning system, not a content library

The to-do list architecture extended into non-scheduled content surfaces across later releases

The Scheduler was demonstrated to institutional partners during the sales process and contributed to early partnership interest

OnlineMedEd was later acquired by Archer Review

30-40% increase

Non-video content traction

~18-20% increase

Premium subscription conversion

4.1 / 5

Beta cohort satisfaction

08

Key Learnings

Abundance is not a value proposition.

Students disengaged from non-video content not because it was hidden, but because the platform offered choice where they needed direction. Most "content discovery" problems are prioritization problems wearing a costume.

Dashboards should drive action, not summarize activity.

The Activity Overview asked users to do interpretive work the system should have done for them. The Scheduler-first layout worked because it answered the only question students had when they logged in: what now?

The Activity Overview asked users to do interpretive work the system should have done for them. The Scheduler-first layout worked because it answered the only question students had when they logged in: what now?

Strong defaults beat deep customization.

Beta testers asked for editing power they rarely used. The system built trust by being right by default. The flexibility layer preserved that trust when defaults missed.

Architectural decisions are interface decisions.

Decoupling the Editor, bundling modalities into single work units, making the to-do list portable: none of these were UI choices. They were system choices the UI made visible. Senior product design is mostly the upstream work.

Decoupling the Editor, bundling modalities into single work units, making the to-do list portable: none of these were UI choices. They were system choices the UI made visible. Senior product design is mostly the upstream work.

Embedded partnership beats handoff.

The Scheduler's prioritization logic, content model, and interface were too interdependent to design in a separate phase. The decisions that mattered were made in shared sprints, not in review meetings.

The Scheduler’s prioritization logic, content model, and interface were too interdependent to design in a separate phase. The decisions that mattered were made in shared sprints, not in review meetings.

09

Attribution

Strategy & Research

Problem framing, research design, architectural decisions
— Data + Product

Design direction, Survey design for student beta cohorts, session recording analysis, behavioral data interpretation
— Myself

Interaction Design

Scheduler system, Editor architecture, onboarding flow, to-do list surface
— Myself

Implementation, edge cases, QA
— Engineering

Visual/UI

Full UI and in-product illustration for the Scheduler, design system integration and synthesis
— Myself