Nizar joined Snowflake as their first UX Researcher. Within a year, he has established an almost 10-person UXR team which is expanding as you read this.
He has been sharing his insights gained over a 15-year-long career on LinkedIn; dispelling UXR myths, sharing research career tips, interview advice, and portfolio presentation templates along the way.
I picked his brain on what it takes to build a UXR practice from the ground up.
This article summarizes his answers and offers some considerations for anyone in that initial, “setting-things-up” phase of building a UX Research practice.
When you start building out the UXR function at an organization, you will be joining an organization with existing processes that do not necessarily account for research.
You may not have enough (or any) buy-in from your stakeholders.
You won’t really even know who your stakeholders are.
The rest of the organization will have little context on what you do (as Joe Natoli told us).
Daunting, we know. During this first phase, you will set things up.
Your goals should include
Unless you’re a founder, you’re rarely coming into a fully clean slate, and there may be existing forms of user research and data collection already taking place — identifying opportunities through what exists today should be one of your highest priorities in the early days.
Before Nizar joined Snowflake, unstructured user research was being conducted by their Product Managers. They were talking to their users and trying their best to learn from them.
This was great — it signified that the organization was already eager to learn from the user, and Nizar saw the opportunity to formalize the feedback and help avoid falling into the trap of having an unachievable long list of feature requests which required a significant amount of engineering resourcing.
If your organization hasn't been running user calls, they may have been gathering data through analytics, hotjar recordings, sales calls or support tickets. Your first job is to discover critical sources of user insight in the company and make sure you understand how your organization currently receives and responds to user feedback.
Even if your organization had some semblance of research before you joined, going through these alternative sources would be a good idea. You might find insights that the product team missed.
Nizar reminds us that there is no “one-size-fits-all” solution to winning during this phase of setting things up. It’s helpful at this stage, therefore, to spend some time understanding the organization itself.
When Nizar joined Snowflake, he spent his time early on connecting with and listening to every stakeholder he could find. He’d suggest you do the same.
Some questions to think of when exploring and understanding the company:
If you were thorough during the previous goals, you will have an easier time with this one.
Nizar recommends prioritizing efforts with a clear path to impact and direct link to actionable next steps and success criteria as a great way to stack up on credibility, earn buy-in from your stakeholders, and build some awareness about the importance of research.
Your first few weeks shouldn’t be spent researching specific questions that some product managers happened to ask you. They tend to be specific (“Do our users use the ‘Explore’ tab?”), which limits the impact of their answers.
Instead, focus on problems that eager stakeholders have and show how research can solve them. They tend to be more urgent and impactful (“How do we reduce churn on the product?”) than simple questions.
Your organization will have stakeholders who would not need convincing of the importance of UXR. Nizar suggests solving their most pressing problems first, which would be the most effective way to cultivate some early champions for your cause within the company.
With these stakeholders on your side, you would have an easier time convincing the rest of the organization.
The first few problems you tackle should be ones where you can deliver a clear answer that can drive the organization towards its goal. When you take on a project, it should be very clear that when this research project ends, and what next steps would look like on the product side.
In the early days, it’s okay to not take on large, foundational studies that boil the ocean. Instead, Nizar recommends focusing on studies where you can draw the line between your findings and the organizational impact very clearly (and make sure you do draw that line often for your stakeholders).
For example, if your team is struggling to decide between two concepts for a new feature—can you help them evaluate those effectively with users? Can your research help them choose a concept that is more likely to drive user engagement/revenue/”insert key metric here”.
Start with minimal process—only as much as you need to get the job done. This lean approach will make it easier to get started and ensure that the project is impactful in a short amount of time. You can always professionalize (a real word) once you are past this phase.
💡 Secret tip: When starting out, get 15 free transcripts of Looppanel instead of investing in a repository tool, a screen recorder, an analysis tool, and a research assistant. We’re all of that rolled into a nifty product.
When you begin to build a research practice, make note of the following:
Each new place where you set up or improve a UXR practice will have its unique challenges, stakeholders, users, and goals. Instead of bringing over a set of rules from your prior experiences, focus on getting the context right and ensuring that you set things up in a way that works for your current workplace.
There are two issues if you start with big sweeping changes. For one, you wouldn’t have enough context on the organization to ensure that your changes will work. Additionally, you will run the risk of overpromising and underdelivering.
Nizar followed his advice at Snowflake. He started by solving the simpler research problems that had immediate impact, and eventually built up UXR credibility to the stage where now his team can undertake larger changes.
Even if you follow every little nugget of advice in this article, you should continue evaluating your approach as your team and work evolve. Speaking from his experience at Snowflake, Nizar tells us that what worked for him as a single-person UXR team is no longer the same as what works for his team as it approaches 10 researchers.
The same was true for when he went from a team of one to a team of three — your task will constantly evolve and it’s best if you keep up with it through constant examination of what works and what doesn’t.
In conclusion, don’t panic — the task in front of you is tough. So are you!
Here’s what you have to do:
Here’s what you have to keep in mind:
Professionalize is a word.
To hear more from Nizar, check out his LinkedIn page.
Looppanel automatically records your calls, transcribes them, and centralizes all your research data in one place