Discovery 101 — When You Don’t Know What You Don’t Know
When we set out to build a new application, we typically begin with our Discovery/Research phase.
“Research” always sounds like a good idea… but what does it actually consist of? And why do we do it? Can you do it wrong? What tools and techniques should you use?
Let’s look into this a little and use some examples from our work at Theory and Principle to help share what we’ve learned about doing valuable user research.
What is Discovery?
When we’re starting a brand new project, we approach it from the mindset of: we don’t know what we don’t know. Typically, clients have an idea of what they want to build or the problem they’re trying to solve when we start on the project, but we want to make sure to address two key elements:
- What critical assumptions are we making and are they correct?
- What unknown context, details, issues, etc. contribute to separate not just what matters to our users, but what matters MOST.
Before a product exists, all of our ideas for its value and function are in fact just guesses. Or “assumptions” if you want to sound like you know a little bit more like you know what you’re doing. A key part of discovery should be to consider the assumptions that if wrong or impossible challenge the entire nature of the solution, then find a way to figure out if that assumption is true or false. For example, we were beginning an app to help users fix common legal issues from their smartphones, but it required users to be comfortable providing the app with personal identifying information. We validated this foundational assumption early by interviewing users and sharing images of basic wireframes to identify what would be required (e.g. logos of partners, encryption, etc.) for them to feel comfortable sharing that type of information.
Not understanding the difference between what matters and what matters most to users is one of the most common downfalls in product development. Any product should have a core function or a central job it helps a user accomplish. All the other little secondary functions and features might matter a little, but if your recipe app doesn’t have easy to understand recipes of things you want to make, it won’t matter how well you executed the “share to Facebook” feature or how pretty your monthly newsletter looks. A good discovery effort will help you understand your users, what they’re trying to do, and what matters most to them.
How do you do it?
There are a myriad of methods you can use on a project, and while there is no firm right and wrong, some techniques will be more effective given your needs. It can be helpful to consider two key questions:
- What vs. Why: Are you trying to learn what people do (what steps do they attempt first, what actions do they take), or why they do it (the behaviors, beliefs, and values that guide their actions)?
- Broad vs. Specific: Are you looking for a base understanding across a broad area, or do you need to get clear answers to specific questions?
When these two axes are combined, we can see a map of some different research methodologies and where they are best suited. While there significantly more than even this map below shows, we’ll focus on 3 of our most common methods we use at Theory and Principle.
- Online Research (Google, YouTube, reviews, etc.)
- Qualitative Interviews (1:1 conversations with users)
- Screen-Share Prototype Testing (e.g. watching user operate prototype; could be live, video call, or unmoderated recordings)
1. When you need to quickly learn the basics of an idea: Online Research
T&P Example: Before partnering with a tax-credit syndication organization to help identify opportunities to use technology to improve their business processes, we needed to understand the world in which they lived. Using Google and YouTube, we were able to expand our knowledge beyond keywords and phrases to more deeply understanding some of the specific challenges their industry was facing. Then, when we began to interview members of the organization, we were able to have significantly more in-depth conversations, and not waste valuable time asking for definitions and explanations.
An oldie but a goodie: just start googling. Every single project we start begins with just some good ol’ fashioned crawling around the internet. Look up news articles, competitive companies, examples of your project in other markets, industries, or regions. Read online reviews, find blog posts, just see what the world is saying about your idea.
The name of the game here is breadth over depth. You’re not looking to answer every single question or become the world’s foremost expert, you’re trying to just get that quick sense of the world around your product or your idea. This is a great way to get up to speed quickly and get a sense of the players and words in your topic.
Pro-Tip: Start typing “[my product/problem] vs.” into your search bar and see what it autocompletes. This is a great way to find out about typical comparisons you might not have known about. For example, maybe you know about TurboTax, but not its competitors; typing “TurboTax vs.” suggests “H&R Block” “TaxAct” and “an accountant.”
2. When you need to learn about context and key problems: Qualitative Interviews
T&P Example: In order to help overhaul a 10 year old UI for a large contract lifecycle management tool, we needed to understand how the tool factored into the contract manager’s life and business process, and the key problems and frustrations they were facing while using it. We interviewed about 20 users and implementers who helped train new users to develop a series of design and functional principles for the new UI/UX.
Qualitative Interviewing is really just a fancy term for “talk to people.” This can be in person, over video chat, or simply on the phone, but is an invaluable tool when you’re not quite sure where to start with a project. It can be anywhere from 20–90 minutes long depending on the topic and how much you need to cover. It’s typically a fairly free-flowing conversation, but with a few questions and areas of discovery you’ve prepared ahead of time.
The key to this process is being a great listener. Your job is to ask a series of open-ended questions that encourage your interviewee to share specific, in-depth information about the topic and their experiences.
Pro-Tip: My favorite follow-up question during an interview is just silence. Especially if you’re asking tricky questions that users might have never considered before, giving them a beat or two after they finish responding will often lead to a valuable “actually, you know what!…”
3. When you need to see how your idea would work in the wild: Screen-Share Prototype Testing
T&P Example: When building an app to help users resolve common legal problems from their phone, we needed to see if users could successfully navigate our app with no one there to help them if they ran into problems. We created a clickable prototype with InVision and used an online testing platform (Userlytics) which recorded the video and audio of a person trying to use the app.
Any idea sounds great if you have someone enthusiastically pitching you. And any app works perfectly if you have someone explaining it as you go. But the real world doesn’t work like that; users are going to be introduced to your idea and try to use it without you there. While this can be a scary prospect, it’s incredibly valuable in getting true feedback on what’s working and what’s not.
The key to this process is not to be too precious. Build as little or as simply as you can to test the main concept. Use an online testing platform to create a series of tasks (e.g. “try to change the language from English to Spanish”) or ask users if they understand a certain page (e.g. “what do you think clicking ‘take action’ would actually do?) and take a peek into the mind of a user when they’re actually interacting with your app. Where do they get hung up, what did they instinctively try that didn’t quite work? How could you better coach them to do the correct action?
Pro-Tip: Often people in these platforms are somewhat trying to please and trying to be successful. If you ask for a simple “how was the experience” at the end of the flow, you’ll likely get some empty praise. Instead, ask something like “which was the most confusing part?” or “where did you get hung up the most?” to drive more critical feedback.
How to make sure your research is useful
If you only remember one piece of advice, remember this: all the research won’t matter if you can’t find a way to communicate it to the rest of the team or the client and help them understand not just what you’ve learned, but why it matters.
Good research is as much about finding great insights as it is sharing them effectively.
When thinking about how to share what you’ve learned, don’t make the mistake of sharing every single little detail; focus on the highlights, using the details to back them up (if necessary).
Below are some examples from a recent discovery effort before building an application to help users who have their driver’s license suspended.
Some Parting Thoughts About Research
A few tips for success:
- Before diving into it, think about (or write down) the questions you need to answer and consider the various ways you might be able to answer them.
- Don’t worry about figuring out everything. Figure out what matters most, then go from there.
- Share early results with your team. If you’re having a hard time selling them on an insight, it’s a good sign you need to do either more research, or more work on figuring out the best way to tell the story.
- Be willing to ask questions even when you’re not sure what you’d do with the answer yet. Good research focuses first on getting all the data, then worrying about making sense of it.
- Just get started! I promise things will start to be clearer once you start. Being comfortable with ambiguity and confusion will make you an infinitely better researcher.
