How to standardize user research in your organization
If you’re in the process of democratizing UX beyond the boundaries of your own UX team, and equipping other people in the organization with the skills to run their own research, standardization can increase efficiency and helps set expectations of what’s involved in a user research project.
However, when departments are uncoordinated, or outside resources get involved, it’s tricky getting everyone to stay within a set of boundaries or to follow a strict UX plan. To complicate matters further, no two projects are exactly the same.
So, how do you standardize the user research process?
As part of our ongoing series where we ask a variety of industry experts their advice on overcoming the biggest UX research challenges, we asked Sr. UX Researcher Samantha Alaimo from GrubHub and Michael Mancuso, Director of UX, Digital Education at Wiley, for their recommendations on getting everyone in the UX team and throughout the organization onboard with a standardized research process.
Everything you need to integrate user research into product development!
Here’s an exclusive collection of content tackling the number one UX challenge – getting user research into the product development process.
This free-to-download bundle contains all the following resources:
- How to include user research in early product development
- Democratizing UX: how to spread user research education and insights throughout your organization
- How To Run Research In Agile Sprints By Democratizing It Across Teams [ebook]
- How to Run User Experience in Agile [on-demand webinar]
Make the research and testing process “approachable”
Samantha Alaimo, Sr. UX Researcher | GrubHub
“It is tempting to create a document or a proposal template and say “anyone with a research request – fill this out and submit it”. Whenever I have done something like this, typically a lot of the submitted questions need to be reformatted and usually entirely rewritten from a researcher’s POV.
I have found it most useful to create a proposal template that is filled out in a meeting with the requester and myself. So we still have a formal proposal doc, but I have been able to work with the stakeholder to tease out the real wants and needs and propose realistic methods and timelines.
This also allows research to be approachable – it is a lot more likely for someone to put time on my calendar to talk about an idea than fill out a doc about something that they aren’t sure about.
One of the best ways I have found to get product to pay attention to research and think of research as actionable is putting a table in the last slide of my presentations. It’s a table with all of the frictions and pain points the users experienced with a column for whether it is being addressed in the current product roadmap or not, and if it is, a column for a link to the roadmap item.
This allows product owners to know what is being worked on and what still needs to be added. This is really successful because it holds the team accountable (no one likes to see an unchecked box on the checklist) and gives people a chance to ‘show off’ the good work they already have in progress.”
- Make sure you have one-to-one time with the requester, and draft the proposal in conjunction with them
- This will help surface actual wants and needs and help you both propose realistic methods and timelines
- This will also help make yourself, and the research process, approachable – which will encourage more interaction and face-time throughout the journey
- Convince product teams by highlighting current user pain-points in your presentation, and whether these are being addressed in the product roadmap
- Holding the whole team accountable for the user experience, can encourage progress and ensure you’re all on the same page
Make your research process the “product differentiator”
Michael Mancuso, Director of UX, Digital Education | Wiley
“As Director of User Experience Research & Design, in addition to guiding the UX Design of our products, a big part of my mandate was spinning-up an effective research practice.
Upon setting foot in the door, it was clear there was a latent appetite for validation of our hypotheses across the company, but no formal mechanism in place to do so.
From the firehose of user feedback and feature requests, which features were the right ones to work on next? Early on in my tenure, if we asked five different people internally that question, we might get ten different answers.
Research was a shared goal in theory, but it had been conducted in fits and starts. From ad hoc focus groups to third party vendors, research was a nice-to-have with no real process or owner.
The product team recognized the need to put structure around our roadmap prioritization and research practices, and codify the UXR mindset into the product org. We needed to be consistent about validating our assumptions with a small, representative segment of our users in order to move forward in an informed way.
Our sales reps are out in the field every day talking to instructors and collecting a ton of feedback, recording areas of interest for each instructor they meet. We wanted a way to utilize the valuable insights and interest in the marketplace effectively for our product team.
In a process devised with our sales reps, we sourced instructors that had been entered and annotated within Salesforce according to their areas of interest (or consternation). Then, when Product wanted to validate a particular user problem, we’d start by gathering relevant quantitative and qualitative data from our product instrumentation such as MixPanel or Looker, followed by reaching out to specific instructors or students early in the process. We organized small groups, ideally four to seven people for focus groups, or perhaps five individual one-on-one sessions as a representative sample.
Keeping the process simple, cheap and effective was critical to indoctrinating it across the org. We used low-fidelity tools such as spreadsheets to capture and collaborate on managing focus group and 1:1 call details, attendance, feedback, and track honorariums. We wrote simple scripts and practiced walk-throughs. We also used ZOOM video call software to conduct focus groups remotely and record those calls as well as to give control to participants on the other end when testing a prototype. And of course we first used Sketch and Invision to create our prototypes, and later Figma.
Basic research is about talking to users, and you shouldn’t need much more to conduct effective research than the standard tools of the trade.
Soon after, Product, Engineering, Sales and Data Science became more or less “addicted” to UX Research, which finally generated the political capital and groundswell to make a hire of an experienced Senior UX Research Lead, who immediately added a whole new dimension of acumen and structure to the process, utilizing her training and experience to develop testing protocols, training our product team to avoid bias and report results in a concise and usable way.
In addition to targeted, problem or feature-based research, we put in place surveys to establish baseline metrics throughout the semester. From then on, our UX lead was in extremely high demand.
While any UX Researcher worth their salt will tell you that you want to keep your research activities pure and free from the bias of sales motives, a happy by-product of this partnership with sales for sourcing research candidates is that our research activities are the single most effective tool in converting a skeptic to an evangelist.
Leads that participated in research would overwhelming convert to users — and it’s clear why that’s true. Users that participate in UX research feel more invested in the shaping of the product. They feel good about the responsiveness of a company that listens to them, and responds to their feedback, and good about that company’s products as a result.
Our research and customer service practices generated praise from our instructors as a true differentiator in our market.”
- Research will never be a ‘shared goal’ if you’re only doing it ad-hoc and with multiple third-party vendors
- Put structure around your roadmap prioritization and research practices, and codify the research mindset into the product org
- Be consistent about validating assumptions with a small, representative segment of your users in order to move forward in an informed way
- Utilize the valuable insights gathered by sales teams as they are in the field every day, talking to customers
- Enter those customers into your CRM, group them by areas of interest, then use them to focus group a relevant user problem
- Partnering with sales for sourcing research candidates helps position research activities as an effective tool in converting skeptics to evangelists
- Keep the process simple, cheap and effective – basic research is about talking to users
When you have executives “addicted to research” you’ll have buy-in to hire senior UX leads
We recommend testing different ways to approach a new project and refining your process over time. To start out, are there things that need to be done for every project, every time? Does your company already have a way to capture and track steps like those?
Use our experts’ suggestions to get started and then adapt as you find what works best for your unique team. Your process should grow and evolve over time.
To better understand the current culture of user research and UX in enterprise organizations, download our latest State of UX in the Enterprise report and discover all the data, trends and insights that are most important to UX teams right now:
Christopher is the Content Marketing Manager for EMEA, which basically means the skipper of the good ship ‘UserZoom blog’. So far his requests for changing its name to the ‘USS-erzoom Blog’ have been rightfully denied. In his spare time, Christopher is a filmmaker and the editor of wayward pop culture site Methods Unsound. He used to be the deputy editor of Econsultancy, editor of Search Engine Watch, staff writer for ClickZ and features editor of CMO.com.