Empathy, Humility, and Moxie

It starts with empathy.

Every journey to a great user experience starts when someone somewhere empathizes with a user in a way that is authentic, human, and compelling. It starts when someone realizes that the most important person to pay attention to is not the person paying for the project or implementing the software, though these folks are certainly important. It starts when someone really, truly, deeply pays attention to the person who will end up using what's being created. User experience starts when someone starts caring about the user.

Next comes humility.

Anyone who has watched usability testing or ethnography or a focus group knows the feeling. I remember my first usability test - I had spent weeks with a talented team designing a great user interface. All we needed to do was validate the design with some end users and possibly make some tweaks. An evening of usability testing provided a huge heap of humility. Labels that were intuitive to me were enigmas to the users. Buttons that were totally obvious to me were invisible to users. Most of the people I showed it to couldn't even figure out what it was supposed to be.

Sometimes we argue with the first few people who have trouble with a design:

"This first test participant is an outlier."
"The second test participant isn't a good representative of our customer base."
"The third test participant must just be stupid."

But by the time we get to the 4th user who can't find their way through our design, we start to realize, maybe the problem isn't with the users. Do this enough times with enough designs and we learn a very healthy sense of humility. Two quotations that help keep me humble:

Several years ago we were testing a new home page design. We brought in several users and gave them what we thought were a handful of simple tasks to complete. By the time we got to the third user I was already starting to hear the humility music playing, and it came to a crescendo when the moderator asked, "so where would you click?" and the user responded, "I'd click over here on 'careers' so a could get a job with these bozos and fix their damn web site!"

And I remember Haim Hirsch, my first user experience mentor, who had conducted hundreds or thousands of usability tests, tell me, "I've never conducted a test where I wasn't surprised by something." So that's my goal - to be humble enough to assume that my design has major problems, and to be grateful to the users who will help me find those flaws.

Empathy, humility, and...

...moxie.

From the dictionary:

moxie
–noun Slang.

1. vigor; verve; pep.

2. courage and aggressiveness; nerve.

3. skill; know-how.

Empathy is about caring. Humlity is about knowing that I don't know everything. And moxie is about knowing that I do know some very important things, and in some cases I know more than my users do. Moxie means that I sometimes contradict the users. It means I have the expertise and the larger vision to create something they hadn't thought of or to do something in a way they would not suggest. We need to conjure up some moxie, because users are great at identifying problems, but not necessarily always great at identifying solutions. User needs should drive all key decisions; user design suggestions should get added to the list of possibilities.

Moxie in the absence of empathy and humility is a recipe for disaster. But in combination with them, moxie enables us to break paradigms, innovate, and create solutions that meet our users' needs and desires better than anything they could have designed themselves.

Empathy - I care
Humility - I don't know everything
Moxie - I know something

How to demo software

The demo starts out nicely enough...

In a dark conference room, the vendor lays out a simple user scenario and starts walking me through the experience. But before he gets to the second click, he needs to mention the cool feature that he isn't clicking on, which leads to a short discussion of the underlying technology, which evolves into a few key points about their design process. When he finally finishes telling me about their unique value proposition and returns to the screen, I can't remember anything about the scenario, which is irrelevant anyway, because now he's running through the menu bar telling me about each of the features.

The thing that's screwed up about this story is that the story gets lost.

Stories are perhaps our most powerful tool when demo'ing software. As human beings, stories grab our attention--we can't help it. Stories are sticky. They stick in our minds much more than explanations, descriptions, or data, and once they get into our brains, all kinds of powerful things start to happen. We intuitively fill in gaps in the narrative; we make connections with other parts of our lives, and--very importantly--we remember. If you want your audience to remember what you said, tell a story.

A good story tends to have some typical components that can all be included quite easily in a software demo, even in a short demo that lasts only 60 seconds. Be sure to include:

1. The main character, your user--give him or her a name (let's use "Bored Bob")
   
2. The setting/context--when and where is Bob using the software (Bob's at home, sitting on his couch with his laptop on the coffee table and the tv on across the room)
3. The central conflict--every story needs a conflict, and for demos, the conflict is usually a problem the user is having that the software will help solve (Bob wants to go to a movie, but he doesn't know which movie to see)
4. The plot--what happens (Bob googles "movies near me" and clicks on my web site. He starts by browsing through a list of new releases, gets drawn into a couple of previews, purchases a ticket for the one he wants, and buys the soundtrack on a whim.)
5. The resolution--in a demo, this is the "so what" part--what are the benefits to Bob and to the owners of the software? (Bob loves his movie and finds a new favorite musician on the soundtrack; my movie site grabs a customer that would have otherwise gone elsewhere, and we make an extra $5 profit from the soundtrack sale)

Five elements sounds like a lot, but it doesn't have to be. Here's what we ended up with in my simple example:

Bored Bob is at home, sitting on his couch with his laptop on the coffee table and the tv on across the room. He wants to go to a movie, but he doesn't know which movie to see, so he googles "movies near me" and clicks on my web site. He starts by browsing through a list of new releases, gets drawn into a couple of previews, purchases a ticket for the one he wants, and buys the soundtrack on a whim. Bob loves his movie and finds a new favorite musician on the soundtrack. And my movie site grabs a customer that would have otherwise gone elsewhere, and we make an extra $5 profit from the soundtrack sale.

A good demo of my web site will tell this story very early on and, very importantly, without interruptions. If I stop the story to explain a feature or why we did something the way we did, the story gets lost--much better to tell the story beginning to end, simulating Bob's experience on the screen, and then go back for explanations and details. When I'm done with the story, I can talk about the incredibly cool matching algorithm we developed to push the right movies to Bob, and the subtle up-sell techniques that prompted him to buy the soundtrack, and the projected increase in revenue due to these enhancements. Those are important things to tell my audience about, but they should never detract from the star of the show.

The star of any great demo is the end user experiencing the product.

Stories and Data

Last week I spent 3 days in storyland. I was in Chicago at a meeting of the Innovation Learning Network, focused on the use of stories in business and innovation. I listened to lectures on the psychology of stories; played games with a Hollywood script writer, a radio show editor, and an acting troupe; and spent a morning redesigning airport security procedures.

It got me thinking about the interaction between stories and data.

Ideally, stories and data have a symbiotic relationship. Stories add richness, context, and meaning to data while data adds richness, context, and proof points to stories. Used together well, they are a powerful combination for telling the truth about the past, present, and future. But if we get sloppy, they can undermine each other.

I think there are two ways that data supports stories:

1. Data helps us figure out which story to tell
2. Data helps us tell the story

These are two very different uses. Confusing one for the other can have tragic consequences.

Data helps figure out which story to tell
First, data helps us analyze reality to determine what's actually happening in the organic stories of real life. By collecting and analyzing data, we begin to piece together a narrative that represents what's going on--who is doing what? how often? how many? how consistently? etc. That's what data analysis is all about--good data helps me understand reality.

For example, if I want to tell the story of how someone uses my web site, I can look at data about user demographics, site traffic, user reactions, and user behaviors. This data enables me to construct a story that accurately represents something real. It may also enable me to create a vision for the future that is grounded in today's reality, or to describe a future that is demonstrably different from today's reality.

With a foundation of good data analysis, I can then create narrative stories that describe reality to my audience in ways that are accessible, compelling, and memorable.

Data helps us tell the story
Once I know which story to tell, I can use data to improve the impact of the story I'm telling. Data enhances the narrative, adding proof points to make it believable, adding context to make it understandable, and adding details to make it compelling.

The pitfall
Problems arise when I mix up the two uses of data. If I'm telling a story, and I grab some data to make my story more compelling, but I have not yet used data to make sure I'm telling the right story, then I'm in trouble. For example, let's look at data and stories about global climate change.

If I want to tell a story about the relationship between human activity and the climate, I need to start by examining the data in order to figure out what's real. If I'm paying any attention at all to science, I will conclude that the story to tell is one in which humans are driving the earth to the brink of climate catastrophe. I can then use data, both qualitative and quantitative, in the telling of that story. E.g., I can cite average temperatures rising, thinning ice sheets, oceanic acidification, and displacement of species. All of these will support my story. These data make my story more accessible, compelling, and memorable.

However, if I skip the first step (using data to determine what is real), then I may tell a story in which global warming is a crazy liberal plot, and I can still use data to support my story--it snowed in April this year; global temperatures historically rise and fall; etc.

I think the critical step is for a storyteller to be self-aware of which of these two roles data is playing. Am I using data to figure out which story represents reality, or am I using data to support the story I'm telling? Both are important, and both are powerful. But if I do one without the other, I either end up with a less compelling story, or I'm distorting the truth.