- I'm going to give you a really brief description
of story mapping.
If you want to learn more about this technique,
I suggest you get Jeff Patton's book
"User Story Mapping,"
which describes the process
and the rationale behind it in much more detail.
The story map is a one page
or rather one wall explanation
of both the big picture of the product
you'll be developing and the details
of what you'll build to meet those big picture goals.
It describes your release strategy,
the minimum solution, and then incremental improvements
and how you intend to deliver each of those pieces.
It also highlights gaps in your knowledge
where you'll want to do more research,
prototyping, or technical investigation
to find the best solution.
That sounds like a unicorn, doesn't it?
A mythical beast with magical powers,
but actually it's just a communication tool
to help make sure the whole team is on the same page.
Here's how it works.
First, list out all of the stages in the user's journey
as they use your product.
For instance, discovering that they have an issue
finding your product to help them through the issue,
working through the steps of the issue.
Then what resolution looks like.
These stages most likely come from your experience map.
Create a blue sticky note for each of these stages
and put these sticky notes
at the top of a sheet of paper,
about the same size as your experience map ended up.
Now lay out all the screens from your paper prototype.
Create a green sticky note for each one.
Or rather, for each conceptual area of your interface.
Stick those green sticky notes
underneath the corresponding blue sticky notes
on your story map.
You might not have green sticky notes under each blue area
because your product might not be designed
to help the customer
through all the stages of their journey.
That's okay.
It's still important to have those areas
of the journey on the wall
so that you can think about things
like marketing messages
or how your product must integrate
with other products that will happen
during those other parts of the journey.
Next, it's time to write yellow stickies
for each capability that your product
needs to have in order to do its job.
That sounds hard,
but you already built paper prototypes
with all of those capabilities in place,
or you learned through user testing
that you were missing certain important capabilities.
This is where you write down
each of those capabilities and place it under
the green sticky that correspond
to that part of the interface.
I like to describe each capability in terms of the outcome
it provides to your customers,
what it enables them to do.
If you're used to working in an agile or iterative process,
you'll notice that these capabilities correspond
pretty much to epic level user stories.
Later, you can create your backlog
by breaking these epics into proper stories.
If the same capability gets used in multiple places
in the interface, you only have to write it out once,
the first time it gets used.
Be very careful here not to add capabilities
that weren't part of the original plan.
This is the time where people's pat features
often find their way into the product
without any real user verification.
So guard against it.
Once you're done with the yellow stickies,
it's time to stand back from the story map.
Look across the whole map.
Where are that big gaps?
What areas are you still uncertain about?
What parts might cause you technical problems?
Add a different color of stickies,
maybe pink to show what extra research you need to do
and what questions you want to find answers for?