Drive innovation through persona development

Personas: A step-by-step guide to building personas to drive innovation, beyond the usual template, with a concrete example.

Adam Faik
10 min readAug 20, 2022


Photo by freestocks on Unsplash

“But Adam, why would we spend time talking to users? We already know who they are, and we’ve been doing this for +20 years.”

It’s the kind of resistance I still face sometimes. However, when I work on a project, I need to talk to users regularly. I set myself and the team the goal of at least one contact with users per week.

Personas are, in my opinion, an excellent way to summarize and communicate our understanding and findings of users. Personas also help teams avoid self-referential design and keep in mind the users. Above all, understanding users through personas drives innovation.

We innovate by starting with the customer and working backward. That becomes the touchstone for how we invent. — Jeff Bezos

However, the effectiveness of personas generates a lot of debate both within teams and within the product community. In this article, I’ll walk you through the 5-step process I take to use personas to their fullest:

  • Step #1: Share a common understanding
  • Step #2: Capture and analyze data
  • Step #3: Represent personas and build assets
  • Step #4: Use personas
  • Step #5: Regularly update personas

I’ll use a concrete example from a project that I led.

Step #1: Share a Common Understanding

I worked on a website redesign project. The website enabled self-employed workers to complete their social security procedures (social contributions, health, retirement, etc.) The project goal was to support self-employed workers in the merger of several social organizations.

I wasn’t a self-employed worker myself at the time. I found it hard to be assertive and understand the project’s benefit. I needed to talk to users to understand their expectations better.

Building personas for me seemed a prerequisite to starting the project in good condition. Still, I faced the “we already know our users” resistance. So, I took advantage of this resistance to start work. “Tell me everything you know about your users!” We began by building proto personas.

#1.1: Start with Proto Personas

Proto personas are lightweight personas created with no research based on the team’s existing knowledge or assumptions.

A 2-hour workshop with stakeholders allowed everyone to explicit their assumptions about users on a simplified template made up of 4 parts:

Proto Persona Template (from

The differences of views and questions raised during this workshop confirmed the need to reach out to users:

  • What do users think of the current website?
  • Are they informed about the merger of their social protection organizations? What did they understand from this reform?
  • Do they complete their administrative procedures themselves, or do they ask their accountant to do it for them?

So I got the team’s buy-in to go deeper into the analysis.

#1.2: Define a Goal

Why go beyond the team’s assumptions? Why spend more time detailing personas? It’s essential to define a goal and specify the expectations before starting.

The development of personas can serve the following goals:

  • Identify user needs and pain points that the product could solve for them.
  • Inspire discussions, share information, and improve design ideation.
  • Humanize complex data captured from quantitative and qualitative research.
  • Target future user groups and determine strategic decisions to be made.
  • Empower teams through UX assets useful for their project and save them time.
  • Abolish silo thinking by shifting the focus from organizational structure to users.

The goal has an impact on the process that will follow.

Our project aimed to build a sufficiently detailed knowledge of the target users to support them during the merger of their social protection organizations through a clear and straightforward website.

#1.3: Determine the Scope

The scope influences the data in the personas and the richness of the insights to fulfill the goal set.

Designing for anyone is like packing for a trip to anywhere — Kathryn Whitenton

Developing the self-employed worker persona for our project would have been worthless to our goal. Indeed, this would push us to collect too general data, which would not influence the design.

Instead, I tightened the scope to ensure we were collecting actionable data. I focused on the users affected by the merger of social protection organizations, artisans, and merchants, and I divided them according to three moments of their life as self-employed workers:

  • New artisans and merchants still discovering their status.
  • Artisans and merchants with self-employed worker status for +20 years.
  • Retired artisans and merchants.

I restricted the study to these three personas to focus, be on time, and not lose the team in many details.

#1.4: Educate Stakeholders

Last step before starting the research: explain to stakeholders what personas are and what they are not. Indeed, some people might be skeptical of persona validity, and a lack of buy-in makes personas impossible to be successful.

So I repeated as many times as necessary that personas are a way to model, summarize and communicate research on our users. It’s not rocket science, and that’s okay: it’s the best estimate based on research and analysis.

A little theory doesn’t hurt. Several scientific verifications confirmed the benefits of personas, of which person-positivity bias is one.

Person-positivity bias is a tendency for people to evaluate individuals more positively than the groups they compose.

It means our brains empathize with “Paul the woodworker” rather than the “users of the website.” Thus, personas allow teams to empathize with users, design features as close as possible to their needs, and make the best use of the budget allocated to the project.

Finally, a pro tip: don’t show only the deliverables resulting from the process; explain the team’s real benefits for personas (mentioned in Step #4).

Step #2: Capture and Analyze Data

#2.1: Learn about the Users

The next step is to go out and find out who these people are, find out what behaviors they have which drive them to need our website, and their motivations, circumstances, and contexts.

Several methods are helpful to collect this information: diary studies, contextual inquiries, focus groups, persona co-design workshops, etc. I chose one-on-one interviews with target users, which is an effective method to meet deadlines.

This article presents general questions for building complete personas. The rules are the same as for a discovery interview. For my part, I relied on the unresolved questions and assumptions resulting from the workshop on proto personas.

#2.2: Cluster Data into Attributes

I recorded and transcribed the conversations minute by minute in a spreadsheet. Little by little, at the end of the 5th interview, attributes and trends began to be confirmed.

Attributes are axes of analysis of the collected data.

The attributes depend on the goal defined initially. It isn’t necessary to add them to make the persona seem complete. So, keep to the details relevant to the problem to be solved.

Examples of core attributes:

  • Goals: What are the supreme motivators? What are latent needs and desires?
  • Attitude: What is the persona’s point of view? What is the expectation and perception of the service, company, or brand? What motivates the persona to go to the website, into the shop, or use the service?
  • Behavior: What does she do? Which behavior while using a service, product, or site? What works well? What are the frustrations? What is stopping her from choosing a function, service, or product?

Examples of attributes that humanize a persona:

The attributes that humanize the persona may seem trivial. However, believable human traits and flaws help create empathy with problems and needs. These attributes make personas memorable as people:

  • Name, age, gender, photo, traits.
  • Quotes to sum up the persona’s attitude.
  • Background, story, or bio.
  • Favorite brands, influencers, preferred channels, favorite digital tools.

Attributes that come from the customer profile part of the value proposition canvas:

For my part, when possible, I like to rely on the characteristics found in the value proposition canvas:

  • The jobs personas are trying to get done (functional, social, or emotional).
  • The pains that annoy personas while they try to get a job done, and adverse outcomes they hope to avoid (dissatisfaction, challenges, frustrations, risks, obstacles, etc.)
  • Positive outcomes they hope to achieve (concrete results, benefits, aspirations, etc.) through a job well done.

So, I selected the attributes that seemed relevant to the project and reported and structured the data collected in the spreadsheet.

#2.3: Involve Stakeholders

I didn’t want to take personas out like a magician pulling a rabbit out of a hat: I tried to involve stakeholders throughout the process and ensure the personas resulted from a co-construction work.

So, I got the team involved in the interviews with the users to also listen to the conversations. I also ensured that the team chose the attributes that humanized the persona (name, photo, background, etc.), thus guaranteeing the adoption.

Step #3: Represent Personas and Build Assets

From this step, once you collect and analyze the data, everything becomes more straightforward. It’s time to “bring this data to life.”

#3.1: Build a One-pager Persona

Representing the data on a slide for each persona is the most popular way to start. The challenge is to synthesize much data recorded in a few bullet points.

These templates 1, 2, and 3 are among +100 templates available on the web. There are even tools 1 and 2 to automate their creation.

It’s not the form that counts but the previous process implemented to build them.

Here is a persona made for our project:

“Paul, the woodworker” Persona

#3.2: Build Creative Assets

Beyond the one-pager, be creative to ensure the adoption of personas by the teams. You can build assets that highlight the knowledge gained about target users.

Examples of persona assets:

  • Card games to share the insights
  • Cardboard cutouts of life-size personas to make them participate in workshops and remind the team for whom they work
  • Goodies, mugs, keyrings, notepads containing the photo of these personas
  • Animated videos or 2-min short films of actors playing the role of the personas
  • Interactive website containing a presentation of the personas and all the assets to be used by the teams

For our project, we temporarily named our workshop rooms with the name of our personas. Thus, we had our target users in mind before starting our ideation sessions.

#3.3: Test Persona Assets during Pilot Workshops

Even if these assets are co-built with the team, planning for an iteration period may be relevant. This agile approach is to ensure that persona assets match teams’ expectations.

You can thus participate in pilot workshops during which teams use these assets. It helps you identify missing elements and optimizations.

Step #4: Use Personas

#4.1: Disseminate Personas within Teams

Once you designed, tested, and optimized the personas, it’s time to distribute them to the teams. As with a product launch, it is helpful to plan a gradual deployment plan within the organization, including:

  • Targeted communications (newsletters, steering committees, etc.)
  • Training and support for teams in their day-to-day use.
  • Tools allowing teams to raise their questions and obtain answers (email assistance, Q&A, etc.)

#4.2: Ensure Regular Use of Personas

There are many opportunities to use personas to their fullest: it’s crucial to ensure that the teams use them in these opportunities.

Examples of daily use of personas by teams:

  • Roadmap definition.
  • Ideation sessions to identify new features or solve problems (scenario mapping, crazy 8, etc.)
  • Product specifications (story mapping, user story writing, etc.) It is particularly impactful to replace “As a user, I want to…” with “As Paul, I want to…”

For our project, I used the personas to lead ideation sessions on the future of the website. We relied on discoveries to prioritize developments. Our knowledge acquired on users enabled us to carry out a categorical redesign of the site:

  • Highlighting online services instead of articles.
  • Implementation of advanced search features on the site.
  • Simplification of the information architecture.

The backlog that resulted from these sessions was oriented directly to these personas. User tests carried out on the prototypes built from these personas showed that the redesign of the website as we imagined it was very close to their expectations. This approach, therefore, allowed a large grain of time.

Step #5: Regularly Update Personas

Having personas close at hand is no excuse to stop talking to users. You have to keep talking to them and update the assets as you learn from them.

You should regularly revise the attributes as the world could change, and new aspects may affect the descriptions. For my part, I update them after extensive discovery work to relate the recent information collected.

Developing personas can take a few weeks, which is inconsistent with the pace of agile. I prefer to deliver personas quickly to allow the team to empathize with users as early as possible and then update them regularly afterward.


  • If you face the “we already know our users” resistance, a proto-persona workshop with stakeholders is an efficient way to prove the value of completing an in-depth study and get the team’s buy-in to go deeper into the analysis.
  • Don’t jump right into the persona research work. It’s essential to validate the study’s goal and scope and educate stakeholders on the benefits of persona development.
  • Don’t overload your personas with unnecessary information. The attributes must serve either the defined goal or humanize the persona. It’s essential to keep it as simple as possible so as not to drown the team with fictitious data and thus affect the credibility of the process.
  • Personas result from co-construction work with the people who will use them daily. Involve them, and make sure that the work done will be of real benefit to them. Build creative assets to ensure persona’s adoption and test them during a pilot period.
  • Once the personas have been designed and tested, deploy them as a product, i.e., a communication plan, training, and assistance to the teams.
  • Developing personas can take a few weeks, which is inconsistent with the pace of agile. Deliver personas quickly to allow the team to empathize with users as early as possible and then update them regularly afterward.


Definitions and Methods


Tools and Templates