Deciding whom to include in a UX workshop is one of the first critical decisions a workshop coordinator or facilitator needs to make. The attendee list can make or break a workshop before it even begins.

One guideline for compiling a participant list for a successful UX workshop is to maintain focus on the user’s voice. Sometimes, this means including user advocates such as UX researchers. Sometimes, however, it is advantageous to invite real users to the workshop. Doing so can make you or your stakeholders feel vulnerable, but the perks of having the user’s voice in the room can be immense.

The benefits of having users present in a workshop vary by type of workshop. 

5 Types of UX Workshops

5 UX Workshops Cheat Sheet
Different types of workshops are used at different stages of the design process.

Discovery Workshops

Discovery workshops are held to build consensus around goals and vision at the outset of a project. Project champions and stakeholders convene to align on business requirements and share existing knowledge.

Including Users in a Discovery Workshop

In a discovery workshop, users share their own perspectives on how a potential project might benefit them.

For example, imagine that user interviews or usability testing uncovered a previously unknown need, and that the company has decided to design and implement a new product or feature to fulfill that need. The team could easily reach back out to one or more of the previous research participants and invite them to attend a portion of the workshop, where they could share their feelings about their unmet need. Workshop participants could then ask questions and receive answers in real time. Not only would this process help them to gain clarity and consensus around direction for the project, but it would also cement a real user in their minds, an image that will almost certainly persist throughout the duration of the initiative.

Discovery-Workshop Agenda: Example

  1. Participants review and agree upon project goals.
  2. UX researchers present findings of previously conducted user research.
  3. The user arrives.
  4. UX researchers conduct live interview with the user; other participants take How might we notes.
  5. Participants ask questions to the user.
  6. The user departs.
  7. Participants cluster and prioritize the How might we notes.

Empathy Workshops

As the name suggests, empathy workshops exist to build empathy for users. They are frequently held at the initiation of a project or following a user research milestone, to share out and socialize research findings with the larger team.

Including Users in an Empathy Workshop

While sharing the findings of recently conducted research can be an effective means of growing empathy for users, nothing compares with the opportunity to meet users face-to-face. Consider inviting a few users to attend a research findings presentation. Give them the opportunity to offer their own perspectives on findings that either do or do not resonate with them personally. Invite stakeholders to ask followup questions, so they can gain further insights and empathy.

Additionally, an empathy workshop is often a time for constructing artifacts like personas, empathy maps, and journey maps. Representative users can be valuable contributors to these processes as well. Put users on a team with stakeholders and ask them to confirm whether the narratives that emerge are realistic.

Empathy-Workshop Agenda: Example

  1. Participants and users arrive.
  2. Audience is divided into small groups, with one user and 2-3 other participants per group.
  3. Each group focuses on the persona corresponding to the group’s user member.
  4. Each group generates an empathy map for its persona; users participate as full, collaborative group members and are encouraged to speak from their own experience.
  5. Users depart.
  6. Remaining participants debrief the process and the empathy maps, making any necessary changes.
  7. Participants decide on the steps needed to finalize and socialize the empathy maps.

Design Workshops

A design workshop enables a group of stakeholders — often both designers and nondesigners — to rapidly generate a wide range of ideas in response to a challenge or prompt. Rather than creating a single polished design, the goal of a design workshop is to broaden the group’s perspective and help members think creatively about the range of directions the team could go. This is why the contributions of both nondesigners (including users) and designers can be equally valuable.

Including Users in a Design Workshop

Teams are often reluctant to invite users to participate in a design workshop. After all, didn’t Jakob Nielsen famously say “don’t listen to users?” While this is true, it deserves caveats. When a user, in an interview or usability test, suggests the addition of a particular feature, we should take that request with a very large grain of salt. Users are not designers and they are not experts in devising features that will meet user needs. However, neither should we completely ignore the suggestion. That feature request indicates a hidden insight, a user need that might have otherwise remained undetected.

For example, if a user suggests adding tooltips to a form, it is an indication that certain form elements are confusing, even though tooltips may not necessarily be the appropriate solution for that problem.

By the same token, users’ contributions to a design workshop can be highly valuable, even if the specific ideas they generate may or may not end up being ready for prime time. Observe carefully the aspects of the design that users focus on when ideating and iterating, as they will likely uncover some unmet needs. At the same time, be on the lookout for design ideas that may be worthy of consideration. Just as nondesigner stakeholders often come up with the most valuable ideas, so, too, can users.

Design-Workshop Agenda: Example

  1. Participants and the user arrive.
  2. All review project goals, previous work, and research.
  3. All engage in design-studio activities such as Crazy Eights, sketching, and storyboarding to generate design ideas.
  4. All present and discuss their sketches.
  5. The user departs.
  6. A prioritization/critique exercise is used to decide which design to move forward with.

Prioritization Workshops

A prioritization workshop allows the group to efficiently winnow a large group of ideas down to the most valuable ones. This can be accomplished through dot voting or impact–effort matrices, among other methods. Prioritization workshops are often used in combination with other types of workshops, such as design workshops.

Including Users in a Prioritization Workshop

Prioritization workshops are supposed to leverage the diverse and varied backgrounds and expertise of the workshop participants.

For example, imagine that a team is plotting ideas on an impact–effort matrix, aiming to assess the impact that each design idea would have on the user experience, as well as the effort needed to implement it. Impact on user experience would best be assessed by researchers, customer-support representatives, or users whereas effort could be estimated by developers.

It is worth noting that, if an organization has multiple audiences corresponding to several personas, one particular user will shed light only on the experience of their user group. Therefore, either invite to workshops representatives of all user groups or, if that is not possible, supplement the input you receive from users with other data sources that document the needs of all personas.

Prioritization-Workshop Agenda: Example

  1. Participants and the user arrive.
  2. Various items to be prioritized are presented to the group.
  3. Each item is collaboratively plotted on an impact–effort matrix.
    1. A developer has approximately 1 minute to offer an estimate of the effort required to implement the item.
    2. The user has approximately 1 minute offer an estimate of the impact the item will have on their experience.
    3. The group decides where to plot the item on the matrix.
  4. The user departs after all items are plotted.
  5. The group discusses which items to move forward with.

Critique Workshops

Critique workshops allow teams to evaluate and iterate upon a set of solutions to a challenge. Like all workshop types, critique workshops benefit from a diverse group of participants who can provide varied perspectives. When a team is not sufficiently diverse, exercises such as the Six Thinking Hats enable team members to role-play perspectives that might not otherwise be present in the room.

Including Users in a Critique Workshop

While it is sometimes appropriate to invite a user to critique a concept in a critique workshop, an alternative, more common arrangement is to ask the user to provide their perspective about that concept, perhaps by using it directly, so that the team can later use this information in the actual critique.

As with all the other examples listed above, the ideas, opinions, and contributions of the user should not be treated as gospel, nor should they be weighted more highly than those of other experts in the room.

Critique-Workshop Agenda: Example

  1. The design to be critiqued is presented to the participants.
  2. The user arrives.
  3. The user is interviewed about the user needs that the design is intended to fulfill.
  4. The participants focus on the user-experience part of the design critique; this process may involve asking the user to complete tasks on a prototype while thinking aloud and providing feedback.
  5. The user departs.
  6. The design critique continues, with a focus on other elements of the design, such as relation to business goals and feasibility.

Logistics of Including Users

Recruiting Users for UX Workshops

Inviting a user to participate in a UX workshop involves a much larger commitment and risk than recruiting for a user-research session. If someone turns out to be a poor participant or a bad match to the recruiting requirements, a study session can be relatively easily replaced by a new one with an additional user.

In contrast, for workshops, you want to make sure that the users who participate will offer valuable contributions and be representative for their user group, so you’re not wasting your team’s time. For this reason, we recommend that you choose people who have previously participated in your team’s research studies — for example, someone who already is known as an articulate person, likely to clearly express their feedback.

Incentives

Like research participants, users participating in workshops will be providing a major value to your organization and, therefore, should be compensated accordingly. Consider the duration of the session in addition to any travel or other logistical requirements when determining a fair incentive amount.

Meals, Breaks, and Downtime

Please be a good and gracious host, and provide your users with meals, breaks, and downtime. If the workshop is longer than 1 hour, provide the user (and all other participants) with breaks and access to restrooms and refreshments. Additionally, build time into the workshop schedule for team members and users to get to know each other, rather than immediately directing them into intensive workshop activities. These interactions help all participants build rapport and feel more comfortable working together.

Avoiding User-Workshop Pitfalls

Many organizations are wary of including users in a UX workshop, for reasons both legitimate and overblown. Below are 3 pitfalls to be aware of.

Following the User Blindly

Some argue that workshop participants will forget Jakob Nielsen’s first rule of usability, to not listen to users, and will simply implement whatever ideas the user suggests.

This is a legitimate risk, particularly for groups unaccustomed to working directly with users. In addition to a well-intentioned desire to centralize user needs, stakeholders may also greenlight users’ suggestions in the moment, out of a simple anxiety to not appear rude or dismissive to their valued and invited guests.

There are two recommended approaches to overcoming this risk:

  • Educate workshop participants in advance. Prior to the workshop, share a presentation with workshop participants about the benefits and limitations of user contributions in workshops.
  • Schedule a frank discussion of users’ ideas after the users have departed the workshop. Often, it is best to invite users to only a portion of a workshop. For example, invite users to help ideate solutions to a design problem, but ask them to leave before critiquing those ideas. Users should not be subjected to hearing the team criticize their output, nor should the team be expected to walk on eggshells while discussing the user’s feedback.

Disappointing the User

Some people fear that users will expect that all their ideas automatically be implemented and will be upset if they are not. This argument is often used as an excuse for not soliciting feedback — whether from external users or internal employees. Frankly, I have little sympathy for it. Users, both internal and external, are almost certainly well aware of the myriad factors that go into releasing new features and fixes. In the rare case that a user may misunderstand this point, it can be very easily and succinctly clarified, both in early communication with users and during the workshop itself. For example, “Today we’re going to be brainstorming lots of different solutions for a particular challenge. This exercise is just one small step in a long and complicated process. Simply because an idea is proposed today does not mean it will be implemented. However, all ideas will be valuable and important contributions to that process.”

Introducing Bias

As with any research or design activity, we must always guard against introducing bias in the workshop process.

Establishing a comfortable working relationship between users and other workshop participants can be a tricky balance to strike. While allowing time for participants and users to get to know each other can encourage sharing and put the users at ease, too much informality and joviality could bias users’ contributions. Users may become empathetic toward the team and, as a result, provide primarily favorable feedback and hold back any criticism. This risk can and should be mitigated by clearly explaining to users (both verbally and in writing) that you welcome and benefit from all forms of genuine feedback, positive and critical. Reinforce this message throughout the workshop and ensure that any questions and prompts to the user are not leading (e.g., ask “What thoughts do you have about this design?” rather than “What do like about this design?”).

Similarly, guard against bias during the recruitment and selection of users for the workshop by ensuring there is a balance of perspectives and user types. For example, avoid relying on only customer-advisory boards, fan groups, or friends and relatives of employees.

When Including Users Is Not Possible

It is not always possible or recommended to include users in a UX workshop. Even in such cases, it is critical to focus on the user throughout these workshops. The best way to do this is to utilize user proxies.

A user proxy is someone with deep knowledge of users and who can speak to their needs and concerns. The most frequently utilized user proxy is a user researcher. This is generally a good choice, as a researcher has likely spent countless hours observing users and can generally advocate for their needs and perspectives. That said, there may be other equally valuable user proxies scattered throughout the organization. Customer-support representatives and sales representatives often spend their entire days communicating or building relationships with current or prospective users, and their knowledge of user needs may run deeper than anyone else’s in the organization.

Conclusion

A successful UX workshop will have a persistent focus on the user. One way to ensure that is by inviting users to participate directly. While users’ contributions to the workshop should be taken with a grain of salt and always balanced by other perspective, they will allow the team to build empathy and provide visibility to users’ needs and pain points.