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.
More about this in the next article of this series!