3 big ideas
Main characteristics of a persona are life context, indicative quotes, behaviours, motivations, needs and goals, pain points and ways to satisfy
There was a missing axis to account for the degree of trauma people in dispute were going through
As practitioners, designers can’t simply assume our tools are always fit for purpose no matter what the context.
What made us think
Our point of view
Why it matters
How it applies in the real world
Nowadays, Personas are a familiar and widely used design tool. Their popularity is rooted in their ability to build empathy by highlighting the ‘why’ behind peoples’ behaviours. Practitioners who think about the needs of a fictional persona are better able to infer what a real person might need. Personas also help prevent ‘self-referential design’ and provide a reality check by helping keep the focus of the design on the target user groups.
Like all effective and long-standing tools, Personas have become standardised over the years. There are any number of ‘How to’ articles that describe the key components of a ‘good’ persona. These include: life context, indicative quotes, behaviours, motivations, needs and goals, pain points and ways to satisfy etc.
The Personas we create at CEC include a range of these standardised components. As the saying goes, “if it’s not broken, don’t fix it.”
We also map our Personas across a 2 x 2 matrix. This is an effective way to validate that we have the spectrum of users covered and also ensures our Personas are categorised by the most important indicators for the needs of a particular problem or solution.
Our approach to Persona development has always worked well.
Until it didn’t.
Our Personas stopped working on a large-scale project we completed last year for the State Insurance Regulatory Authority (SIRA). Our remit was to help SIRA shift CTP claims from an adversarial process to one focussed on recovery. A key deliverable was a set of Personas to help SIRA understand how their new recovery framework could be applied across the NSW populace.
The Personas we developed were very effective for the first few months of our engagement. They validated initiatives, helped us define channel priorities and guided the range of self-service vs. facilitated experiences SIRA needed to cater for. We were also able to validate the Personas through several rounds of concept testing. But when we were asked to do detailed research on CTP claimants who went into the disputes process, our Personas hit a wall. The research participants for dispute scenarios didn’t easily map to them.
We tried many different tacks to discover what the issue was. Did all claimants in dispute fall into the two quadrants that required the most guidance – against statistical expectations? Were our Personas fundamentally wrong? Did people in dispute need their own set of Personas? We pulled our axes apart and put them together again. We reviewed all the raw data we’d used for the original Personas and factored it in with the new data we obtained from research participants in the disputes process. We scratched our heads.
One day, after a research interview with a person who’d been in dispute process for over 2 years, one of us remarked how much the process itself wore people down. Everyone we’d interviewed had ended up more emotionally fragile than when they entered into dispute, even if they ended up winning. And something clicked! We needed another axis to account for the trauma people in dispute were going through.
The existing Personas were valid, but for some claimants in dispute, the extra complexity and demands of the process showed that, in some circumstances, Personas are not static categories. Designers often point out that real people can have elements of multiple Personas and even move between Personas as they progress through a journey or a process, but the idea of Personas themselves changing over time was new for us.
Our research with people in more extreme circumstances had surfaced the fact that every person in a claims process goes through some degree of trauma not only as a result of their accident but also because of the claims experience itself. It exposed that difficult and extended claims experiences not only affect people but also the Personas they can be mapped to.
This insight was backed up by the Cognitive Triad of Traumatic Stress, a model developed by behavioural therapists to describe how, after a traumatic event people’s views of the world, of themselves and their future, change. These changes range from the subtle to the drastic depending on the magnitude of their trauma. We realised we needed to develop a new type of Persona to account for these changes.
With this insight, we were able to evolve our Personas to show the additional needs and considerations when designing for people in trauma.
I’ve always subscribed to the truism that “a bad workman blames his tools” but our experience developing citizen Personas for SIRA calls its veracity into question.
Personas rightly have a prominent place in our design tool kit, yet it’s important to understand the context of the tools we use. Personas were developed in the 1980s in software development contexts for largely tasked based, transactional interactions. Our work to help improve CTP claims experience required us to engage with people who had all been involved in a traumatic event (e.g. car accident), none of them had a life goal to make an insurance claim and all of them were affected by the process itself. If we hadn’t critiqued our Personas model we never would have surfaced some of our most important insights about how the claims process impacts each Persona type. Nor would we have been able to define the Persona-led improvements required for different phases of the claims process.
Service Design is a developing practice with evolving applications. As practitioners we can’t simply assume our tools are always fit for purpose no matter what the context. The nature of our work is often abstract, so we need to take care when we try to frame it using established methods. We need to engage as critically with our tools as we do with our research data.
Service Design & Research
Understanding and designing for customers