Start the workshop

Well, if you have nothing, then just make something up. Just go for it. You wouldn't believe—let me share a bit from my own experience—how often I've heard things like: No, we don't know our users. We don't have any users. We have no idea where they come from. Honestly, that's complete nonsense.

We already carry a lot of knowledge within us, simply from our daily work. And the same goes for our colleagues in specialized departments or within the business—there's an incredible amount of information embedded in them. This knowledge can be leveraged.

With my years of experience running proto-persona workshops, I've now compiled everything to make it easier for you. This is a step-by-step guide that allows you to conduct a proto-persona workshop without needing expert knowledge. By the end, you'll have generated incredibly valuable insights into who your potential users might be.

Outcome

What you need

⭐️ Rules of the meeting

❌ No phone, ❌ no laptop, ❌ no distractions. Please make the awarneys in the beginning of the meeting and in the invatiation.

Nothing is right or wrong. Each idea is valuable ✅. Make this a safe space for everyone to speak up. No judgement! 🙈 It is important. These are assumptions about the users.

The goal

First, all participants are aligned to understand that today, we will be creating proto-personas that originate from within themselves. The goal is not to achieve the most accurate results but rather to develop a fundamental understanding, facilitate information exchange, and make assumptions about who this proto-persona is or might be.

Present the obstacles

Present the obstacles once again, summarizing what it is about. Keep it brief—maximum of 5 minutes—like an elevator pitch, ensuring that everyone in the room gets a clear picture. Participants may also ask follow-up questions if needed.

How to do it?

Divide the team into pairs

First, all team members are divided into pairs. If there is an odd number of participants, the remaining person will be randomly assigned to a group. Based on my observations, people often struggle to form pairs on their own, so it is now your task as the meeting moderator to assign individuals accordingly. Randomlists generator

Step 1 is special.

At this stage, the teams are already formed, but each participant individually brainstorms all possible roles they can think of—relevant to the given topic.

Once the team or the audience has completed this step, the process can be refined using dot voting. This helps determine which personas are considered more important than others. Depending on the available time, the most crucial personas will be addressed first, while the less important ones will be tackled in the second step. However, they are not discarded; they remain valuable for further research later on.

Recommendation for better accessibility

I recommend including at least one persona with a disability to ensure that the product is designed with diverse needs in mind. For example, this could be someone with cognitive impairments, motor disabilities, visual impairments, or low vision.

To reinforce accessibility, the persona that receives the most votes should even be given a special perk—ensuring that accessibility is naturally integrated into the product from the very beginning.

Shuffle the Team after Step 1

With each new step, the groups will be rearranged. Each group works on the next step of the previous person's work. It goes in a cycle—round robin. No one stays stuck, and no one stays in place.

Why we shuffle the team?

Like a large language model, the group taking the next step must once again put themselves in this persona's perspective. This holds great potential, as the new thought processes can spark additional ideas among participants. By continuously questioning and challenging each other, they can generate even better and higher-quality ideas.

What should the pairs do together?

The provided questionnaire will now be worked through step by step. The pairs starts with Step 2: Create the needs and wants. Here, the participants take turns in a ping-pong style, asking each other the given questions. The person asking the questions writes down the answers. Then, they switch roles—the other person now asks the questions and records the responses.

The person how ask the question can wirte down there own answer on the stickynote. BUT first they have to lisen to the answer of the other person.

Why are we doing this?

This approach ensures that quieter individuals, who might not usually engage in group discussions, also have a voice. It allows them to contribute meaningfully to the overall product, ensuring that they have worked on something together. This is crucial—without this collaboration and the empowerment of quieter participants, communication becomes imbalanced. By giving everyone a role, a stronger and more well-rounded product can emerge. Additionally, this process encourages active listening, which is a key aspect of the proto-persona workshop.

Create the proto-persona

  1. Create roles – Try to think in terms of roles.
    1. Each participant writes down as many roles as they can in two minutes.
    2. Everyone shortly presents their roles to the group.
    3. Group similar roles together to create a clearer structure.
    4. Participants vote on the most important roles two minutes.
    5. The roles with the most votes will be further developed in the next steps.
  2. Bring it to life go into the pairs
    • What is the name?
    • What is the job title?
    • What is the company?
    • What is the location?
  3. Create the needs and wants - Shuffle the Team - Give your teammate time to think and write down the answers.
    • What has she or he to enter in the system? Each item on 1 Stickynote
    • Where does she or he enter the data?
    • How did she or he orginize the working day?
    • Where is the data coming from? Helper: communication channel, other systems, etc.
    • Whitch information is important for the he or she?
    • What is the main goal?
    • What is the main task?
  4. Create the possible painpoints - shuffle the Team
    1. What can go wrong with the main goal? Ask the other person: Why? Try to argue the reason.
    2. What can go wrong with the main task? Again Why?
    3. What can go wrong with the main challenge? Why?
    4. Whitch information is important for the persona? What's happening if it's not available? ...?
  5. Create the wishes - shuffle the Team
    1. Imagine you have a magic wand. What would you change?
    2. What would you add?
    3. What would you remove?
    4. What would you improve?
  6. Next, the next group will give the personas a text that best describes what their daily life looks like.

If you still have time, you can repeat the process.

For the last half hour, take the time to present the proto-personas to each other so that all colleagues know which personas have been created. These can then be perfectly documented in Confluence or another documentation tool.

What is the result?

Now, once you've applied this method, you will have developed several proto personas based on the collective knowledge of everyone involved. These personas are assumptions about who these users might be and what they might do. This approach is especially useful when you don't yet have an existing user base.

Because I mentioned documentation in the previous sentence, it's important to always keep in mind who you are developing a service or product for.

Because this is important to me as well, but I haven't yet found a method that satisfactorily integrates proto-personas or personas into the process of story creation—beyond just mentioning them or sharing knowledge—I'm unsure if it's enough for designers or product managers to occasionally review them. So far, I haven't found a concrete method that effectively ensures proto-personas or personas remain a consistent focus throughout the process.

Caution

However, caution is needed here—it's essential to validate this information later with real users. Still, you can use this information to conduct so-called dry runs by using fictional personas and having real people act according to those personas during usability tests, helping to confirm initial assumptions.

However, this does not replace real users who will come later. Only real users can validate the product in the end.