UX & UI

8 min read

Every UX Project Should Start with These 10 Questions

We get asked this a lot, by clients and fellow UX designers – what is the main information you need to know before you start working on a project?

We wish there was a magic formula that works for everyone… Oh wait – there is. If you’re about to start a new UX project (as a client or a UX practitioner), your first conversation should be based on the below questions.

You can add dozens of other useful topics, and they’ll indeed help you to understand the project even better, but before diving into more details, these are the basics that will help both parties to understand if they can work together.

1. What’s the problem that your product is solving?

This is purely to explain what the business is about and what it is doing for the customer. It’s not a tricky investor’s question, and the conversation should never go into a pitch mode – or even worse, the client trying to “sell” the product and the designer challenging the concept. This will get you off on the wrong foot.

2. What is the main product problem you want to solve with this project?

Never accept or give an answer like “we need a site refresh; our current website is quite old and clunky”. You’ll never be able to estimate the results of the UX work if there’s no clear problem that you’re solving. If the client can’t answer the question and says something similar to the above, then the designer needs to extract this information and rephrase the answer. “OK. Once you have a better-looking website, would you want to see an improvement in the conversion rate, customer satisfaction score, or staff productivity?” Knowing the answer to Q1 will help you to easily identify this.

3. What data have you been tracking, and what tools are you using?

Every live product holds some performance data, even when the answer is “nothing, unfortunately”. GA and some basic business insights are the very minimum, but even if this is not available, qualitative data is still a good start. The data is needed for two main reasons: 1) analysing past product performance and identifying UX issues and 2) selecting the right metrics/variables for measuring the impact of the UX work that will be conducted.

4. What’s your typical user like?

Understanding the user demographics and their main pain points can sometimes make all the difference for a UX project. Again, there’s no answer like “everyone” or “all sorts of people”. Everyone might benefit from using the product, but it’s usually a specific group that forms 60-70% of the user base. This will help the UX practitioner to create the user personas, which will be crucial for making product decisions at a later stage.

5. What do you want them to do when they land on your website? What is the business opportunity?

The conversation here should be focused on the main conversion actions we want the user to take, for example, complete the sign-up, purchase a product, engage with the content, etc. Things like recognising the brand or being delighted and entertained are the methods we’re using to achieve the conversion, and they’re part of another discussion when you’re exploring solutions.

6. Do you have customers we could speak to in order to understand their pain points better and what they love about your product? Can you assist us with organising the interviews?

We’re very passionate about the topic of how much time designers should be spending on user research. Stef’s got a great, quick video on building user personas in 4 days (spoiler: it’s easy!). Wasting too much time on user research is a common project mistake, but it’s even worse when the UX lead doesn’t take the time to speak to a few users and understand how and why they’re using the product. Some product loopholes can’t be discovered in the data, and speaking to users and stakeholders is what completes the picture.

Also, asking for assistance to organise the interviews would help with the estimations of how much time will be spent on the interview process.

7. What’s your business model?

This easily could be Q2; it really depends on how the conversation flows. Understanding the business model is crucial for product design. Designing a product without understanding the business behind it is a recipe for disaster. The design team must be familiar with the main revenue streams, so they can track the impact of their work on the overall business. Being familiar with the concept of growth design is essential for both designers and product leads.

8. What’s your ultimate goal with this project? What are you trying to achieve?

Similar to Q1, don’t give or accept vague or abstract answers. It might not be agreed during the first conversation, but every UX project must have a measurable and meaningful goal. It could be as clear as “reduce cart abandonment rate by 18%”, or they could be more subjective, like “Improve the product satisfaction score by 3 points”. It’s extremely important to follow the growth-let approach and pick specific, measurable variables, instead of high-level business metrics that might be lacking context for measuring UX. For example, if the business goal is to increase revenue from selling online courses, then a UX project goal could be “increase bulk orders by 12%” or “The share rate for the Refer a Friend program should increase by 17%”.

9. How are we going to track this?

As soon as the main KPIs for the project are confirmed, the two parties must agree on the process and the toolset used to track the performance, making sure that everyone involved is on board with the mechanics and that there’s little to no room left for free interpretation of the results.

10. Are there timeframe and tech requirements or constraints?

In the interest of everyone’s time, all housekeeping questions should be discussed during the first call/meeting, as sometimes this could be a deal breaker – especially when the client needs the project completed in a really tight timeframe and the UX studio/designer has other projects running at the moment. After the scope of the project has been discussed, the UX specialist would have a rough idea how long this will take, depending on the size of their team, the workload, and the complexity of the UX work required.

If you enjoyed this post, here’s a great video on evaluating if a feature is worth building.