What people want is to get their job done. It’s not the product they need the most, they need results. I am not saying that the product is not important, I am a product owner, after all. It’s just not the most important thing. Going even further, I’d say that understanding what people really need is the tricky bit; building the product is easy.
The first step to understanding what users need is to understand the users themselves.
Some problems can only be discovered in the user’s natural environment, and it’s usually a different place from that quiet office where software developers create the product.
For instance, real users don’t follow testing scripts. They just want to get their job done, whatever it takes. It often seems illogical. Your team may ask why users would ever do things a particular way. They can’t understand the pressure real users experience if they haven’t spent any time with them.
But that can be fixed. To begin, shadow experienced users for a day. People like to be treated as experts and are usually happy to share their knowledge. These shadow days are particularly helpful to understand why a less cool feature needs to be prioritized in the backlog. It’s also how empathy is born.
Even with shadowing, problems may remain hidden, especially when experienced users are involved. People can adapt to anything, even bad software. They will find workarounds to complete their tasks. Getting a fresh perspective helps highlight these invisible issues. The views of new and experienced users may be surprisingly different, so attend new user training programs when available.
Confronting two completely different perspectives—three if you include yours—is a big step forward. But don’t stop there. Encourage users to visit your environment and put themselves in your shoes. Hold a brainstorming session. The users might spot problems in your way of thinking that are invisible to you and wouldn’t be discovered during the shadow days.
This shadowing and user interviews, called qualitative research, helps build important relationships and great products. It can also be a lot of fun. There is only one problem with it: It’s impossible to interview every user, so this type of research doesn’t prove anything.
Here is where quantitative research helps. If there is any kind of data about your users, use it. Visualize data wherever possible, as it often triggers new questions. And be sure to tackle questions from different perspectives to avoid confirmation bias. (Testing an antithesis usually mitigates the problem.)
This combination of qualitative and quantitative research helps answer exactly what it is that happens and why people do it. It helps build products with the users in mind, products that get the job done.
User personas are a great way to summarize qualitative and quantitative research and to share the results of user research across the company. In addition to development, you’ll want to share that information with marketing, sales, company trainers, technical writers, HR and other stakeholders.
Personas are fictional characters that represent specific user segments. But this isn’t about demographics; age and gender don’t matter that much. What’s truly important are users’ goals, attitudes and behaviors. Studies show that people respond to individual stories with more empathy than they do to statistics.
When done right, personas have great power. Daniel Kahneman, psychologist and behavioral economist, states, “People who have information about an individual case rarely feel the need to know the statistics of the class to which the case belongs.”
Ocado Technology, the company I work for, is the world’s largest online-only grocery retailer, reaching 70 percent of all British households. We develop our own systems for processing and delivering those groceries because you simply can’t buy the solutions we need off the shelf. That means we’ve had to create the world’s most efficient online grocery delivery system from the ground up. During our user research, my team quickly discovered that we don’t have a specific user type; we have several because we serve such a broad customer base.
For example, our internal user personas, Luke and Robert, are both delivery drivers, responsible for delivering groceries within one-hour time slots. While they share a common goal of delivering groceries to customers, their motivations and frustrations are different. Why does it matter?
Most people we hire are like Luke, but become more like Robert over time. As they gain experience, their perspective changes. Roberts provide excellent customer service and know the job better than anyone. They have navigated through the complex process and are happy to share the tricks they’ve learned.
If we could understand the things that frustrate and motivate Lukes, they would become Roberts more quickly. They would perform better, experience more job satisfaction and be less likely to leave the company. The result would be better employee retention, less time and money spent on initial training and less need for Roberts to help Lukes (or cover their mistakes).
In other words, helping Lukes ultimately keeps customers happy, because it supports the continuation of excellent service. Helping Roberts means providing ongoing support and further improvements to job efficiency.
Involving various departments in our research—especially service delivery, data and HR—not only enriched the details for each persona, it resulted in the discovery of a third persona: Albert. Alberts are similar to Lukes, but don’t become Roberts over time. They find the job too complicated because they don’t have any relevant experience on which to build. They give up quickly and leave the company. Knowing where Lukes and Alberts struggle lets us question the most complex parts of the process and focus on things that matter.
It’s important to keep user personas alive. In order to work, these personas need to be properly communicated. Sending an email with persona descriptions to the team is not enough. A poster on the wall is not much better. People get used to them quickly, like any new office furniture. Instead, our personas are real-life size cardboard cut-outs, residing close to our desks, where we can always see them. They come to our sprint review meetings and they attend workshops with real users. They even have email addresses and wear real clothes. People stop beside our office and ask about them. That directs more attention to our users and triggers conversations that wouldn’t happen otherwise. And my team doesn’t say, “The users want the latest AngularJS on the UI,” any more. They say, “Robert struggles with out-of-date information; he needs it to be refreshed in the background.”
It’s not just the product team that benefits from the existence of Robert, Luke and Albert. Others benefit as well.
- The users themselves benefit, of course, as they get better products.
- Development’s work is more appreciated and receives better feedback.
- Software testers have the capability to test realistic scenarios.
- Data analysts know which questions to ask.
- The UX team is no longer solely responsible for the user experience; responsibility has become shared.
- Technical writers write documents that address real problems.
- Managers understand how users’ behavior influences company’s KPIs.
- Product owners have accurate data to ensure that their products succeed.
By combining qualitative and quantitative research, you’ll gain an accurate picture of your users that allows you to create user personas that will resonate with teams cross your organization.