The goal in UX is always to solve the problem for the user while accommodating business goals, technical limitations, and functional requirements to name just a few. Understanding the problem you’re trying to solve is fundamental to a successful product or service.
This blog is the first in a series of posts that will tackle – UX fundamentals. The spotlight for this post is on defining the root problem and solution with respect to discovery (planning) and the design of a product or service.
What is the Actual Problem you want to Solve?
Deciding whether a project is viable is often based on establishing that the problem is not unique to a small group. You want a smart solution that is relevant to a large enough market to justify the investment of time and money. One could argue that if the demand for your offering is high enough, then a smaller market – higher price point balances the scale of viability; but that is a whole topic unto itself and not the focus of this post.
With any new project, it’s important to take time to identify the primary problem a product or service solves. This should be a statement that can be articulated simply; avoid industry buzzwords and technical jargon. It should be easily understood by technical folks, stakeholders, and laypersons alike. A well-defined problem statement will shape your solution (offering), value proposition, product-market fit, etc., it should be clear and concise.
It sounds like an easy exercise but so often (and depending on the participants) it can prove to be harder than you would imagine. Sometimes simple root problems end up clouded by the usual suspects:
- Professional Knowledge
- Technical Know-How
- Personal Bias
This is normal, and these opinions and biases are valid and will be useful at the higher levels of our problem-solution tree. We will be addressing these issues in future posts in this series.
Managing your Solution Between Requirements
For now, let’s use one of my favourite analogies that will illustrate the point of this topic in a way that we can all relate to… the motor car (or perhaps a spaceship – both work). Let’s take the following as our super-simple root problem:
We need to get from point A to point B.
- Solution: Some kind of transportation.
- Benefit: You can travel between points quickly and efficiently.
- Audience: The known universe
Of course, this is a trivial example, but it illustrates the model by which we can evaluate the general idea. Understanding the fundamentals behind the idea is critical to defining the future direction of the product. This will be the North star for the project that we can (and should) revisit to validate that we are on a course true to the core value.
To that end let’s look at some potential requirements.
- Business requirements: Time is money! We need to get there quickly.
- Technical requirements: To be efficient, (and meeting the business requirement), it needs to be speedy and therefore powered somehow.
- Non-functional requirements: It must be safe. Speed can be dangerous.
- User requirements: The controls need to be familiar and easy to understand.
Of course, this list is not exhaustive, and many more requirements exist, but it starts to build-out our problem-solution tree. As the idea develops, we re-use our simple problem-solution-benefit-audience model at every branch of the tree. This helps us discover new requirements (user, business, technical), and so it continues as the solution becomes more complex.
Takeaways: Keep it Simple
Keep it simple; don’t introduce solution bias at the early stages of discovery and definition of the product. Use a simple, repeatable model to define requirements – the solution may be complex but the reasoning behind it should be easy to understand; everyone involved in the product should be able to tell you:
- What it does
- How it’s done
- Who it benefits
In the next post in the series we will be taking a deeper look at requirements.
Get the Best IT Business Solutions