I started developing these frameworks several years ago and have since whiteboarded them hundreds of times, each time followed by a series of Ah-ha! moments. These frameworks (which started out as my own, Ah-ha! moment) have since become my trademark. I now share them with you to help you out in your discussions with colleagues about Research.

This article is intentionally meta. I’m taking a high-level view about how to approach User-Centered Design, and not how to execute User-Centered Design Research.

The User-Centered Design process ideally starts with understanding your audience, what problems they have, and then what solutions will meet their needs. Each flows linearly from one to the next and generally looks something like this:

The problem is that all too often, even seasoned tech professionals start with the solution in mind, and then go back and reverse-engineer the audience and the problem to fit the solution.

This makes good research difficult because it’s not based on an understanding of who the user is and what problems they have.

Grad School: Day 1, Class 1: Qualitative Data Analysis, Lesson 1: Understand your audience. Know your user. Understand your paradigm-the lens through which you see and interpret the world.

The only way to have an accurate understanding of a Solution you are trying to build is to understand WHO is going to use it and WHAT problem that solution is going to solve. Only then can you truly understand HOW to build the right solution for the problem.

Each aspect of this process has its own set of questions that it addresses and associated methodologies in order to answer those questions.

Understanding your Audience

Understanding your Audience is really about addressing the question of WHO your users are and WHY they do what they do. The focus is on the person, their current behaviors, habits, and practices. The goal of understanding your audience is to have empathy for them. Authentically understanding that these are real people with real problems that just want to move on with their day and not have technology get in the way.

From the corporate standpoint, understanding your users fosters users that love your brand and your products. The only way to get people to love your products is to understand them. Know what makes them do what they do and why they do it. What their values are. And then, see where they struggle. When they struggle to use technology or to get something done, we feel their pain too. We know it’s hard and then we create the best solution to their problems. The best solution lets technology get out of their way to make the process easy and effortless.

Understanding Problems

Understanding Problems addresses the question of WHAT the users are trying to do, WHEN they are doing it, and WHERE they are when they do it.

The goal is Utility, which is having the confidence that the problem exists and is worth solving. All too often we create problems just so we can fix them (hypothesized problems unconfirmed by data) or create solutions to problems that don’t really exist (which is probably the biggest waste of time and resources-I’ll discuss this quite a bit more, below).

Taking this a step further, by understanding Problems better, we also have to dig into understanding scenarios and context. Scenarios most directly address the question of WHEN users run into a particular problem. A good scenario explains what the user is trying to do, what information they have, what information or outcome they want, and then details either the current (broken) process or the new (desired) solution. Context is about WHEN and WHERE they are when they have that scenario.

Designing Solutions

Context also helps us design the solution because it grounds the problem in WHEN and WHERE they are. At the beginning of my career, context was all too often simply assumed. The user is at work. Or, they are on their laptop at home. But I quickly learned that context is actually very important. Being one of the first Researchers at Microsoft to conduct ethnographic research on how people use iPads in their homes, I learned just how important context is to understanding usage. People do different things on devices depending on where they are, who else is around, and how they are holding the device (Posture). Context is the term for all of these things, though for hardware projects, posture is also talked about regularly as an important part of context.

Solutions are typically the part that we are most familiar with. It’s the fun part that Designers love because Solutions are all about creating something new, novel, innovative, or useful. The role of research when it comes to solutions addresses the question of HOW. How does the user get from A to B in your app? How does this product help the user do what they are trying to do better than your competitors?

The level of HOW-or the FIDELITY of the solution-depends on where you are in the User-Centered Design process. You start out with an idea or concept. It might have a wireframe or low-fidelity design associated with it, or it might just exist in a textual description. From there, it develops into a higher-fidelity Design… and then a series of Designs which lead to a flow (which also invites Interaction Design and Motion Design to join the party). As the Design becomes more developed, there’s the role of prototyping and finally, starting to get real coded Designs.

I’m going to pause the discussion of methodology here and revisit it later. But next, I have something special.

The 2 x 2

Now that we’ve looked at how you approach research for your Audience, Problems, and Solutions, let’s look at this same idea another way, which breaks out the process further into known versus unknown problems and known versus unknown solutions.

Let’s start at the lower-left quadrant: Unknown Problems and Unknown Solutions. This is typically where you would start off if you don’t know what problems you users have or if you want to conduct research to see if there are any problems that exist that you don’t know about.

The key question to address here is: What problems do we not know about that should be on our radar?

And the best way to find out about those problems is to conduct explorative (or generative) research. For example, in an Ethnographic study, you go into people’s homes and learn about what they do, how they do it, what their goals and motivations are, and where they get stuck. With this data, you have a good sense of the important problems that need to be solved and you can graduate to the next quadrant.

In the top-left quadrant, you have identified some problems that users have that need to be fixed, but you haven’t yet found the solution. When you know what problems you’re trying to solve, you can focus your efforts on designing solutions to address those problems.

The great news is that there’s a proven method for finding solutions to problems that users have. It’s called the User-Centered Design process. You may have heard of it. This is the realm of design sprints, iterative user testing, concept testing, and as the fidelity increases, you get to usability testing. (I’ll discuss how to align methodologies to each part of the process in the next section).

After a few rounds of iterative design and research, you arrive in the top-right quadrant. You’re confident of WHO is having the problem, WHAT problems your users are having, and HOW to best solve their problems with a carefully designed and tested solution. You can then move forward with confidence in that solution. Hooray!

Of course, there’s still that last lower-right quadrant to deal with and unfortunately, that’s the quadrant that many tech companies (And thus, researchers) find themselves starting in: A known solution to an unknown problem. Or, as I like to call it: Solutions in search of User Needs.

Someone somewhere had a great idea of a cool use of a new technology or a nifty way to do something. You added your widget to your app and now, you’re well along the, “If you build it, they will come,” mentality of software development. And what happened? They didn’t come, did they?

Why didn’t people use your brilliant idea? Because people don’t use things they don’t need.

And that’s why you have to start with existing problems that you know people have and work on solving those problems first.

Ok, so what do you do as a researcher when you’re assigned a feature to conduct research on when you have no idea who your users are and what problems you have? You go back to the beginning and you start investigating WHO uses your product, WHAT problems they have, and then start designing solutions to meet their needs.

Can you do this in the same research project? YES :)

What does that look like? Typically, I would start off the study with a behavioral interview: understanding the key areas of frequency, duration, and importance. How often do they perform the task? How long does it take them? And how important is that task to them? From there, you’ll get a good idea of what your users are trying to do and where they get caught up in the process.

Next, I’d have a discussion around the key problems they face and how they have gone about trying to solve them… and where they would go to look for the solution. Then, we would talk about what the solution would look like.

This is the place that we can start introducing new concepts or potential solutions. They are a great way to aide the discussion of what a good solution looks like.

So, when you start off with the solution in mind: ignore it, focus on the user and their problems, and then return to it with an open mind. Your first solution is a starting point… a jumping off point for a discussion about what the solution could be, not what is should be. It’s important to be critical of all of your ideas and only keep the good ones.

After rounds of User-Centered Design, you’ll find that the first solution isn’t what you end up with. That’s because you iterate on it as you go, honing it down into the best solution you can find …. (for your target users for right now). Because of course, things will change and the right solution now might not still be the right solution 5 years later… or even one year later.

The answer isn’t Solution A or Solution B, it’s a little bit of A with maybe part of B and none of C, and then you put it all together to create Solution D.

That’s why it’s important to stay on top of balancing out Strategic research with Tactical research. Keep up to date with what problems your users are having to ensure that you’re always going after the right solutions to build first.

Aligning Methodology to User-Centered Design

Ok, now we’re ready to come back to User Research Methodologies and how to align them to each part of the User-Centered Design (UCD) process while keeping these frameworks in mind.

Each part of the UCD process takes you through many iterations until you finally get a full working-code-launched solution into your app, website, or platform. But how do you get there and where do you start?

The place where this goes awry is when you’re asked to evaluate a Solution without first understanding the User and the Problem that it’s supposed to address. You could spend a lot of time looking at the usability of a Solution only to find out later that it solves a problem that people don’t have or that your users actually have a way bigger problem that no one is solving (this, by the way, is why products fail).

This is why the selection of methodology is so important. Because each methodology addresses different parts of the process with greater (or lesser) success. Here’s a conceptual, non-exhaustive, way of looking at aligning methodology with my Audience/Problem/Solution framework:

If you want to understand WHO your users are (Audience), the best way to start is to talk to them. You can talk to them in their homes (Ethnography), in the lab (In-Depth Interview/IDI), or together in a group (Focus Group). These are qualitative methods for understanding users. Quantitatively, you can use Surveys or look at User Feedback (if your product is already released). If you put all of these together, you get a pretty good picture of WHO your users are and WHAT problems they have. However, this isn’t really the place for a Usability test. Ethnography is good for looking at unmet (“Latent”) needs, but not for determining whether users can successfully find the button.

Once you get further down the User-Centered Design process and you have a good idea of the problems that your users have, then you can start the iterative process of honing in on the best solution through Concept Studies, Prototype Testing, and Usability Testing. You can also learn about problems over time though Diary and Longitudinal Studies. As your solutions get more and more solid, you can start qualitative Benchmark Testing or quantitative A/B testing.

As an example, in what I lovingly call the, “Franken-study,” (Thanks to a former manager), you can always start out a lab session with an interview, move on towards concept testing, and then conclude with usability. But, notice that the order here is important. You have to understand who the user is first (Interview), then understand their problems (Concept testing can help you see which problems resonate the most and direct you towards solutions), and then finally evaluate a solution (Usability Testing).

Taking it Further

The goal of this conceptual framework is to help you evaluate where you are in the UCD process. Once you have a good idea of where you are in the process, it’s much easier to select the right methodology. An important step, however, it to ensure that you are very candid with your stakeholders about which quadrant you’re in. I’ve had a lot of success talking about these quadrants with other Researchers, Designers, PMs, and even Engineers. You can use this 2x2 to help align on where you are in the UCD process and then use it as a talking point to discuss what types of Research and Design activities need to happen next to continue along the path of creating the best solutions for user needs.

Another way you can apply this framework is to put all the features that you’re being asked to test in each respective quadrant based on where they are at. If it’s a solution in search of a user need, then it sounds like it’s a good idea to plan some exploratory research to see what problems your users have. If you have a good idea of what problems exist, then it’s time to partner with your Designer and plan some design sprints and iterative testing to hone in on the solution. And, if you are confident in your solution, but just need to ensure it’s as good as it can be, it’s time for a usability test.

In the end, it’s solving people’s problems that matters. People only use software when it solves a problem they have and by listening to them and observing them, we can better prioritize their key problems so that we can create delightful experiences that make using technology so effortless that they can focus on what they are trying to do and not just trying to figure out how to use the technology.