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
  • Tools
  • Work place/environment
  • Attitude/mindset
  • Major pain points
  • Needs
  • 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.

Not logged in
  • Anonym  5 years ago

    Thanks for this definition Caro. Your description describes indeed the minimal scope of a persona. However, I very often find that personas include not only a name, age, and picture to make them more tangible, but also things like number of children, marriage, hobbies, etc. In worst cases, creating these attributes can eat up a lot of time, In best cases they just add more stuff to read for the project team. I know they should help create empathy, but I fail to see the benefits of these things for a typical project.

    I even go a step further and argue that adding to much personal information to a persona can be quite harmful. Why? For two reasons:

    Number one is that the team focuses solely on this persona and the moment you meet a person who does not have these attributes the team will say “this is not our persona, we can ignore his/her input. But a target group can be quite diverse. Just imagine you are building an application for creating leave requests. You will find people of every age, gender, background, characterstics, etc. The persona you are building will only represent a small piece of the target group.

    Number two: I have yet to come across a persona that is based on research. Most of the personas I get presented are made up by the team, they are brainstormed or written down by the one person in the team that had some contact with a potential persona in the past. But the moment you create the persona and give it a name, the team takes it for face value and treads it like it is “the thing”. I hardly remember a typical project that changed the persona once it has been created or even started to research the persona. So the persona gives the false impression that it is based on real data, just because it is so detailed and specific and sounds real. That is why I, honestly, am not a big fan of personas at all.

    So next question: what to do instead?

    Answer: Visit REAL end-users in their REAL WORKING ENVIRONMENT. That creates more empathy than the best persona you come up with. Every project I have ever worked in that did on-site research did not need a persona because the team talked about “remember this person…”. So we should take every effort to get everybody in the team to get in contact with a real person, instead of focusing on creating personas (and yes, I know it is hard and expensive and time consuming, etc. etc. etc., but it can be done!). Project teams should truly KNOW their users, and not only personas.

  • Marc Dehnke   5 years ago

    Thanks Caro and Conni! I am totally with both of you albeit I must say that I can only support Conni’s last statement.
    While I totally acknowledge either approach I have a hard time defining a persona which represents all relevant peers (gender, age, etc) in case of one of two key personas I have to deal with at the moment: one is a fleet manager , the other is a driver/operator basically ..you and me.
    That said, I – in my project area, am perfectly satisfied with a very basic persona description since any additional characteristic suits maybe many but not all – which leads me to focus my research on basically arbitrary colleagues because whomever I choose will contribute proof to what already has been defined requirements-wise. This way I may not have “one” clearly-defined theroretical persona but a wealth of valuable info to select and filter from to eventually come up with feature-laden design solution matching exactly the users’ requirements.

  • Ramona Winkler   5 years ago

    I must admit that I have good experiences with personas, but I also see the point that personas can do more harm than good if they are not based on input from real end users (or validated against it).
    In most of my user research projects the teams did already have a persona that they created based on assumptions about their end users. That is, the persona was an artifact from the team discussions at the beginning of the projects about who their end users are. After we conducted interviews with end users at their workplace, we analyzed the data, created end user profiles, and updated the existing personas accordingly. These validated personas served as a starting point to learn more about the target end users of the application for colleagues who joined the team at a later point in time, but also for other projects with the same end user profile.
    While I agree that nothing is better for creating empathy with end users than seeing them perform their tasks in their work environment, the truth is that not every developer will get the chance to visit customers and observe end users (esp. not in bigger project teams). Therefore we need good methods for creating empathy, and in my opinion personas come off pretty well. A rich, detailed, text-heavy profile will serve the purpose not so good as a persona with a name, a picture, and all the important information from the profile displayed in a more visually appealing way.