Personas in UI/UX design
A fictional person as a representative of a user group
The concept of the persona was first introduced by software developer Alan Cooper in 1999. At the time, software products were still being designed by developers themselves, which usually meant that actual users were unable to find their way around them. On the one hand, there was a lack of knowledge about the needs, requirements and behavior of the users. On the other hand, developers never had the intention to put themselves in other people's shoes in order to design the user interface accordingly. Alan Cooper wanted to change this and developed the persona to help developers design software from the user's perspective. This is a fictional person based on real, collected data and represents a group of users with similar characteristics. A persona can therefore be understood as a kind of data model, which is usually documented in a profile. In addition to a name and a photo, personality traits, wishes and interests as well as behavioral characteristics are noted there.
Design persona vs. marketing persona
Personas used in UI/UX design should not be confused with other variants of the persona. These are also used in marketing, among other areas. However, the focus there is on purchasing behavior and not on user behavior when interacting with a user interface. Accordingly, other data is relevant.
There is also a risk of confusion between personas and target groups. The latter is an abstract description of a user group based on quantitative data. Personas, on the other hand, are specific and primarily based on qualitative data.
Precise instead of elastic users
When talking about the user within a project team, there is a risk that everyone involved has a different person in mind. This is usually based on their own assumptions and, in the worst case, is even stereotyped. This should be avoided with the help of personas. The precise definition of one or more personas leads to a common understanding within a project team. So when talking about the user - or even better: the persona called Max - everyone involved has the same person in mind. This also helps to avoid the phenomenon of the "elastic user". If the user is not defined, it can happen that the characteristics of the user are adapted to the needs of developers or designers during the course of the project. Then the beginner who needs support from the system suddenly becomes an expert who can operate the system straight away without any problems. This avoids problems in the design and development process rather than finding a solution. The phenomenon of the "elastic user" can also be avoided by documenting the characteristics of the user. This occurs when the characteristics and requirements of users are adapted to the existing product, which means that problems are avoided rather than solved. If you put yourself in the shoes of the personas, potential problems can be uncovered and solutions developed or validated. This is an important advantage of the persona: obvious problems can be identified before testing with real users. This saves time and effort when evaluating a system.
Common mistakes in the development and use of personas
When we talk about a persona, most people think of the profile in which the information is documented. However, this is only the documentation and not the persona. This should not only exist on paper, but in the minds of all those involved - like a person you have actually met or a character from your favorite TV show.
When developing personas, people often make the mistake of basing them on their own assumptions rather than on collected data. As a result, stereotypical characteristics and incorrect information are incorporated, which means that a persona is no longer representative of the actual users. This can happen if you are not sufficiently informed about the method or because the effort required to collect the data is considered too high. After all, the process of developing a persona involves collecting and evaluating data, deriving several personas, documenting the information and presenting it to the team. However, this effort is absolutely necessary in order to create truly representative personas.
Another mistake is to create personas as profiles and then not use them any further. You might think that you are finished with the method and can move on to the next one. However, the benefits of personas only begin when they are used in combination with other methods. These include, for example, jobs to be done, use cases and user journeys, which can be completed and applied much more reliably and precisely.
Conclusion
Personas can be highly beneficial for UI/UX projects, as they contribute to a shared understanding of users within a team and can provide quick answers to design questions. However, to fulfill this benefit, representative personas are required. And these require a great deal of effort in terms of data collection and evaluation as well as regular updates of information. If this is not taken into account, it can have serious consequences for the product. Relying on made-up personas can lead to great dissatisfaction on the part of actual users and cause even greater expense if major changes have to be made to the product after release. So if you decide to use personas, they should be developed carefully.
Do we use personas?
Compared to the benefits, we consider the effort involved in creating representative personas to be too high. In addition, changing requirements in agile projects always require new information, which can only be obtained through your own imagination in addition to the data collected. However, this can lead to unreliable assumptions that can distort the actual user-centricity of a project.
So before collecting and evaluating further data and entering it into the personas in order to be able to put yourself in their shoes with a clear conscience, you can also talk to the actual users. We therefore rely on direct communication to ask about requirements and carry out tests. This gives us precise feedback and allows us to respond directly.