Personas

Personas are a powerful technique to capture our knowledge about the users and customers of a product.

A persona defines an archetypical user of a system, an example of the kind of person who would interact with it. The idea is that if you want to design effective software, then it needs to be designed for a specific person. In other words, personas represent fictitious people who are based on your knowledge of real users.

Personas Names

A lot of examples of personas include having a name, age, etc. This is good for marketing personas but less useful for agile personas and tends to waste a lot of time thinking up names and ages for fictitious people that are never used again. Remember, the usefulness comes from understanding our users and using the persona as part of the story-writing process, not that they are called Bob.

For a story, we don't need it to say, As Bob, I want to withdraw money so I can buy things I want. We only need, As a valid bank account holder. This gives us enough context without having to rely on a "persona dictionary", and we can substitute test data for each valid bank account holder we know about (see Additional Uses at the bottom of the page).

Agile Personas are not the same as marketing personas. They have similarities, but their purpose and method of creation are different. Therefore don’t just use the marketing ones 'cause they are already there – to create useful personas for an agile team, you will have to do the work, and that means thinking! Again, a lot of example personas say, "Don't make them up", but you must start somewhere - and they need to be somewhat generic; otherwise, you'll end up with a persona for every person that uses your solution (again, think ROI). But, use real examples to help ensure that you have covered the majority of users - no doubt you'll find more details or more personas as you go along, so don't get hung up on perfect just aim to get enough to start, and then review them regularly to make sure that you have all the latest data included in your assumptions.

Personas have specialized knowledge of the stakeholder’s specific needs and know which elicitation techniques may be most effective in understanding those needs.

Personas represent the typical users (maybe up to 10 personas with 1-2 primary personas). Personas must be derived from actual user profiles but given exaggerated needs and problems with the service/product.

Develop personas on roles and responsibilities – not titles. One persona may be representative of a variety of titles depending on the problem being solved and the hierarchy most commonly seen in the companies in the market segment the persona addresses. What makes them unique is perspective. For example, a role that's responsible for company growth may view a problem or objective quite differently than a role responsible for managing costs. Think CEO vs. CFO.

Sometimes you want to identify negative personas, people that you are not designing for.

Personas provide you with the opportunity to integrate real User Experience throughout your project.

Personas are a major part of the user story-writing ceremony. Without them, we do not know who the work is for.

A simple template is used and can be customised based on your needs, but these are probably all you need to get started - too much detail, and they become useless. Too little, and they are too generic - finding the sweet spot will be up to you.

Template:

What we are looking for is "specific generalisation" - be specific enough to ensure that the persona is usable but generic enough to ensure that your time creating them is used wisely.

Note: specific generalisation is a term used in mathematics, particularly facial recognition and cartography, where regular approximations allow for information to be gathered and analysed quickly.

Hierarchy of Personas

Within an organisation, there are usually many solutions being created all over the place by different teams. But there are often a lot of common users between these solution teams.

By creating a global persona registry, we can start to reuse personas and share knowledge about our users with the rest of the organisation.

If we create the persona registry as a hierarchy, we can start to segment our users based on role, customer or stakeholder type, or any other attribute (for example, geographic, demographic, psychographic, or behavioural segmentation).

From here, we can further break down the personas for our solution. If we are creating a motorcycle insurance claims solution, for example, we might look at the staff involved as this:

As shown, we can also include the template here to help further understand the persona. Ultimately each persona will have the template filled out, but for the first cut, don't worry too much about filling it all out. Go wide first by getting all the personas, then go deep and fill out the details as required.

The same can be done for the other global personas:

The policyholder is one of our primary personas; therefore, more detail should be provided here. There may be personas that are identified but not used for this solution, e.g. "School Runner", - but don't waste the data. Make sure that you capture it, as it will undoubtedly help other teams later.

Sometimes there may be occasions when a persona has two or more parents. That's ok. This isn't an organisational chart or family tree - do what you need to do to convey the information in the best way possible.

Each solution should start with the global persona set and use what they can - if there is insufficient detail or a persona should be broken up, then do it. But make sure to categorise the new personas correctly to ensure that they can be found easily and reused by other teams.

Inputs & Outputs

Inputs

• Solution knowledge from stakeholders and team members.

• Research of user behaviour, demographics, etc.

• Marketing personas, if available.

Outputs

• Set of personas that you will use for this solution.

• Updates to the global set and any new personas are categorised for reuse.

Procedure

Typically personas are created as part of a larger workshop, either in Conceptualise or Commence modes.

While understanding the problem and breaking the problem down into smaller, more manageable problems, a set of personas will present themselves. At first, just capture all the "names" of the personas - don't worry about the hierarchy yet. Let this happen organically - just listen for the names as they are spoken in terms of the problems.

For example, "What happens when a Motorcyclist who only uses their bike for commuting applies - is that different?", "Yes". Then capture something like "Commuter Motorcyclist", - which can lead to other conversations like, "Are there any other types of motorcyclists - what about them?"

If there is already a global set of personas, make sure to bring them along. They will help with brainstorming the problem from different perspectives.

When you think that you have enough, then you can rearrange the personas into a tree. Don't worry if it's not perfect or a "valid tree" - the point is to see the problem from all perspectives to figure out where the benefits reside.

Additional Uses: As a story-writing aide

When writing a story, you are hopefully breaking the work down from an epic or larger piece problems statements.

A how-to guide to writing features can be found in Confluence. A good structure to use is the following:

As you can see, this includes a list of personas, benefits, and acceptance criteria - all just as bullet points and quick notes.

Personas can then be categorised into one of the following:

This helps validate that we have got all the right personas, as usually, you want at least one in the first three categories. The 4th, Facilitators, is not as common and usually, any stories pertaining to these groups are non-functional or purely tasks that the team needs to do, but having it here helps to determine if they are important or not.

We can then create a simple matrix of acceptance criteria (AC) and benefits (BN) vs each of our personas by placing a tick in each box.

Some boxes may have more than one tick. Some might have none. But if a persona has no ticks at all, then we can question if there are actually personas included in our solution at all - or do we have the wrong AC/BN captured?

Another clue can be found where a persona only has AC - that might mean that we haven't captured the right benefits yet. The same goes for BN. If a person only has BN and no AC, then maybe something is missing. These are not rules - they are indicators to help you quickly see if something is missing and allows you to ask the right questions at the right time. If you miss it, you'll undoubtedly find it out later (if nowhere else when it goes to production or when sales are down!). The key here is to find it as soon as possible.

Additional Uses: As a test resource

Personas can be used for testing as well as writing stories - especially when you are looking to do automation.

As our persona is a "specific generalisation", we can then create prototype personas that can be used for testing.

This helps to remove the age-old problem of "Which user can I use?" or "What is some good data that I can use to replicate this defect?" by allowing testers and developers to have a common reference of data.

For example, our MC commuter could be any of the following:

Furthermore, this can be automated quite easily, especially when using tools like BDD and Gherkin language, which allows for rows of tabular data to be injected into each iterative run of a test.

For example, our BDD might be:

And our examples can be used directly from here. These can obviously then be stored in a database or a file and added to over time.

Alternatively, if your automation is advanced, you could also auto-generate these and create them on the fly, ensuring that there is always fresh data to test with. But, having the table first works as Acceptance Criteria for the test automation developer as they have a working example to duplicate.