19 KiB
Action Mapping
A visual approach to designing training and experiences that focuses on what people DO, not what they KNOW
Originated by: Cathy Moore
Source: Action Mapping website and workshops (2008+)
Applied in WDS: Scenario design, interaction design, UX specifications
What It Is
Action Mapping is a visual design process that helps create effective training and user experiences by focusing on observable actions rather than information delivery.
The Core Structure:
1. Business Goal (What measurable outcome do we want?)
↓
2. Actions (What must people DO to achieve it?)
↓
3. Practice (How can they practice those actions?)
↓
4. Information (What minimum info do they need?) - ONLY IF NECESSARY
Revolutionary Insight: People don't need more information. They need to practice better actions. Information should support action, not replace it.
Why It Matters
The Problem Without Action Mapping
Traditional approach to design and training:
- Dumps information on people
- Assumes knowledge = ability
- "Here's everything you might need to know"
- No practice, just reading/watching
- Boring, ineffective, forgettable
- People leave informed but unable
Example Bad Training: "Here are 47 slides about our CRM system. Now go use it!"
The Solution With Action Mapping
Action-focused approach:
- Identifies what people must DO
- Provides realistic practice
- Information only when needed
- Engaging, effective, memorable
- People leave capable and confident
Example Good Training: "Here's a real customer scenario. Show me how you'd handle it. [Practice] Need help? Here's the relevant info. [Just-in-time] Try again."
The Core Insight: Behavior change, not information transfer, achieves business goals.
How It's Valuable in Strategic Design
1. Scenario Design
Instead of "What should users know about this feature?", ask: "What should users be able to DO?"
Traditional Feature Design:
New Feature: Advanced Reporting
Content Needed:
- What reports are
- Types of reports available
- How reporting engine works
- Report customization options
Action Mapping Approach:
Business Goal: Managers make data-driven decisions daily
Actions Needed:
- Generate weekly team report (Tuesday mornings)
- Spot performance outliers in <30 seconds
- Share insights with team
Practice Scenarios:
- "It's Tuesday. Get your team report."
- "Sales dropped last week. Find out why."
- "Show Sarah this insight."
Info: Only what's needed to complete these actions
Result: Users learn by DOING, not reading documentation.
2. Onboarding Flows
Traditional onboarding = product tour (information dump)
Action Mapping onboarding = guided practice
Instead of: "Here's where tasks live. Here's how to create them. Here's how to assign them..."
Do: "Let's create your first task. [Do it] Great! Now assign it to yourself. [Do it] Perfect! You've got the basics."
3. Help Documentation
Traditional docs = reference manual
Action Mapping docs = action-oriented guides
Instead of: "Reporting Module: The reporting module allows users to generate various types of reports..."
Do: "Generate Your Weekly Report: 1. Click Reports, 2. Select 'Team Performance', 3. Choose date range, 4. Click Generate"
4. Error Messages and Empty States
Traditional = explain what went wrong
Action Mapping = guide toward successful action
Instead of: "Error: No data available for selected parameters"
Do: "Let's find your data: Try expanding your date range or selecting a different filter"
5. Component Design
Traditional = show all options
Action Mapping = guide user toward most common successful actions
Example: File Upload
- Most common action: Drag and drop
- Make that HUGE and obvious
- Other options smaller (browse, paste URL)
- Result: Users DO the happy path naturally
Attribution and History
Cathy Moore - The Creator
Cathy Moore is an instructional designer who developed Action Mapping in response to ineffective traditional training approaches. She noticed that most training focused on delivering information rather than changing behavior.
Her background in journalism and instructional design led her to ask: "What do people need to DO differently?" rather than "What do they need to know?"
Development and Influence
Timeline:
- Late 2000s: Developed Action Mapping methodology
- 2008+: Shared freely on blog.cathy-moore.com
- 2010s: Became widely adopted in e-learning community
- Now: Influences UX design, product onboarding, and user experience beyond training
Impact:
- Shifted e-learning from "page-turners" to interactive scenarios
- Influenced UX onboarding design
- Changed how designers think about user education
- Emphasis on practice over information now standard in good UX
Philosophy
Moore's core belief: "People come to work to do a job, not to learn."
Therefore:
- Focus on job performance, not knowledge transfer
- Provide practice, not presentations
- Give information only when needed (just-in-time)
- Measure behavior change, not quiz scores
Source Materials
Website and Blog
- Original source for Action Mapping
- Free detailed explanations
- Case studies and examples
- Downloads and templates
- "The best training blog you're not reading"
🔗 Action Mapping: The Infographic
- Visual guide to the process
- Free to download and share
Books and Resources
📚 Map It: The Hands-On Guide to Strategic Training Design
By Cathy Moore (2017)
- Comprehensive guide to Action Mapping
- Step-by-step worksheets
- Real project examples
- Available on Amazon
Workshops and Courses
🎓 Action Mapping Workshops
- Cathy Moore offers periodic workshops
- Check blog.cathy-moore.com for schedule
🎓 Online Training on Action Mapping
- Various platforms offer courses teaching the methodology
- Search for "Action Mapping course" on LinkedIn Learning, Udemy
Articles
🔗 "Action Mapping: A Visual Approach to Training Design"
- Core article explaining the methodology
- Available on Cathy Moore's blog
🔗 "Saving the World from Boring Training"
- Philosophy and approach
- Blog.Cathy-Moore.com
Whiteport Methods That Harness This Model
Phase 4: UX Design Guide
Scenario design uses Action Mapping principles:
Instead of "What does user need to know about this page?"
Ask:
- What is the user trying to DO here?
- What actions lead to success?
- How can we guide those actions?
- What info supports (not replaces) action?
Result: Scenarios focused on user actions, not information architecture.
Page Specifications
Component specs describe actions, not features:
Traditional Spec:
Component: Dashboard Widget
Features: Data display, filters, export button
Action Mapping Spec:
User Action: Check team performance at glance
Success: Spot issues in <10 seconds
Design: Key metrics prominent, issues red, drill-down on click
Info: Only when drilling down, not upfront
Interaction Design
Flows prioritize action paths:
Traditional Flow:
1. Welcome screen (info)
2. Feature tour (info)
3. Tutorial (info)
4. Dashboard (finally do something!)
Action Mapping Flow:
1. "Let's create your first project" (action)
2. [User does it] (practice)
3. "Great! Now add a task" (next action)
4. [User does it] (more practice)
5. "You're ready! Here's your dashboard" (info only if needed)
Imaginary Examples
Example 1: Project Management Tool Onboarding
Traditional Information-Focused:
Screen 1: "Welcome to TaskMaster!"
Screen 2: "Here's your dashboard. This is where you'll see all your projects."
Screen 3: "Click here to create projects. Projects contain tasks."
Screen 4: "Tasks can be assigned to team members and have due dates."
Screen 5: "You can view tasks in list or board view."
Screen 6: "Reports help you track progress."
Screen 7: "Now try it yourself!"
Action Mapping Approach:
Screen 1: "Let's create your first project"
User: [Types project name, clicks create] ✅
Screen 2: "Every project needs tasks. Add one:"
User: [Types task, clicks add] ✅
Screen 3: "Who's doing this? Assign it:"
User: [Selects person] ✅
Screen 4: "You're all set! Here's your project."
[Show completed project with task assigned]
Tip available: "Want to add more? Click + to add tasks anytime."
Result: User has created project, added task, assigned it within 60 seconds. They KNOW how because they DID it.
Example 2: Design System Documentation
Traditional (Information Dump):
# Button Component
The button component is used for user actions. It has several variants:
## Variants
- Primary: Main call-to-action
- Secondary: Secondary actions
- Tertiary: Low-priority actions
- Danger: Destructive actions
## Properties
- size: 'sm' | 'md' | 'lg'
- variant: 'primary' | 'secondary' | 'tertiary' | 'danger'
- disabled: boolean
- onClick: function
## Examples
[Code examples]
## Usage Guidelines
[More information]
Action Mapping Approach:
# Button Component
## What Are You Trying to Do?
→ Create a main call-to-action
Use: <Button variant="primary">
Example: "Sign Up", "Save", "Continue"
→ Add a secondary action
Use: <Button variant="secondary">
Example: "Cancel", "Back", "Learn More"
→ Warn about destructive action
Use: <Button variant="danger">
Example: "Delete", "Remove", "Clear All"
## Quick Copy-Paste
[Most common code snippets ready to use]
→ Need all the details? [Expand full documentation]
Result: Designer finds what they need to DO, gets it done. Deep reference available but not required reading.
Example 3: Feature Announcement
Traditional (Broadcast Information):
Subject: "Introducing Advanced Reporting!"
We're excited to announce Advanced Reporting is now available!
What's new:
- Custom report builder
- 15 new visualization types
- Scheduled report delivery
- Export to multiple formats
Advanced Reporting allows you to create sophisticated reports...
[Several more paragraphs explaining features]
Check it out in the Reports menu!
Action Mapping Approach:
Subject: "Generate Your Custom Report in 60 Seconds"
Hi [Name],
Want to see which features drove growth last month?
→ Click here to try the new report builder [Button]
You'll create a custom report in 3 steps:
1. Pick your data (sales, signups, usage)
2. Choose visualization (we'll suggest best one)
3. Save or schedule it
[Video: 45-second demo of doing exactly this]
Questions? Reply to this email.
Result: User clicks, DOES the thing, experiences value. Learns through action.
Real Applications
WDS Scenario Specifications
WDS scenario specs focus on actions:
See: WDS Presentation Scenarios
Each scenario specifies:
- User Goal: What user is trying to achieve (action-oriented)
- Success Criteria: Observable action completed
- Key Interactions: What user DOES at each step
- Supporting Information: Only what's needed for action
Not:
- Everything user might want to know
- All possible features explained
- Comprehensive tutorial
Philosophy: Users learn by doing, not reading. Guide action.
The Four-Step Action Mapping Process
Step 1: Define Business Goal (10 minutes)
Not a learning objective! What business outcome do we want?
Good Goals:
- "Reduce support tickets by 30%"
- "Increase feature adoption from 20% to 50%"
- "Managers make weekly data-driven decisions"
Bad Goals:
- "Users understand how reporting works"
- "Increase knowledge of features"
- "Complete training module"
Why: You want behavior change, not information transfer.
Step 2: Identify Necessary Actions (20-30 minutes)
What must people DO (not know) to achieve that goal?
For "Reduce support tickets by 30%":
Actions users must take:
- Solve common problems themselves (not contact support)
- Find answers in help docs quickly
- Use self-service troubleshooting tools
Key Question: "If I could watch people working, what would I see them DOING that shows we're succeeding?"
Avoid:
- "Understand how system works" (not observable)
- "Know where help docs are" (not an action)
- "Be familiar with features" (vague)
Want:
- "Search help docs and find answer in <2 minutes"
- "Reset own password without help"
- "Check system status before contacting support"
Step 3: Design Practice Activities (30-45 minutes)
How can people practice those actions?
For each action, create realistic scenarios:
Action: "Search help docs and find answer"
Practice:
Scenario: Your report isn't generating. The screen just says "Processing..."
What do you do? [Simulation where user can try actions]
- Search help docs? ✅ Shows article on report timeouts
- Contact support? ❌ "Could you solve this yourself first?"
- Wait longer? ❌ "It's been 10 minutes..."
[User finds answer, applies solution, report generates]
"Perfect! You saved 2 hours waiting for support."
Characteristics of good practice:
- Realistic context (not abstract)
- Consequences of choices (not just "right/wrong")
- Challenge appropriate to learner
- Feedback that guides, not lectures
Step 4: Identify Minimum Information (15-20 minutes)
What information do people need to complete the actions?
Critical Question: "Can they DO the action without this information?"
If YES → Don't include it
If NO → Include it just-in-time
Example:
Action: Generate weekly team report
Info they DON'T need upfront:
- Complete feature list of reporting module
- History of how reporting was built
- All possible customization options
- Technical architecture of reports
Info they DO need:
- Where to click to start ("Reports menu")
- Which report template to use ("Team Performance")
- How to set date range (quick inline guide)
Provide info:
- Right when they need it (not before)
- In context of action (not separate tutorial)
- As briefly as possible (then let them do it)
Action Mapping vs. Information Dumping
| Information Dumping | Action Mapping |
|---|---|
| "Here's everything about this feature" | "Here's how to accomplish your goal" |
| Starts with information | Starts with business goal |
| Explains how system works | Guides what user does |
| "Know this, then apply it" | "Do this, learn along the way" |
| Passive reading/watching | Active practice |
| Tests knowledge | Observes behavior |
| "Did they remember?" | "Can they do it?" |
| Front-loaded learning curve | Progressive disclosure |
| Boring | Engaging |
Common Questions
Q: What if people need conceptual understanding before acting?
A: Provide JUST enough concept to enable action, not comprehensive explanation. Example:
Don't: "Branches in Git are pointers to commits in the commit graph. When you create a branch..." Do: "Think of branches like parallel workspaces. Let's create one: [command]. Try it."
Concept → minimal. Action → immediate.
Q: What about reference documentation?
A: It still exists! Action Mapping is for learning and onboarding. Reference docs are for looking up details later. Users should be able to DO the common actions without reading reference docs.
Q: Isn't this just good UX design?
A: Increasingly, yes! Action Mapping originated in training but its principles apply broadly:
- Onboarding
- Feature adoption
- Help systems
- Product design
- Any context where you want behavior change
Q: What if the business goal isn't about behavior?
A: Usually is, indirectly. "Increase awareness" isn't measurable behavior. But "Attend webinar" or "Sign up for newsletter" are. Find the observable action.
Q: How much practice is enough?
A: Enough that person can perform action independently with confidence. Usually:
- Simple action: 1-2 practice scenarios
- Complex action: 3-5 scenarios with increasing difficulty
- Critical action: Practice until automatic
Using Action Mapping in Your Process
For Onboarding Design
- Define success: What does activated user DO?
- List actions: What specific actions show activation?
- Design practice: Guide user through those exact actions with real data
- Minimize info: Remove any explanation not essential to action
Test: Can user complete key action within first session?
For Feature Adoption
- Goal: X% of users use feature monthly
- Actions: What must they DO to use it successfully?
- Entry point: Where do they encounter opportunity to practice?
- Guide action: Show, don't tell
Test: Do users try feature after seeing it?
For Documentation
- Identify common tasks: What are people trying to DO?
- Action-oriented structure: Organize by task, not feature
- Minimal explanation: Just enough to complete task
- Quick examples: Copy-paste ready
Test: Can users complete task from docs without asking for help?
For Error Handling
- User goal: What were they trying to DO?
- What went wrong: Why can't they do it?
- Corrective action: What specific action fixes it?
- Guide repair: Show path forward
Test: Can users recover without frustration?
Action Mapping Template
## Business Goal
[What measurable outcome?]
## Actions Needed
[What must people DO to achieve goal?]
- Action 1: [Observable behavior]
- Action 2: [Observable behavior]
- Action 3: [Observable behavior]
## Practice Scenarios
[How will people practice each action?]
Action 1: [Observable behavior]
- Scenario: [Realistic context]
- User does: [Actual action]
- Feedback: [Result/guidance]
## Minimum Information
[Only what's needed to complete actions]
- Info bit 1: [Just-in-time, just-enough]
- Info bit 2: [Provided in context]
## Success Metric
[How do we measure behavior change?]
Next Steps
- Read: Cathy Moore's blog (blog.cathy-moore.com) - start with Action Mapping intro
- Try: Take one feature/onboarding flow and redesign using Action Mapping
- Test: Does new version enable action faster than old info-dump version?
- Apply: Use action-focus in next scenario specification
Related Resources:
- Phase 4: UX Design Guide - Scenario design using action focus
- Trigger Mapping Guide - Connect actions to driving forces
- Blog.Cathy-Moore.com - Original source and examples
Action Mapping - People don't need to know, they need to DO.