Larkstone Workplace Harassment eLearning

Solution

I redesigned the course as one continuous, problem-centered story, followed by a transfer assessment. Knowledge is delivered only at the moment a decision needs it.

A Story-Based Approach

The learner works on a six-week project to clear Larkstone’s returns backlog, alongside a recurring cast of coworkers. Each scene is a moment in that project, and every protected characteristic is the focus of at least one full scene. One coworker’s arc (sidelined after announcing her pregnancy, reporting it, then facing retaliation) carries the Report and Don’t Retaliate sections. Tyler, a likable coworker who thinks his jokes are harmless, is the recurring example of what not to do, but is not painted as a villain.

At each decision point, learners see a verdict first (“Good choice” or “Not the best choice”), then the consequence of their choice, then feedback tied to EEOC guidance or Larkstone policy. The final assessment uses five new scenarios with new characters, so learners have to transfer the skill rather than remember the story.

Designing for Self-Reflection, Not Defensiveness

A course that simply says harassment is wrong rarely changes anyone’s behavior. Most people don’t see themselves as someone who harasses others, so a lecture is easy to tune out. Instead, I focused on how often harassment is something people witness without recognizing it, or even do without realizing it.

The course opens by inviting learners to privately reflect on a time a comment landed badly at work, whether it involved them or not. Early scenarios ask learners to evaluate situations happening to coworkers, which builds recognition without putting anyone on the defensive. Later, the learner becomes the person whose comment made a coworker uncomfortable, and has to decide what to do next.

This progression lets learners start from a place of safety rather than guardedness, and then turn the same critical eye on their own behavior.

Key Components

Evaluation Plan

Because Larkstone is a concept project, this plan shows how the course would be evaluated in a live deployment. It covers all four Kirkpatrick levels, and completion requires passing a performance-based assessment rather than a recall quiz.

Levels 3 and 4 rely on self-report and HR case data, so changes can’t be credited to the course alone. A change in the number of reports shouldn’t be read as success or failure on its own. It should be read alongside timing and channel data.

My Process

Larkstone was my first time building a complete eLearning experience by “vibe coding” with Claude Code. I used AI as a collaborator at every stage, but the design decisions, quality checks, and accessibility testing were mine. Here’s how it came together and what I’d do differently next time.

Analysis & Goals

I started by drafting an analysis and goals from the challenge description. I chose to focus on employee behavior rather than managers’ legal duties. Managers would need their own training, and the biggest difference comes from everyone in the workplace being more aware and knowing what to do.

Action Map & Design Document

From the goals, I built an action map and used Claude to help refine ideas against those goals. I then turned the action map into a full design document and had Claude check its alignment with Gagné’s Nine Events of Instruction and Merrill’s Principles of Instruction, two frameworks that were helping to guide my decisions.

Storyboard & Scenarios

Once the storyboard felt solid, Claude helped draft the scenes that became the course’s scenarios. This stage needed the most human oversight. When we changed something, Claude was unpredictable about changing similar items elsewhere, so I had to track every suggested change closely and make Claude confirm any changes with me before executing. I also caught many things only a person would notice: situations that didn’t fit this training, wording that was awkward or unclear, or situations that may even have been too triggering or offensive for an employee training.

Scenes

To keep documents manageable, the specific scenes were scripted out on a separate document. I prompted general scenarios to Claude along with providing my other documents, and Claude created the scenes. I used a combination of prompting changes and directly editing the output to reach the final version before moving on to next steps.

Assessment Design

Next, I developed the five assessment scenarios, using new characters so learners would have to transfer what they learned rather than recall the story. I wanted the learner to have two chances with each topic covered. For each question, if the learner missed the first attempt, they could try again with a new scenario covering the same topic. It took some prompting back and forth with Claude to decide how to structure this and word all of the instructions to make it clear to the learner, and make sure each page has a distinct title for accessibility purposes.

Throughout the course, the scenario questions are never locked. Learned can select any answer to read the consequence and feedback. The priority is in practicing the behaviors, so learners can select a correct answer to see how the feedback is different after choosing an incorrect answer. The final 5 questions, however, do lock in and are used to determine if the learner receives their certificate to turn in to HR, or a document detailing what they need to review to use in their follow-up with HR.

Prototyping & Developing

To keep the build true to my design, I worked with Claude to write a Build Guide: a single source of truth for Claude Code covering the design, accessibility requirements, and consistency rules. The Build Guide was formatted entirely by Claude, based on my requirements for the project, and the guide was edited as needed throughout the design process before moving on to development.

Before building, I used Claude to create visual prototypes, one section type at a time rather than every screen, so changes could carry forward. Seeing the design visually surfaced issues I hadn’t noticed on paper. It especially pinpointed some accessibility bottlenecks I hadn’t identified from my Storyboard and Claude’s Build Guide. This helped me experiement with different options before moving into Code.

In Claude Code, I built in small portions, answering its questions as we went. I tested every new output for accessibility with VoiceOver, keyboard-only navigation, and ANDI (Accessible Name & Description Inspector), changing screen sizes and zoom, and prompted fixes before moving on. When a section was complete, I retested the whole section before starting the next. There were plenty of fixes, but they were quick to make.

Visual Assets

I used ChatGPT to create the course’s two images and the Larkstone logo. I included the design document, the two scene descriptions, and branding colors in the prompt, and was satisfied with the output. The logo took a bit more back and forth to get just right. I chose colors based on the initial course presented for reworking, adding a darker teal to promote accessible contrast and choosing the coral to complement them. Claude chose some additional colors for the character avatars to fit into the theme.

Claude Code created each of the smaller banner illustrations to set each scene. These didn’t require any iteration and used details from the scene, without adding in people. I was pleased with how quickly it created these and follow the prompt closely.

What I learned

I honestly wish I’d moved into Claude Code sooner. I spent more time, and more usage, perfecting visual prototypes than it took to build the actual course. Claude Code makes changes so quickly that it’s often faster to adjust the real thing than to keep refining a mockup. Next time, I’ll prototype just enough to settle the look and feel, then start building.

The Build Guide kept the course consistent, but keeping the guide itself under control was its own challenge. As I prompted individual changes, Claude struggled to tell the difference between a one-time change on a single screen and a rule that belonged in the guide. Before long, it had added so many “truths” that some contradicted each other. I had to reel it back and reprompt until we found the right balance: the guide held only the design decisions, accessibility requirements, and consistency rules that applied across the whole course, and one-off fixes stayed one-off. Once it was trimmed, every new session started from the same foundation instead of drifting from the design. Next time, I’ll set clear rules up front for what belongs in the guide, instead of chasing the pendulum back and forth until it settles.

AI sped some things up and slowed others down. Now that I have experience vibe coding with Claude, I know how to structure my workflow and promtps to avoid some of the slow downs. When I prompted a fix to one scene, Claude sometimes changed other scenes it judged to be similar, or quietly updated the design document, without saying so. Unlike making my own edits, or even receiving a SME’s edits, which are visible and limited to what they review, these ripple changes were easy to miss. I had to check every output closely to keep the course aligned with my design. Catching those moments, and testing every piece with VoiceOver, a keyboard, and ANDI, is where my judgment made the difference.