The right question, at the right moment and context, can make a significant impact on how a feature / product is going to end up.

When I was starting out, I could not understand why designers weren’t taken seriously by companies when it comes to high-level decision making for products. I worked in several startups and the attitude was more or less the same — after the management team defined the path and solutions we need, they came to the design department for the “candy look”.

A couple of years later, I understood that if we change the conversation from “Ok, I will get right on it” to “Sure, but what business problem are you trying to solve? Will the change achieve the goal?” it changes how things are perceived. Asking the right question will only make you a better designer and will help you to have a proper business conversation. And with time and patience, you start getting that seat at the table.

Asking the right question, at the right moment and context, can make a significant impact on how a feature / product is going to end up.

A couple of years later, I understood that if we change the conversation from “Ok, I will get right on it” to “Sure, but what business problem are you trying to solve? Will the change achieve the goal?” it changes how things are perceived. Asking the right question will only make you a better designer and will help you to have a proper business conversation. And with time and patience, you start getting that seat at the table.

Defining the problem

Never accept a problem at face value. Instead, try to find what the real problem is — the problem behind the problem — by asking a few questions:

• What’s the main problem we are trying to solve?

• Is this the right problem to solve?

• Is it worthy of our best efforts?

• What other problems could we solve that would bring more value to our company or customers than this one?

Important: What will be the impact on your business if we don’t redesign/change the ____? Let’s say we leave it like it is for the next 1–3 years.

This question is critical to answer after you have defined the problem. I had a client who told me that nothing could go wrong, because he would not allow it. That’s a sad and unpractical way of looking at things. If you don’t know what could go wrong, than how would you know when it’s not wrong? Also,this allows you to see if you really need to focus on that issue or not.

Validating the problem

After we discuss the problem in general terms, now it’s time to put some practical KPI’s behind it and also align with the business goals and stakeholders.

• What are the business goals?

• Which business goal(s) will the problem solve?

• What do the stakeholders think about the idea/project ahead?

• What are the measurable KPI’s for those goal(s)*?

• What is the value of those goals to the business? (it may be money, more time to do N things, etc)*

• How will we know when we achieve the main goal(s)?*

• Are there enough resources for this project? What if we go extra, will there still be enough resources?

• What are the risks and problems we have to overcome?

• Have you taken into account the opinion of all other departments which will be affected by your end product/feature/UI change

Important: *for those questions we use a table (below) that allows us to have a tangible view on what we are solving, the metrics behind the goals and the impact it will have on the product/company overall.

Defining the thinking model of your users

After you define the problem, make sure you speak the same language as your users do. It is important, because without a proper alignment the project may end up in a different direction.

• What do users think when doing their tasks?

• How is their thinking process structured?

• How do you structure the problem so when you speak about it with your users, they are thinking about it in the same way?

Getting to know your users

Here the question will depend mostly on the industry you are in and who is your core user. But as a general rule, you have to know all the details of how a day in their life looks like (whether at home or work). Any small detail can make a difference on the end result.

For example, let’s say that we design an app for restaurant owners. The app should allow them to manage their business better. In this case, you have to know:

• How does a day in their work life look like?

• How do they refer to different processes they do?

• What are the different steps they go through when ordering food?

• How do they manage their inventory?

• How do they manage people/shifts/responsibilities?

• How do they manage customer complaints? What do they do about them?

Assessing if the design is satisfying or not

Our primary goal is to see if the KPIs we have set in the beginning can be achieved or will be achieved through what we have designed. After that, we should assess the design itself.

Important: it’s not productive and will not add any value if you ask questions such as: “Do people like drop-down menus?”. The right question to ask is: “Does this drop-down menu, with these words, in this context, on this page create a good experience for people who are likely to use this site?”

• Did it take the user an hour or a couple of minutes to do the task at hand?

• Did he have to stop everything while doing the task or was it something done subconsciously?

Important: when a person uses your product, don’t forget that a user shouldn’t spend time thinking about:

• Where am I?

• Where should I begin?

• Where there f* did they put _____?

• What are the most critical things on this page?

• Why did they call it that way?

• Is that an ad or part of the site?

And take into account that this is not a template, but rather a guiding list of basic questions which allows kickstarting a project or thinking process.