"Why do you need to know that?" A team member sighed in response to my question about the organization.

As a Designer new to a large project, I asked the team many questions. People were initially receptive to getting me up to speed with the project, but I might have gone overboard with questions. As a result, the attitude of meetings shifted from "Let's help UX understand the project" to "Here comes the UX person to bog down our meeting with questions."

However, asking these questions is crucial to understanding one crucial factor that's often hard to address: Why are you doing something? Understanding the "Why" of a project is crucial to make sure that you're designing something that suits business and user needs.

The reason for this is simple: the "Whys" should never change. What you design might constantly change. How you should design something also changes as you learn new things throughout the process. But the "Whys" should be static, as they're often tied to the overall project goals.

Repeatedly asking "Why" to everything, though, can be tiring for both your team and your users. These "Whys" can also slow your meetings to a crawl if you're not careful.

So here are seven tips you can use to help uncover "Why" with your stakeholders and users more efficiently.

Asking "Why" for stakeholders

Think about outcomes or behavior changes for stakeholders

One of the more challenging things to do in larger organizations is to convince your stakeholders why it's necessary to know the larger picture. If you ask about things like "business goals and measures of success," sometimes the response may be, "Why do you need to know that? You're just doing the design."

One thing that can help with this process is to ask them to visualize outcomes for the project or what behaviors they want to change.

Ask them to imagine that it's the end of the year, and they're trying to convince their boss that they should get a big bonus. In what areas do they want to prove that they moved the needle with this project? Thinking about this should help them get to the underlying "Why" more quickly.

However, addressing "Why" for many of these questions isn't easy for stakeholders to answer in real-time. As a result, you may want to consider off-loading many "Whys" to e-mails.

Consider asking Why in e-mails or private conversations

Sometimes, asking Why can feel like putting people on the spot. What may be the best-case scenario for Designers, where a troublesome "Why" turns out not to have a good reason behind it, can often feel like you're throwing stakeholders under the bus.

You might want to consider off-loading these questions into more private settings, such as individual e-mails or direct messages, to make sure that you're able to understand things without slowing down meetings or addressing things in public.

However, there is something else you might want to consider if you've run into a snag: the Five Whys method.

Try the five "Whys" method after crises or complex problems

If you and your team have run into problems or have encountered a crisis, one helpful thing to do after addressing the immediate problem is the Five Whys method. Eric Ries, the author of The Lean Startup, developed this method to see out the root of the problems that often occurred.

He found that while some problems start with technology or organizational processes, some part of the problem comes from human-level processes as you dig deeper. These are often problems that UX can often address.

One typical example is user training. For example, the problem might be that "organizational metrics" are often inaccurate with a particular application. But as you peel back the layers, you might find that there isn't an automatic way of capturing these metrics: instead, managers have to input them manually. What's worse is that there aren't any instructions about what these metrics mean, which means that managers interpret the labels and categorize them as they see fit.

This is something that you can uncover and help address within your designs. Getting to this root "Why" is at the core of design thinking, which is understanding the problem you are addressing with design.

However, what is equally (or even more) important is to uncover the "Why" regarding what users do and say. It can be tricky to delve deeper into interviews without seeming like an interrogation. Here are a few ways to ask "Why" in your user research without overwhelming them.

Asking "Why" for users

Use think-aloud protocol questions with moderated research:

Regardless of what user research methods you use, you should spend time asking specific questions that reinforce the think-aloud protocol if you're doing moderated research.

While users might not have all the answers, asking think-aloud follow-ups to user actions or statements is often a great way to uncover why users think the way they do.

Some examples of these questions include:

• "I noticed that you clicked on X button. Could you tell me a little bit more about why you did that?"
• "Can you tell me what you're thinking at this stage?"
• "Are you looking for anything in particular?"

In addition to just providing deeper research insights during user observations, these questions also have the highest success rate of reaching into "Why" users are doing or saying something.

Follow-up questions to perceived usability tests (SEQ, SUS)

If you're using tests like the System Usability Score (SUS) or the Single Ease-of-use Questionnaire (SEQ), this is an excellent point in time to ask why this was the case.

After glancing over how they responded, you can ask a simple follow-up:

"Why did you give X the score that you did?"

Having the user quantify usability or ease of use means assigning a particular value or grade to your application.

There tends to be a reason why this is the case. Make sure you take this opportunity to ask why this is the case, as following up with this often can bring about additional insights that might have otherwise been hidden.

Gather context around how a product will be used:

One way of understanding the larger picture and building rapport with the user is to understand how this application will fit into the user's overall workflow.

A user who likely uses the application first thing in the morning, when they're fully caffeinated and with little time pressure, will be a little more forgiving of errors and frustrations.

A user squeezing in using this application in the afternoon, between workloads and talking with customers, is entirely different.

If users don't seem fully invested in a product design, ask why: perhaps something in the larger context is missing.

Some of the most informative user interviews have come from the user explaining how they're accessing your application in the first place. Sometimes, the process to open your application requires going through several lengthy steps: as a result, they might not be in the mood to do it very often. If that's the case, you might need to prioritize something like efficiency or ease of use with how you approach things.

Hypothesizing with your observations and alternative designs

Lastly, it's essential to have an established process for thinking about patterns among participant observations. For example, you might see all of your users skipping straight to the search bar instead of messing around with navigation. Many of them explain that they don't find navigation helpful when asked about this.

It's easy to draw a simple conclusion from that: we need to fix navigation somehow. But stop for a moment and consider the "Why": Why do users prefer search over navigation? In some cases, this might be the optimal approach. For example, if we were Amazon, we would want users to use the search bar instead of navigation because it's easier to find specific products.

What can be helpful is creating hypotheses to consider different design solutions. This can help inform alternative designs we might want to user test and figure out why users might take these actions.

For example, these are hypotheses we might want to explore from those user findings:

• We need to improve navigation so that users can find things through navigation instead of having to resort to search
• We should lean into our user's preference for search and test a design that emphasizes it on the home page
• We should look at common search terms and rename our navigation headers to make it easier to navigate

We might consider several design alternatives when we think about these hypotheses, which we can user test. In that sense, we're using the "Why" to uncover if we need to improve navigation or emphasize search more.

Understanding "Why" is tricky but crucial

Most of your time on projects will likely be at the "How should you design something" level. However, understanding "Why" a user or stakeholder does or says something can be crucial in making sure you design the right thing.

The reason for this is simple: at its core, design is about problem-solving.

Design does not exist for design’s sake. Design is about problem solving. — Jon Wiley, Director of Immersive Design at Google

Taking the time to uncover the "Why" is the crucial step you need to take to transform your designs from something decent into something that directly addresses your user and business needs.

So if you feel like you're trying to understand "Why" something is the case and are running into resistance from stakeholders or users, try out these tips. These small changes can

So if you've ever encountered resistance when you've gone to ask Why certain things are the way that they are, try using these tips to help you uncover Why. This will allow you to create a better UX product.

Kai Wong is a UX Specialist, Design Writer, and Data Visualization advocate. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.