Personas and archetypes help you understand and model the characteristics of the groups of people who will use the proposed tool.
- Personas are grounded in evidence;
- Archetypes are assumption based, and reviewed, less rigourous than personas but still useful;
- Stereotypes could be described as "badly drawn" personas or archetypes based on unexamined assumptions, even prejudices;
- A good archetype is more useful than a stereotype.
Ideally to build personas we interview a representative sample of users. With a small number of users you may be able to interview them all. With a large population you need to use a method that helps you understand groups that represent your users.
You can:
- Map personas around preferences and perspectives;
- Map personas around communication and work styles;
- Map personas around roles;
- NB: Perspectives, preferences and styles may cut across roles rather than align with them;
Ways to collective evidence for personas include
- user interviews and workshops (takes time, but can be thorough);
- using sampling, or statistical methods based on usage data if this is an existing tool with analytics collected (but you only learn about existing customers);
- using the heuristics to help you build an archetype as a starting point towards personas (you will need to customise to your context);
- use AI and prompts to build the personas (beware! they may not be accurate!).
There is much evidence that interviewing a sample of real users is still the best way to build representative personas, for example see the CHIRA 2024 paper "Interviewing Chat-GPT generated personas to inform design decisions" by Jemily Rime which compares personas generated through user interviews to personas generated by prompting Chat-GPT and critiques the bias in the generated personas.
Heuristics H03 to H12 help you add details to the characteristics of the personas, and understand their contexts. The Quality Attributes information will help you enrich the personas.
Suppose we are building a tool for a large group of people to use, and we don't know them, and cannot interview them. Ideally we might run workshops with a group, but depending on how we select the participants, and who is willing to take part we still might not get a representative sample. We can use the heuristic questions and a classification tree to start us thinking about who might use the tool and what their preferences might be. This won't give us personas, but it might give us a clue about some questions to ask during the design, and some user research areas, helping us to build archetypes.
The worked example below shows one approach. To reach a set of personas for your context, you would need to build context-specific classification trees similar to these, and then build on them with user interviews or other evidence.
Worked example of thinking about the heuristics to help plan a set of archetypes or personas
Heuristic H04 is about communication preferences, and if we don't know that about the people who we want to use the tool, we could model it based on - for example - the DISC profile, giving us four potential communication styles - Blue/conscientious, Green/caring, Red/dominant and Yellow/social. That communication preference affects how they want to receive and give information. Blue and Green tend to be more introvert, reserved. Red and yellow tend to be more extrovert, outgoing. Blue and Red tend to be focused on process and results. Green and yellow are more focused on people. We might imagine their tool interface preferences: blue might want a detailed spreadsheet, Red might prefer bullet points on a powerpoint slide, Yellow might enjoy a chatting channel such a Slack. Green might want to work in a group at a whiteboard... Is it worth thinking about how a tool might allow data to be shared between interfaces that allow both detail and overview, and allow both individual and group work?
We could therefore start our personas by imagining at least one persona for each DISC preference, and start a claasification tree.
(personasegmentH04.jpg)
Heuristic H05 asks us to think about what type of learning people want to do when engaging with the tool. Are they wanting to master the tool and invest in the time to do that? Or, do they have limited time and simply want to carry out the next task. Both are reasonable approaches, and the same person may want to take different approaches at different times, or with different tools. They might have constraints because of budget pressures or management expectations. They may want to try out the tool quickly and then commit to mastering it.
Therefore we might need quick-start routes, wizards, short task-based videos, and also training/apprenticeship routes for mastery.
We can draw another mini-classification tree to show this split in approaches.
(personasegmentH05.jpg)
Different people prefer to learn in different ways, and this may match to their communication preferences or be different. people may move from group to solo preferences and back again depending on context. There are three areas we could start to consider: solo or group learning, theory or practical learning and the preferred media. Remember this also includes preferences, accessibility and also relates to H05 - for mastery we might want some theoretical basis, for task based we may prefer to be practical.
We can draw this in another classification tree segment, breaking down as:
- Solo or group?
- Solo
- Group
- pair learning
- master - apprentice
- teacher - group
- ensemble
- more theory or more practice?
- more theoretical
- more practical
- preferred media
- video
- audio
- text
- hands on
This is shown in the figure below:
(personasegmentH06.jpg)
Once we have those segments, we can assemble the whole classification tree, adn we find that we need 5 personas to cover all the options, because the learning preferences for solo and group break down into 5 branches.
The diagram shows we have named 5 persona groups with suggested preferences. This can make the basis of a fuller persona definition, tailored to our spefici context.
- Andy has Blue/C communication preferences, prefers solo learning, with theory in audio and text, to reach tool mastery
- Bill has Green/S communication preferences, preferes pair learning, practicall based, through video and hands-on, focused on completing the next task
- Carol has Red/D communication preferences, would like master/apprentice training that is practical, includes videos and hands-on learning, and is for tool mastery
- Dee has Blue/C communication preferences, would like a taught class, with some theory, through audio and text, for tool mastery
- Edi has yellow/I communication preferences, would like ensemble learning that is practical, hands-on, with supporting text and focused on the next task to be completed.
(personasegmentcommsandlearning.jpg)
We can also add role-based characteristics - in the next figure, a set of assumptions have been made about the archetypal roles who might use the tool, their levels of authority and team autonomy (H10), the workflows they might be involved in (H08) and the risks associated with those workflows (H09). This adds to the personas developed above with archetype assumptions. In the diagram as it is drawn:
- Andy is a test analyst, mainly using workflow 1, which includes tests for high risks, and has low authority and low autonomy;
- Bill is a product owner, mainly working in workflow 3, low risk area, with high authority, in a team with medium autonomy;
- Carol is an automation engineer, mainly working in workflow 3, medium risks, low authority, medium autonomy;
- Dee is a quality coach, across the workflows, they work across the risk levels, they have medium authority and medium autonomy;
- Edi is a developer, on workflow 1, high risk level, medium authority and high autonomy.
This version of the diagrams is a starting point for a discussion - it will be different in every context, but the idea is that the choices can be changed in discussion of the assumptions. The two diagrams together make the starting point for archetypes or personas to be more fully developed.
(personaclasstree-roles.jpg)
We found that people testing are a much wider and more heterogenous group than meets stereotypes for IT workers. We found that tools often were designed for a more narrow and stereotypical group.
To add to your personas, we have added quotes and other research points to each of the heuristics' explanations - Use these ideas as a "pick and mix" menu, for example:
- educational background: most of the people who took part had degree or postgraduate qualifications:
- but 16% did not have a degree;
- and although some of those with degrees had a software engineering qualification, many did not - degrees included arts, humanities, sciences, social sciences;
- people's degrees didn't predict their role: 42% of Arts graduates in technical roles, 40% of Social Science graduates in technical roles, 44% of Science graduates in technical roles, 41% of IT graduates were NOT in technical roles;
- Suggestion include different educational backgrounds in your personas, and don't assume IT or software knowledge to help you think about learning support and communication preferences;
- work background: many of our participants had previously worked in non IT roles, sometimes in the domain for the software under test, sometimes not:
- Suggestion include different work and background experiences in your personas to help you think about the language people use and their learning support requirements;
- learning preferences: different participants had different preferences for how to learn:
- these did not necessarily match their usual communication preferences and styles;
- Suggestion include solo versus group learning and problem solving preferences, include preferences for different media based on communication styles, use the examples in the heuristics to add to the personas.
Unless you have a small number of specific people using the tool, it will always be useful to make groupings by persona or archetype to help you identify the range of preferences, perspectives, styles and characteristics that people using the tool may have.
Gain a better understanding of people who will use the tool, while managing that in a small number of representative groups, rather than a myriad of individuals.
Takes time to do well.
NNGroup have a really useful summary with links to many ways of building personas
Personas may be more or less broad in scope
Having got your personas or archetypes, you can build usage stories per persona, which can be simple stories or scenarios and you can build empathy maps.