Building Research Panels
USER RESEARCH
Background
Two years ago, I conducted user research for a secured messenger application as the sole designer. The product was being developed using an agile methodology, and I had tight deadlines without a generous research budget.
To begin, I sought approval from multiple levels within the organization and then reached out to internal users. I first rolled out the application internally to employees to test and gather feedback. For actual customers, I recruited users from the existing user-base and used any available budget for incentives.
My chosen path was to build RESEARCH PANELS
Identifying users
First step Customer support team
We were curious about the identity of the messenger application's customer. Unfortunately, our data didn't give us much insight into their profile. All we knew was how much they paid, the size of their team, and the duration of their business relationship with us. We wanted to dig deeper and learn about their daily challenges, job responsibilities, and what they valued most.
Initially, we were daunted by the prospect of recruiting participants for our UX research. However, we eventually realized that the best approach was to reach out to customer relationship managers (CRMs), given our understanding of the company's structure and client base. This allowed us to keep track of contact information, progress, and communication and add notes and attachments.
We compiled a list of managers who could help us access their team members for the research session.
Next Survey to understand user types
Demographic data
From the CRM data
In-product survey
Short survey = High response rate
I conducted a mini survey to gather information about user types and understand the Net Promoter Score (NPS) as a way to capture quantitative data. NPS surveys are a useful tool to obtain customer names. Additionally, I obtained some information from in-product surveys to recruit participants for my research panel.
My survey covered a wide range of users and based on the gathered information, I compiled a list of customers and end-users who could potentially become part of my research panel.
-
Customers who are end users and who use the product frequently
-
Customers who are end users and who don’t use the product frequently
-
Customers who are purchase decision makers
-
Important customers from companies who bring in a lot of revenue
-
Customers who fall under the “Promoters” NPS category,
-
Customers who fall under the “Neutral” NPS category
-
Customers who fall under the “detractors” NPS category
-
Customers who have joined recently
-
Age
-
Geography
-
Department
Version 1
Version 2
Next Reaching out via emails
After receiving multiple levels of approval, I had the opportunity to write emails to the managers. In these emails, I explained who we are, what we are looking for, how we can assist them, and how much time we would require.
Email iterations:
We crafted 3-4 iterations of an email to convey information concisely, considering the different types of users and their roles. To ensure clarity, we used plain text and kept the content simple. We included their names in the subject line to establish a personal connection and grab their attention.
.jpg)
Building a research panel
At this point, we realized the necessity of implementing a system to engage with our customers and gather data regularly.
Why opt for a research panel?
-
Allowed for greater insight
-
Provided better response rates
-
Helped in data-driven decision making
-
Easy access to research participants
-
Provided continued engagement
-
Amazing recruitment cost savings
-
Demonstrates a “we care” attitude toward customers
Pre-interview preparation
I collaborated with PO and a technical writer to create guides and necessary materials for the user interviews. To prepare for the sessions, I conducted research on the participants and had meetings with customer relationship managers (CRM) to gather previous feature requests and NPS survey comments. It was important to be well-prepared and informed for the interviews.
After the session
-
Sent thank-you notes to participants within 24 hours of each session.
-
Quickly relayed key feature requests to the product team for immediate action.
-
Reviewed session recordings to capture any missed insights.
-
Shared key takeaways and participant-specific notes with the team after each session, along with early access to the recordings.
-
Spent a focused week compiling the final report, allowing the product team to act swiftly without waiting for full documentation.
What did I learn
-
The term “panel” often worries users due to the perception of lengthy sessions.
-
Customized emails and CCing me on invites improve response rates and save time.
-
1:1 sessions worked better than focus groups, which were often dominated by vocal participants.
-
Managing the panel was time-intensive—some participants became irrelevant over time.
-
I kept engagement high by sending regular product roadmap updates.
-
Initially, CRM resisted the idea. I gained their support through persistence, flowcharts, and leadership discussions.