Getting stakeholders onboard

Some user experience designers and researchers have the luck of working in an organization that already knows their value and have fully integrated user experience and research into their process. Most of us aren’t so lucky.

Some of us are designers, some of us are project managers, and some of us are developers. We are the growing number of people who believe in regular feedback. We believe in making decisions with evidence, not personal preferences and “the way things have always been done.” We believe the team builds a product for the users, not for the stakeholders. We believe that a product should help a user complete their goals; the business goals can only be met if the user goals are met first.

The hardest part of conducting user research isn’t finding participants. It isn’t collecting the data. It isn’t analyzing the data. The hardest part isn’t even applying the knowledge gained from the data. No by far, for most people who believe in the user experience process and user research, the hardest part getting started in the first place.

The hardest part of conducting user research is getting stakeholders and the rest of the team onboard with the idea.

What are the most common complaints we hear about getting started with user research from stakeholders? How do we counter these arguments?

Argument 1: It will take too much time to conduct studies.  Perhaps the most common argument against conducting user research and implementing the user experience process. Ask instead, how many times have we had to redesign things? How many times have we gotten to development, only to still find holes in the planning and design? How many times have we launched a product or feature, only to get no traction at all? The problem is if you are just planning, designing, and building without having evidence, you are wasting time on a project and features that have not been validated. Regular research saves time in the big picture, and it’s usually pretty quick to get started in the first place.

Argument 2: We can’t afford it. Time is money. Maybe it costs $200-300 per month for the tooling, and a similar amount for recruitment. But can your team really afford all the planning, design and development overhead by not conducting research? Can your team really afford to be wandering around in the dark?

Argument 3: We already know everything we need to know. We are the experts. Expertise is a double-edged sword. Often experts would consider themselves to be “unconsciously competent”, meaning experts are often unaware of how much they actually know. 99% of the time, your users are not experts. That means that they may need more support or more simplification than an expert would need. Even if you have experts on your team, you still need research to be able make sure your expertise isn’t getting in the way of forming a comprehensible product for beginner and intermediate users. User research will keep your team honest.

Argument 4: I don’t think this study method is legitimate. Every form of research, user or academic, has some weakness, or flaw. This is why, in academia, we don’t accept a theory until the problem has been researched using a variety of techniques and the results are reproducible by multiple teams. Just because a technique has a weakness does not make it have no value. For example, usability testing may only need a handful of users, but you can combine it with a survey to confirm the results. The answer isn’t to not conduct research, the answer is to use a variety of techniques to validate your findings.

Argument 5: We already use analytics and other forms of testing. Analytics provides quantitative data only. It only tells you what happened, and by how much. Analytics, by its nature, will never be fully comprehensive. It will never tell you why something happened. It will never tell you what your users are expecting, what your users are motivated by, or how your users feel about your product. All it will tell you is what they are doing. Analytics is a seriously powerful business tool. But you can multiply the power of analytics by combining it with qualitative methods, like usability tests and qualitative surveys and interviews.

Argument 6: This isn’t a university. User research is almost never as formal as academic research. An academic study can go on for years. Most user research studies last a matter of a few hours from beginning to end. While its true that user research is based on psychology’s research methods, it’s nowhere near as rigorous. User research works best when its quick and dirty.

Argument 7: That’s the job of the marketing team. Marketing by its nature has a different set of concerns than development. The job of marketing is mostly to get users to show up. The product team’s job is to help users accomplish their goals while meeting the needs of the business. By its nature, the product team will be focused on retaining users and forming deep relationships with the user. The marketing team is heavily focused on getting users in the door. Marketing needs its own research to be certain. But the product needs its own research, separate of marketing.

Argument 8: Users don’t know what they want. This is true. Users will not tell you directly what their goals are, most of the time. Sometimes you can glean it from support tickets, but that is a very skewed set of users. User research helps you to undercover what your users aren’t saying. By observing their behaviors and experiences, you can observe what they don’t know how to articulate.

The best way to get people to agree to something is to put them in an agreeable mode. And no, this doesn’t mean buying sweets or doing favors for them. Instead, appeal to their core values and get them to agree to something very small. This will prime them to be ready to agree to things in general, and breaks a defensive state of mind. Then, after you get that first small agreement, show them how the research will benefit them. Instead of saying “we should be doing this…”, focus on the benefits that they will receive. Again, start small, and build your way to full integration.

What are these core values I am talking about? Some people value budget and financial concerns. Some people are more concerned about shipping out the product and getting more features out the door. Some people are worried about the emotional health of the organization. Some people genuinely empathize with the users. Some people are focused on making sales. Some people want things to be as efficient as possible. Ask questions to find out what core values drive the stakeholders and unconvinced team members.

Another hint I have is you might find engineering to be the most sympathetic people to the user experience and user research cause. This might be a bit counterintuitive, as most people would guess marketing or design as the most sympathetic to the user research cause. But engineers want things to be very efficient, and engineers hate spending their time on things they feel are arbitrarily decided. Most are big fans of the scientific method. Engineering can be an excellent ally in the fight for the user’s interests. Graphic design, QA and technical support can also make great allies. Even the documentation team can be persuaded and assisted by the research data.

Some people will never be convinced. If you are at such an organization, and you have made several efforts before and seem to get nowhere, you need to evaluate if this is the right organization for you to be part of. After all, if the leadership or other team members refuse to be influenced at all, the chances of a sustainable product become much slimmer. It might be time to look for a new team to call home.

Other tips or suggestions? This is a difficult topic, and there’s always room for improvement. Let us know on the comments or on Facebook or Twitter if you have suggestions here! Thanks!

About these ads

2 thoughts on “Getting stakeholders onboard

  1. Pingback: Stop making full-page comps | Transformative Research

  2. Pingback: User Research Devil’s Advocate | Transformative Research

Comments are closed.