Use Of Personas In Software Development

Initially introduced by Alan Cooper, an American software designer and programmer who is widely known as the “Father of Visual Basic,” personas are examples of fictitious users who represent a subset of users.

Before Alan Cooper’s keynote address at Agile 2008, which marked a formal reconciliation between Agile discourse and interaction design, as described by Agile Alliance, roles were the primary method through which system engineers tried to understand users within the context of their requirements for a system. Personas and roles are two entirely different concepts, despite being often confused with each other. This article explores the limitations of roles and goes over the best practices of creating personas.

Limitations Of Roles

“In requirements engineering, a role is the specific behaviour of an entity participating in a particular context. For example, the role is captured using actors in use case diagrams and descriptions,” state Granville Miller and Laurie Williams in their white paper titled, Personas: Moving Beyond Role-Based Requirements Engineering.

The main limitation of roles is that they don’t allow analysts to develop a deep understanding of all users of the system because of their homogenous nature. A single role of the user doesn’t capture the fact that there can be many different types of users, from the so-called power users to technophobes.

To overcome this limitation, personas have been used together with scenarios, series of actions and system responses, to better examine the different types of people who could assume a certain role.

Creating Personas And Scenarios

A persona describes a fictitious person interested in the system. “The idea is that the personalization of a role via the persona psychologically creates a longer lasting impression on the development team comprising business analysts, managers, designers, testers, and so on.” explain Miller and Williams.

Personas are commonly described on a single page. The page includes the persona’s knowledge, skills, abilities, goals, motives, and concerns. To make personas feel alive, it’s a common practice to also include a photograph, name, and social details. 

An example of a persona: Laurie Jones, 26, a PHP developer.

Laurie Jones is 26 years old. She lives with her dog in Brooklyn and works as a PHP developer for a major software company. In her spare time, Laurie enjoys cycling and reading. Her mortgage has been paid off, and she has no debt.

“You will want to develop several personas to ensure that you explore all the needs of your user base. To write personas well, you will need to do some form of research to ensure you truly understand your users,” advises Agile Modeling. The depth of information instilled in a persona should vary depending on your needs.

To leverage personas to their fullest potential, they are usually placed in various scenarios. As explained by Miller and Williams, “The scenario identifies the person as having certain motivations toward the system, describes the actions taken; some reasons these actions were taken; and provides insight into users’ motivations and expectations.”

Such scenarios are often expressed as a series of actions and responses. As the persona tries to complete a series of actions, he or she may stumble upon obstacles that prevent the goal from being reached. These obstacles should become the focus of the development as their removal leads to a better user experience.