What people want is to get their job done. It\u2019s 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\u2019s just not the most important thing. Going even further, I\u2019d say that understanding what people really need is the tricky bit; building the product is easy.<\/p>\n
The first step to understanding what users need is to understand the users themselves.<\/p>\n
Some problems can only be discovered in the user\u2019s natural environment, and it\u2019s usually a different place from that quiet office where software developers create the product.<\/p>\n
For instance, real users don\u2019t 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\u2019t understand the pressure real users experience if they haven\u2019t spent any time with them.<\/p>\n
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\u2019s also how empathy is born.<\/p>\n
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.<\/p>\n
Confronting two completely different perspectives\u2014three if you include yours\u2014is a big step forward. But don\u2019t 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\u2019t be discovered during the shadow days.<\/p>\n
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\u2019s impossible to interview every user, so this type of research doesn\u2019t prove anything.<\/p>\n
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.)<\/p>\n
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.<\/p>\n
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\u2019ll want to share that information with marketing, sales, company trainers, technical writers, HR and other stakeholders.<\/p>\n
Personas are fictional characters that represent specific user segments. But this isn\u2019t about demographics; age and gender don\u2019t matter that much. What\u2019s truly important are users\u2019 goals, attitudes and behaviors. Studies show that people respond to individual stories with more empathy than they do to statistics.<\/p>\n
When done right, personas have great power. Daniel Kahneman, psychologist and behavioral economist, states, \u201cPeople who have information about an individual case rarely feel the need to know the statistics of the class to which the case belongs.\u201d<\/p>\n
Ocado Technology, the company I work for, is the world\u2019s 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\u2019t buy the solutions we need off the shelf. That means we\u2019ve had to create the world\u2019s most efficient online grocery delivery system from the ground up. During our user research, my team quickly discovered that we don\u2019t have a specific user type; we have several because we serve such a broad customer base.<\/p>\n
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?<\/p>\n
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\u2019ve learned.<\/p>\n
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).<\/p>\n
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.<\/p>\n
Involving various departments in our research\u2014especially service delivery, data and HR\u2014not only enriched the details for each persona, it resulted in the discovery of a third persona: Albert. Alberts are similar to Lukes, but don\u2019t become Roberts over time. They find the job too complicated because they don\u2019t 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.<\/p>\n
It\u2019s 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\u2019t happen otherwise. And my team doesn\u2019t say, \u201cThe users want the latest AngularJS on the UI,\u201d any more. They say, \u201cRobert struggles with out-of-date information; he needs it to be refreshed in the background.\u201d<\/p>\n
It\u2019s not just the product team that benefits from the existence of Robert, Luke and Albert. Others benefit as well.<\/p>\n
By combining qualitative and quantitative research, you\u2019ll gain an accurate picture of your users that allows you to create user personas that will resonate with teams cross your organization.<\/p>\n","protected":false},"excerpt":{"rendered":"
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.<\/span><\/p>\n","protected":false},"author":26,"featured_media":9004111222570242,"menu_order":0,"template":"","categories":[9004111222497210],"tags":[],"content-series":[],"content-format":[9004111223037711],"framework-box":[174,178],"vertical":[131],"ppma_author":[961],"class_list":["post-9004111223065778","resources","type-resources","status-publish","has-post-thumbnail","hentry","category-product-development","content-format-article","framework-box-fw-planning","framework-box-fw-user-personas","vertical-product","author-anna-miedzianowska"],"yoast_head":"\n