Learning experience design

Writing outcomes, not to-do lists.

A scenario-based Storyline module that helps product managers write outcomes they can measure.

Try the Storyline sample
My role
Instructional designer
Audience
Outbound product managers at an enterprise tech company
Tools
Storyline 360 · Miro · Mural · Figma · Adobe Leonardo · Concepts · Illustrator · Claude
Scope
Portfolio project based on a real team's problem

Determining Outcomes at Verrant

Learners join this team for a product launch.

Dana leads the team and coaches the learner. Rahul and Aisha are the teammates whose drafts learners review, and Noah runs the launch dashboard.

meet the team →

  • Dana

  • Rahul

  • Noah

  • Aisha

Summary

The product managers had never been taught to write an outcome.

The outbound product managers on this team plan product launches on a shared Monday.com board. The board asks for outcomes, which leaders use to judge whether a launch is on track.

Outcomes on the board often described deliverables, such as “publish the deck,” where the board needed results, such as “sellers can tell the story.” A deliverable can be finished on schedule while the launch still misses its goal, so the board could show a healthy launch that wasn't one.

Today the program manager and the team lead write every outcome. The goal is for product managers to write their own, and none of them had been taught how. I designed a scenario-based module to teach that one skill.

01 / The solution

The card sort in the Storyline sample: six statements waiting to be dragged into Outcomes and Deliverables columns, with Rahul's instruction above them. Opens the sample in a new tab.

Try the Storyline sample.

I designed a 21-slide scenario-based module in Storyline 360. Learners join a team call, review two teammates' draft outcomes, and write one of their own. This working sample includes the team call and the card sort, where learners sort six statements into outcomes and deliverables.

Open the Storyline sample

The sample opens in a new tab.

02 / Analysis

The needs analysis told me what to teach.

I interviewed the team's program manager and ran a root-cause session with him in Mural. We found six barriers to the board's adoption. Writing outcomes was the one training could fix. The others needed fixes that training alone couldn't provide, such as clear ownership, board permissions, and leadership changes. I recommended those separately and kept them out of the module.

Fishbone diagram from the root-cause session, with sticky notes grouped under leadership, processes, motivation, tool, culture, and knowledge, all pointing to the question of why inbound product managers don't update key deliverables in the Monday board
This is the fishbone diagram from the root-cause session I facilitated. It answers the question I started with, which was about the inbound product managers. The follow-up conversations are what moved my focus to the outbound team.Read the needs analysis (opens in a new tab)

The turning point

Follow-up conversations changed both the audience and the skill.

My first version of the analysis treated the trainable gap as tool knowledge. Follow-up conversations showed two things I had missed. The outbound product managers are the people who own the board, and their gap is writing outcomes. I revised my own analysis to fit the evidence and narrowed the module to that skill.

03 / Design

Learners practice the judgment before they write.

Learners play themselves, as an outbound product manager preparing for a launch. The story opens on a team call where the dashboard says everything is on track while client renewals are slipping. Dana, the team lead, then asks the learner to help review two teammates' drafts.

Rahul voices a belief I heard from the subject matter expert, which is that narrative work can't be measured. I disagreed and chose win/loss reasons as the measure. In the module, Rahul raises the objection and Dana answers it.

I wrote a design document before I built anything. It sets the business goal, the terminal and enabling objectives, the audience, the plan for the module and its two job aids, and how I would evaluate it.

Ask me for the design document

  1. Recognize

    Sort outcomes from deliverables.

  2. Diagnose

    Find what's missing in a weak outcome.

  3. Revise

    Improve a teammate's draft.

  4. Create

    Write an outcome, then complete a scored check.

The rubric

The team had no shared standard for a good outcome, so I wrote one.

The rubric checks five things. The first three keep the board tidy, and the last two decide quality. An outcome has to describe impact, and it has to name a measure. Every activity in the module practices one of those two criteria.

Preview of the one-page job aid, Write outcomes that show impact: three questions to ask before submitting, and a table that turns a deliverable into a measurable outcome for each pillar

The job aid

I turned the rubric's two quality checks into a one-page job aid.

Product managers check their outcome against three questions before they send it for review. Then they can compare it with a model outcome for their pillar.

Open the job aid (PDF)
Action map linking the business goal to on-the-job behaviors, practice activities, job aids, and process fixes
I used action mapping to tie every activity in the module to something product managers do on the job. Anything that didn't lead to writing outcomes went into a job aid or a recommendation.

04 / Development

I'm building the module in Storyline 360.

Before I built any slides, I made a visual system for the module: a color palette checked against WCAG 2.1 AA in Adobe Leonardo, and a type scale based on how text actually renders in Storyline. The published sample has the team call and the card sort, and I'm building the remaining slides now.

My Miro flowchart of the module, with each step labeled by one of Gagné's nine events, from gaining attention through assessing performance and enhancing transfer

I planned the build with an outline and a storyboard.

I checked an early AI-drafted outline with the subject matter expert and reviewed it against Gagné's nine events and Mayer's principles. Then I rebuilt the flow myself in Miro.

My version opens with the hook, asks learners to recall what an outcome is, puts diagnosing before fixing, allows two retries, and ends with a scored check.

From that outline I built a 21-slide storyboard in Google Sheets, with the narration, on-screen text, and build notes for every slide. Claude drafted parts of it, and I set the rules for narration and made the design calls that connect the slides.

  • The card sort after a wrong attempt: Dana's feedback and a Try Again button sit in the left column, beside the learner's sorted cards

    I moved the feedback beside the learner's work.

    The first feedback design was an overlay that covered the learner's answers. I noticed the left column empties once the cards are sorted, so I moved Dana's feedback there. Learners can read her coaching while they look at their own choices.

  • The team call in the module: Noah, Dana, Aisha, and Rahul on a video call, with Dana speaking and her line in the caption bar

    I designed the team call, and AI wrote the JavaScript.

    I wanted the call to behave like a real video meeting, with captions that arrive after each speaker's face changes. AI wrote the JavaScript behind the captions and motion. I tested each version myself, and my keyboard test found a focus problem that the automated tests had missed.

How I worked with AI

I led the design and used AI to speed up production.

I wrote the needs analysis, built the action map, and wrote the rubric myself, with Claude as an editor I went back and forth with. Claude also wrote first drafts of the storyboard and build specs for me to revise, and it helped with the JavaScript and prototypes for the Storyline build. Here are two examples of how that worked.

  • I replaced a measure the team doesn't track.

    Claude suggested a measure for seller readiness. I checked whether the team tracks it, and they don't. I used an industry practice instead, which is pitch certification against a scorecard. A model outcome is useless if its measure doesn't exist.

  • I tested a build spec against the tool.

    Claude's build spec relied on variable font weights. I inspected the build, found that Storyline doesn't render them, and switched to static font files. The spec sounded right, but it didn't match the tool.

The characters

I drew the cast myself, starting with Dana.

I ruled out fully AI-generated characters and compared licensed sets before deciding to draw. I worked in Concepts and finished the expressions in Illustrator, and I used AI for production tasks like placement and recoloring.

Dana went from pencil to vector by hand.

I sketched her on paper, redrew her in Concepts, and finished her expressions in Illustrator. Her flat fills and soft shading became the rules for the rest of the cast.

My pencil sketch of Dana, with curly hair and a collared shirt
My pencil sketch
My first flat-color vector drawing of Dana
My first vector
The final illustration of Dana
The final Dana

Drawing them made sense for a four-character portfolio piece, and illustration is something I love doing on the side. On a larger project, I'd bring in a licensed set or an illustrator.

05 / Next steps

Here is how I would launch it and measure it.

Implementation

I'd finish the build and pilot it with a small group.

I've finished the job aid for writing outcomes. Next I'll finish the remaining slides and a second job aid for board statuses. Storyline's drag-and-drop isn't fully keyboard accessible, so I'll add a keyboard-accessible version of the card sort before launch. Then I'd pilot the module with a few product managers and revise it based on what I see.

Evaluation

I set a goal the team could check.

The team didn't track outcome quality, so I set a goal: by the end of Q4, 80% of the 20 most recent PM-written outcomes describe impact and name how success will be measured. There is no baseline yet, and I chose not to invent one. The first step would be scoring recent outcomes against my rubric.

I planned evaluation at Kirkpatrick Levels 1 through 4, from a short learner survey and a scored final check to tracking rubric scores on real outcomes. My analysis rests on one stakeholder, so I would also interview more product managers and leaders and review the board's update history.

Project context: This is a portfolio project based on a real workplace situation. I changed the company and character names. My findings come from one stakeholder, across an interview and follow-up conversations. The module hasn't been delivered to the team, and I don't claim any business impact.