There has been a lot written about using personas in the design process. Over the years I’ve always shied away from creating detailed personas. Personas are loaded with one’s biases.
In my career I’ve run across personas that were sexist, or racist, or developed by stereotypes. I’d like to think that the personas that I created didn’t succumb to these issues, but I know that’s not the case. No one is perfect.
These personas are dangerous. Personas that are created with these conscious or unconscious biases lead to biased products. The cycle of bias continues.
Personas are imaginary customers defined by attributes that don’t acknowledge causality. @ALANKLEMENT
Personas fail before they become documents printed on so many dead trees. They start with a batch of assumptions. Assumptions that tend to be wrong, much like every assumption ever put into software development contracts.
These assumptions typically fall down when reality sets in. I’ve seen personas created in which the women were looking for the right guy or were trying to lose weight. Two things which — ignoring the latent sexism — don’t really matter at all. At the end of the day, decisions are made by factors of a persona.
There are causalities that drive product decisions that can’t be recorded in a persona.
The misdirection of persona creation leads teams towards following the wrong path. User stories get created with incorrect priorities, or that weren’t needed to be completed at all.
Focusing on meeting the needs of the personas also leads teams to forget that there are real world users that can help guide and influence a product. Personas create a false barrier between stakeholders and real world customers. This causes unnecessary revisions and wheel spinning.
The Jobs to Be Done (JTBD) framework has offered an alternative to the traditional persona. Instead of focusing on the customer for a product, a designer instead focuses on the job that customers need to get done with a product or service.
A key component of the JTBD framework is the replacement of user stories with job stories. Job stories focus on the motivation and not the person. This helps to reduce bias contamination in the stories, but also increases the overall empathy within the story.
A typical user story goes something like this:
As Steve, I want to be able to checkout quickly
For starters, a designer or developer needs to know who Steve is. This information is generally stored in a persona document and rarely ever referenced as the project progresses.
Once they figure out who Matt is, then they can move on with the story. Unfortunately, this story lacks any context that was there when it was originally created. This could be for any number of reasons, but usually what one person assumed would be known turned out to be unknown.
Enter the job story:
When I’m at the store with two kids, I want to checkout quickly, so I don’t have to chase them around
In this case, the persona is long gone. The result though is a story that is clearer for the team and includes the necessary information for whomever works on it to have a bit of empathy for the end user.
Job stories are the way of the future for design projects. Hopefully, adopting their use will also kill personas along the way.