Learning Journey

  • Company

    Cerner

  • Industry & Product Line

    Healthcare IT · EHR Adoption

  • Product

    Cerner Learning

  • Role

    Sole UX Designer · 0 to 1 · Concept through Launch

  • Year

    2017 to 2020 · Still in production

  • Recognition

    Featured at Cerner Health Conference 2019, Day 2 keynote

1. The Reframe

They handed me a content problem. Make better videos, write clearer materials.

It was an experience problem.

Cerner Learning is a clinical training platform, and its job is narrow and high-stakes. When a hospital switches to a new electronic health record, thousands of clinicians have to learn new workflows while they are still seeing patients. Not “learners” in the abstract. A hospitalist, an ED nurse, an acute care nurse, a cardiologist. Different roles, different days, and not one of them with a spare hour. They learn the new system in the gaps between patients.

The content itself was fine. What was missing was a path: where am I, what is next, why does this matter for my job, and can I do it in the three minutes I have. Once I saw it that way, everything downstream changed.

I was the sole UX designer, from the first sketch through launch. Internally we called the project Learning Journey; it shipped as Cerner Learning and runs as Oracle Health today. It is the one consumer-facing product in my portfolio, and it carries two very different muscles. A learner side that has to feel consumer-grade. An admin side that has to hold up as enterprise infrastructure. This is the story of both.

2. Discovery

The reframe came from talking to clinicians in the middle of their shifts. I do not over-research. I research just enough to ask better questions.

So we mapped it on the wall. Every role. Every venue: emergency, acute, ambulatory. What each person had to be able to do before go-live, and how long it actually took. Hospitalist basics, then workflow, then the simulations. Two minutes for this one, five for that one.

Discovery whiteboard mapping each clinical role, care venue, and the tasks and time each one needed before go-live.

What surfaced was the shape of the thing. The learning had to be role-based, task-specific, and short. Not a course anyone sits through. A rehearsal for a real shift.

3. Vision: Progress-First and Responsive

The first design move came straight out of the reframe: take a pile of content and turn it into a journey. Stages you move through, progress you can see.

The insight is simple. When someone can see where they are and what is left, a mountain of training becomes a path they can walk. That progress-first model became the spine of the entire product.

Desktop concept of the progress-first journey, showing the stages a learner moves through with the active stage highlighted.

It also had to meet clinicians where they actually are. Desktop at the workstation, tablet on the floor, phone in a pocket. This was not a nice-to-have; learning happens in the flow of work, on whatever screen is in hand. We designed for every viewport, and testing was clear that the phone mattered more than the tablet, so that is the reality we optimized for.

Tablet concept showing a single stage of the journey in detail, one of the viewports the product was designed for.

4. The Learner Side: Consumer-Grade Craft

This is the learner side. Everything here is a consumer-grade experience built inside an enterprise product. It is the craft-and-empathy half, designed for the thirty seconds a clinician has between patients.

It started on paper. Journey ideas, a stage summary, a completion screen. I show the sketch because this is where the structure got decided: the journey, the stages inside it, the sense of arriving somewhere at the end. The spine of the whole experience is here in pen, before a single pixel.

Early paper sketch working out the journey structure: the stages, the activities inside them, and a sense of arriving at the end.

And here is what it became.The Cerner Learning platform shown on a laptop and phone side by side on a desk, the learner experience in its real context.

“Welcome back, Dr. Nelson.” One glance tells you three things: where you are, what is next, how much is left. That is the reframe made real. We took the invisible question, how much of this do I still have to do, and put it on the surface. For someone squeezing this in between patients, that clarity is the entire point.

Learner dashboard greeting Dr. Nelson, showing the current stage, what comes next, and how much of the journey remains.

Inside a journey, this is a single stage: what you will accomplish, the activities, your progress right there. The activities are role-based simulations. Medication reconciliation. Physician handoff. Rounding. Discharge. Each takes a few minutes. Not a course you sit through, a workflow you practice, in the time you actually have.

Stage overview listing the role-based simulation activities in the stage, each with its own progress.

And this is where the learning stops being passive. You log in as the clinician, Dr. Wanda Nelson in this case, pull up the schedule, endorse results, do the real tasks. It is a rehearsal in a safe copy of the actual system. Not a video about the workflow. The workflow itself. That is the difference between knowing something and being ready for it.

A role-based simulation in progress, rehearsing a real clinical workflow inside a safe copy of the live system.

And here is where it all comes to rest: the phone. Same journey, same stages, same progress, now in a pocket, on the floor, between patients. Some activities send you back to a desktop, and the interface is honest about that on screen. But the day-to-day, the checking in and the tracking, lives here. This is the reframe finished. Learning that fits the thirty seconds a clinician actually has.

The same stage on a phone, the Stage 3 overview and its activities, including the note to return to a desktop to complete the simulation.

5. The Admin Side: Systems Thinking

That was the consumer side. This is the enterprise side, and it is the hinge of the whole product. If the learner side is craft and empathy, this side is systems thinking. It is the half that made the product scale.

Every journey a learner walks, someone has to build. A single hospital runs dozens of them at once, one per role, cloned from master templates and turned on or off as rollouts change. So the first job here was to make building a journey feel manageable.

Like the learner side, it started on paper. A journey has a name, stages, and activities inside each stage: a video, a simulation, a job aid, a survey. The builder is the mirror image of the journey a learner walks. The learner experiences stages moving forward; the admin assembles those same stages in reverse. One structure, two audiences, two very different jobs.

Paper sketch of the journey builder: naming a journey and laying out its stages and the activities inside each one.

6. The Hardest Problem: Versioning

The hardest problem in the system was not building a journey. It was changing one that is already live.

Real people are partway through it. Some finished stage two. Some are mid-way through stage three. You cannot overwrite the thing underneath them. This whiteboard is where I worked it out: every path, push the change or hold it, existing users versus new ones, open a stage now or schedule it for later.

Whiteboard working out the versioning logic: every path for changing a live journey without disrupting the learners inside it.

The question was never how to save an edit. It was how to change a live journey without breaking the people inside it.

Here is the resolution. The real case is not a typo fix; it is adding a whole new stage, Enhance Learning, to a journey already in production. So the first step is scheduling: when does the new stage open, and for which group. Nothing goes live the instant you save.

Admin scheduling when a newly added stage opens and for which group, so nothing goes live the moment it is saved.

Then the heart of it. Before anything ships, the system runs the impact analysis for you. It tells you exactly which groups this will affect, and which it will not. And then it stops. It holds for a person to confirm. Nothing touches a live journey until a human says proceed. In a system real clinicians depend on, that pause is not friction. It is the safeguard.

Confirmation step showing the system's impact analysis of which groups a change will affect, holding for a person to approve before anything ships.

And then it lands. The new version pushes out, the journey updates, and it is back in the library. A stage added to a live product. Hundreds of learners, none of them disrupted. That is the systems half doing its job quietly.

The journey library confirming the Hospitalist Journey was updated after the new version was pushed live.

7. Users, Groups, and What Testing Changed

Journeys get built. Then someone has to decide who takes them.

Before a hospital can assign anything, it has to get its people into the system: hundreds of clinicians, sometimes thousands. So this begins with a bulk import. Nobody hand-enters a hospital.

Bulk import bringing a hospital's clinicians into the system, with import progress shown.

Then journeys and people get connected through groups. My original design for creating a group was one long screen: name it, add members, assign journeys, all at once. It made sense on paper. Then we tested it, and testing told me I was wrong. One screen doing four jobs overwhelmed people.

So I broke it into a wizard. Three clear steps. Group details, then members, then journeys.

Step one of the create-group wizard, entering the group's details.

That is the honest version of this story. The structure did not come from my first instinct. It came from watching people struggle and changing it. This is what usability testing is actually for: not validating what you built, but finding where it breaks. Accessibility was treated the same way, as part of the definition of done rather than a pass at the end.

Step two of the create-group wizard, pulling members from the directory into the group.

The third step is the payoff of the whole admin side. You assign a journey to the group, then set when each stage opens. Stage one in January, stage two in February, paced across the rollout. This is how a hospital controls its go-live: not everyone learning everything at once, but the right stage, to the right group, at the right time.

Step three of the create-group wizard, assigning a journey and setting when each stage opens across the rollout.

8. Readiness, Not Completion: Reporting

The last question on the admin side is the one that matters most. We built it, assigned it, scheduled it. Is it working.

Reporting started as a sketch: completion by stage, survey results, the top groups. But the question behind it was never “did they click through.” It was “are they ready.”

Paper sketch of the reporting view: completion by stage, survey results, and the groups furthest along.

Here is that sketch, built. One note on the numbers first: this dashboard shows sample data. It reports five hundred learners inside a single client system. Around five hundred client health systems run the platform in production, which is the same figure at a completely different scale, and I want to be precise about which is which.

The real design decision is the framing. The dashboard does not lead with how many videos were watched. It leads with commitment, confidence, and readiness. Because completion is not the goal. A clinician being ready for go-live is.

Reporting dashboard leading with commitment, confidence, and readiness rather than completion counts. Sample data.

And you can go deeper: stage by stage, group by group, who is ready and who is behind. This is where an admin acts. A group lagging at stage three is a group that needs attention before go-live. The report does not just show progress. It tells you where to intervene.

Drill-down report showing readiness stage by stage and group by group, so an admin can see where to intervene.

9. Scale and Durability

So did it work.

The same journey runs across every device, the vision whole. Around five hundred client health systems are live on the platform, and not only in the United States: Canada, the UK, Australia, Singapore, and more. Among the clients, the U.S. Department of Veterans Affairs and the Department of Defense, for years. Clients roll off as they finish their EHR adoption, which is the product doing its job and letting go. The reach was real, and it was global.

Inside the company, the learning framework was featured at the Cerner Health Conference in 2019, a Day 2 keynote. Not a one-off, but a model other teams were pointed to.

The learning framework featured on stage at the Cerner Health Conference 2019, Day 2 keynote.

Here is the part I keep coming back to. Nine years after the first sketch, the platform is still in production, now under Oracle Health. The logo changed; the experience did not. No UX redesign, in all that time.

The platform today under Oracle Health branding, still in production years after the first sketch.

The product owner, Mike Michalski, put it better than I could: “The fact that Learning Journey is still going strong after all these years, without a dedicated UX associate, is a testament to the foundation Lai laid out for us.”

That is what I care about most. Not what launches. What is still standing years after you have moved on.