Personas … the magic ingredient to solution success!

Personas is a technique which can be seen as “the magic wand” ensuring solution success! When the Business Analyst can paint the requirements with a Persona brush, then the requirements and design specifications suddenly sings the song of the real end user. This might sound like flowery language applied to a formal analysis technique, but once you understand the magic that Personas can add to your solution’s chances of being successful, then you will want to embrace each persona with a warm hug and even a kiss…alright I will stop with the unorthodox metaphor, however it is time get more serious about: Personas!

This blog article (& video) describes what is meant by the term “Persona”, why this is a popular analysis technique and how to find the personas within your Agile project context.

What is the purpose of using Personas?

Personas are used to in order to understand and empathise with an intended stakeholder so that we are able to align the solution with the stakeholder need.

Let’s understand a bit more about what a persona is:

Personas are fictional characters or archetypes that exemplify the way that typical users interact with a solution. They are often used in agile approaches to understand value from the perspective of a particular stakeholder and allow a team that may not have direct access to a customer representative to better understand their needs. Work can then focus on the features of greatest value to a particular persona.

A persona is described as though it is real person. Personas may provide a name, personality, family, work background, skill level, preferences, behaviour patterns, personal attitudes, goals, and needs. They can also include a picture and a short “day in the life” narrative that helps to visualize the user and their experience.

JOIN THE IIBA AGILE BA PRACTITIONER ONLINE COURSE – EARN 16 PD HOURS

When do we use Personas as Business Analysts?

Business analysis practitioners use personas to gain a deeper understanding of stakeholders than is generally provided from a role or actor description. Personas help improve a solution, a purpose, and usability because they are patterned after the subtle qualities of real people that will interact with the solution and how they do their job.

Personas are ranked to identify those that will realize the most benefit from the solution design.

How to identify the Personas relevant to your Agile project?

Firstly, it is important to understand the concept of having primary and secondary Personas.

• Primary personas represent users with specific needs that can be satisfied only with a user interface designed specifically for them.
• The secondary personas are people who also use the system but can use an interface that was designed for a primary purpose.

Identifying personas helps development teams create user experiences that are optimum for a certain class of user. User stories provide clues as to where we might find them. Analysing the roles described in our user stories and the story itself gives us clues as to where the personas might lie. For example, if we are developing an online banking portal, the bank customer role uses the solution for a completely different reason than the system reconciliation team uses the system, so we would need to develop different user interfaces for these two role types. However, if the customer support team can use the same user interface as the bank customer, then although we need to be aware of their needs, we should focus the design for ease of use by the consumer, our primary persona. In this case, we would consider the needs of the customer support team user role as secondary.

There are some guidelines as described in Dean Leffingwell’s book, Agile Software requirements:

1. Don’t “make up” personas out of thin air. Rather, discover them as a byproduct of your requirements discovery and user story writing process.
2. Develop a specific, individual persona – an actual person who you can interview, interact with, and come to understand. Understand their abilities, background, environment, and usage of the system.
3. Identify the persona’s goals so that you can see what your system needs to do and not do.
4. Design your system to make it easy for that one person to use your system. If you’ve defined primary personas well, that individual will be a specific “representative of a class”. However, they will be more tangible, and their needs more understandable, than attempting to design for the general case.
5. Secondary personas are just that, secondary. You do not have to design specifically for them. They will bend and stretch to use the system. Even then, however, the goal should be to develop software that bends and stretches to them. But you must do it in such a way as to not make the system harder for the primary persona to use.
   There shouldn’t be a large number of personas; the goal is to narrow down the people you are designing the system for. If you identify more than three primary personas, the scope of your system is likely too large. If that is the case, then break the system into subsystems, and identify personas from there.
6. Finally, after you’ve identified each persona, attempt to first understand both what they expect from the system and what they need to do with the system.

What aspects should you consider when you describe a Persona?

Persona Name and Image

Agile business analysis practitioners give personas a realistic name and attach a fictional image in order increase its relatability and thereby the understanding of and empathy with the intended stakeholder.

Traits and Characteristics

Personas include unique, distinguishing, and differentiating characteristics or traits regarding the intended stakeholder.
For example, one Automatic Teller Machine (ATM) persona may be an office manager who deposits cash at the end of the day. A different ATM persona may be an individual who likes to get small amounts out at a time.

Motivations

Personas include a representation of the underlying motivations regarding how and why the intended stakeholder interacts with the solution.

For example, an ATM office manager may be motivated by reducing risk of fraud or theft. The individual withdrawing from the ATM may be motivated by withdrawing the minimum amount needed.

Needs

Needs for the persona address very specific needs. These can be basic needs such as safety, trust, or access to food and shelter. They can be higher level needs such as the need for acceptance and validation. Needs are finite as compared to wants which are infinite.

Differentiators

Differentiators identify specifically why this persona is different from another persona. They identify what is unique about this persona. These could be generational or experiential differentiators, preference differentiators, or identifying characteristics.

Some of the strengths of this technique include:

• Personas facilitate the shared understanding of specific requirements for different sets of users. These requirements can be used to develop user stories.
• Proposed solutions can be guided by how well they meet the needs of individual user personas. Features can be prioritized based on how well they address the needs of one or more personas.
• Provide a human “face” so as to focus empathy on the people represented by the demographics.
  If the data is available, using demographic (or anthropomorphic) data about the intended user population is a good way to start building personas. However, in some cases it is necessary to be creative and invent personas based on little more than a few dry facts about the intended end users.
• Personas help stakeholders from projecting individual values and biases onto the solution. They help to develop compassion for various users.

Some of the limitations of this technique include:

• Personas are fictional, so there is a tendency to create personas that embody traits common to most users, but this creates a generic user that is not distinct or realistic. This can lead to solutions that are trying to be everything to everyone.
• Personas may not be a good substitute for a real user. Personas can distance a team from a user community.
• Personas need to be regularly reviewed and updated.


Conclusion

The Agile analysis technique: Personas is an especially effective technique to apply when designing the system capability and user interface. It can make a big difference in the level of acceptance by primary user roles within the organisation if the primary personas have been carefully analysed and understood prior to finalising the design aspects of a solution. It is a very easy technique to understand and a great technique to help guide our perspective to come from our primary user roles when making decisions about requirements and design.

References used when writing this article:

Agile Extension v2 to the BABOK v3 Guide
Agile Software Requirements by Dean Leffingwell.