Personas End Feature Debates

Surprisingly, another extremely important contribution of personas is their value as a communications tool. The cast of characters becomes a design taxonomy with great power to explain our design decisions. Even more, they become a spotlight, showing the programmers, marketers, and managers that our design decisions are obviously correct.

It is vitally important that everyone on the design team not only become familiar with the cast of characters, but that each persona become like a real person like a fellow member of the development team. Programmers with their mathematical nature have a natural reluctance to think about specific user cases, preferring instead to think about general cases. This spills over into their thinking about users, and they are always imagining users in the aggregate, the average, or the generic. They much prefer to speak of "the user" than of Judy, Crandall, Luis, Estelle, Rajiv, and Fran.

Before personas are put to use, a typical conversation between a programmer and a manager engaged in interaction design would go something like this:

Programmer: "What if the user wants to print this out?"

Manager: "I don't think we really need to add printing in version one."

Programmer: "But someone might want to print it."

Manager: "Well, yes, but can't we delay putting printing in?"

The manager cannot win this discussion because she has not advanced an argument with the force of reason. Regardless of its truth, it is stated merely as her amorphous desire to do things differently, and the programmer's logic of what "might" happen is irresistible.

After the cast of characters is developed, we have our taxonomy for expressing precisely who needs what in the program. But programmers are hard to move, and a typical discussion with a client programmer early in the relationship goes like this:

Programmer: "What if the user wants to print this out?"

Interaction designer: "Rosemary isn't interested in printing things out."

Programmer: "But someone might want to print it."

Interaction designer: "But we are designing for Rosemary, not for 'someone.'"

At this point, we are at a standoff. The programmer is still using the term "user" and is still stuck in the world of possibility thinking. However, our invocation of the persona Rosemary is not an amorphous, unformed desire. Instead, it is a specific person with a demonstrated skill set and objectives. We finally have an argument that is compelling.

However, because programmers have possession of the code, they can and will still do what they want, regardless of the strength of our arguments. The key to success is getting the programming staff to buy into the existence and reality of the cast of characters. Every one of our designers resolutely insists on expressing all design issues in terms of named personas. We never fall back into the "user" construct. We never let the programmer or anyone else get away with assertions about "the user." After a while, this consistency pays off, and the programmers begin to adopt personas and refer to them by name. Although this seems like a subtle change, when the programmers begin to speak of personas by name of their own volition, it is really a dramatic, watershed event that changes the nature of the collaboration between designers and developers.

This watershed occurs in every one of our successful design projects. When it happens, the entire process shifts into high gear. The conversations now sound more like this:

Enlightened programmer: "Would Rosemary want to print this out?"

Happy interaction designer: "No. Although Jacob will want some printed reports on a quarterly basis."

Enlightened programmer: "Well, if they are so rarely needed, we should save ourselves time and effort by not writing a fancy, proprietary report-writing feature, but instead license a commercially available tool."

Happy manager: "And that shaves two weeks off of the shipping schedule!"

I have seen dramatic changes come over our client companies after the watershed. Before, they were stuck in endless feature wrangling, and issues once thought resolved would reappear for further discussion every couple of weeks. Afterwards, design issues are raised, answered, and put away once and for all.

Some of our client companies have printed T-shirts with a picture of an important persona on it for each of the developers. We have had other clients print posters with personas to put on the walls of the programming shop. These efforts help to unite the programmers in a mutual understanding of their ultimate customer.

Both Designers and Programmers Need Personas

On the other hand, we have worked with companies where the programmers are simply too embarrassed to actually call users by their names, and they would not buy in to the idea of precise personas. They would continually backslide into "user-speak," and their products suffered enormously.

I know a programmer who simply doesn't understand how personas work. Under the pressure of arguments from my colleagues and myself, he has admitted that personas are important. However, he misses the central point of specificity, so he tends to use the term "persona" as a synonym for "user." He says, "We have to fulfill the needs of the personas." Although he uses the term, he rejects the specificity, which is the active ingredient, so he loses any value.

Another client gave us just a few days to make some recommendations. We created a persona named Edgar, who was not defined with much detail. We then entered some protracted discussions with the client on issues that extended beyond the original project scope. We quickly found that Edgar began to multiply. Different teams within the client adopted different Edgars, each with different qualities.

Marketing professionals will be instantly familiar with the process of persona development because it is very similar to what they do in the market-definition phase. The main difference between marketing personas and design personas is that the former are based on demographics and distribution channels, whereas the latter are based purely on users. The two are not the same and don't serve the same purpose. The marketing personas shed light on the sales process, whereas the design personas shed light on the development process.

As we begin to develop ideas for design solutions, we can constantly hold them up against our personas to see how well we have done. We become character actors, inhabiting the minds of our personas. This is easy to do because they are so narrowly defined. When you try on a persona and examine a product or a task, you can tell right away whether or not the design has succeeded in making that persona happy.