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
- A shared understanding of the potential users
- A set of proto-personas that are not based on real users
- Team building - ❤️
What you need
- Setup a meeting with the stakeholders and Team minimum 8 people
- The rules of the meeting
⭐️ 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
- Create roles – Try to think in terms of roles.
- Each participant writes down as many roles as they can in two minutes.
- Everyone shortly presents their roles to the group.
- Group similar roles together to create a clearer structure.
- Participants vote on the most important roles two minutes.
- The roles with the most votes will be further developed in the next steps.
- 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?
- 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?
- Create the possible painpoints - shuffle the Team
- What can go wrong with the main goal? Ask the other person: Why? Try to argue the reason.
- What can go wrong with the main task? Again Why?
- What can go wrong with the main challenge? Why?
- Whitch information is important for the persona? What's happening if it's not
available? ...?
- Create the wishes - shuffle the Team
- Imagine you have a magic wand. What would you change?
- What would you add?
- What would you remove?
- What would you improve?
- 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.
- It's not for you, but for your users.
- For people who may have special needs.
- For people who think differently than you.
- For people who act differently than you.
- For people from different fields, using different technologies, or coming from different parts of the world—and who approach problems and challenges in different ways.
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.