<aside> đźš© A persona is a description of a hypothetical yet realistic user of a design intervention, intended to represent a subset of all possible members of a particular user group.
</aside>
It’s common practice to develop hypothetical archetypes that represent the most likely combinations of characteristics of people in a given user group. An archetype of this sort is called a persona.
Personas capture the edges of the “envelope” of HFs, because if you can design for the edges of usability, all other users will also be satisfied. Personas combine individual HFs into reasonable though not necessarily likely wholes.
Fig 1: Well, that won’t do!
A good Persona will help you resolve mismatches between an intervention’s human factor demands on its users, and the capabilities of those users.
Personas can come from any user group. However, in this introductory design course, teams should focus on the end users and co-users.
Personas help you view a design situation from the perspective of different users.
While no one perspective is completely correct, they are all partly valid, at least from the point of view of the user.
Considering a problem from multiple perspectives helps designers see the real problem that all users have, thus helping to ensure interventions that satisfy as many users as possible.
Fig 2: Different perspectives benefit designers.
Many questions about a HF mismatch take the form of “What can such and such a user do?”
Each of these questions involves a user in a specific situation involving a product. What might happen in each case depends on the answer to the question. For instance:
Personas are used to specify the kinds of users for which you must design, and to make sure that everyone agrees to the abilities of those users. Thinking about the consequences for those users will help you design a better intervention.
Can you prevent the child’s finger getting stuck in the toaster?
Can you design a life-raft that a person with PTSD can easily operate?
A person with PTSD will very likely be differently abled than a construction worker or a child near a toaster. An appropriate design will interact successfully with users of diverse abilities in particular cases. That's why you need different personas depending on the kind of intervention you're designing and the situations in which those users find themselves. The set of personas you create for a project will become essential for thinking through the experiences your users will have while interacting with your intervention. You want to try to make sure all users have a safe, efficient, and effective (and, possibly, even fun!) experience.
How could anyone mess that up, you ask? It's easy! If you're not treating your users properly and respectfully, you will cause harm. Look at Figure 3 (click the image to embiggen, or read the source). These are actual persona descriptions developed by previous years' students in MEC325. Note the highlighted phrases.
These kinds of descriptions were rampant throughout students’ Personas.
Fig. 3: This is how it starts; and it always ends badly.
Personas lie at the edges of the HF envelope of user capabilities and limitations. That is, they should represent people who would likely have difficulty using any of the reference products you reviewed in your Situation Scan. Personas are very useful for thinking through how to handle those limitations.
Unfortunately, students rarely represent the actual population with their Personas. In Figure 4, you can see how far off previous years' teams have been. It's important to represent your users accurately, and it's important to learn how to look things up.
Being a student does not excuse you from due diligence. While it's understandable that you may design for “what you know”, it should be glaringly obvious that it’s easy to look many things up! If you cannot demonstrate due diligence to your users by accurately representing them, then you don't deserve to be an engineer.
Fig. 4: You have to reflect real life.