Take These Steps To Define Your UI/UX Problem And Avoid Haphazard Changes

If you don’t know what you are trying to solve, you hardly stand a chance at solving it. And good design for user interface (UI) and user experience (UX) is about solving the most pertinent problems for your target audience. If you can define the problem you are tackling, you’ll have a solid foundation to build your ideas. However, that’s just one, small part of the story.

The key factor here is how you go about defining your problem. For instance, you could state your problem as, “The X mobile app is not engaging enough.” However, it is such a broad definition of the problem that you will keep stumbling in the dark to find the right solution. The idea of defining a problem in design thinking is to make the iterative process streamlined, without limiting the possibilities. At my agency, this process helps our team to effectively narrow in on the appropriate areas, resulting in improved UI/UX for our clients.

Now, this can be a confusing process to navigate, which is why it is easier if you break down the problem-defining stage into steps:

Empathize: Put yourself in your customers’ shoes and think of their pain points. Here, imagining user cases helps a great deal. The empathize stage is about analyzing all the pertinent data that you can.

Define: Once you have tried to understand your end consumer, it is time to define the exact problem that you will be tackling. Let’s say you have a car-sharing app. At the empathize stage, you realize that older consumers who are new to the internet have trouble using the app. Given that insight, you can now define the problem as, “The app is not very user-friendly for people 50 years and older.”

The define stage is where you collate your analysis of the empathize stage and synthesize a problem statement. Very often, you will go back and forth between the two stages to get a clear problem statement.

Defining a problem is a team effort.

While the above gives you a basic blueprint for defining a problem, practical scenarios can be more complicated. For one, you will have a design team and each team member will likely have their own analysis and synthesis. In these situations, it helps if you collate all the information from different team members into one place. Create a dashboard where designers can pin their ideas and insights. Keep connecting the dots between these different insights to delve deeper into the problem. Like everything else in design thinking, this process, too, is iterative.

You will often define several problem statements as well as prototype solutions for each of those statements and test them in the market before you can come to a problem statement to really hone in on the issue.

Your problem statement is your key to a successful solution.

A problem statement is the guidance you need to deliver a useful product. For that reason, it is important to keep your problem statements action-oriented. For instance, taking our example problem above, a good problem statement could be, “Create a simpler UI for users older than 50 years of age.” You could also rephrase that to, “Users 50 years and older need a simpler UI because they are new to the internet.”

Broadly speaking, a good problem statement should have the following elements:

  • Focus On End Consumers: A problem statement should never be about monetization or the technology involved in making the product. Instead, it should focus on your end user. The goal of defining a problem in design thinking is to solve a problem for humans.
  • Not Too Broad: A good problem statement has inherent constraints in it to make problem solving an easier task. For instance, “Improve the UI of the app,” is too broad a statement. If you run with that problem statement to the solution stage, you are going to end up in a long iterative loop that is going to cost a lot of time and money.
  • Not Too Narrow, Either: If we were to revise our original definition to, “Employ adaptive font size to make the app more inclusive,” that would be too narrow a problem statement. The problem with such a precise problem statement is you miss out on all the possible creative solutions. In our case, while adaptive font size can definitely make the UI better for older users, there can be other things that can improve the experience. For instance, a smaller number of options on one screen can help older users navigate the app better.

Your problem statement also lets you explore the “why.”

The empathize stage allows you to collect data on user behavior. This analysis allows you to frame a lot of “why” questions, which are important to actually get to the problem solving stage. In our running example of older internet users, for instance, the problem we have defined allows us to answer why the app is difficult for people who are 50 years of age and older. The framing of “why” questions allows you to come up with possible solutions in the form of “how” statements. And this why-how laddering can be immensely useful in nailing the UI/UX of a product.

The entire process of identifying and defining the problem may seem lengthy. However, when done right, it can actually help you save a lot of time and headache at a later stage. Working with your entire design and development team at the problem-defining stage, and being thorough in the process, allows everyone better understand the need for the project.

This clarity translates to a better-designed product that is more likely to meet clients’ expectations. It also shortens the iterative process later on, making the project less time-consuming and less expensive. If you are looking to build an efficient UI/UX team that meets its targets, you would do well to adopt the design-thinking model and pay particular attention to how you go about defining the problem that needs to be solved.