Over the past month, AtomLeap’s in-house UX specialist Aileen Pohl has held several workshops on user research for the startups in our accelerator. We decided to devote this week’s post to this topic because it is extremely important for startups preparing to prototype their solutions to understand the users for whom they are building them. Furthermore, in this post, we would like to clarify some issues that came up during the workshops.
While ours is by no means an exhaustive guide to user research — you can find a number of guides of varying quality online, but we recommend you start with Salesforces’ module on user research basics — below are a few aspects that stood out during our workshops.
What is user research?
User research is a discipline aimed at providing insights into user behavior. These insights then help product teams to define their product requirements based on how users interact with the product. The end-result is therefore more likely to be a well-thought-out and user-friendly product.
The term user experience was first introduced by Don Norman, the director of the Design Lab at the University of California, San Diego, whose decade-long career has focused on improving the interaction between users and products.
Depending on the type of product or service that startups want to subject to user research, they can employ qualitative (interviews, diary studies, contextual inquiries) or quantitative (surveys) methods — or a combination of both. Data collection through interaction with users is the centerpiece of user research; without it, you are merely designing solutions or products based on unvalidated assumptions about user preferences.
Another noteworthy aspect to be had in mind is the fact that improving user experience is a team effort that requires the involvement of everyone in the company who influences the product in any way — from designers to user researchers, developers to managers, and marketing to sales representatives. Each and every one of them will benefit from gaining and sharing insights about user experience.
Why it is important
User research is important because, while it may be tempting to simply assume that your users have similar needs and drivers as yourself, talking to them may reveal that that is not necessarily the case. When performed early enough in the process of product development, user research can impact the features and ultimate shape of the solution you are developing. Furthermore, user research can help startups avoid a common pitfall : discovering, too late and after investing a significant amount of time and money in your product, that there may not be a market or user need for your solution. The benefits of user research include, but are not limited to: (1) making sure that your prototype is truly solving a need or problem your target users encounter and have difficulties solving without your product; (2) ensuring that they have enjoyable experience using your product; and (3) understanding the return on investment of user experience.
When you need to conduct user research
The short answer is: always. But if your product is simple and addresses a very specific problem that users have and that is common knowledge, you may find that you only need to conduct a little research to validate your assumptions.
Do we really need to pay a UX specialist?
User research is something that you can definitely do on your own, but whether or not the data you collect yourself will prove useful is a different matter. Budget allowing, you should talk to a specialist at least when you devise your interview or survey questionnaire (or other data collection methods) to ensure that the likelihood of collecting relevant information is high and, once you have collected and processed the data, to discuss how to make the best use of it.
Common pitfalls when conducting user research
Depending on the chosen methodology for user or UX research, there is a wide range of things that can go wrong, particularly when the data is collected by inexperienced researchers.
A few common pitfalls that we have come up during our workshops are:
- Confusing the user persona with a marketing persona. They are different. The first is meant to help you understand how users interact with your solution, the latter is meant to shed light on purchasing behavior (and purchasing power) in order to inform marketing and sales strategies.
- Failing to clearly define which problem(s) you want your solution to address. If you find yourself in this situation, you may want to employ a job-to-be-done approach, whereby you identify exactly why users resort to buying solutions like yours. For instance, in one of its UX experiments, McDonald’s determined that its users purchased milkshakes in order to have energy during their commutes and to keep hunger at bay. When they did not purchase milkshakes, they would resort to purchasing bananas instead. This important information influenced the features of McDonald’s shakes (they are filling and loaded with sugar, so they give users an instant rush), as well as its marketing strategy, because user research revealed that bananas, and not Burger King milkshakes, were its main competing products.
- Jumping straight into the interview without first making sure that the user feels comfortable. You need to create empathy when conducting user research. You build empathy by sharing some information about yourself first, asking informants contextual questions, and allowing them to respond freely. An ineffective way to create empathy is to jump straight into the questionnaire and ask directed questions throughout the process. Speaking of, avoid the related pitfall of
- Asking leading questions because you want to obtain a specific type of information from users. User research needs to serve your needs so it should cover topics that are important for your product development process. However, there is a delicate balance to be struck between gathering specific and useful information and asking leading questions. For example, if you ask an informant: ‘What do you have against milkshakes?’, you are already suggesting to them that there is something negative about this product. They are therefore more likely to give you a negative answer. Try to use neutral language and instead ask open questions, such as ‘What do you think about milkshakes?’. In so doing, you are more likely to get to the bottom of what informants really think.
- Not asking why often enough in interviews. Asking why too often or after consecutive statements makes for rather awkward conversations. For example, when a user states: ‘I don’t like milkshakes?’ you should ask them why. But if they answer that it is ‘Because I don’t like how they taste.’, you should not stop there. Dig a little deeper by asking, again, ‘Why?’ If they look nonplussed, elaborate. For example, you could say ‘By why I mean—type of flavor(s) do you like?’ If enough informants answer by saying something like ‘I like…fresh, citrusy flavors’, then your takeaway is that you should probably include a citrusy flavor in your offering of milkshakes.
- Confusing the user persona with individuals that you interviewed. A user persona is not an individual that you interviewed, but a grouping of users that was devised based on one or several relevant common trait(s). While it may be tempting to create a persona for every person you interview, that will not ultimately help you when you need to make design-related decisions. Narrow down the list of factors that are important for your decision making and disregard those that do not influence a user’s interaction with your solution.
We hope you found this post informative, particularly if you are currently working on your first prototype and are looking to learn how to have it tested by users. As always, feel free to get in touch with the AtomLeap High-Tech Accelerator using the contact form on our homepage if you need assistance in commercializing your high-tech product or solution.