What BAs Can Learn from Using Personas in Product Design

This is a followup piece to the article, Use Of Personas In Software Development. It provides more information on how personas can be employed on software projects and reasons why BAs should incorporate them on projects.

What Is A Persona?

A persona can be defined as the illustration of the activities performed by a group of users who have similar motivations, behaviours, and goals.

Though personas are fictional, they can be realistically portrayed since they are built on the knowledge of the behaviours and characteristics of real people. A persona reflects the goals, pain points, behaviours and psychology linked to members of a user segment. To make them seem real, a background is usually provided for each persona to reflect how they would use the product.

Why Bother Using Personas?

Personas are particularly useful because they serve the purpose of constantly reminding the design team whom they are building the solution for, plus they are easier to remember since there’s a story behind each persona.

Personas can also be used to aid the prioritization process with stakeholders, since each requirement that surfaces can be compared with each persona to assess where it fits and determine how relevant it is to the objective reflected in each persona.

Business analysts can employ the use of personas for bringing requirements to life, thereby leading to empathetic designs.

Another one of the major uses of personas in product development is for communicating information about users and establishing a level playing field by merging views from different team members, which can lead to an increased understanding of the target users and high level of system acceptance.

From the onset of a project, personas should be created early by design teams (BAs inclusive) to affirm their opinions about users and achieve a user-centred design.  

Even though personas are a familiar phenomenon, they are often underutilised. Generally, about 4-7 designs are enough to capture majority of user requirements.

The companies that embrace the use of personas create teams that conduct research, examine data and create the personas. Indeed, the use of personas is viewed by many organisations as an effort that is too intricate and time-consuming to apply on a design project.

What Information Should Be Reflected In A Persona?

• Name of persona: Marketing Manager
• Roles & Responsibilities
• Demographics – age, background, status, etc.
• Objectives of using the application
• Pain points or frustrations
• Typical work environment, technical experience and peculiarities of working in the marketing role
• Photos

Approaches For Creating Personas

Organisations can take several approaches to creating personas as described below:

Empirical and non-empirical personas: Empirical personas involve data-complex efforts that employ both qualitative and quantitative data sources whereas non-empirical personas employ hypothesis-based efforts that rely on current knowledge regarding the user population.

The empirical approach requires that specific data inform specific user research for forming the persona. In-depth research undertakings such as usability testing, field studies, surveys, analytics, market research and interviews may also be used in this approach.  

In contrast, the non-empirical approach creates personas while having conducted little or no research. This approach mainly uses existing organisational knowledge and suppositions from past dealings with users. Organisations with small budgets may use this approach since they will spend less on the persona effort.