How to make your design stories focused on your user's perspective
Design storytelling should be from the user's perspective, not yours
"I don't work for [this company]. I work for the users." This quote, by a Lead Product Designer to the CEO, helped illustrate a subtle shift we always need to keep in mind when communicating about our users.
Design storytelling is one of the most potent design communication tools to persuade our team to make hard but valuable decisions for our users. However, we often make a critical mistake when learning to tell stories: we tell our story from the wrong point of view.
I've made this mistake before: I've jumped straight into insights from user testing, making it about all the work I did without ever really adequately introducing who our user is. You might have, as well.
You are not the main character in your design stories; your users are. Shifting how you present your work to this perspective will lead to more success in persuading your team.
Here's why that matters more in design storytelling than you might think.
Make sure your main character, the user, isn't a faceless entity
Every story, from children's books to fantasy novels, requires a main character. After all, why would you read a book consisting of several hundred pages about someone you don't know or care about?
Even nonfiction stories, like Design stories, focus on people. While a nonfiction book may focus on central themes, insights, and concepts, they are often tied to historical examples of people or are focused on you, the reader, to get you invested.
For example, the Psychology of Money, a nonfiction book about how human psychology affects how we think about money, offers historical examples of people encountering each lesson to help tell a story about why this matters.
We'd object to listening to a story about a faceless main character with no defining features. However, we often jump to telling our team what's going wrong with the product or usability fixes without first ensuring they know who the user truly is.
It's not as though your team is entirely clueless about your users. They'll know some stuff, such as their job title, what companies they might work for, or other market research.
However, they may not know about the user's typical day, roles and responsibilities, and workflow around your product. This means they don't know why a specific change might be a big deal.
But often, these specific changes may be your most critical recommendation.
To understand users is to understand the context.
One of the most significant changes I persuaded my team of in one project didn't sound that critical: I convinced my team it was worth printing directly from the application.
It sounds like a minor change from the business standpoint, but when you understand (and present) how users work, you can immediately see the impact.
My users worked in field offices where several people (sometimes a dozen) shared a single printer. When they had to print an application, it would go to an external printing application where their print job was queued with everyone else's.
As a result, users often had to spend tons of time sorting out mixups with paper applications, trying to find their customers' applications and more. This often resulted in several lost hours of work a week.
By telling that story around our user's struggle and getting people the ability to print applications on demand, we took a seemingly minor problem (from a business perspective) and addressed it to solve a significant user need.
But that likely wouldn't have happened without detailing the struggle with the user's workflow as the main character.
This is why defining your user in a way your team can understand can help you highlight the most critical aspects of what needs to be done.
So before you dive into the usability issues when talking with your team, ask yourself one crucial question: what do they understand about our users?
What does your audience know about users, and can personas help?
One of the first steps of the storytelling process is to understand who you're presenting to. Typically, this is done by identifying your change agent, the person you're targeting who can take a specific action.
If you're targeting a team member who has sat in interviews with your users and knows just as much about users as you do, then perhaps you're OK with moving on.
However, suppose you're talking to an executive or presenting in a town hall with a more general audience. In that case, you may consider adding your personas to your slide (if they're polished enough).
This is to quickly establish who you're talking about in a way that doesn't drag down your story. Consider the following statement:
"We interviewed 5 users, including Network Administrators, Tool Administrators, IT Engineers, and IT Managers."
Do you, as the outside audience, know the difference between these job titles? Do you know what they do or why that is important? Probably not.
This is why dedicating a single slide to an existing persona can be helpful. Not only does it visually spell out some of the critical aspects of your user, but others can revisit these slides and see who they are later.
In addition, if you've done all this work around personas to figure out who your target users are, this is a way to showcase your hard work and get people interested in using them.
Of course, you don't want to define every point of the persona. Here are some topics you might chat about:
- How many people were we tested with, and how similar were they to our persona (i.e., Our persona is the IT engineer, but we also tested with managers and administrators to get a broader view)
- How do their responsibilities sync up with their product (i.e., do they use our product a lot, or is it just for one thing)
- Common tasks they're looking for software to solve (i.e., have they used our competitors, etc.)
- The environment they're working in (are they super swamped, or can they take their time?)
- Additional context to help start the story (Are they accessing our site from mobile devices?)
After that comes the story from the user's perspective
Tell your user's story through the first-person peripheral view
What do the Sherlock Holmes and The Great Gatsby have in common?
It's simple: the narrator is not the main character. Sherlock Holmes is the main character, but we take the view of John Watson in these books. Likewise, Jay Gatsby may be the main character, but it's told from the perspective of Nick Carroway.
This is technically known as the first-person peripheral view, where you're the narrator but not the main character. When you realize this is the viewpoint you should aim for, it becomes easy to analyze your findings and see if you need to rephrase them.
For example, consider an essential research headline that you might have given before:
"3 out of 5 users failed to find the help button or link by themselves and had to be prompted where to go to find assistance."
This sounds like a relevant finding, but whose perspective is this from? It's yours. You conducted user research, you observed something, you counted up how many people ran into this issue, and you are reporting on what you observed.
What might this look like if we shifted to a user's perspective? It might look something like this:
"Our users struggled to find help when they had trouble understanding certain concepts. When they didn't understand the term "Tag," 3 out of 5 users couldn't figure out how to find that without relying on Google."
It may be a subtle shift, but there are a couple of things that we've done to make this more user-centered:
- We gave context around user workflow: The user was doing a task and ran into an issue. This helps to establish what happened
- We gave a detailed example: When users didn't understand "Tags," they ran into this issue
- We talked about scale after establishing what users did: The count, 3 out of 5, was talked about afterward to show this impact.
So, what exactly can we do if we talk about what we did rather than what our users did?
Don't report what you observed: report what users experienced
When compiling user research, we often make a critical mistake: we talk about what we observed and stop there.
To understand why this is a problem, consider how non-UX professionals might analyze your user testing data. Can Sales, Marketing, or Engineering count the number of users who said X and report that? Of course, they can.
However, we know that won't always give us what we need: what users say vs what they do can always differ. This is where a different framework, the Ladder of Inference, helps us figure out how to approach things.
Essentially, everyone can start at the same "Observation" level (i.e., 3/5 users did X), but what matters is what we infer about the data that we collected (i.e., how we climb the ladder).
By doing this, we can not only understand why something is occurring but also what decisions need to be made.
It could be that 3 out of 5 users failed to find the help button because our "Help" is not where our users initially expected it to be, which you inferred because your users always went to one specific place for help before moving on.
Or, it could be that our help is too general, which you infer when you hear user frustration when they land on a general documentation page.
So if 3 out of 5 users ran into a particular issue, don't start with what you saw: start with what conclusions you might draw from that point, and build a story around it.
Your job, as a storyteller, is to convey how frustrated your users were, based on what you observed, and provide insights into how we can fix this.
The primary purpose of our job is to advocate for users
As designers and UX professionals, it's sometimes easy to get lost in the fact that we do cool stuff. We design things that solve user problems and build beautiful pages and applications.
But always remember that the primary purpose of your job is to advocate for users. Users cannot be in every meeting your product has, and someone must speak up when lousy user suggestions are recommended.
One of the easiest ways to do this is to ensure that your team always understands who your users are beyond just a vague description of them. By ensuring that your users are kept front and center with any stories you tell, you can ensure that you're correctly conveying what they're looking for.
So make them the main character of any story you tell around the design. Doing so ensures that your team always remembers who they're making decisions and building a product for.
I'm creating a Maven course on Data Storytelling for Designers! If you're interested in learning (or would like to provide feedback), consider filling out this survey.
Kai Wong is a Senior Product Designer and Data and Design newsletter writer. His book, Data-Informed UX Design, provides 21 small changes you can make to your design process to leverage the power of data and design.
