Persona creation background.png

Persona creation

Persona creation



- To reduce call volume to the customer contact centre, which resulted in creating a portal for existing customers

For who
- Toyota Insurance Management (France and Germany)

Things I learnt
- How to create personas
- The difference between the two jobs-to-be-done frameworks (as-activity and as-progress) and how jobs-as-progress can be used to understand user motivations
- Cultural differences between the UK, France, and Germany in car insurance behaviours

Team responsibilities
- Me
Ran 29 interviews that were a mix of discovery and usability testing, presented our personas and process to colleagues in the company as well as a Lunch and Learn for Engine, a service design company that doesn’t have much exposure to these methods, synthesised our data and created the personas
- Me and colleague
Worked on strategy of how to analyse knowledge on users to translate into persona creation

- Creation of 4 proto-personas for a product that hadn’t had any prior, in a company that’s in its early stages of becoming user-centred

Discovery phase

For this project, we worked within the Lean UX framework by carrying out research every sprint to create more informed assumptions about what we were designing and who we were designing for.

Before we began our design sprints, we conducted a discovery sprint. This involved open ended interviews to people who acted like our own customers and was focussed around the journey of interacting with their car insurer from researching, to cancelling, and everything in between.

This enabled us to get a picture of why and how people used their car insurance as well as how it fit into their lives. We were able to see how we differed from our European participants too (we conducted some interviews with British people in our downtime to see if our assumptions were true - they were!). British folk commonly use comparison sites and buy whichever one’s at the top without much of a care of the brand or perks. The French and Germans we interviewed didn’t share this trait. Some didn’t know comparison sites exist, one even doubted it was possible due to their belief that insurance is too complex. Often they took their friends or family’s advice and rarely went for the cheapest option because they knew if they paid a bit more they’d get a better service which may save money in the future.

By the end of this sprint we’d conducted enough interviews, 5 French and 5 German, to start attempting to spot patterns. We came across Activity Theory on the GDS blog and gave it a go.

The idea is that motivation is what drives people to do what they do and so we should use this to define personas. The framework turned out to be too time consuming and complex for what we wanted to do, but this idea of motivation went on to influence us later when we delved deeper into the world of jobs-to-be-done.


So, instead of just using mine and my colleague’s time sifting through Medium articles and blogs to find a good way of defining personas, we branched out to the wider team through a workshop.

We began by setting the scene and gave a short intro to some of the people we had interviewed. What their top motivation/goal was, their biggest pain and need, as well as a bit of demographic info. The others hadn’t been working on this project so it was important to give them some knowledge to fuel inspiration.

Redacted engage.png

Then we had a graph which displayed what we assumed to be two very divisive scales: how much they care about their car and how familiar they are with insurance. We made some fake characters, e.g. Marie who is 65 and her car is simply a way to see her grandchildren, she doesn’t think of it as much more. She’s been driving for many years so knows a bit about insurance but has never actively engaged with understanding it and as a result, isn’t an expert.


We then brainstormed a list of scales that could separate people and how they react to car insurance. Using the above fake characters, we plotted where we believed they would be on those scales. This was all to test our method and see if it could be used to find groupings of people. This proved to be a valuable method of analysing and grouping people together by behaviours - but that nagging feeling that motivation is more important was still there. We did end up using some of the scales below in our final proto-personas as they were evident in their behaviours.



With ideas floating round from our initial discovery phase and the outcome of our workshop, we looked to hone in on a more robust method now that sprints had begun and we’d be able to use more insights from new participants.

This is where jobs-to-be-done (JTBD) came in. I’d used these before and found it useful to frame user needs, but after reading an article explaining the difference between two different types of JTBD, we could really see the benefit of using this for our personas.

The difference between jobs-as-activity and jobs-as-progress can be seen in the famous quote:

“People don't want to buy a quarter-inch drill. They want a quarter-inch hole!”

Wanting the quarter-inch hole is jobs-as-activity, it’s a task someone’s trying to accomplish. Jobs-as-progress looks deeper to their motivation. They want the quarter-inch hole to hang up a family photo because they love them and want to feel connected with them. From this you understand why people do what they do. Hanging up a photo is just one way they could fulfil that goal, but they could also arrange a family day out or a meal together.

So, how do we use this for persona creation? Take all the notes from participant interviews, strip them down to their motivations in an old fashioned word doc (we also used pains and gains), and use that to spot patterns.

This gave us 4 clear cut personas.

We also thought it could be useful to integrate the JTBD with the personas somehow. This framework gave us the ability to understand why the person has acted in the way they did, but they acted in different ways depending on what they were doing - researching or calling to change something, for instance. So we broke down the journey into everything you can do with your insurer. These were:

Buy, admin, change, non-urgent claim, urgent claim, renew, and cancel.

We uncovered several motivations in these stages such as, ‘to be trusted’ and ‘to be legal’, and then grouped them in categories such as, ‘personal fulfilment’ and ‘fear’. But we saw that sometimes two stages would have the same motivation even though the action derived from that would be quite different. For example, one of our personas had ‘to feel reassured’ for both non-urgent and urgent claims despite the reaction of the former being nonchalant and of panic for the latter.

To show this nuance we separated this into what they were ‘wanting’ and what they were ‘thinking'. So, for the above, we can understand that the persona is thinking “what’s the simplest way of doing this?” when submitting a non-urgent claim and “help me, I don’t know what I’m doing” with an urgent one.

Final personas

We created a persona overview sheet to explain what personas are, what they’re useful for, etc. As well as to quickly breakdown what makes each persona different from each other.

Redacted overview.png

And here’s one of our personas - mostly redacted but enough to see how it was structured. The user needs row at the bottom is the how we highlighted stages through JTBD.

Persona template.png

Lunch and Learn

As Engine are a Service Design agency, they haven’t had much exposure to the use of personas or the wider project that this involved. Due to this, I created a Lunch and Learn to show them the process involved in creating an MVP and personas.