TL;DR – Brief description Persona:
A Persona is a fictitious figure created to represent a group that could use a website, software, brand or product. The Persona is made “alive” with image and description and ensures that you can better put yourself in the position of this person in all requirements to be planned (software feature, UX, purchase process, etc.) and think through all aspects as this person. This is easier and leads to better results than working abstractly with sociodemographic target groups.
The persona is often used in Scrum or other agile development processes in the areas of user story, user experience (UX) and testing. Personas can still be found in online marketing and content marketing.
The persona as a central element of user stories
In software development, the term “persona” for a representative user of software was already established in the 1980s by the developer Alan Cooper. In today’s agile development, personas are now de facto standard for all planning that concerns the user or customer.
First and foremost, the persona becomes important in the user story (further uses later in the article series). User Stories usually have this structure:
“As <role> I want <goal/wish> to <benefit/problem solution>”
The reason for this structure is explained in a separate article on the topic “User Story“. For the persona we are interested in the area <role>
The User Story is a short software requirement formulated in everyday language. Since we want to work very customer-centric, we formulate it from the point of view of a user who wants a problem solved or a need satisfied.
“As a customer, I would like to have a large selection of payment options in the online shop, so that I can pay as simply as I want”
This everyday language formulates for developers the “what” of a development to be created. The “how” is left to the developer. On the one hand, this everyday language should make it easier to raise the requirements without having to write huge specifications. On the other hand, each team member involved should be able to empathize with the person and ask themselves: Would this be in the interests of the customer?
This would be difficult if we were to work with socio-demographic target groups, as in classical user analysis. Our target group is male, 35-45 years old, upper middle class, etc … – But if we now have a “real” person in front of our eyes, with a picture, name, profile and history, we can almost imagine how this person sits in front of the computer and uses what we are currently developing.
Personas also have the advantage that they are not as arbitrary as a sociodemographic group. It’s easier to make a feature appealing to a handful of small personas than it is to a large unspecific group. So you don’t get bogged down in any broad and uninteresting design of features.
Disadvantages of Personas
Maybe you’re wondering: If personas are so great, why doesn’t everyone use personas everywhere?
With all these advantages one big disadvantage should be taken into consideration: The persona is a fictitious individual, which is usually based on a few specific data – if at all. You should therefore be aware that there is no clear direct reference to real customer data and that it should be used with caution in areas where this customer data is needed. For example, no persona should be taken as a starting point for scientific analysis.
Personas are part of an agile process. This means that personas and their results should be applied iteratively and in short periods of time and then checked and questioned. Do not apply Personas as absolute truth!
Let’s start with the creation of a persona by classifying it first.
Classify and categorize Personas
1) Determine participants / profiteers of the persona
The Persona has the potential to be the cross-departmental and cross-professional basis of all action. Attention: As you can read in the previous section, this is limited to agile environments where there is no clear reference to real customer data.
Depending on the corporate and departmental structure, the following corporate areas could be involved and synchronized:
- Requirement collection of software or hardware requirements
- Requirement collection of User Experience Requirements
- Online marketing
- Content marketing
- Social Media Marketing
- Purchase processes
- Registration processes
- Testing and UX Testing
- Design decisions such as appearance of hardware, GUIs, corporate identity
Goal of step 1:
Find the appropriate departments/employees and invite them to a kickoff meeting for the persona creation.
2) Determine the type of persona.
We now have to specify the type(s) of persona(s) in the kickoff or subsequent appointments:
a) Persona as starting point or target?
Depending on the age and/or orientation of the company, the persona should either represent the current customer – or the future customer. This distinction is important! For example, in a company that is not yet on the market, you can model exactly the persona you want to reach. The first is much freer and the creation of the persona can influence the company direction back if necessary.
b) Categories of Personas
We can distinguish between 3 groups of personas:
- Primary Personas
- Secondary Personas
- Ad-Hoc Personas or Proto-Personas
The Primary Persona is someone who can be served as completely and satisfactorily as possible with our developments. The primary persona must not be hindered, restricted or disappointed by developments generated by other primary personas. In the most extreme case, several contrary primary personas ensure that several products are developed.
Example: We are a company for simple amateur radios. There is now the primary persona of a 35 year old CB radio amateur and the primary persona of a 7 year old child. Since the technology of the devices is the same, the management wants to reach both groups. Both have however few identical requirements, but many contrary. So it can lead to the fact that we manufacture different products. For the child, the simple pink Hello Kitty radio with just one control button, which our CB radio operator would probably not be satisfied with. Whether it makes sense to operate all personas is an individual business decision and should not be the issue here. In order to satisfy both, it would lead to two teams developing two products while respecting primary personas.
The Secondary Persona is very similar to the primary persona in characteristics and wishes. However, there are few small differences that need to be taken into account. These must not influence the primary persona, but the secondary persona can benefit from them.
Example: In our CB radio example the secondary persona could be an older person with lower vision. This would lead to additional requirements that the inscriptions on controls be slightly larger. Does not disturb our main user, but has advantages for the secondary user. Here, too, the question should be asked as to what the cost/effort ratio is for secondary users.
The Adhoc-Persona or Proto-Persona is a special type. The first two Persona types are based on data (see also the next article in the series). For the proto-persona there is no data, only assumptions or a well-founded assumption. Either because you create them spontaneously in the course of a planning meeting (e.g. to investigate different possibilities for exotic users) or because you don’t have any data yet. In the latter case you should verify the persona with data at a later time.
Example: In a meeting someone has the idea to connect the radios from the previous examples with a Smart Home system. A persona is spontaneously created who is assumed to be a Smart Home customer. Now one can put oneself into this persona and think through whether this connection makes sense.
c) Types of personas
It is helpful to think through the context in which the persona moves. For example, one could think of these 3 areas:
- Audience Persona
- Buyer Persona
- User Persona
A Audience Persona is the “audience” that is played on social media channels, for example. A Buyer Persona is someone who gives you the money for your product or goes through your online buying process. A User Persona is someone who uses a product or software.
That can be one and the same person, but maybe not. Example: In a children’s toy the user is a child, the Audience may be parent number 1 following the social media channels, but parent number 2 is the buyer persona you think or know is using the company’s online store.
d) Determine market / environment
It is possible that your company will not only talk to end customers, but also to corporate customers. Or even with partners, to whose end customers we indirectly address ourselves:
- B2B Persona (corporate customer)
- B2C Persona (end customer)
- B2B2C Persona (end customer reached via a corporate customer)
Companies like to get bogged down in too many unclear target groups and markets. If we initially determine the personas as above, it becomes clear very early on how much effort it takes to satisfy them. A company with products for children, teenagers, adults, families, from low to high income, with its own e-commerce in the B2B and B2C market will either make an extremely high effort to satisfy the personas with a lot of individual solutions – or they will not even create personas and with the missing customer view they create an unspecific uniform mush that nobody is interested in.
Personas can’t change the wrong entrepreneurial decisions, but you can indicate very early the possible effort you have to make to satisfy your customers.
Now we have narrowed down the persona(s). But we still need something to create the persona: data!
Data as the basis of personas
a) What problem or needs does the persona have?
In practice, one often finds Personas and Templates that offer far too much information about this fictitious character. Less is often more! The most important point with the persona: What problem is solved by your product or what need is satisfied? If you cannot answer this question, your persona is unsuitable or it makes no sense to address these people – why should they buy your product?
The creation of a product with the answer to the question “What problem will be solved” is not part of this article and will be published later.
b) Procure data
Often there are already existing data dumps from which you can retrieve data. Since the data for a persona is dependent on the company, product and target, it cannot be generalized. The following suggestions can help you:
- Consult the marketing department
e.g. the classic product marketing managers who have sociodemographic data, e.g. the classification of customers in Sinus milieus. A valuable source is web analytics, who can collect particularly accurate data on users and preferences.
- Consult the product managers, developers and designers
Perhaps these colleagues have already given some thought and obtained some data. Maybe there are already UX Pesonas or even real users and beta program participants who may be interviewed?
- Consult the strategists
Is there a strategy department or something like that? Ask in which direction the company is heading, perhaps you would like to develop into a different user clientele?
- Get some data or buy some data
There are many free sources for data, or sources that have many insights ready for small money. For example Statista, industry associations, consulting service providers. You should also have a look at LinkedIn and Xing, where whitepapers are published by companies and consultants. It is worthwhile to follow these people.
Caution with expert opinions
What you should avoid with yourself and also refrain from with the consulted colleagues: If data is available, don’t assume, or guess just because it’s easier. Professionals often have a frighteningly wrong view of the real user!
Always when a discussion round without data drifts into a kind of democratically elected mainstream opinion, I throw this quote into the room that it sums up quite well: Without data, you’re just another person with an opinion.
Create a persona
Important: Limit the circle of personas on the basis of the categories mentioned in the previous articles and choose not to create more than 1-2 primary and secondary personas.
Now you are ready to go:
On the basis of the data obtained in the previous point, a picture of the first persona should have formed. Now you think up a few personal qualities that this person has. So the persona gets a face, a story, a character. And that makes it much easier for the people who later work with the persona to think their way into it!
We start with Master data:
- First and last name
- Profession and industry
- family status
Then we describe the character of the persona:
- Disappointments / Challenges
Ideally, we describe the character in relation to the environment in which you are planning. You should therefore not formulate general life goals, but goals in connection with your project/product. If you have a travel portal, the goal of the persona is a travel booking, with sub-goals like: Money save, unusual journeys without package tourists, or similar.
Further fields you should think well through, since the persona should not become too complex and time-consuming. But depending upon context the following fields are perhaps interesting.
Context: Website, e-commerce or similar:
- Technology affinity
- Used browser, mobile or desktop
Context: Marketing (brand marketing, online marketing, content marketing, etc.) and design
- Psychological type (e.g. after the Myers-Briggs type indicator):
- Introverted / Extroverted
- Intuitive / Sensoric
- Thinking / Feeling
- perceiver / judge
- Favourite brands
- Favourite colours, cars, smartphones, etc.
Try to keep these other fields as short as possible and to identify the most important peculiarity of the persona in the context. In B2B it may be the responsibility and hierarchical level of the person, in registration processes technology affinity and data protection concerns are important. Just think: Which factors distinguish people here from people in other environments?
Fills this data best in a standard template.
4) Template Download
Here you can find the Persona Template for different purposes:
Persona – Total Persona – Basic
checkout process in the travel portal Contentmarketing of a perfume brand
You think that’s it? Not quite! In an agile environment we constantly want to question and improve ourselves, that’s why a Persona Review shouldn’t be missing.
Since personas are not “truths” as described in the previous article, you should review the Personas regularly review:
- After each Sprint you should measure the results, whose planning is based on Personas, and check for discrepancies.
- Set a fixed appointment (e.g. per quarter) with all departments that use the personas to question the personas themselves. Maybe the corporate strategy or the target groups have changed? Personas may have to be adapted or replaced.
- Make yourself constantly aware that there are situations in which the persona is completely unsuitable. Do not fall into the cargo cult that is omnipresent in agile situations: Do something just because you have seen somewhere that it is being done. Or because you have always done it. Stay alert and self-critical.
I hope I was able to give you a broad overview about Personas. I am looking forward to your feedback on the article and your experiences with Personas. Write a comment or twitter about it. Thanks a lot!