A half-day interactive workshop for researchers, designers, and anyone who practices UX research
One of the biggest challenges and top frustration causes for UX research and usability practitioners lies in getting buy-in for research from stakeholders. People have trouble persuading stakeholders to conduct UX research to begin with. They have difficulties in getting sponsorship and budget for fieldwork. They experience hostility when they try to get their stakeholders to act upon research results. This workshop provides strategies and tools for getting stakeholder buy-in for UX research. During the workshop we will learn tried and tested techniques, hear success and failure stories, practice and role play, and share insights with other workshop attendees.
1. Improve client skills, learn to deal with difficult stakeholders
2. Learn communication techniques that have been proven to work with stakeholders
3. Learn how to encourage stakeholders to act upon research results
Bob finds himself challenged by his product managers about the number of participants in his studies. Bob works as an in-house UX researcher for a medium-sized company that develops software for call centers. These are some of the things his product managers say to him about his sample size:
Bob is about to give a presentation to his stakeholders (product managers, software developers, maybe a couple of c-level executives) reviewing his recent usability studies. He will summarize three studies he conducted in the past 6 weeks in which he had 5, 4, and 6 participants. He knows he will be challenged with regard to the number of participants and thinks of ways to persuade his stakeholders it's okay. He tried to use Jakob Nielsen's famous chart to no avail. His stakeholders were not persuaded. He set up a meeting with a key stakeholder prior to the presentation to discuss (and try to solve) the sample size concern.
Case 2: The satisfaction survey
Ron is a researcher in a company that provides book publishing houses of all sizes a Web application for managing book proposals, reviews, and approval processes, as well as monitoring book production and distribution. The company has extremely diverse user population - from very small publishing houses that publish 1-5 books annually, up until publishing powerhouses that span many countries and verticals. The latter is the icing on the cake for the company. On one hand, they provide the most revenue through paying per usage of the application. On the other hand, these are high-profile customers, extremely vocal, sensitive, and demanding. A brigade of sales and professional services people take extra care of the relationship between the company and these important customers.
Recently, Ron was working with his stakeholders from product management and R&D departments on launching a satisfaction survey. His stakeholders supported this effort that required some tweaking in the application to allow adding a link on the main dashboard that will be presented to a sample of the users based on various calculations.
One of the consultant in the company's Professional Services department asks to meet Ron. During the meeting she complains:
"What is the goal of this survey? How do we intend to use the results? From my perspective, I am not sure this is the right approach for high-end publishers. And we can not put this into the application unless it gets full buy-in from Sales and Professional Services. Given that we ask for surveys after each technical support interaction, it may not be worth the time and effort. Instead of this, can't we spend our R&D resources on other areas such as must-have features that haven't been prioritized yet?"
Case 3: The great firewall
Tony is a researcher for a small company located in down town Dallas, Texas. The company consists of a small, yet amazingly talented software engineering team. The primary product the company offers is disease management solution for patients who suffer from chronic deseases such as diabetes, multiple sclerosis, etc. Although users of these sites are patients, the company sells its product to giant pharmaceuticals. These pharmaceuticals offer disease management tools to patients who use or potentially use medications manufactured by these pharmaceuticals.
The company has a huge Sales organization with about 50 salespeople organized into different teams, accounts, and pharmaceutical size. Tony is the sole UX researcher. To make sure everyone is aware whenever someone from the company contacts a customer, Tony agreed with the Sales team leadership that they will support his UX study recruiting effort. Whenever Tony plans a study, he lets Sales know and asks for participants while providing details about the study. In many cases, this has worked rather well for Tony and he usually got the participants he needed.
Tony is currently recruiting participants for a field study aimed at identifying needs of physicians who interact with chronic disease patients. The goal is to explore the need for adding an online tool to the company's offering that will enable effective communication between doctors and patients. Pharmaceuticals can help recruit doctors and patients who already use the company's tools. Since the development team for this future tool has many smart, opinionated engineers, Tony invited them to join him and observe field sessions. When he sent the usual request for recruiting support from Sales, Tony mentioned that for each client visit, there will be two software engineers joining him.
After a couple of weeks where recruiting has not gone so well, Tony feels something is wrong. He pinged the North America Sales Director and asked about the recruiting status and if there is anything he can do to help make it more successful, faster. In their meeting, the Sales Director's says that there is concern among the sales leadership in putting engineers in front of customers on this topic since it is an area where the company feels competitive pressure and wishes to control the messaging. He also asks Tony to see and approve the list of questions that will be asked during the study before recruiting begins.
Case 4: Get out!
Rachel, a UX researcher at an Enterprise software house, attends team meetings during which heavy technical topics are discussed. She decided to attend these meetings for several reasons which she explained to the R&D manager:
In the first few meetings Rachel attended, the R&D manager demonstrated a behavior that seemed very strange to her. About 3 minutes into each meeting the manager would turn to Rachel and tell her that she should not attend the meeting, that it’s not for her, and that she shouldn’t waste her time. Rachel asks to speak with the R&D manager to discuss his concerns.