A persona is a description of a typical user for a particular use case or scenario. It goes back to 1998, where personas were first introduced by Alan Cooper as a design tool and grew in popularity in the software industry rapidly from then on. Personas, as we use them today, can include different characteristics and are created mainly to help the development team to understand for whom they are designing the product. Shared knowledge about the user is the focus of a persona. It is helpful to the team as a guide when deciding about product features, functionality and visual appearance. The minimum attributes a persona should include are:
- Professional background and experience
- Core business tasks
- Core business responsibilities
A persona can also be an instrument within the team to evoke empathy and to stop arguing about individual opinions. Therefore it should always be an aggregation of research data. The more characteristics a persona includes the higher the empathy level will be with it. So a typical persona would include, in addition to the attributes above:
- Name, age, picture
- Working style
- Communication style
- Work place/environment
- Major pain points
- Collaboration with others
These attributes clearly show that a persona needs to be fitting for the product. The persona will inform design decisions and help the team to prioritize functions and features. Personas help the team to understand user needs and accelerate the design process. Therefore it is crucial that the persona be based on actual data and is not some fantasy exercise on the part of the team.
A persona can have various formats: it can be a handwritten poster with pictures of a typical work environment affixed to it, it can be a PowerPoint slide including diagrams, or it can be a structured table; basically it can be anything that fits the team’s working style.