Article Continues Below
To be successful, workshops need to be planned carefully and explained clearly. Good workshops start long before you get people together in a room. They start with a list of goals, an agenda, and clear communication to the attendees. While this does not guarantee success, it does set a solid foundation for how you want things to run. It also provides a framework for the tasks and activities you use in the workshop, but we will take a look at that in another post.
Setting workshop goals
Let’s start at the beginning. Someone in your organization, whether it’s you or another leader, has identified the need for a workshop or session with the team. This is most likely in response to a perceived lack of skills, lack of direction, or the need to form consensus around a decision. Pinpointing a problem is always an excellent first step, and lets you define some high-level goals.
Start by writing down some general ideas of what you want to achieve. I usually end up with a list of five to seven goals, all related to the team need. Then that gets whittled down to two or three sentences. I state them like this, to help guide me as I create the rest of the workshop:
At the end of this workshop:
- Attendees will be able to define, plan and conduct UX research on a new product feature.
- Attendees will have decided on a set of research questions, so they can gather user feedback.
- Attendees will have demonstrated the power of UX research planning to the organization.
Creating an agenda
Your workshop agenda should, in every way, support the goals you stated. Every agenda should have an intro and a wrap-up. Depending on your goals, sometimes a Q&A session at the end is necessary. If a goal was to train your coworkers on a new system or strategy, then questions and answers fit perfectly. However, when the goals of your workshop are to generate or refine new design ideas, a Q&A at the end would not contribute much.
I also make sure to define, down to five-minute blocks, how long each section of the workshop will take. This is key. The relative amount of time spent on each task tells attendees exactly how important it is to the topic at hand. 10 minutes spent brainstorming ideas and 30 minutes spent critiquing them says something very specific about your team’s skills and needs—that they need practice generating ideas quickly and then analyzing them for a longer period.
Here’s a sample 90-minute agenda for a workshop for a team of designers who need to learn how to scope and deliver user-experience research. The tasks are loosely based on Chapter 3 of Just Enough Research:
Intro (5 minutes)
Task A: defining the Research Problem (15 minutes)
Task B: selecting a Style of UX Research to Conduct (20 minutes)
Break (10 minutes)
Task C: conducting the Research (20 minutes)
Task D: collecting and Sharing Data (10 minutes)
Wrap-up (10 minutes)
For sessions longer than an hour or two, it’s essential that you plan bathroom and laptop or phone breaks. Although you want attendees to be engaged and “with you” the whole time, life doesn’t stop for anything, and people need time to check in at work. It can also serve as a release valve if there are tensions or disagreements happening in your session. We will talk about how to manage these situations in a later post.
Deciding whom to invite
Each attendee should have a role to play. The goals of your workshop are there to help you. If any attendee will not be able to contribute to achieving them, they don’t need to be invited. Political considerations may trump this, but try to keep your attendee list focused. When it comes to design workshops, there are five possible roles that will show up.
- Sponsors are the people who have asked you to conduct the workshop, or are on the line politically for the success or failure of it on an organizational level. They will often speak to higher-level concerns and strategy.
- Stakeholders are the people who have a stake in the results of the workshop—they are most often directors, team leads, or others with responsibility for others. What is learned or decided in the session will be what they need to manage or implement, so they care on an operational level.
- Participants are team members and attendees who have been invited because of their design, marketing, or even development skills. They will be the ones most often tasked with doing the actual user research, writing the code, and designing the interfaces that come out of the session.
- Users are those who will be consuming, or interacting regularly with, the final product the workshop seeks to work on. As geography breaks down on the internet, often it’s better to plan separate research sessions focused completely on users, but for some design projects, it can be effective to have them attend. When the workshop goals are about an internal tool or platform, users will be your coworkers.
There will be overlap in these roles, especially with smaller teams. That’s fine. Simply decide which one best defines the attendee’s role during the workshop, and you’ll be okay.
Participation vs. facilitation
One other role I want to mention is the role of the facilitator. A facilitator is not actually an attendee. Facilitators remain impartial, inform attendees of timing and schedule, guide but do not dominate a discussion, and take notes in a way that provides documentation. They listen, coax, and sometimes even redirect attendees in the tasks and discussions that arise. If you cannot play this role, then assign another member of your team to facilitate, and communicate this early and often to the rest of the attendees.
Okay. You’ve now done all the prep work for this workshop. You have some defined goals. You have a list of attendees and the role they each play. You’ve emailed everyone with the schedule, name of the facilitator, and given instructions for the day of the workshop.
Next time, we’ll look at how to run the actual workshop, and how to choose tasks based on your defined goals.
