Lesson: Managing Design Innovation with Matthew Beebe

Step #7 Analyze Design: Finding meaningful stories

When you come back from doing user research, let's say you had a team doing some user research, and you went to all corners of the world and you came back with all kinds of stories, basically. I think it's good practice to do periodic story-telling as you do this ongoing user research to start to allow the rest of the team to understand what everyone is learning.

And so, as you are going through these stories, I think it's a good practice to try to focus on telling the stories that seem most relevant to the project, first of all, but then you should be able to share stories that you don't exactly know why they are relevant yet. Stuff that seems important, but you haven't really figured out how it's important to the project.

That's the point of the team. So the team now is listening, to try to understand what's interesting about it, basically, for the purposes of the project. And now I'm writing post-its, I'm telling stories, and people are listening and asking questions to help me understand why I think it's important.

Inevitably, as we are going through this storytelling, there will be a bunch of stories that seem related. They may not be stories from the same person, they may not be observed by the same person, or be stories from the same subject of the research, but they are related because they point to the same problem.

So this is the most important pattern to recognize during the storytelling, is this story and this story are both evidence of the same problem that exists in the world. Then you need to create clusters of the stories. There are a lot of different ways things could be related. They could be related because of different types of similarity. The similarity that you are looking for, though, is they point to the same or similar problem or opportunity.

Once you have those clusters, now you have to turn that into something actionable, because an observation of a problem in and of itself isn't necessarily isn't as actionable as it needs to be. So then what you need to do is summarize the detailed stories and this is what I call the insight.

So you say, "This cluster of stories, what is the high-level summary of all those stories, and why is this a problem or an opportunity? What is the harm that arises because of this thing that we observed?"

So the first part of this is not really up for debate. These are observable facts about the world. We saw these things happen. People said these things. They did these things. This is just a fact. So summarize those facts.

The next part is where design judgement starts to come into play where you say, "This is why this is a problem. This is the harm that arises or the opportunity that this presents." This is where judgement starts to play a role. Creativity starts to kind of eek into it a little bit more.

Then you can turn that into a statement of solution criteria. So, we see this happen. This is a problem because of this. And so therefore, our system that we are designing here should solve for this.

So it's like this logical flow from observed facts to a contention about the harm that arises to a solution criteria. Now I like to give this chain of ideas a title. So now it becomes part of the project lexicon, I guess, or the language of the project.