Updated: Mar 11, 2019
The ability to ask meaningful questions is a fundamental yet often overlooked skill in the UX Designer’s toolkit. I’ve begun to notice a clear correlation between the number of questions a designer asks throughout the process and the quality of the final design output.
It’s much more than creating, it’s about understanding your problem so well that the solution is obvious.
To understand the challenge at hand, UX Designers must ask great questions at every stage of the process. I’ve catalogued a robust list of questions (100 to be exact) that I’ve found to be useful for projects spanning industries, devices, and personas. While by no means comprehensive, it should provide a framework for design thinking through different stages of a project.
To align the delivery team and stakeholders around the vision and project plan, the big questions need to be asked. Avoid jumping to solutions, instead focus on the underlying problems and insights that can give the team foundational knowledge to design from later.
What is the problem or need we are aiming to solve?
What does the product need to do?
What is the business opportunity? (e.g. acquisition, activation, retention, revenue, referral, etc.)
What are the Key Performance Indicators (KPIs)?
How else will we define success for this project?
How does this product fit into the overall strategy?
Who are the users or customers?
Why is this important to them?
Why do they care?
What are the users trying to do?
What are their pain points?
How can we reach users through this design process?
Are there any constraints (technological, business, etc.)?
How are we better than our competitors?
Are there any relevant products we can look at?
Who are the primary decision makers on this project?
Does any relevant documentation exist (personas, user flows, etc.)?
Do brand guidelines exist?
Does a style guide exist?
Further understand the business and market by speaking with individuals who who have a vested interest in the organization and the project. Many of these questions can be asked during kickoffs, but if asked individually they can yield better answers.
What is your role in this project?
What is the one thing we must get right to make this project worth undertaking?
How will you, personally, define success for this project?
What is the role of this project in achieving that success?
What are the goals you need to achieve from this project?
What have you tried that has/hasn’t worked?
What went wrong in that case?
Who are the biggest competitors and what worries you about them?
How do you expect to differentiate this product?
Where do you want the product to be in the next year, 5 years?
What keeps you up at night with regards to your users?
What assumptions do you think you are making about your users?
What do you know for sure about your users?
What are the most common problems your users face?
What worries you about this project?
Avoid the risk and expense of creating something users don’t want by first understanding their goals and pain points. Answers to these questions can give you the all-important “why” behind user behavior. These are best supplemented with observational findings (what users say and do can be different) and analytics if they exist.
What does your typical weekday look like?
Tell me about your role at your company.
What are your daily responsibilities?
What are some of the apps and websites you use the most?
How do you currently go about [problem/task]?
Are you looking for a solution or alternative for [problem/task]?
Tell me about the last time you tried to [problem/task].
What are you currently doing to make this [problem/task] easier?
Have you tried any work-arounds to help you with this?
Have you tried any other products or tools?
If so, how did you hear about them?
What’s the most frustrating part about [problem/task]?
How often do you encounter/perform [problem/task]?
How long do you spend on [problem/task]?
Validate your assumptions and improve the experience by watching real users interact with your prototype or product. While this is to mostly gather qualitative feedback, there are opportunities to supplement these findings with qualitative answers (e.g. testing against success metrics).
What is your first reaction to this?
What is going through your mind as you look at this?
How does this compare to your expectations?
What can you do here?
What is this for?
Do you have any questions right now?
Why would someone use this?
How do you think this is going to help you?
What is the first thing you would do?
If you wanted to perform [task], what would you do?
What would you expect to happen?
What parts of this were the most/least important for you?
How could we present the information in a more meaningful way?
Is there anything you would change/add/remove to make this better for you?
What was the hardest part about this?
Was there anything surprising or unexpected?
On a scale of 1–5, how [adjective] was this?
Would you use this today?
What might keep people from using this?
What is the most you would be willing to pay for this?
What, if anything, do you like or dislike?
If you had a magic wand, what would you change?
Does this feel like it was designed for you?
Is anything missing?
What adjectives would you use to describe this?
On a scale of 1–5, how likely or unlikely would you be to recommend this to a friend?
Since this isn’t finished, what would you like to see in the final version?
Conducted with fellow designers or the larger project team, design reviews can ensure the “whys” behind design decisions align with user and business goals. Ask these questions to better understand how a designer arrived at their solution. Good design requires intentionality.
What part of this design are you looking for feedback on?
What constraints are you working within?
What is the user trying to accomplish on this screen?
What problem is this solving?
How could this design fail?
How did you arrive at this solution?
What’s the simpler version of this?
Is there anything we can remove?
What assumptions are you making?
Why is that there?
Why is that shown at all?
Is that worth displaying by default?
Why is the screen organized this way?
Why is this a better solution than [established design pattern]?
What is your type hierarchy?
What UI patterns are you using?
What rules have you defined for these patterns?
Are there opportunities to be more consistent?
What are your margin and padding rules?
What rules have you defined for the color palette?
Receive feedback from stakeholders that is clear, relevant, and helpful. They’re probably not experts in giving design feedback, so it’s your responsibility to ask questions that steer the feedback towards project goals and areas they are subject matter experts in.
Does this solve your users’ needs?
Does this effectively address [project goal(s)]?
Does this meet all functional requirements?
Does this effectively reflect the brand?
Why is [design request] important?
Follow questions with a healthy dose of “why?” or “tell me more about that”.
Know what you don’t know.
Think of a product you love. Then think of the great questions the design team had to ask to arrive at that solution.