Shifting to Disposable Personas

Jared Spool

May 21st, 2013

“We tried creating personas and it was hard. It took us months and they never got traction. Eventually we abandoned the project.”

I’ve heard this dozens of times from design team managers. They all embarked on these big persona projects, often with energy and excitement, only to find that energy dissipate and the project lose its momentum. Personas that don’t help make design decisions are a waste.

However, it doesn’t have to be that way. These projects fail because of a perspective problem. The design teams think of making personas as a project in itself. I’ve come to the conclusion that thinking this way will lead to failure.

The alternative to having personas be a project is to make them just a step inside of every project. Instead of making them once and trying to use them everywhere, we come up with a low cost way to insert them into each project as they are needed.

We can divide well-done design projects into a discovery phase (where we explore the boundaries of the problem we’re trying to solve), an exploration phase (where we toy with different possible solutions), and a refinement phase (where we choose a direction and fill out the details). (Not everyone does design projects well, but the folks who do end up following these three phases. The ones who don’t, well, they skip one or more of these stages then regret it later. Or maybe they are unconsciously incompetent.)

Part of the activities in the discovery phase are to gather information about the users of the design and what they’ll need. We can do that with fancy-ass research or we can do it by just collecting all our thoughts about what we already know. The more specific we can get each question, the easier they are to answer.

For example, if we were building the part of a clothing e-commerce site that showed the product previews, we’d want to know how people used previews in their shopping. We can make guesses or ask our peers. Or we can go into the field and study shopping online or in stores.

Now, we can group what we’ve learned about our users into behavioral categories. We might group people who love to match different pieces in one pile, while we group people who prefer to see pre-designed outfits in a different pile. We might group the folks who are matching colors to things they already own in a different pile from people who don’t trust the colors they see and will use the free 90-day return period to ship back products they don’t like.

These different groups become the persona clusters. And the things people did in those groups become our scenarios. If we’ve done a good job of collecting our data and knowledge about the users, it should be quick to create these personas around this specific functionality. Less than a day, in fact.

And there we have it: Detailed personas about using previews. There’s probably a ton of design decisions these personas can now help us answer. (And where they can’t, well, that points out for a little more research.)

At the end of the project, when our preview module is out there and being used, well, the personas aren’t that useful anymore. But because only spent a day on them, we don’t need to “protect our investment.” We just toss them out and create new ones for the next project.

There you have it: cheap and easy disposable personas.

2 Responses to “Shifting to Disposable Personas”

  1. Carolyn Wood Says:

    You put it better and much more authoritatively than I ever could, and I agree completely.

    One project immediately comes to mind. When helping to create a big project for web and print people, I said, ”We need personas,” and immediately just made a list of 5 categories of people and described each group in a couple of sentences. Group A, the ones with the highest level of expertise, were our primary “target,” if you’ll excuse the expression, and yet we wanted it to be very appealing to Group B, as well. I also identified what the other 3 groups, C, D, and E, might get out of the project, and I laughed each time I saw that I’d put myself into Group D.

    As simple as this was, it helped us immeasurably—in considering how each group would likely perceive each piece of the project and the project as a whole; in making sure that all of our content was balanced properly (much more for Group A, less for each group going down the list) and discovering what was missing; in determining the editorial voice and where that voice needed to appear; in making sure that a piece was directed at Group A’s needs, yet finding ways to make sure most were accessible and appealing in some way to the other Groups if they chose to tackle them; and in assessing the overall desirability and usefulness of each piece of the project for each group (and whether that was important to us or not). It took me very little time (certainly less than an hour), we referred to it constantly, and it had a great impact on the finished project.

  2. Andrew de Ville Says:

    Jared, If you have skilled people developing behavioural Personas and skilled people embedding the use of Personas within your organisation then they will stick. You need to involve the key stakeholders across the organisation in co-creating the Personas, not just the CX/UX team in isolation from the rest of the organisation. The data for the Personas needs to come from observational research to be most accurate. In the many years I have been involved in managing UX projects/teams in developing Personas for ter 1 companies I can say with 100% certainty that behavioural Personas last many years, are highly accurate, are constantly validated within every project and lastly behaviours do not change that much and there are not that many, compared to segmentation Personas for example.

Add a Comment