Motivation-based Personas

The Challenge

When my team at Sofar Sounds and I brainstormed and prioritised ideas, we were often lacking a clear understanding of our users and their motivations to use our product (= intimate music events). Coming up with personas for every project was too time consuming when done correctly, so I decided to spend some time on creating universal personas that reflect different groups of our user base.

Limits of personas

Everyone who is familiar with the jobs-to-be-done framework knows that personas are the anti-pattern of jobs-to-be-done.

The critique is that personas artificially break apart the audience and try to find differences rather than similarities. In reality though, the same motivation can be shared by people with different demographics and characteristics.
At the same time, a clear one-phrase job-to-be-done is easer to process than reading through a detailed persona every time you sit in a meeting and want to make a decision.

How can we bring Personas and Jobs-to-be-done together?

So I set myself the goal to create personas that are highly motivation-driven rather than defined by demographics and characteristics. These will still be part of the persona, but for the purpose of helping people in the organisation to empathise with users and customers, especially if they work in positions where they don’t get exposure to users on a regular basis. Having said that, personas should never replace talking to and testing with real people as scenarios and situations always evolve.

The Approach


Deciding on a lean approach to personas

Facing the challenge that we didn’t have weeks of time and a dedicated team to work solely on personas, I was keen to make the most of what we already know about our users. Having read a lot about Lean Personas in the past, I decided to treat personas as any other design project: Start with a prototype full of assumptions and then refine and validate it through testing and user feedback.

My plan comprised the following steps:



Starting with existing data

One problem with personas is that they are time consuming to create, especially if they require research upfront. But most of the times the company has already done some research, like recent user testing sessions and interviews or constantly ongoing NPS surveys and customer support activities.
All these resources provide rich information about user needs, behaviours and pain points and are therefore a great starting point for creating personas.

Looking into analytics to detect behavioural patterns

When I initially dived into the persona work, I was looking for behavioural patterns to identify similarities and differences in how people use our product. I wanted to answer questions like How often do people attend a Sofar event? and How many people do fall into which group?.

So I analysed quantitive information using analytics tools and asked our developer to run some queries on the data base in the hope to come up with a logical classification of the audience.

Mixpanel allows to filter the audience by different properties.

The difference between Personas and Segments

This way of classification though let me end up with segments rather than personas.

Although personas and segments are often used interchangeably, they serve different purposes.

  • Segments are a marketing tool that helps target products, services and messages to different groups of users or potential users. They are supposed to give the team a quantitative understanding of the target audience, mainly based on demographics and behavioural patterns.

  • Personas instead help designers to keep the user in mind at all times during the design process. They also help the wider team to develop empathy with users and customers. They usually come in form of fictional characters that represent users with similar goals, needs and motivations rather than demographics.

Using motivations as the dividing factor

The more I made myself familiar with the different purposes of segments and personas, I realised that all the quantitative data I gathered from analytics won’t help me to empathise with users and design solutions that meet their needs.

It was in fact my personal experience of talking to real people that gave me most insight on their goals and motivations. So I reviewed qualitative feedback from previous research, like interview documentations and user testing reports. The motivations identified were so distinct that it seemed natural to use them as the main differentiator between personas.


Prototyping personas to discuss them with your team

Using the qualitative data we already had, I came up with three personas based on motivations, or ‘reasons to come’ as I tended to call them. I also included any assumptions that needed to be validated with follow-up research. As with any prototype, incorporating your assumptions into a proposed solution will make it easier to discuss with your team.

Gathering internal knowledge as a first validation step

Who else could give better insights on personas as team members who dedicate the majority of their time talking to and thinking about users?

I reached out to our customer service guy (aka Head of Guest Experience) and scheduled a meeting with the two other designers at Sofar to present them and discuss my proto personas.

It turned out that I was missing an important persona, whose main need is to meet people at events and become part of a local community. Since added, I’ve already met this persona twice at a Sofar event.

Validating personas by talking to users

The next step was to see if the personas I made up actually exist in the real world. Since the main goal of this research was to understand the motivations behind using our core product (intimate music events), the best way to reach our users in a natural environment was the event itself.

Guerrilla research at the “crime scene” is a cheap and fast way to get user feedback.

So I prepared a brief interview guide, grabbed a colleague and we went to a few shows to meet and interview people. After each interview, I refined the personas, moved attributes from one to another and removed assumptions which couldn’t be validated.

Using quantitive data to confirm demographics

As another validation method, I looked at some bigger data collected by surveying hundreds of users. While surveys are certainly not the right method to dig to the core of user motivations, they can provide crucial information about demographics like gender, age and income. Most importantly, the large data samples give personas the necessary level of representativity, something stakeholders always ask for.

I looked at the age ranges collected in a survey to make sure my personas cover the right demographics.


Becoming aware of hybrids

When I looked at the results from the interviews, I realised that users barely matched only one persona. While the personas themselves turned out to be valid and realistic, most times I met hybrids who shared motivations of at least two personas.

In the end, the main purpose of personas is to illustrate why a person decides to use or purchase a product. I have to agree with Alan Klement as pointed out in this article that personas in their typical form often lack this perspective.

This was where the jobs-to-be-done framework became the right tool to extract the core of why people are using our product.

Nailing the job-to-be-done

After spending much time on making personas as rich as possible, I also wanted to make sure the personas don’t lose their potential because no one had time to read them. Therefore extracting the jobs-to-be-done was key to make user motivations accessible for decision making.

Personas & Jobs-to-be-done together create a deep understanding of users while each of them answers a different question.

Get rid of all the unnecessary

What I also took away from Alan’s article was to reduce my personas to the information that is critical for us designers to understand how our product can help this persona – and get rid of everything else that doesn’t answer this question.


For instance, one persona called Adam included the information “sometimes he browses content on his iPad sitting on the couch”. This information tells us nothing about the persona’s motivations and goals related to our product:

Will developing an iPad app solve Adam’s problems? Probably not. Is “sitting on the couch” a situation that is crucial for deciding to buy tickets for Sofar’s events? I don't think so. Will we make sure that our website is responsive on different devices? Of course we will, but because of accessibility standards and not because Adam sometimes sits on the couch and reads articles on a news website.


Finding the right format

When I started working on personas, the first thing a colleague asked was “Can we have cardboard stand-ups of each persona in our office?”
And even though it was way too early to ask this question, he made a good point. Visualisation is key to make sure the personas will be actionable and understood by different people in the organisation.

But since we were working from different offices in London and had offices in the US, cardboard stand-ups would be logistically inefficient. Keeping the personas digital only was not ideal either, since it’s too easy to file them away and forget about them.

Identifying different use cases for personas

Again looking at personas as any other design project, I was thinking about the different situations in which personas will be used within the organisation. Each of them require a more or less detailed perspective on the user and happen more or less often in the team’s workflow.

Different use cases require a different level of detail for the personas.

Since decision-making, ideation as well as workshops and feedback sessions happen on a weekly basis, the visualisation of personas should especially support these formats.

Defining premises for the visualisation

Based on the different use cases and the company’s structure, I came came up with three functionalities the visualisation needed to fulfil to ensure the personas will be effectively used within the organisation:

  • Accessible: Everyone in the company should be able to read and use the personas without needing special programmes or equipment.
  • Comprehensible: Everyone should understand the persona’s motivations within seconds while being able to access more information to develop empathy.
  • Reusable: Everyone should be capable of reproducing the personas in a cheap and easy way, whether in presentations or workshops.

The Solution

Different visualisations for different use cases

My analysis of different use cases and their requirements led to the decision to create two visualisation formats for each persona. To maximise their use and visibility, I made sure they can be printed and sticked on the wall by any team in any office.

Displaying personas in the office kitchen makes sure everyone reads them while making a coffee.
Visualisation 1: More detail for deep empathy

One is a more detailed persona overview (A4) including all the information which was researched and validated during the project. This format should particularly help the product team to emphasise with users when prioritising and designing new features.
The persona is structured in a way that can be read as a story that in the end reveals why people “hire” the product as the solution to their needs and challenges.

Detailed personas in A4 format

Note: I used photos of real guests instead of stock images to make the personas appear realistic. For privacy reasons, I blurred out the images here.

Creating some sorts of music social network profile wasn’t originally planned, but ultimately made sense since it lines up well with the brand and helps bring the information in a brief format.

Visualisation 2: Less detail for team collaboration and decision making

The second form of visualisation is a smaller card (A6) which summarises the key information on both sides of the card, so that it can be turned around and become a playful tool in innovation workshops and meetings.
Whether it’s attached to user journeys on the wall, or held up like a ‘red card’ in team discussions, the card works as a signal reminding the team of the people they’re designing for.

The cards can be produced in minutes due to its paper-friendly A6 format. Print, cut, fold, done.

Emphasising user motivations rather than demographics

The smaller cards show the most important information on the front, while containing more detailed information on the back. As opposed to more traditional personas which put the focus on demographics like age and occupation, I reserved the front page for the user’s motivations to use the product.

The front of the persona card is reserved for the persona’s title, photo and most importantly, the “reasons to come” to a Sofar event.

Aligning segments and personas

I used the quantitative research I did at the beginning to kick off work on segments together with the marketing team. These segments mainly focus on purchase behaviour and frequency and will support marketing and strategic planning. By pointing out which persona represents each segment, I made sure we are all on the same page and able to see the difference between both tools.

Continuous refinement

Similar to a software product, personas must not be considered a static output that doesn’t need an update. Users and products evolve over time and when viewed through the lens of a particular problem, the personas may get another twist. This doesn’t mean that persona research needs to be repeated every three months. Instead, any future design research, whether it’s field research or usability testing, can be seen as a chance to refine and validate the personas. Combined with regularly collected quantitative data via analytics and surveys, personas become sustainable without requiring any extra effort.


Keep the interview casual if the setting allows it

Although the research goal should be always kept in mind, I found it extremely rewarding to go off script and have a casual conversation with the user rather than a structured interview. It made me become naturally curious about the person in front of me while it put the user at ease because she didn’t feel she is answering questions. The environment can be very important here, so why not try a nice café instead of your office if the technical setting allows it?

Step into the users’ shoes by becoming their buddy

Going ‘undercover’ can help see the experience with the eyes of the user: from getting drinks before the event, to struggling to find the venue, to sitting on a hard floor. Even though I told people I work for Sofar, they also saw me as a guest and let me become part of the group. This was truly insightful and made me accidentally come up with a new research method where I accompany users throughout the whole evening. I’m planning to do this more often now.

See every touch point as an opportunity to get feedback

When I emailed guests and asked them if they have time for an interview before the gig, they often got back to me saying something like “I’d love to help out, but I work until 7pm, so I can’t make it.” Since they expressed interest, I sent them an email the day after the event, like “How did you find the show?” and “What could we have done better?” They were again happy to help.