Story mapping solo exercise

The team exercise assumes a room full of people. This solo story mapping exercise is for when it is just you. You might be new to a team, taking over a product, or trying to understand a process that nobody has written down. The steps are similar, but the goal is different. A team maps to agree. On your own, you map to understand. If you have not seen a story map before, read what story mapping is first.

When to Map Alone

Solo mapping is useful when:

• You have joined a team and need to learn how the product works.
• You have been given a problem to solve and need to work out where in the product it lives.
• You are preparing for a group session and want a draft to start from.
• You are writing a proposal and want to check your own thinking before you show it to anyone.
• A process exists only in people’s heads and you want to write it down.

What Is Different

In a group, the map comes out of discussion. People disagree, and the disagreement shows you where the map is wrong. On your own, nobody disagrees with you. So the job is to find the places where you would disagree with yourself: the parts you are guessing, the parts you have never seen, and the parts you know from only one source.

A solo map records two things: what you know, and what you do not. The second one matters more.

Solo mapping is also faster. You can build a first draft in an hour, put it down, and come back to it over a few days. You do not need to finish in one sitting.

Step 1: Pick a User and a Question

Write three things at the top of the map:

1. Who is the user? One specific person. “A member who has reserved a tool and needs to collect it,” not “members.”
2. What are they trying to do? The result they want, in their words.
3. What am I trying to find out? This is the question the map has to answer. “How does a reservation get made today?” “Why do members stop using the library after their first loan?” “What is the smallest version of this feature?”

Keep the question narrow. A broad question gives you a large, shallow map that does not tell you anything. If you have several questions, pick one and make a separate map for the next one later.

Step 2: Write the Story as You Understand It

Lay out the user’s story from memory, before you read any documents or look at any code. Write the big activities in a row, left to right, in the order they happen. Under each one, write the steps the user takes. Give yourself fifteen minutes.

Where you are not sure, write the card anyway and mark it as a question. Do not stop to check. The point of this pass is to get your current picture out of your head so you can look at it.

When you are done, read the row out loud. It should sound like a story, even though this draft will be wrong in places.

Step 3: Add What You Know

Now go through the map step by step and add a card for each thing you know about that step. What the product does. What users do. What goes wrong. What people have told you. Keep each card to a few words.

For each card, note where the information came from. A short note is enough: “from the code,” “support ticket,” “Sam told me,” “dashboard,” or “my guess.” You will need this later when you decide what to trust.

Good places to look:

• The product itself. Use it as the user would. Click through every step. This is the fastest way to find steps you missed.
• The code. Even if you do not read it closely, the names of routes, tables, and jobs tell you what exists.
• Support tickets and reviews. These tell you where users struggle, in their own words.
• Analytics. How many users reach each step, and where they drop off.
• People. One short conversation with someone who has worked on a step is often worth an hour of reading.

Step 4: Mark What You Do Not Know

Go through the map again. For each step, ask: have I seen this, or do I only think it? Mark the cards that are not facts:

• Questions. Things you could find an answer to. “Do members search by brand or by tool type?”
• Knowledge gaps. Areas you know nothing about. “I have no idea what happens if the confirmation email fails.”
• Risks. Things that could go wrong. “Two people could book the same tool.”
• Pain points. Places where users struggle today.

Then look at the shape of the map. Three patterns to look for:

• Steps with no cards. You have never looked at this part. Add a knowledge gap card so the empty column is not mistaken for a simple step.
• Steps where every card is a guess. You have a theory about this step but no evidence.
• Steps where every card came from one source. One person, one document, one dashboard. You know what that source thinks, not what happens.

At this point the map shows what you know and where the edges of what you know are. For many questions, this is already enough to act on.

Step 5: Fill the Gaps

Pick the gap that matters most and go find out. Use the product. Read the code. Check the numbers. Ask one person one question. Watch a user for ten minutes. Then come back and replace the question card with a card that says what you learned and where it came from.

Repeat this a few times. Fill gaps in this order:

1. Gaps on the path every user takes. If you do not know what happens at “Confirm,” nothing after it is reliable.
2. Gaps that block the question you wrote down in Step 1.
3. Gaps that are cheap to fill. A five-minute question to a colleague.

Do not try to fill every gap. Some questions are better answered by a group, and some do not matter for your question. Leave those cards on the map as questions. They are useful to the next person too.

Step 6: Prioritize and Slice

Now sort the cards under each step from top to bottom. The rule is the same as in a group: if the user could not get through this step without it, it goes near the top. If they could, it goes down.

In a group, people hear each other’s reasons. On your own, nobody does. So write a short note on any card whose position is not obvious. A week from now you will not remember why you put it there.

Then draw a line across the map. What the line means depends on your question:

• If you are planning something new, the top slice is the walking skeleton: the smallest version that lets the user get from start to finish.
• If you are trying to understand something that exists, slice into “works today,” “broken or missing,” and “ideas.”

A Worked Example

You have just joined the team that runs a neighborhood tool library app. Your manager tells you that a lot of reservations are never collected, and asks you to find out why.

Question. The user is a member who has reserved a tool. The question is: what happens between “Reserve it” and “Pick it up,” and where does it go wrong?

Story from memory. Find a tool, check it is free, confirm, get a reminder, go to the shed, show the booking, collect it. You are not sure about the reminder, so you mark it as a question.

What you know. From the code: a confirmation email is sent when a booking is made. From the dashboard: about a third of bookings are never marked as collected. From support tickets: members say they forgot, or turned up and could not find the shed.

Gaps. Nobody has said whether reminders exist. The “Get a reminder” column has one card on it and it is a question. The “Pick it up” column has a pain point about finding the shed and nothing else.

Filling the gaps. You search the code for anything scheduled. There is nothing. You ask the person who handles support. They say members ask about reminders every week. You replace the question card with two facts: no reminders exist, and members ask for them.

Result. The map answers the question. The biggest gap in the journey is a step the product does not do at all. Your proposal is a reminder the day before, plus directions to the shed in the confirmation email. Both go in the first slice, and the sources on the cards show why.

What to Do With the Map

• Keep it as your own reference. When someone mentions a part of the product, you have a picture to place it in.
• Bring it to a group session as a draft. Say it is a draft. Let people move cards, add cards, and tell you where you are wrong.
• Use it to write a proposal. The top slice is the plan, the sources on the cards are the evidence, and the remaining questions are the risks.
• Keep updating it. When you learn something new, add it as a card. When a question gets answered, replace it with a fact.

Common Mistakes

• Treating guesses as facts. If you cannot say where a card came from, mark it as a question.
• Mapping only what you know. Show what you do not know as well, so the map tells you where to look next.
• Adding too much detail too early. Get the whole journey down first, then go deep where your question points.
• Not writing down sources. Without them, you cannot tell later which cards to trust, and neither can anyone else.
• Trying to fill every gap. You will run out of time. Fill the ones that matter for your question and leave the rest marked.
• Never showing anyone. A solo map is a starting point. The first person who looks at it will find something you missed.

Build It in Cartographer

Cartographer has card types for the marks used in this guide: question, knowledge gap, risk, pain point, and learning. Use the card notes for sources. Attach a persona so the user stays in view. Use milestones for the slices.

If you have notes, tickets, or interview transcripts, connect Claude or ChatGPT through the MCP server and ask it to place what it finds on the map as cards. See an example of turning an interview into cards. When you are ready to show the map, use a shared view so people can see it without an account.