My team at the University of Edinburgh, Website and Communications, have been using personas for more than a decade to help inform decision-making around product development of a content management system.
Those personas served the team well over the years. But with our work to reimagine the future of our web services, and our attention turning to the development of a new web publishing platform, we recognised that these personas needed to evolve.
Co-designing a new iteration of personas
We undertook a programme of user research into the needs of our web publishing community. This research was not just with people directly involved in editing or managing websites. It also considered others in the wider web publishing ecosystem, such as academics and senior managers — people who may not directly edit their own content, but still have an influence on decisions surrounding the web estate.
Through one-to-one interviews, co-design events, and activities during community sessions, we worked with more than 100 people to enhance our understanding of the users of web services.
Outcomes of our co-design activities informing future web services
As part of these events, we asked people to edit the existing personas. This told us which parts of the personas actually resonated with our users, and what elements were missing.
As the co-design activities continued, the personas evolved to become even more role-focused. At one stage, these were distilled back down to six interim personas, focused on roles like:
- Tech expert
- Communications/marketing manager
- Senior manager
- Academic
Using these role-based personas worked during the co-design sessions because it enabled participants to more quickly relate to them and engage in the activities. For example, academics could quickly gravitate towards “their” academic persona, and communications specialists could identify with the communications persona.
But interestingly, participants often created multiple versions of each role-based personas. Often, academic variant 2 had more in common with communications manager variant 2 than with academic variant 1.
So while the emergent role-based personas were useful at helping our participants engage with the activities, they were proving less useful at helping our team understand our users. That is why we thought of them as interim personas rather than anything more permanent.
A different type of persona — moving towards behaviour modes
At this stage we began to take inspiration from prominent examples of personas going beyond demographic information and roles.
Indi Young has outlined the dangers of focusing on demographic details in your personas:
Demographics can cause assumptions, shortcuts in thinking, and subconscious stereotypes by team members…
We could see this in the way the old personas were sometimes used. It was easy for people to accidentally drift towards lazy, stereotypical thinking about our users: “The comms specialist wants a shiny carousel! The tech expert wants complicated functionality!”
Our approach to tackling this problem was to adopt behavioural archetypes, as outlined by Radina Doneva:
Behavioural archetypes are structured models of customer responses to a brand. As the name suggests they tap into the behavioural level of cognitive processing. In a nutshell, the focus is on who does what, how they do it, and why.
We also drew heavily on Co-op Digital’s case study of developing their own behaviour modes instead of traditional personas:
Cognitive empathy requires not a face, not preferences and demographics, but the underlying reasoning, reactions, and guiding principles.
Creating behaviour modes
To create new versions of our personas more aligned to the behaviour mode approach, we ran some sessions within our team to establish the common groupings of behaviours among our users.
To do this, I created a digital whiteboard containing sticky notes of the insights we’d gathered through our user research. This included some high-level findings from our interviews, and many of the common items that users had added to the interim personas thorough our co-design sessions. But crucially, I mixed these sticky notes up, and avoided all mention of our previous persona names.
Through remote workshops, team members began to create their own groupings from the sticky notes. The only golden rule was: no contradictory items in the same group. So “My web presence needs to make a big impact” couldn’t be in the same group as “My website is not such a high priority”.
From our initial activities, we quickly identified four main groupings. These were gradually refined over time to become our four new personas.
Our new behaviour modes looked like a major departure from the original personas. But it all began with our users making scribbles on top of those 10+-year-old originals. These personas are now rooted in over a decade’s worth of research, thinking and experience — but reformed in a way that brings them fully up to date and relevant to our current work.
We have already found it highly useful to work with our personas to drive our decision-making around aspects of the development of the Design System as well as the new Web Publishing Platform.