Who's the user?
Not long ago, we collaborated with a new UX designer who was curious about creating user personas. To help them understand the concept, we proposed two scenarios:
- Imagine you get into a car, turn the ignition, and the car starts. Who is the user?
- Now, consider the same situation, but this time the car doesn’t start. Who is the user?
In some cases, identifying the user is straightforward. It’s the person using the product, who can be characterized by attributes such as age, gender, marital status, etc. This approach works well in the first scenario.
However, the second scenario is more complex as it may involve more than just the immediate user. Let’s delve deeper into this scenario: Can the user resolve the issue on their own? Have we designed the product in a way that allows the user to diagnose the problem with the car? Have we made it simple for them to fix the problem? For instance, if the issue is a dead battery, can they easily recharge it? Most of the time, this is a straightforward fix - they can connect the car to a charging station if it’s electric, or get a jump-start from another driver if it’s a gasoline model.
But what if the battery is dead and won’t recharge, despite the user’s attempts?
In such cases, as UX designers, we still have ways to identify the user.
Traditionally, we establish a persona for each use case we encounter, based on specific criteria that align with the user. This approach is effective when identifying the direct user.
Alternatively, we can utilize the ‘Jobs To Be Done’ (JTBD) framework. This approach concentrates on the tasks a user needs to complete a specific job. By shifting our focus to these tasks, we can create more flexible and adaptable personas, simplifying the process of matching any user. The JTBD framework’s scalability allows it to accommodate any new task, thereby broadening its applicability across various scenarios.
It’s important to note that JTBD doesn’t replace user personas, as identifying the user remains crucial. For instance, in the second scenario where the job to be done is to replace a dead battery, several potential users come into play. A car owner with knowledge of their vehicle might be able to swap out the dead battery for a new one. Alternatively, they might need to take it to a mechanic or a dealer, especially in cases where the battery panel of an electric car is completely dead.
In designing a user experience, we need to consider all potential users who will be affected by this issue and who will be involved in resolving it. This could include the car owner, a mechanic, or even roadside assistance services. By taking into account all potential users, we can design a more inclusive and effective user experience.