In a mid-sized Nordic company, a team had been working for some time on a new customer-centric digital service concept. The team, consisting of developers, designers, and business experts, had started the project with what seemed like a clear vision, but now it felt as if that vision had been lost. One of the developers had been bothered by this for a while and decided to share their concerns with the rest of the team. Their observation resonated with others, and the issue was discussed in more detail.
The team realized they had lost a shared understanding of who they were developing the service for. The needs of different stakeholders were conflicting, and the team couldn’t agree on who their primary target audience should be. The list of required features had also grown, and no one seemed to know whose needs the new requirements addressed or how important they were compared to earlier ones.
Why hadn’t the early customer research been translated into actionable insights? Why was it so difficult to prioritize needs, even with a large amount of collected data? Why had the vision been lost?
When developing complex applications that serve a variety of users, it is crucial for the success and progress of projects to identify the most important users—those who will actually use the application. Building user understanding involves collecting data through research, interviews, and probes, but merely gathering data is not enough to produce concrete and proven solutions. The challenge lies in distilling this knowledge into a tangible format that ensures everyone involved in the development process understands:
- The primary users of the application
- How these key users think and behave
- The most critical needs of the users
- The most likely contexts, tools, and methods users will use to interact with the product
- How the product provides value to each user
This list has a critically important flip side—the requirements that are not essential. Every development project operates within a budget and timeline that must be respected. It is quite common for the list of requirements to grow as various stakeholders participate in the development process, and in some cases, the initial list may already be extensive. This in itself is not a problem, but without a method to prioritize needs and a clear way to document them, the growing list of requirements can stall the project entirely.
Additionally, the implementation order of features that add value must somehow be determined. Not everything can be done, which means there must be agreed-upon tools to support decision-making. User personas in designing digital services are a helpful tool for this.
How this can be done?
A great way to consolidate target groups and their needs is by creating user personas. User personas are representations of the most likely target groups and their mindsets, based on user research conducted around the subject in question. The greatest strength of user personas lies in their ability to distill the findings of customer research into easily understandable, relatable, and tangible characters. They allow teams to reference the needs of different users effectively, systematically, and research-based. This makes it easier to document and communicate those needs.
User personas typically consist of:
- An image, a name, and a concise background package tailored to the specific context, which might include:
- Personality type
- Family background
- Influences
- Tools and devices they use
- Other contextual details that impact product use and their way of thinking
- The person’s goals:
- When using the product
- In their broader life
- The emotional state they aim to achieve while using the product
- Barriers to using the product
- Challenges that make product use difficult.
What are the benefits of the background information in a user persona?
While developing personas, the team noticed that a lot of time was easily spent debating the details of the personas. How old is the character? Do they have pets? How many children do they have? Or are they single, perhaps using dating apps? What brand of soda do they drink? Are they college-educated or not?
At times, the whole exercise felt pointless—after all, these details didn’t seem to have any relevance to the actual development of the application.
Yes, they can feel pointless. However, these more detailed background details are valuable when carefully selected and based on real customer research.
User personas in designing digital services include two types of information: details directly related to the product being developed and indirectly related information. While personas could function as a design tool without the indirectly related details, they would lack the relatable nuances needed for fostering empathy. In service design, it’s crucial to build empathy for the users, and genuine empathy requires understanding the user’s situation and the challenges they face.
The information included in a persona serves two distinct purposes: first, to provide evidence-based reasoning for why users think a certain way, and second, to add enough relatable, real-life detail to create a sense of connection. Let’s compare two examples.
First, a persona where needs are described without any background explaining their causes. This makes it difficult to relate to and to understand the true scale of the challenges or the prioritization of goals.
In the second option, the user persona’s goals and challenges are easier to understand when sufficient background information is provided.
Both personas include information directly related to the product being developed, and some design could already begin based on either. However, the needs described in the more limited persona do not feel as tangible. They are easy to forget, as they lack a name and an owner. Other needs may start to feel more important than those of a nameless, context-less ghost persona.
Can a persona mislead?
One persona was initially named after a celebrity, but this led to completely fabricated assumptions about the character’s mindset. Fortunately, this was eventually cross-checked with customer research data, and the misleading details were removed. The personas were also renamed to make them more neutral.
It’s true that factors like wealth, gender, nationality, age, and spoken language do not necessarily influence a user’s needs. The danger lies in repeating the same needs across multiple personas with different demographic profiles or artificially creating distinct needs based on attributes like wealth or skin color. Careless naming of personas can also lead to assumptions about the individual’s characteristics, making the persona inaccurate and misleading. Such details should be carefully considered, omitted if necessary, or adjusted to avoid artificial, assumption-based biases. For example, personas could be named after animals or zodiac signs, avoiding harmful stereotypes while remaining memorable.
Background information can also be valuable for tasks like targeting the right type of audience in marketing, planning testing scenarios, and recruiting test participants.
The team even printed their personas as cardboard figures and brought them into workshops. This effectively added a couple of new “colleagues” to the team. The personas later proved useful in many areas, such as targeting the app’s marketing to its intended audience, recruiting test participants for usability testing, and conducting internal audits to assess the usefulness of the app’s features for end users.
User personas in designing digital services are just one example of how user understanding can be refined in service design. They are a practical tool that has been in use for a long time and work best when applied thoughtfully and tailored to the need. The internet is full of templates for creating personas, but these often lack warnings about the risks of conducting customer research merely to fill in the template’s blank fields. This approach will yield data that aligns with the wrong focus. Instead, the research should shape the template, not the other way around.
