Deeper Understanding: Stories, Observations, and Insights

May 5, 2014

Have you ever been on a project where you conducted user interviews and got some answers, but didn't know why you were asking specific questions, what the answers meant, or how they really related to a business? Have you felt like you were checking off questions, but not gaining any real value?

We have. Many times, sadly.

As UX professionals, we need to pay more attention to why we are conducting specific research and design activities. We need to ask how our learnings can impact people and the business for which we’re working, in positive, holistic ways. We need to know how our research activities integrate with the bigger program of user research and how they fit into product and business roadmaps.

Champion Advertisement

A Recent Project

On a recent project, a business asked us to help create personas and a customer journey map. So we needed to develop a user research plan that would enable us to gain a deeper understanding of the users for whom we were designing by collecting stories that could lead us to observations and insights about the domain under study.

While creating our deliverables, we also considered our process—listening to stories, translating the data from the stories to each other, and asking what we’d learned along the way. Then we thought about what this meant for our practice and how to improve our process the next time we conducted similar user research—our practice of the practice.

The deliverables were important, but for the purpose of this article, we’ll focus more on the process itself: capturing stories to develop a deeper understanding; looking at why planning is critical, how to capture stories, and how to evolve stories into observations and group observations into insights from the user research to help us to tell a compelling story to the business.

Note—We’ve recently presented on this topic—at IxDA Seattle in March 2014 and at Lean UX New York in April 2014.

Barriers in Business to Deeper Understanding

Here are some example of barriers to our more deeply understanding users that exist today:

The business already believes that they understand their customers, leading to false assumptions about what their customers need, who they are, what they do, what type of people they are, and incorrect design choices.
There are gaps between the business and the people who own the customer relationships and channels.
The business is working heads down to meet deadlines, so they have little time or attention for customer stories.
The business does not know how to connect the data that may already exist in different parts of the organization to gain a clearer understanding of customer needs.
The business relies on traditional market research that tends to look at demographics and does not help us to understand the user’s context.
The business is wary of seeing the customers in their own context.
Teams across the business, who own different parts of customer understanding, do not speak to each other, resulting in a customer story that doesn’t reflect reality and leading to further assumptions about what customers might need.
The platform drives decisions that are targeted toward the customer. When platforms, systems, interfaces, products and services, and interactions drive our understanding of customer stories, needs, and goals, this results in a focus on technology, features, and language that the customer might not need.
There is no time to plan. Continually, people are assigned tasks to meet the business’s short term goals and working hard to implement them so quickly that they have little time to lift their heads to see the path ahead and no time to plan what they should really be working on. See “the great tragedy of speed.”

Even when a business does have a human research and design practice, the business sometimes misunderstands its role and its tools, again leading to poor customer understanding and connecting inaccurate stories, needs, and goals to business strategy. Plus, there is an inability to view a problem or opportunity holistically, as we also mentioned in “Holistic Thinking on Transitioning to a New Practice Framework.”

Business obstacles to holistic thinking include, but are not limited to the following:

silos—This creates divisions between people who should be speaking to each other.
management structures—Sometimes people feel that they cannot speak to other people because a manager is blocking them from doing so.
too much rational thinking—People sometimes spend so much energy on being business people that they forget how to communicate as human beings and instead speak in numbers—all because they think that’s the language of business or are unable to express themselves openly or connect with new and better ideas.

How can we better understand the systems at play so they’ll encourage human conversations that lead to healthier outcomes?

Your Lens for Collecting Stories

Before conducting user research to collect stories that will provide observations and insights, it helps to remember what it means to be human and focus on the human qualities that are necessary to gain a clear view into users’ lives.

Think of this less as research and more as a relationship. Getting to know people takes time. With every visit we make to users, we see how their lives have changed. Often, when the main driver is meeting research goals or ensuring that a person matches the recruitment criteria, we get to hear from people only during brief, one or two-hour blocks of time. Forming a relationship with a person means viewing that person as an equal participant in the research; a human being who can contribute actively to these conversations.

Be open to diversity in these conversations. Everyone has interesting and diverse thoughts and experiences to share with others. It is important to recognize and celebrate this. But we should also ensure that we don’t focus too much on differences for their own sake and instead try to understand where differences and similarities should play out in the designs and all of the work that we do. This will enable us to appreciate where people are coming from and give them the respect that they deserve, but at the same time, allow us to recognize new viewpoints and opportunities.

Caring for other people means that you care enough to look out for their best interests; that you’ve thought about the points at which people may face roadblocks in their journey and how to guide them gently around these obstacles. Users also need our design solutions to provide the flexibility to handle situations that we may not have considered when devising them, so we can empower users to handle those situations well. Doing all of this ensures that, when solutions impact people negatively, they’ll remember turning a challenging situation into positive one. These moments are rare.

We are seeking truth in the stories. If we care enough to have empathic conversations with the people who are our customers, so we can better and more deeply understand their lives, we’ll be able to uncover truths about their usage of our current products and identify gaps in functionality that we should explore further in designing future products. This is absolutely not about leading people to get them to tell us what we want to hear, framing our discussions with people with constraints that guide them, or placing our primary focus on business goals or political benefits to our project team. It’s about how a design can truly match what people want now and perhaps even in the future. Also see Practical Empathy by Indi Young.

Human Qualities

When conducting user research, our human qualities can help or hinder our ability to get great stories. These qualities include—in no particular order—respecting, seeing, listening, probing, feeling, synthesizing, playing, leading, mentoring, facilitating, connecting, collaborating, critiquing, communicating, constructing, deconstructing, framing, envisioning, and persuading. Our ability to dip into and rise above these human qualities or to expand and contract as necessary is important. It’s equally important to have safe forums in which to practice these qualities, which help us in the context of our practice. At times, we need to be able to extend our framework beyond our primary research goals and themes to explore things that we might not initially know could lead us to insights that would be key to the business direction.

Planning Is Critical

It’s important to learn about a business’s expectations and also to enable its representatives to be part of our user research. We encourage business representatives to join us in doing user research so they can listen and learn from users’ experience first hand. In this way, we avoid research happening in a black box. Plus, it encourages everyone who participates to learn directly and connect what they learn to other stories as they emerge from customer visits. And the business can experience this first hand how the customers feel. We also promote going out into the user’s context—whether at home, at work, or at play—so we can gain a deeper understanding that goes far beyond demographics.

When planning your research, consider the following:

research themes—What do you want to find out and how does it connect to larger research themes?
immediate answers—To what questions do you want to find immediate answers?
stretch questions—What stretch questions could your research help to answer and how would their answers connect to future learning opportunities—either as part of a holistic strategy or in understanding the systems at play?
results—What do you want to do with the results? For our current project, we plan to map the observations to both personas and customer journeys, so what templates should we use to encourage designing for these deliverables?
known or unknown assumptions—What do you know and what is unknown? What are your assumptions?
other research—What other research already exists that could complement your research themes and goals?
design implications—What questions should you include whose answers might impact the design?
observations and insights—How do these fit within the larger collection of stories that form part of an observations and insights library for the business?

Understanding Users

With our discussion guide in hand to help facilitate a conversation, we want to gain a deeper understanding of the users from whom we’re learning and begin collecting stories.

When seeking understanding of users, consider the following:

moving beyond the discussion guide—Allow yourself opportunities to move beyond the key questions to explore conversations that may lead to your learning what you might not know about users. This may lead to some good insights.
not doing research, but having good conversations—Although we use the term research in our practice, we really consider this to be more about having good conversations with users. Remember, getting to know people takes time. Sometimes our own language can get in the way of gaining access to good stories.
being present—Remember to be present, interested, and aware, and give users your undivided attention during their interviews. This is common courtesy, and it also helps users to feel more at ease. See Interviewing Users by Steve Portigal.
allowing enough time—If you don’t cram your discussion guide with too many questions, you’ll have enough time to uncover three to six stories in a session lasting about an hour and a half to two hours. Neither you nor the participant should feel pressured to complete all of the questions in the discussion guide. Instead, allow stories to emerge naturally.
meeting user needs—Listen for words in the stories that speak to user needs. Consider times when users were let down because the business was not able to fulfill their real needs. Try to let go of your business-domain knowledge, and let users drive your interactions with them and use their own language. This may give you clues to the terms that you should use in the information architecture and product descriptions, for example.
realizing that you are not the expert—In the context of the interview, think of yourself less as an expert and more as a person who is there to learn from the user. In other words, the users are the experts, and they’ll help to drive their conversations with you. As a researcher, you are there to listen and to foster opportunities to dive deep as the stories emerge.

Capturing Stories

After the interviews, capture the stories to begin the process of unpacking the data. We’ve found that it’s best to do this in pairs, with Person A describing the interview and Person B transcribing the stories into story sheets. This approach allows us to become intimate with the data. Remember, it’s important not to question the data, but rather to let it wash over you.

Story sheets may include a user number; the user’s age range and profession; the user’s descriptions of the business domain under study and the people who influence them in their decision making; story 1, story 2, story 3, and so on; the issues users face as part of their stories; the observations you make that will impact your deliverables and connect to observations from other interviews; a wish list of items that users have requested as part of their stories—though these may not be present in the current product offering; opportunities for the business; and potential improvements to the products and services under study.

When gathering stories, consider the following:

calling beforehand—Call users before you meet them, so you can start to understand their interest in the domain, get a sense for their fit with your study, and build a relationship with them. This may also give you a sense of what stories you should dig into together when you meet.
time—Allow time in your discussion guide to delve deeper into the stories.
stories—Users’ stories can capture information about people, emotions, relationships, needs, motivations, and issues. From the common patterns that emerge from the stories, start to create personas. It’s important to think about how to link up personas, stories, and customer journeys so you can tell the larger story within the context of the business strategy and the future product direction.
priorities—Your product or service is not users’ priority. In the context of this type of research, your purpose is not to dig into all of the individual features and functions of the product, but to listen to the users’ stories, then determine how your products and services can fit into their lives.
clues—Stories give us clues about users’ emotions, relationships, needs, motivations, issues, and opportunities.
boundaries—Think beyond the boundaries when exploring how users interact with your products and services and the business. Consider what other connections you might make to see beyond your current views and perspectives?

From Stories to Observations

After documenting the stories on story sheets, take the time to read the stories to one another. Listen to all of the stories. As we read stories to each other, we capture bits of them on Post-it notes, then start moving the bits onto the stages of the customer journey—while, at the same time, questioning the stages themselves. The intent is not to try to get this right the first time, but rather to see what the stories are beginning to tell us and how the stories fit into the overall journey.

When mapping stories to a customer journey, consider the following:

emotional words—What were users feeling as they told their story? Were they angry, happy, frustrated, annoyed, joyful?
elements to unpack later—Identify elements in the stories to unpack later—either with the users or together with the business.
quotes—Identify important quotes that you could use in the personas or when presenting to the business.
deliverables—See how the stories may map to your deliverables—for example, personas, journeys, user-interface improvements, design goals, and assumptions.
time commitment—This will be time consuming and tiring, but well worth the effort. This provides another chance to become intimate with the stories.

From Observations to Insights

With all of this data on the wall in the form of a customer journey, it’s nice to be able to see and move the physical data around and connect it across difference spaces to better understand what it’s telling you. This is all part of telling the story to the business.

When developing insights from your observations, consider the following:

moving bits around—Move the Post-it notes around on the wall and connect them together.
structuring—Loosely structure bits of data into groups that map to your deliverables—for example, personas, journeys, assumptions, and design goals.
telling stories around the Post-it notes—Stand up and tell stories around the bits of data. Challenge your observations and insights, as necessary.
identifying gaps—Look for gaps in your data that may require further investigation with users or the business.

After a few rounds of refining, challenging, and revisiting the story sheets and groupings, start to move the data on the Post-it notes into a spreadsheet. Take another look at the insights before moving them to your final deliverable. Your spreadsheet may include tabs for design principles, stories, critical findings, information-architecture implications, overall observations, and opportunities. Overlay the personas at each stage of the customer journey. This may tell you about users’ painpoints, emotions, needs, and motivators; and help you to identify gaps in the stories, as well as users’ specific questions and their answers.

We hope that this process of exploring users’ stories will help you to progress from stories to observations to insights and enable you to design better user experiences for people.

In UX Strategy | User Research | User-Centered Design

Deeper Understanding: Stories, Observations, and Insights

A Recent Project

Barriers in Business to Deeper Understanding

Your Lens for Collecting Stories

Human Qualities

Planning Is Critical

Understanding Users

Capturing Stories

From Stories to Observations

From Observations to Insights

No Comments

Join the Discussion

Daniel Szuc

Josephine Wong

Other Columns by Daniel Szuc

Other Articles by Daniel Szuc

Other Articles by Josephine Wong

Other Articles on User-Centered Design

New on UXmatters