Introduction:
This is the second in a series about using stories and storytelling in the design, development, and the deployment of products and services. In each post, I will weave in some advice about what makes for a good story as well as how to use stories. In this first case, the emphasis is on using stories to help uncover customer needs and wants. Needs and wants are not quite the same thing. For an extremely worthwhile discussion on the difference, check out this classic article by George Furnas.
We Human Beings are not just Information Processors; we are also Energy Processors.
I had just attended a conference on “knowledge management” co-sponsored by IBM consultants and IBM Research. On the plane ride back, after finishing the crossword, I turned the page to find a full page color ad by an IBM competitor that proclaimed: “Knowledge Management is simply [sic] providing the right information to the right person at the right time.” Color me skeptical, I thought. It isn’t simple to do those things. Beyond that, the formulation seemed simplistic even in its formulation.
The image of one of my undergraduate professors flashed into my brain. Professor MacCaw, (as we will call him), taught advanced German, a language which he had learned in a Russian prison camp, which might explain his approach to testing. At semester’s end, he asked, “Who in class wants A?!”
All two dozen of us raised our hands, of course. At this point, he proceeded to — there is no other word — attack one of the students in the class who had had four years of German in high school and had also lived in Germany for two years. The contents of his questions were not really that difficult, but the manner in which he demanded the answers was horrid. He would ask, for instance, “In first story, main character went where?” (He would always ask the questions in English).
And she would begin to answer (necessarily in German), “Er geht…” And after a couple words were out of her mouth, he would scream, “Please to conjugate!” This meant that she would have to think back to the last verb she uttered and then conjugate it. “Ich gehe, Sie gehen, …” Then, he would interrupt again and scream a completely different and unrelated question in English. She would begin to answer; he would interrupt after she uttered only a few words: “Please to decline!” This meant, that she would have to give the various forms of the last noun she spoke according to the case. But once again, she could not finish but only begin declining the noun when he would once again interrupt. After 40 minutes, she was in tears and he looked menacingly around the room and asked, “NOW! Who in class STILL wants A?”
I have zero desire to go hang gliding or sky diving. But when it comes to the danger of mere social humiliation, I say, “Screw it. Been there. Done that.” I was one of only two of the remaining students who raised their hand. This act won me the next turn on the chopping block. He proceeded the same whip-saw questioning fest with me. The two-period class was almost over when he finished with me and began questioning “Mr. Lepke.” The bell rang and everyone else in the class left. Later that evening, I chanced to see Professor MacCaw in the Student Union. He walked up to me, eyes blazing. “Ha! I had Mr. Lepke after class for two hours! Finally, he said to me, ‘No, No, Dr. MacCaw, no more, I beg you. No more!’”
This oral exam was difficult (even with my “screw it” attitude). It was much “harder” than my dissertation defense, for example. Again, it was not the information requested but the manner of questioning that made it difficult. People are not emotionless robots, as it turns out.
The next semester, not surprisingly, only about half the class returned. One day in class, as Dr. MacCaw began one of his lengthy digressions on Eastern European history, he stopped himself in mid-sentence to say, “What is THIS!? Someone is passing notes in my class! I will take note and read in front of entire class!” He snatched the note, unfolded it, and indeed read the note in his loud ringing voice: “Doctor MacCaw: your zipper is down.” And, indeed it was. He had meant to humiliate someone in front of the entire class — and he had succeeded. He had the necessary information delivered at the right time to the right person, but — thanks to his own actions — it had not been done in the best manner — at least not the best manner for him.
Human beings are not just information processors. We are living things and as such, the emotions, the vibes, the manner, the intensity of presentation — these are all vital to how we will react at the time and also how we will feel about the people involved and what we will recall years later. And this fact also means that the atmosphere you create when you interact with various stakeholders will vastly impact the quality of the insights and stories that you receive. If you really care about the people and are really committed to doing something to making people’s lives better; if you are truly open to hear and take in something unexpected or even disruptive to the project; and if you allow your informant to feel that truth about you, you will obtain the gold ring.
Stakeholder Stories Solicited at their Sites.
If you use a mechanical method and a mechanical tone and a mechanical manner to ask your users and other stakeholders about their needs and wants, what you will uncover are the most mundane, most rudimentary, most superficial and socially acceptable needs and wants. You can indeed use this information to design a product or service, and you may even have a product or service that succeeds in the marketplace. It will likely be, however, a rather short-lived “win.” Why? Because you are designing to fulfill wants that are subject to the wild winds of passing fashion rather than to catch the fire of an underlying passion.
What I found for myself was that it typically took about an hour of talking with a stakeholder, and most importantly, listening attentively, before they began to tell me their real stories. Your mileage may differ according to culture, context, power relations, your personality, and so on. I like to use a semi-structured interview. In this type of interview, there are known questions that I want to ask. But I also schedule plenty of time to let them elaborate, tell me what’s what behind the scenes. I know that in the corporate world, there is an ever-present push for being “efficient” and getting the job done as quickly as possible. So, it’s tempting to get the informant “back on track.” I always prefer to interview an informant in their workplace. This seems like common courtesy; it puts them more at ease; and it sometimes reveals their use of other people, references, private notes, etc. as well as what they are dealing with in terms of atmosphere, noise levels, interruptions, desk space, etc.
John Whiteside, who ran the Usability group for Digital Equipment Corporation for a time, recounts running various usability studies and gathering data in various ways about a product they were designing for manuscript centers (places where human beings, historically almost always women, transcribed the dictation of others into text on a computer so that it could be edited, re-written, stored, etc.). The first time that they visited their users in the field, they discovered that they spent about seven hours a day typing and a considerable amount of time every day counting up, by hand, the number of lines they had typed. So, in one instant, they realized a feature that would improve productivity significantly.
Guidelines for Soliciting Stakeholder Stories.
When I managed the storytelling project at IBM Research, I was fortunate enough to hire Deborah Lawrence to help with the project. She thought it would be a cool idea to interview experts in a number of fields whose job, in one way or another, involves soliciting stories. So, she went out and did just that. I believe that her interviewees included medical doctors, policeman, reporters, social workers, and psychotherapists. These various practitioners had very similar guidelines.
Story Elicitation Guidelines:
- Provide a “warm-up” period.
- Tell something personal and revealing about yourself; perhaps tell a story that is a model of the kind of story you’re looking for.
- Observe an implicit contract of trust.
- Provide a motivation for the story — why it’s important.
- Accept the storyteller’s story and worldview. Don’t resist the story.
- Reveal who you are, how the story will be used, potential audience and goals, answer questions.
- Use questions to probe. Sometimes, a totally “off the wall” question can create space for story to emerge.
- Empower the storyteller — they are the expert.
- Avoid threat; don’t appear as an expert yourself.
- Listen with avid interest.
These may seem fairly obvious such as does a lot of the advice in the book, How to Win Friends and Influence People. (Come to think of it, that might be the single best book you can read if you want a career in HCI/UX). However — back to the guidelines. I think they seem obvious once pointed out, in much the same way that once someone points out the “pig in the clouds” (or the face in the tree) you cannot not see it.
The above list is not, of course, meant to be the definitive such list. This was based on one study. If you have additional guidelines or disagreements, please let me know.
