How to tell the user’s story and get your team excited about UX?
Your user’s story covering the entire user experience
Understanding the users is of vast importance for us, designers. We dedicate so much time and effort to understanding our users better and ensuring that what matters to them will find its way into the project roadmap. User research and field studies can help us better paint the “user picture”, which will later translate into meaningful designs.
But how the user research data can make an impact the whole team can benefit from? How to transform dry research documentation into a gripping story which resonates with our team members and stays with them to encourage user-centered development?
While we might get attached to the products we are working on, what truly stays with us is the satisfaction of solving a problem. Our job as designers is to find solutions to user problems but to solve the right problem we need to get to know our users first.
Research is the way! Start with it.
“Observation is a form of humility and humbleness because for me to understand you, I have to first admit that I don’t understand you. And that admission allows me to have permission to get to know you, to learn about you, to serve you.”
Jason Mayden
Research comes in many forms and practices, but it all starts with the idea that user research isn’t only for designers. In fact, everyone from the cross-functional team needs to be aware of the research findings. This will help the team focus on what’s important and bring real value to the products they are developing. Having a shared understanding of the users’ struggles and goals helps teams move faster together. And most importantly it allows teammates to feel the true impact of what they’re building.
Involving engineers and management when considering user studies is an overlooked practice, (mainly because it’s time-consuming) but it’s worth considering when aiming for harnessing a culture of high design maturity in your organization. Involving cross-functional teammates in your studies will spread empathy within the team and greatly boost team collaboration. It is proven that people who are informed or participated in work early on care more about it. Sharing research helps the team think beyond the functionalities and consider the best solution for the user. That in the end leaves you with a team full of user advocates who can connect code and business and translate that into meaningful experiences.
Remember that if you don’t communicate the insights from your studies there is no point in conducting them in the first place. Doing design documentation for the sake of accumulating plenty of deliverables is a mismanagement of both your and your team’s time.
Are User Stories Enough?
“Do you know how to tell your users’ story? How do you know? Are you sure you’re not just making it up as you go along?”
Christopher Butler
In Agile development, user stories are used to describe software features from the user’s perspective. They include who the user is, what the user wants, and the reason they want it.
As [a user persona], I want [to perform this action] so that [I can accomplish this goal.
It’s a quick formula for describing software features from the user’s perspective. It’s undeniable that user stories help teams organize their understanding of the system and its context. This is why they are being vastly utilized as an IT instrument. What sometimes product teams tend to forget is in order for a user story to be useful it must be written based on actual user observations.
If you’ve worked in a product team you might have noticed that the majority of the user stories are being written by the development teams as a result of workshop activities and during the course of Discovery sessions. What we often miss is that a good amount of user stories is also accumulated through the product development cycle and usually, those are a product of the engineers themselves. The result is a list of feature descriptions merely disguised as user needs since they are based on assumptions and don’t even follow the user story format. That may result in sprints consisting of disconnected statements instead of actual user-related goals.
Another disadvantage of user stories is that they don’t represent the full picture of the product. They target a specific feature or small task in the large flow which is a very limiting view of the user experience. Important aspects like motivations and in dept context remain hidden.
But if user stories are not enough to do our users justice in telling their story the right way what is?
Tell the Story on Multiple Levels
To tell our user’s story we need a broader scope than a typical user story in Jira. To advocate properly for my users I like to provide a view of the entire user experience by covering everything from how users first learn about the product to their first signup and testing all the way to their daily use and product advancement. Here is a take on how to utilize research findings and transform them into a tangible narrative for your designs.
Once you’ve done with research, you’ve familiarized yourself with the product domain and your users, chosen a user problem you would like to resolve, ideated on possible solutions with your team, and considered them based on feasibility and viability it’s time to shape your users’ story. Here are some instruments that would help you package your discovery findings into a compelling narrative:
User Scenarios
A user scenario introduces details about how a product might be interpreted, experienced, and used by a specific user group/persona. A scenario typically begins with a description of a key situation or activity that the user is required to complete. Unlike user stories which tend to be brief and specific by nature user scenarios are written in a story-based format that opts for exploring different contexts and use cases.
User scenarios can help you build upon your user stories by incorporating user intentions and motivations, as well as different circumstances and considerations users might have while engaging with a product or service. You can also explore how other key figures may interact with the main persona as your scenario unfolds. It is important that scenarios contain a range of user difficulties and challenges, based on actual user data and real insights in order for key issues to be resolved.
Use Cases
Use cases could be viewed as nothing more than a set of steps a user might take to complete a task or a goal. Even though this is a user-centered technique use cases are less about user needs and more about user actions. A use case describes an event of a user interacting with a product/service and maps their every step until they’ve either successfully completed their task, or have failed to do so.
Use cases can be your guiding checklist. They help us designers envision outcomes before they happen or have been defined. This boosts team collaboration by making a requirement definition of a team sport. Adding use cases to your design process helps highlight how the product/service should behave and it also pinpoints the things that might go wrong.
User Flows
A user flow is a diagram representing the user’s path to achieving a main goal. It contains each step, from start to end and its primary task is to optimize the user’s ability to complete a task. User flows are incredibly useful when it comes to getting a bird's eye view of things when designing seamless experiences since they are great when it comes to easily spotting steps in need of improvement.
User flows can help you bind functionality and storyline. You can use them to visualize your user’s journey by elaborating on user needs and desires. Let’s also not forget the happy and unhappy paths which could be used to see if we’ve covered all use cases in the design. Such flows could also be utilized when developing your product’s error-handling strategy by providing error states and alternative or recovery journeys.
Storyboards
A UX storyboard communicates a story through images displayed in a chronological sequence. “A picture is worth a thousand words” — they say and it’s true. Images convey information way better than words and this is one reason storyboards do so well when presenting murky design insights.
Despite being labeled as “artsy” artifacts without much value some storyboards are a great way to make your ideas visible. They translate research findings into an understandable and compelling narrative by focusing on the user’s actions and the emotions that follow. This makes it easier for stakeholders and non-designers to comprehend and remember user information and key findings. What is more, the stories you create by using storyboards can encourage teams and stakeholders to be proactive and take action. They can also help you notice gaps in your thinking.
Conclusion
In order to accurately tell the story of your users it needs to be based on research and outside-in insights. Only then the uncovered user problems can be translated into user stories to define a feature. Being aware of the steps and actions users take along their journey while interacting with your product highlights the whole UX picture. In that way, you can ensure you and your team are not focusing on singular features, having the whole flow in mind and advocating for user-center development.
On the other hand, raw research data from user interviews and field studies may excite us designers, but it doesn’t always make sense to our cross-functional partners. We need a way to transform research findings into something tangible to narrate our designs and make them more understandable and compelling. Leaning on user scenarios, use cases, user flows, and storyboards can help visualize the whole user journey and provide a designer with the context to make designs compelling. This way research insights become more alive and relatable. And most importantly it gives us the why behind the designs and enables us to put our vision into context for anyone we are showing them to.
