# Experience Maps, Mental Models & Ecosystem Models

This reference covers three diagram types that go beyond a single product's customer journey: experience maps, mental model diagrams, and ecosystem models.

---

## Experience Maps

### What They Are

An experience map visualizes a broad human activity or behavior — not tied to a specific product or service. It tells the story of how people accomplish something in their lives, regardless of which tools or companies they interact with.

**Experience map vs. Customer journey map:**

| Aspect | Experience Map | Customer Journey Map |
|---|---|---|
| **Scope** | Broad human activity | Specific product/service interaction |
| **Product focus** | Product-agnostic | Product-specific |
| **Purpose** | Understand the problem space | Diagnose product experience |
| **When** | Before you know what to build | After you have a product to evaluate |
| **Example** | "How do people manage their finances" | "How do users interact with our banking app" |

### When to Use an Experience Map

- **Exploring a new market** — You don't have a product yet, or you're investigating adjacent opportunities
- **Understanding the full context** — Your product is part of a larger ecosystem of tools and behaviors
- **Identifying white space** — Looking for unmet needs that no current product addresses
- **Reframing the problem** — Moving from "how do users interact with our product?" to "how do users accomplish this goal in their life?"

### Typical Elements

Experience maps are free-form, but commonly include:

| Element | Description |
|---|---|
| **Phases of behavior** | How the activity unfolds over time |
| **Actions and steps** | What people do (verb-first) |
| **Jobs to be done / Goals** | What they're trying to accomplish |
| **Thoughts and questions** | What's on their mind |
| **Emotions and state of mind** | How they feel |
| **Pain points** | Where they struggle |
| **Physical artifacts and devices** | What tools/objects are involved |
| **Opportunities** | Where value could be created |

### Building an Experience Map

1. **Define the activity broadly** — "Managing personal finances" not "Using our budgeting app"
2. **Research widely** — Interview people about their behavior, not your product. Use story-based questions: "Tell me about the last time you [activity]"
3. **Include non-digital touchpoints** — Conversations, paper, mental calculations, habits
4. **Map chronologically** — How does this activity unfold over days, weeks, months?
5. **Stay product-agnostic** — If a specific tool comes up, note it as one of many touchpoints, not the center of the map
6. **Identify opportunities** — Where are the biggest pain points, workarounds, or unmet needs?

### From Experience Map to Product Strategy

The experience map reveals opportunities. To turn them into strategy:

1. **Overlay your product** — Where does your product touch this experience? Where doesn't it?
2. **Identify gaps** — Phases where no product serves the user well
3. **Compare to competitors** — Which companies address which parts of the experience?
4. **Use Jobs to Be Done framing** — For each phase, articulate the job: "When I [situation], I want to [motivation], so I can [outcome]"
5. **Prioritize** — Which opportunities align with your capabilities and business model?

---

## Mental Model Diagrams

### What They Are

Mental model diagrams are hierarchical visualizations of how people think about a domain. They are built bottom-up from interview data, using a laddering technique that groups specific behaviors into increasingly abstract categories.

### Structure

A mental model diagram has two halves:

**Top half — The Mental Model:**
- **Towers** — Vertical stacks of tasks, beliefs, and feelings extracted from interviews
- **Mental spaces** — Groups of related towers that represent a theme in how users think

**Bottom half — The Organization's Support:**
- Features, content, and services that address each tower
- Gaps where no support exists (these are opportunities)

The alignment between top and bottom halves is the diagnostic power of the diagram.

### When to Use a Mental Model Diagram

- **Deep domain understanding** — When you need to thoroughly understand how users reason about a complex area
- **Content strategy** — Identifying what content to create based on user mental models
- **Feature prioritization** — Seeing which user needs are well-served and which are neglected
- **Product-market fit** — Understanding whether your product maps to how users actually think

### Building a Mental Model Diagram

1. **Conduct interviews** — 15-30 participants, open-ended, focused on behavior and reasoning. Ask "why" repeatedly
2. **Extract tasks** — Pull out every distinct task, belief, or feeling. One per note. Use participant's language
3. **Cluster into towers** — Group related tasks vertically. Name each tower
4. **Group towers into mental spaces** — Cluster related towers horizontally. Name each space
5. **Map organizational support** — Below each tower, list what your product/service offers
6. **Identify gaps** — Towers with no support below them are opportunities

### Reading a Mental Model Diagram

| Pattern | Interpretation |
|---|---|
| Tall tower, strong support | Well-served need — maintain it |
| Tall tower, no support | Major opportunity — unmet need that matters to users |
| Short tower, strong support | Over-invested — consider reallocating resources |
| Gap between towers | Users don't connect these concepts — don't force them together |

---

## Ecosystem Models

### What They Are

Ecosystem models visualize relationships between actors, systems, and content in a network-like arrangement. Instead of showing a timeline (like journey maps) or a hierarchy (like mental models), they show how value flows between entities.

### When to Use an Ecosystem Model

- **Complex multi-stakeholder services** — Multiple actors with different needs and relationships
- **Platform businesses** — Two-sided or multi-sided markets
- **Understanding dependencies** — What depends on what? Where are bottlenecks?
- **Strategic planning** — How does our product fit in the broader ecosystem?
- **IoT and connected products** — How do devices, services, and people interact?

### Core Elements

| Element | Description | Visual |
|---|---|---|
| **Entities** | Actors (people, organizations), objects, content, systems | Nodes (circles, boxes) |
| **Relationships** | How entities connect and exchange value | Lines/arrows between nodes |
| **Value flows** | What moves between entities (money, data, attention, goods) | Labeled arrows |
| **Concentric rings** | Priority or proximity (closer to center = more important) | Ring layout |

### Building an Ecosystem Model

1. **List all entities** — Who and what is involved? People, organizations, systems, content, devices
2. **Define relationships** — How does each entity relate to others? What do they exchange?
3. **Identify value flows** — What moves between entities? (money, data, trust, goods, services, information)
4. **Arrange spatially** — Place the most important entity at the center. Use proximity to show closeness of relationship
5. **Add layers** — Use concentric rings to show priority or influence levels
6. **Annotate** — Flag dependencies, bottlenecks, and opportunities

### Ecosystem Model Variations

**Stakeholder map:**
- Focus on people/organizations
- Show power and influence
- Map needs and expectations per stakeholder

**Value network:**
- Focus on value exchange
- Show flows of money, information, and services
- Identify where value is created and captured

**Technology ecosystem:**
- Focus on systems and platforms
- Show integrations and data flows
- Identify single points of failure

---

## Service Ecology Mapping

Service ecology maps visualize the complete web of relationships in which a service operates — all actors, all value exchanges, all dependencies. They are broader than ecosystem models (which focus on entities and flows) because they include the motivations, promises, and power dynamics between stakeholders.

### Why Map Service Ecologies?

- **Services are created in silos but experienced as a whole.** Organizations structure themselves around internal efficiency; customers experience disconnected touchpoints. The ecology map reveals the gap
- **Invisible connections drive visible problems.** A customer pain point at one touchpoint may be caused by a broken relationship three steps upstream
- **Services are co-produced.** Both the provider and the customer contribute effort. The ecology shows who does what and whether the burden is balanced

### The Three Core Components

| Component | Role | Returns |
|---|---|---|
| **Enterprise** | Makes a promise to customers (the value proposition) | Revenue, data, market position |
| **Agents** | Deliver the promise through channels (staff, technology, partners) | Compensation, purpose, growth |
| **Customers** | Receive the service, co-produce part of it | Value (the service outcome), data, payment, participation |

**Healthy ecologies have reciprocal value exchange** — value flows in multiple directions, not just from customer to enterprise. When the exchange is one-sided (extractive), the ecology breaks down.

### Building a Service Ecology Map

1. **List all actors** — Who is involved? Customers (segments), employees (roles), partners, regulators, competitors, communities
2. **Map promises and expectations** — What does each actor promise to others? What do they expect in return?
3. **Identify value flows** — What moves between actors? Money, data, trust, effort, attention, goods, services
4. **Assess balance** — Is value exchange reciprocal? Where is one actor bearing disproportionate effort or risk?
5. **Find invisible connections** — Which relationships are undocumented but critical? (e.g., internal service quality affects customer experience)
6. **Mark tensions** — Where do actors' interests conflict? These tensions are where service breakdowns originate

### From Ecology Map to Blueprint

The ecology map gives you the big picture. The blueprint gives you operational detail. Use them together:

1. **Ecology map** → Understand all stakeholders and their relationships
2. **Pick a journey** → Select one customer type, one scenario
3. **Blueprint** → Map how the organization delivers that specific journey
4. **Cross-reference** → Do the blueprint's backstage dependencies match the ecology's relationships?

---

## User Story Maps

### What They Are

A user story map is a two-dimensional arrangement of user activities that helps teams plan product releases around user workflow rather than technical priorities. The horizontal axis shows the user's journey (the backbone); the vertical axis shows priority from top (essential) to bottom (nice-to-have). It bridges the gap between understanding the user's experience and planning what to build.

### Structure

A user story map has three layers:

| Layer | Description | Position |
|---|---|---|
| **Activities** | High-level things the user does (verb phrases). These form the backbone — the narrative flow of the user's experience | Top row, left to right |
| **User tasks** | The steps within each activity. Ordered by typical sequence or priority | Second row, under each activity |
| **User stories / Details** | Specific stories, sub-tasks, or variations for each task. These populate the body of the map | Below tasks, stacked by priority (top = most essential) |

### The Backbone

The backbone is the single most important element. It's the user's journey told as a sequence of activities — the "walking skeleton" of the experience.

**Building the backbone:**
1. Start with the user's goal — what are they trying to accomplish end-to-end?
2. List the major activities in chronological order (left to right)
3. Keep it to 5-12 activities — if you have more, you're too granular
4. Use verb phrases: "Set up account," "Create first project," "Invite team," "Track progress"
5. Validate by reading it left to right — does it tell a coherent story?

**Example backbone for a project management tool:**
> Set up account → Create project → Define tasks → Assign work → Track progress → Review & report → Close project

### Building the Full Map

1. **Start with the backbone** — Get the activities right first
2. **Add tasks under each activity** — What specific steps does the user take? Keep them ordered
3. **Slice horizontally for releases** — Draw a line across the map. Everything above the line is Release 1 (the walking skeleton). Below is Release 2, 3, etc.
4. **Fill in stories and details** — Add specific user stories, variations, and edge cases under each task
5. **Prioritize vertically** — Essential at the top, nice-to-have at the bottom. The map should be readable top-to-bottom as "most important first"

### Vertical Slicing

The power of story maps is in vertical slicing — cutting thin, end-to-end slices through the map that deliver a complete (if minimal) experience.

| Slice | What It Contains | Purpose |
|---|---|---|
| **Walking skeleton** (Release 1) | The minimum story for each activity — one task per column, bare essentials only | Deliver a functional end-to-end experience as fast as possible |
| **Release 2** | Next priority stories — fills in the most painful gaps | Make the experience usable for early adopters |
| **Release 3+** | Progressively richer stories, edge cases, power features | Mature the product toward full vision |

**The rule:** Every release should be a complete story. Users should be able to go from left to right across the backbone and accomplish their goal, even if the experience is minimal. No release should be "all of activity 1 but none of activity 5."

### When to Use a User Story Map

- **Release planning** — When you need to decide what goes in Release 1 vs. later
- **Shared understanding** — When the team can't agree on scope or priority
- **Backlog organization** — When a flat backlog has lost its narrative structure
- **New product discovery** — When you need to visualize the full user experience before building

### When NOT to Use a User Story Map

- Single-feature work — too heavy for one feature; use a simple task breakdown
- Maintenance/bug work — no narrative backbone to map
- When you don't know the user's journey yet — do experience mapping or research first

### User Story Map vs. Other Diagrams

| Aspect | User Story Map | Customer Journey Map |
|---|---|---|
| **Focus** | What to build and when | How the user feels and where they struggle |
| **Audience** | Product team (PM, design, engineering) | Broader stakeholders, service design |
| **Emotional layer** | Not included | Central element |
| **Output** | Release plan, prioritized backlog | Insights, opportunities, alignment |
| **When** | After you know what to build | Before or during discovery |

### Collaborative Mapping

Story maps work best as collaborative workshops:
- **Who:** Product trio minimum (PM, designer, engineer). Include domain experts
- **Materials:** Large wall, sticky notes, markers. Activities on one color, tasks on another, stories on a third
- **Time:** 2-4 hours for initial map; 1 hour for refinement sessions
- **Facilitation:** One person manages the backbone; everyone contributes stories. Read the map aloud as a story to validate

---

## Choosing Between These Diagram Types

| Question | Best Diagram |
|---|---|
| "How do people accomplish [activity] in their life?" | Experience Map |
| "How do users think about [domain]?" | Mental Model Diagram |
| "How do all the actors and systems connect?" | Ecosystem Model |
| "How does our customer experience our product?" | Customer Journey Map (see separate reference) |
| "How does our organization deliver this experience?" | Service Blueprint (see separate reference) |

### Combining Diagrams

These diagrams complement each other. A typical progression:

1. **Ecosystem model** → Understand the landscape and actors
2. **Experience map** → Understand the broad human activity
3. **Customer journey map** → Zoom into your product's specific experience
4. **Service blueprint** → Understand how you deliver that experience
5. **Mental model diagram** → Deep dive into specific domain understanding

Each diagram answers different questions at different levels of zoom. Use the combination that serves your team's current needs.

---

## Content Syntax Reference (All Diagram Types)

Maintain consistent syntax across all alignment diagrams:

| Element | Rule | Good | Bad |
|---|---|---|---|
| Actions | Start with verb | "Compares prices" | "Price comparison" |
| Thoughts | Phrase as question | "Will this work for my team?" | "Worried about team fit" |
| Feelings | Use adjective | "Anxious" | "Feeling of anxiety" |
| Pain points | Start with gerund (-ing) | "Waiting for approval" | "Slow approval process" |
| Touchpoints | Use noun | "Email confirmation" | "Sends email" |
| Opportunities | Start with change verb | "Eliminate manual entry" | "Manual entry is a problem" |
| Jobs to be done | "When I [situation], I want to [motivation], so I can [outcome]" | Full JTBD statement | Vague goal |
| Goals | Complete sentence with user perspective | "Find a tool that works for small teams" | "Find tool" |
