B2B - User persona canvas

Detailed persona guide

Users personas are especially useful when designing a new system. They allow you to empathise with the needs of specific groups of people and build a system that meets their expectations. User stories can be used to capture these requirements:

• As an accounts administrator

• I want a report on who has completed their monthly accounts

• So that I can ensure everything is submitted on time for tax calculations

Once you have gathered the high-level requirements of these users, you can prioritise. The next sections describe in detail how to use the canvas.

Persona name and photograph

Personas are representations of people. Naming them can make them feel more real. Use a real photograph of someone who represents your customer. Make sure this isn’t someone famous, as that will impact the way people think about them.

Persona overview

This is a summary of the type of person this persona represents. Use this to bring them to life. Give some relevant background information on who they are.

Segmentation

There are three parts to segmentation. Here is an example:

• Segmentation category - Technical ability

• Segment value - Low

• Segment information - This user struggles with complex operations. They can perform basic tasks that have a few steps. They are best supported over the phone and will often need the same advice several times before they can do a task themselves.

Use one or more segments to build up a picture of the type of person you are modelling. Avoid going over four segments.

Software considerations

For software, consider starting with segments that differentiate users based on the following:

• Use the product very differently due to different needs. For example, a manager who only reviews reports

• Having a very different skill level

Differentiating software skill levels should impact your UX design. If you are working with low-skilled users, consider:

• Minimising the number of steps to achieve key tasks

• Hiding advanced functionality. By, for example, creating an “advanced” section on a form

• Support tools such as bots or AI

• Well-designed UX that makes everything easy to use (you should aim for this regardless of skill level)

Segmentation categories

Here are additional segmentation types you can consider:

• Demographic segmentation - e.g. age, gender, income

• Geographic segmentation - e.g. where the person is located

• Behavioural segmentation - e.g. time of year, usage, customer loyalty, benefits sought

• Psychographic segmentation - e.g. social class, values, personality, activities and interests

A common anti-pattern is selecting a segment that points to something else. Let’s use some examples to make this clear:

• Selling a 4X4

  • Geography = Lives in the mountains

  • What we really want to say is that they are going off-road. In this case, this segment would be more suitable:

    • Off-roading frequency = >10 times per month

• Selling running shoes

  • Age = >60

  • What we really want to say is that they are unfit. Using age is a generalisation and in many people’s cases very wrong. In this case, this segment would be more suitable:

    • Fitness = low

Number of personas

Avoid creating too many user personas, or you may find the following issues:

• It becomes challenging to identify and build specific software requirements for each of them

• Struggle to find users to test with as they are so narrow

• May find yourself performing excessive amounts of the same user testing to meet similar user’s needs

• Find niche user needs that are not worth servicing

Create different personas when you have:

• Very different skill levels

• Very different needs

Let’s use some examples:

Skill level considerations

Let’s say 95% of your users have high technical ability. You may decide not to cater for the remaining 5%. Considering their needs would mean significant changes to the product, resulting in very high costs and representing little value. In this case, you may decide only to create one persona.

Needs considerations

Let’s say you have a specialist group of users who want to be able to perform data analytics using code. To implement these changes would be very costly. Your product is functionally rich enough to provide most of the analytics needed by most users already. In this case, you may decide not to create a persona.

Persona anti-patterns

1) Not based on research

Making up personas is the number one anti-pattern. This means you have made a lot of assumptions about your customers or have based them on poor-quality information. If a product team wishes to get together and create personas, this is fine as long as they are validated later. Defining quantified problem statements is good practice as it requires research.

2) Irrelevant information

Talking about irrelevant information in personas, such as the fact that the person has a dog and enjoys walking. This information has no value to our product development. This anti-pattern is common when people want to bring that person to life, but it isn’t helpful. This can be found on the canvas in the persona overview section.

3) Not using them in product development

You should look for real people who match your personas and then use them to test out ideas and new products. You may have several personas if you have a large product with many features. When creating new features, these may be targeted more towards specific people. In this case, make it clear in your strategy which persona the feature is aimed at. Be careful when targeting features only for people with a high skill level. In this case, always try to make your UX easy to use.