A well-designed product is one that users can navigate effortlessly — without requiring extensive guidance. Our commitment to testing designs with users and incorporating their feedback is a key reason our product is highly rated for its user experience.
Why should anyone invest in user research? Jared Spool has the answer:
At OpenPhone, my role is to understand our customers and what they’re trying to achieve with our product and communicate those insights to our teams. I also test our designs and features with our customers and share their feedback with the product and design teams.
In this article, I’ll share our approach to user research and specific examples where research has influenced our product — an approach informed by my 20+ years of experience as a user researcher at companies like Amazon, Salesforce, and Hopin.
If you’re a startup founder or product leader who hasn’t invested in user research yet or you’re a user researcher looking to compare notes on your process, then this article is for you.
How OpenPhone approaches user research
Our research approach supports the product team through different stages of product development, including:
- Understanding the “Jobs To Be Done” that our customers expect our product to fulfill
- Validating hypotheses related to product features as they’re being built
- Helping designers refine product concepts through iterative testing
When the product team requests a research project, we follow a five-step process to run the project and share our data with them:
- Design study methodology: Based on what we want to learn, we design a study that gets us there. If we want to study whether users can find a new feature in our product by themselves, we might design a remote usability test. But if we want to learn whether there’s a problem our product can solve that it doesn’t yet, we might design exploratory interviews.
- Recruit customers: Our recruitment process is tailored to the specific needs of each study, focusing on customers who represent the contexts we’re interested in exploring.
- Interview customers: We schedule and record interviews in Gong so we can surface insights from them later.
- Summarize interview findings: We try to find patterns across our study data we can distill into learnings for the product team.
- Share findings with the team: We share our analysis and findings with the rest of the team in Notion, which is where we manage projects cross-functionally.
Now that you know our approach and process for conducting user research, here are three examples of how research has directly influenced the OpenPhone product.
Custom call views: New feature creation
I worked with the Inbox team on a discovery research project to understand more about how our customers use shared inboxes and what they want from collaboration features in our product.
Discovery research is a type of research we undertake to understand problem and opportunity spaces for our customers. Zendesk has a great visual representation of discovery research in the product development process.
One of the things I learned through this project is the notion of temporal access. Our customers want to understand what has happened, what is happening, and what will happen regarding their contact with customers. Plus, they want to share that highly relevant context with their users in a way that can be digested and acted upon easily.
We also learned our customers want to know what they have to do right when they start their day instead of having to look around their OpenPhone workspace to find that information for themselves.
Based on this feedback, we’re working on product features that surface the right information for our users at the right time. One such feature: custom call views allow users to focus on specific activity types, like missed calls, that they can leverage like a to-do list and respond to customers quickly and efficiently.
Uploading contacts: Pivoting an existing feature
One specific study helped us rethink how customers upload their existing contacts into OpenPhone and changed our plans for future iterations of the feature. We learned that users were confused by the number of configurations that were needed to upload their contacts to our system via CSV.
Discovery research helps us identify opportunities for new features, and user research has also helped us find areas for improvement for existing features once they are released.
With that feedback in mind, we made the process much clearer for them so they knew which properties were essential and which ones they didn’t need to import into OpenPhone.
Inbox viewers: Uncovering a new product insight
User research also helps us uncover new insights we hadn’t considered with a product feature.
For instance, when we were interviewing one of our customers and studying how they navigated OpenPhone, we noticed they weren’t interacting with a new feature we rolled out called Inbox Viewers. The feature lets OpenPhone users see which team members have viewed a message or are in a conversation thread.
During our interview, we discovered our customer wasn’t interacting with the feature because it was grayed out and didn’t stand out in our desktop app. It didn’t draw the customer’s attention enough, and we realized this was a roadblock to feature adoption.
To address this, the product team released an update where we display each user’s avatar when they’re viewing a conversation alongside colleagues who have viewed the conversation before.
This improved feature discovery and provided teams with more transparency because OpenPhone users can see when their colleagues view a conversation. This small change doubled usage of this feature compared to our other collaboration features, in addition to a marked increase in users newly discovering it.
Get started with user research at any size
Whether you’re a tech startup or a young brick-and-mortar business, user research is essential to improving your products and services. Getting started with user research might feel intimidating, but it doesn’t have to be.
Start talking to your customers to understand their needs. Allow yourself to be surprised by what you learn vs. validating your assumptions. Let them tell you their stories uninterrupted. If you interject with your own biases, you’re preventing your customers from telling you what their needs are and how your products support or undermine them. Make sure you give them enough space to tell their stories and share their pain points with you, keeping the focus on them and not what they might think you want to hear.
If you’re looking for more insights to scale a product-led company, here are a few more articles to check out:
- How we scaled our support team to serve 58K+ customers
- How we think about product design
- Lessons from scaling a startup in 2023
