Are we trying to solve a customer’s problem? Do we know what exactly is our customer’s problem that we are trying to solve? The ‘Define’ stage in Design Thinking is dedicated to defining the problem. In this blog, we will discuss user needs statement, why they are essential, their format, and a few examples.
What is a user need statement?
A user need statement is an actionable problem statement that provides an overview of who a particular user is, what the user’s need is, and why that need is valuable to that user. It defines what we want to solve before we move on to generating possible solutions.
A problem statement identifies what needs to be changed, i.e., the gap between the current and desired state of the process or product.
How to build a good problem statement?
A good problem statement should always focus on the user. Here are some indicators that will help us create a good problem statement:
For example:
Suppose we have framed our problem statement as shown below, we will not be sure of exact user needs, what insights are required by the reporting manager, should the insights be based on the number of reportees, their roles, leaves they have availed, projects they are assigned to, or is it anything else?
As the reporting manager, I should have insights into the reportees’ reporting to me.
Instead, if we build our problem statement as below, we should know who the user is, their needs, and why it is important to them.
As the reporting manager, I should have insights into the total number of leaves applied by my reportees (yearly/half-yearly/quarterly/monthly/weekly/day-to-day basis). I should also be able to drill down and view the details to keep project managers informed and as well evaluate reportees’ KPIs.
Format
Traditionally, user need statements have 3 components:
These are then put together in the below pattern: User [the user persona] needs [the need] so that [the objective].
For example, [As a reporting manager, I] should be able [to approve leave requests applied by my reportee] so that [they can avail planned holiday(s)].
The user should refer to a specific persona or actual end-user we’ve conducted discovery on. It is helpful to include a catchline that helps to understand who the user is, whether the problem statement will be utilized by a group or an individual, what’s the user role is, etc.
The need should reflect the truth, should belong to users, should not be painted by the team, and should not be written as a solution. It should not include features, interface components, and specific technology. For example, possible goals may be:
We should recognize that users do not always know what they need, even if they may say so.
For example, the customer says that they copy content from a page in the application and paste it into Excel and try to do some calculations they are unable to do due to formatting issues and want us to fix them.
But the exact need is:
As the accountant, I need a copy of the figures/table that I see on the screen in Excel format so that I can make further calculations if required using the data and save it for auditing purposes.
For a successful outcome, the insight or goal should fulfill the user’s needs while incorporating empathy. Instead of focusing solely on the surface-level benefits, it’s essential to consider the user’s deeper desires, emotions, fears, and motivations:
Problem statements can also take these formats:
Benefits
The process of making a user need statement and the actual statement itself have many benefits for the team and organization, including:
Conclusion
User need statements help communicate the end user’s problem we are about to solve and what value we are bringing in. When done together and correctly, they can act as a single source of truth for what the team or organization is trying to achieve.
