I have a confession to make. I sometimes get lost in Agile projects.
I understand the Agile philosophy but from a design perspective I find it lacking. Very often, I miss the ‘Big picture’. Looking back, I have done many good designs that have ended up being realised as a bit of a 'Homer mobile' in the end. I blame myself, but the system has played its part.
In internal discussions, I find myself saying ‘shouldn't we define this more comprehensively first ?’.
‘We need to look at the entire user flow..'
‘Who is this for and what problems are they solving ?’ and eventually the word ‘requirement’ will slip out of my mouth.
At this point someone will point to me and scream ‘Heretic’ and run away shaking their head mumbling something about Waterfall and the Agile manifesto and the conversation will end.
Recently, I have been reading Jeff Patton's new book Story Mapping and really cant recommend it enough.
When I read it i thought ‘Finally, someone that gets me..’
Jeff reviews a lot of great methods in the book (LeanUX, Design Studio etc.) but the central theme is Story Mapping. I have spent the last month experimenting with this method and am extremely happy with the results.
Some background: Within our organisation, we have been working theme that includes a set of features that will deliver value but needs to work across multiple projects. The technology and the UX needs to be consistent across these three products. All products are maintained by different development teams and different PMs. The challenge has been to follow the UX and technology development across these products and User Stories.
A real soup.
The basis for Story Mapping is the telling of a story of a user. In this story, the user uses a product or system to solve their problem.
The telling of this story, will allow people working on creating this solution, to have the same understanding.
Lets imagine a future. Lets assume for a minute that this system is live and let’s talk about a day in the life of someone uses it and start telling the story.
First, they would do this, then this, and so on ….’
This story, will allow people working on creating this solution, to have a discussion. Through this discussion they will define the scope of the solution (big picture), develop the same understanding of the major goals and find any weaknesses in their thinking.
Pretty basic. Sort of.
Story Boards -
Up until know, I thought we had a fairly good definition of the problem we were solving, but over time I felt things were being viewed from different perspectives within the organisation
In order to align this thinking and so we could tell a good 'what if' story I felt we need something more. To facilitate, this I chose to use another UX tool: the Story Board.
In this case, I worked with the PM teams to develop a Story Board that described what the system would do to solve the user problem.
I centered the Story Board around the ‘Job to be done’ principles. I have found this to be a really effective way of defining the user problem.
Overall I am super pleased with this discussion and the resulting Story Board.
The aim of Story Mapping is to tell the whole story - so the first priority is to concentration the breadth of the story and solution.
For practical purposes we needed to have two meetings (2 hours) for the entire Story Mapping session, but ideally it would be better to do it in a single one day meeting.
To do this I used the Story Board as a guide and had the team do a 10 min session of silent brainstorming. During this session, the group used the major Activites of the Story Board and to consider steps that would go into each of these Activities. After 10 minutes the group presented their steps and these were grouped under the appropriate Activity. This was a very good discussion and some new Activities were discussed that added to the width of the Story Map.
At this point the team was pretty satisfied with the breadth of the Story Map.
During this meeting we now dug into the details of each Step the respective Activities.
In doing this, I used a few questions to guide the discussion. Stopping at each step in the process we would ask:
- What are the specific things they would do here.
- What are the alternative things they could do.
- What would make this really cool.
- What happens when things go wrong.
I had the team do silent brainstorming then post their ideas under each Step individually. Each person then presented their idea and thinking to rest of the group, followed by a discussion. Once each person (6) posted their ideas we had a discussion within the group. We consolidated some of the details and placed them in a of prioritisation, the higher priotitised details closer to the top .
The end result was a quite large Map that outlined the entire solution that would guide us through the development.
I was very pleased this this method and I received a great deal of positive feedback. The major benefits:
- A well discussed common understanding of what problem we were solving and how a user would solve this with our solution.
- A clear image of what each Product needs to contribute to the solution, and where these connection points needed to be. This was extra-valuable in our context.
- A scope that made the Interaction Design much easier over the entire flow of the solution.
- A large number of holes in our thinking were uncovered. Numerous technical challenges were identifued that would need further investigation.
- We should have done this some time ago. I am glad we did these session now but really felt this type of session is the most valuable when we start a development effort. Definitely more appropriate in the initial Discovery stage of a project.
Finally, I would like to thank Jeff Patton for a comprehensive well written book.