Jobs to be done is a framework that can be used to help define a product scope, its requirements or marketing positioning. It's based on the premise that when a person buys a product or service, that person is not actually buying it, but hiring it to execute a certain job: People don’t want a quarter-inch drill, they want a quarter-inch hole.
In sum, a job to be done consists in four main aspects:
The first step, exposition, presents the context of the product, briefly explaining the who, what, when and where (but not the why).
In the observation step, the current and past user's behavior is identified - namely, which products they're using.
The situational analysis concerns the motivations and anxieties of the users, explaining the challenges that customers are facing and what is pushing them towards different solutions.
Finally, the job to be done itself is about the desired outcome that the user is looking for. It shouldn’t present a solution - either a product, feature or requirement - but, instead, a description of what should be accomplished by the user at a higher level.
This methodology is often considered as better suited than personas for product development due to the fact that it's outcome-driven, objective and measurable.
There are a lot of approaches that can be taken to personas. Some are fairly poor, while others do just enough to be accepted. In both cases, they only serve specific purposes that shouldn't include product design and development.
Loosely defined personas are a technique to model users. They are archetypes, formalized as fictional - but realistic - characters. While many designers claim to use personas, when analyzing their practice, we see that what is being called “personas” includes a range of very diverse materials.
The information that a persona configures changes considerably from one designer to another, and so, naturally, the potential of this technique changes as well. If we carefully observe the several ways of doing personas we can identify four different types:
The first type of persona is not actually a persona but a proto-persona and all the following types of personas can turn out to be a true persona or a proto-persona.
Proto-personas are not based on actual research, but, instead, in assumptions about the users. This type of persona requires the people involved in making them to have insightful knowledge about the real users. You shouldn't have only designers or engineers doing them, but, instead, should gather people from the customer support department, for instance, at the table.
Proto-Personas should only be used as a first step to guide further user research, but never as a base for defining the product requirements.
The second type of personas we can identify is the empathy personas. These are built around a persona's background story (a narrative about the persona life and context) usually with a name, age, photo and quote.
This type of persona may be useful to create empathy in the development team, helping them to keep motivated during the project.
Professionals who don’t have regular contact with customers may lose the vision about the utility and relevance of the product, in which case, knowing someone for whom the product will make a difference may help them understanding their efforts in a higher context.
In the end, this type of persona is of little to no use when it comes to establishing the product requirements and the project plan.
The third type of personas we can identify is the Marketing/Demographic personas.
Whilst the worst that can happen with an empathy persona being used for other goals besides the ones listed above is that it might turn out to be a waste of time, the marketing/demographic personas can really damage your product development (especially if we are talking about marketing proto-personas).
Marketing personas have a focus on demographics, seeking to find the root of the user's behaviors and desires in that data.
This is the type of personas against which most job-to-be-done defenders rise against, since there is no true causality between demographics, goals and behaviors. The identified patterns are usually the result of prejudices and stereotypes.
This fourth approach, named goal-oriented/design personas, relegates the persona's background story and demographics to a secondary plan and focuses on goals and needs.
These personas specifically identify life goals, experience goals, and end goals, as well as needs, frustrations and behaviors. This type of persona gets very close to the jobs to be done methodology, while preserving some attributes that give personas some of their power, one that goes beyond creating empathy to motivate the team.
If you want to know more about goal-oriented personas I recommend you to check Alan Cooper's book About Face.
Looking at the critic from Intercom, for instance, one of the most prominent voices in defense of JTBD and against personas, they present us the following user story based on a persona:
“As a 35 old man called Peter, I want to eat something tasty when I'm hungry, so I don’t feel hungry anymore”.
While we couldn’t agree more with the critic when she points out that the first part “As a 35 old man called Peter...” is irrelevant - since there is no causality between that data and the last part of the sentence - this is a persona method example that uses user stories and not user journeys.
Therefore, as we see, this argument is only applicable to marketing personas and not to goal-oriented/design personas.
If it was a goal-oriented persona the story would be different:
”As a senior chronicle patient who wants to enjoy retirement the most, I want to be able to easily contact my doctor anytime, so I can feel at ease with my health status”
It would only mention demographics that would have a causality relation with the persona's goals and focus on the desired outcome, making it very similar to the job-to-be-done.
Still on the critic from Intercom, when presenting the equivalent JTBD the following example is given:
“When I have only 2 minutes to stave off hunger between meetings, I want to grab something that will be quick and easy”.
But what is “easy”?
Things like “easy” or “pleasant” are subjective attributes, they do not concern the product itself but of the experience of the user with the product, being completely dependent on the user's attributes.
This means it's impossible to evaluate those attributes without having some sort of user profile. Specifically, experience goals, expertise, knowledge, intellectual and motor skills, for instance.
Let’s say the JTBD is “to have a place to save my files in a way that is easy to find them”. In terms of design, this may reflect in a hierarchical and well-organized folder structure or in a simple repository folder with a search field.
This brings us to three common project pitfalls that personas have the potential to avoid, but JTBD doesn’t: the elastic user, self-referential design, and edge cases.
If we don’t explain the term “user”, it'll be troublesome when applied to specific design problems. Everyone on a product team has their own conceptions when making product decisions, and so this “user” becomes elastic, conveniently bent and stretched to fit the opinions and presumptions of whoever is talking.
When making design decisions, a given product may be considered “easy for the user” and the next one, of the same complexity, “too hard for the user”.
Inevitably, things fall into a self-referential process with either designers or clients, depending on who holds more power of decision-making in the project, ending up making decisions based on their tastes and preferences.
In the same way, “easy”, “pleasant” and “beautiful” are subjective concepts and so is “important”. Once you start thinking about the several jobs to be done for the product, you will probably end up with a list that you won't have the time nor budget to fully develop.
Even if you have the budget, you will have to know where to start. Information like how often a persona does a certain action will help a lot when it comes to prioritizing features.
The jobs to be done method reveals itself very useful to uncover the “what” of a product, but it doesn’t give much insight on the “how”. However, users are as equally concerned with accomplishing the goal as with the process to achieve it.
This is what user experience design is about. The straight-forwardness of the JTBD is tempting but it falls back to the engineering mindset about universality and objectivity and it ignores that, firstly, there are different ways of getting to the same end and that, secondly, users are emotional beings that look for more than the accomplishment of objective goals.
Are goal-oriented personas the answer? I can't say for sure. In our practice, we still find a few problems with that method. While demographics and background stories are relegated to second plan, they are still present, which causes a few problems.
They are intended to be a communication tool between the entire team, but personas are being handled by people with different backgrounds, from developers to clients, and it often happens that not everyone is involved in this process of deconstructing the role of demographics.
That being said, those attributes, often, reveal themselves to be considerable distractors. Developers find themselves a bit lost in personas, not assimilating their importance for the implementation work and have trouble grasping its relevant information.
Also, clients sometimes have trouble distancing from pre-conceptions about how that "single and shy" demographic in the persona relates to things like the product's look & feel.
Refer to the persona as a he, and you will find yourself struggling to explain why lavender is still the best color for your interface, since the persona's experience goal is to feel calm, relaxed and luxurious.
Weighing both options, how do we create a character that teams members can relate to, which is seen as the person whose opinion should be the most important in the decision-making process and avoid stereotypes and prejudices related to profiling?
A possible solution is to merge both the persona and JTBD method. Develop personas, but in a way that is closer to jobs to be done:
The name “job to be done” easily drives people into thinking about solutions rather than about desired outcomes from the user's point of view. This is premature at this point of the design thinking process, when no design solutions were yet studied and drafted.
Also, for someone who's not familiar with the JTBD method, it's not clear what observation and situational analysis are about, and what's the difference between them.
There isn’t a perfect methodology and we should keep a critical posture in face of all methodologies, acknowledging that some projects (or some clients and teams) may be better served with something closer to one method and other projects/clients/teams, with another method.
In the end, above everything else, methodologies should be faced with a flexible mindset, seen more as guidelines than as rigid prescriptions. The space for improvement should always be acknowledged.
Simply put, you shouldn't be afraid of innovating in the way that better suits your product, teams and professional skills.
At Imaginary Cloud we have a team of experts on UI and UX design. If you think you could use some help with design, drop us a line here!
Found this article useful? You might like these ones too!
With 10 years of experience and a background in cognitive science. I’m passionate about inclusive design and calm technology.
People who read this post, also found these interesting:
.png)
