Personas

Owned by Former user (Deleted)
Last updated: Jul 20, 2007Version comment
4 min read

Modeling Users: Personas
Excerpt from Alan Cooper, About Face 2.0 (pg. 55)

Personas
To create a product that must satisfy a broad audience of users, logic tells you to make it as broad in its functionality as possible to accommodate the most people. This logic, however, is flawed. The best way to successfully accommodate a variety of users is to design for specific types of individuals with specific needs.

When you broadly and arbitrarily extend a product's functionality to include many constituencies, you increase the cognitive load and navigational overhead for all users. Facilities that may please some users will likely interfere with the satisfaction of others.

The key is in choosing the right individuals to design for, ones whose needs represent the needs of a larger set of key constituents, and knowing how to prioritize design elements to address the needs of the most important users without significantly inconveniencing secondary users. Personas provide a powerful tool for understanding user needs, differentiating between different types of users, and prioritizing which users are the most important to target in the design of function and behavior.

Since they were introduced as a tool for user modeling in The Inmates Are Running The Asylum (Cooper, 1999), personas have gained great popularity in the usability community, but they have also been the subject of some misunderstandings. This section attempts to clarify and explain in more depth some of the concepts and the rationale behind personas.

Strengths of personas as a design tool
The persona is a powerful, multipurpose design tool that helps overcome several problems that currently plague the development of digital products. Personas help designers:

  • Determine what a product should do and how it should behave. Persona goals and tasks provide the basis for the design effort.
  • Communicate with stakeholders, developers, and other designers. Personas provide a common language for discussing design decisions, and also help keep the design centered on users at every step in the process.
  • Build consensus and commitment to the design. With a common language comes a common understanding. Persona reduce the need for elaborate diagrammatic models because, as the authors have found, it is easier to understand the many nuances of user behavior through the narrative structures that personas employ.
  • Measure the design's effectiveness. Design choices can be tested on a persona in the same way that they can be shown to a real user during the formative process. Although this doesn't replace the need to test on real users, it provides a powerful reality check tool for designers trying to solve problems. This allows design iteration to occur rapidly and inexpensively at the whiteboard, and it results in a far stronger design baseline when the time comes to test with real users.
  • Contribute to other product-related efforts such as marketing and sales plans. The authors have seen their clients repurpose personas across their organization, informing marketing campaigns, organizational structure, and other strategic planning activities. Business units outside of product development desire sophisticated knowledge of a products users and typically view personas with great interest.

Personas also resolve three user-centered design issues that arise during product development:

  • The elastic user
  • Self-referential design
  • Design edge cases

The Elastic user
Although satisfying the user is our goal, the term user causes trouble when applied to specific design problems and contexts. Its imprecision makes it unusable as a deisgn tool every person on a product team has his own conceptions of the user and what the user needs. When it comes time to make product decisions, the "user" becomes elastic, bending and stretching to fit the opinions and presuppositions of whoever has the floor.

If programmers find it convenient to simply drop a user into a confusing file system of nested, hierarchical folders to find the information she needs, they define the elastic user as an accommodating, computer-literate power user. Other times, when they find it more convenient to step the user through a difficult process with a wizard, they define the elastic user as an unsophisticated first-time user. Designing for the elastic user gives the developer license to code as he pleases while still apparently serving "the user". However, our goal is to design software that properly meets real user needs. Real users - and the personas representing them - are not elastic, but rather have specific requirements based on their goals, capabilities, and contexts.

Self-Referential Design
Self-referential design occurs when designers or developers project their own goals, motivations, skills and mental models onto a product's design. Most "cool" product designs fall into this category: The audience doesn't extend beyond people like the designer, which is fine for a narrow range of products and completely inappropriate for most others. Similarly, programmers apply self-referential design when they create implementation-model products. They understand perfectly how it works and are comfortable with such products. Few non-programmers would concur.

Design Edge Cases
Another syndrome that personas help prevent is designing for edge cases - those situations that might possibly happen, but usually won't for the target personas. Naturally, edge cases must be programmed for, but they should never be the design focus. Personas provide a reality check for the design. We can ask, "Will Julie want to perform this operation very often? Will she ever?" With this knowledge, we can prioritize functions with great clarity.

For more information on personas, like how to create them and choose primary and secondary personas, see About Face 2.0 or the newest version, 3.0.