When, what and how to run workshops as part of the product design process

Charlie Harding
7 min readApr 16, 2019

--

A sketching session with the Android Developer and Potato team

If you‘re part of a product team and looking to forge better collaborative practices, move faster and help your team build more valuable products, then knowing when, what and how to workshop is a vital skill you’ll need in your career.

At Potato, we rely on them to super-charge our user-centred product development process, helping teams unpack complex problems, align quickly around a way forward and explore multiple solutions in a focused and efficient way.

The workshops we use take many forms and serve different ends. It can be tricky to know which ones to use, when to use them and how to get the most out of them.

As a product designer who’s facilitated a number of different workshops for clients like Google, NatWest and Mozilla, I’ve made made my fair share of mistakes. Hopefully this series of reflections will help you avoid those same mistakes and help your team on their path to building better digital products.

When is a workshop a good idea?

What no one tells you — or at least no one told me—is that the secret to a successful workshop lies not just in its meticulously curated agenda, nor the quality of the facilitation. A successful workshop relies on your ability to have successfully understood and acted on the signals coming from your product team.

Teams emit signals, both through their behaviour — what they say and do — and through the artefacts they produce. Some of these signals are clues to potential points of friction that may end up affecting the quality of your product further down the road. A workshop may help ameliorate these problems before they get any worse. Here are a few signals you should look out for:

Stalling over a decision.

The product team is caught in the jaws of a difficult decision, an impasse resulting from the conflicting demands of time, resources and opinions. The original problem area is muddied as discussions drift down numerous tangents and the team becomes frustrated by a lack of progress.

When the way forward is unclear.

The product team has multiple, equally valid points of view about how best to solve a problem. Developers might be vocalising support for a robust, scalable solution to the problem where a Product Lead might see a simpler but less stable solution as a means to delivering value more quickly.

When stakeholders are not aligned or aware of each other’s position on a subject.

The product team is being buffeted by the winds of unaligned stakeholders, each taking turns to swoop down, offer notes and course-correct in their desired fashion. This is affecting productivity and team morale: the teams focus is pulled in multiple directions and sight of the original problem is lost.

When louder voices are drowning out the the valuable contributions of quieter ones.

More confident members of the product team are holding sway and over-influencing the direction of decision-making. Talented, less confident members of the team with valuable insight are not being given room to express themselves and contribute to the success of the product.

When is a workshop a bad idea?

Workshops can be contagious. Run a successful one and you’ll find your colleagues clamouring to use a workshop to solve every problem. It’s tempting to see them as a panacea to every product design problem because, done well, they’re really fun! However, done badly, and for the wrong purposes, a workshop can be a tedious exercise in creative theatre.

When deep understanding or comprehension is needed.

Sometimes spending time alone with data or a piece of research is precisely what you need to build a more nuanced understanding of a problem area. Pulling a room full of workshop participants together to sit and read something is not the best use of everyones time.

When a simple discussion is just as valuable.

I’ve seen teams try to abandon meetings altogether and workshop everything. A controlled discussion (ie. one with an agenda, goals and a time limit) can often be the most productive use of a teams time. Think of how many post-its you’ll save too!

When a stakeholder isn’t ready or willing to make a decision.

Workshops require it’s participants to be courageous. They ask that you question every assumption and offer your wildest ideas; some ask even more: that the team make decisions or ‘bets’ on the best way forward based on limited insights. If a key stakeholder simply isn’t ready to make a decision, this leaves the team toothless and unable to progress.

What workshop activities are the most useful?

Workshops often comprise of numerous smaller activities that are designed to move the room towards a shared goal. Some workshops can go on for weeks such as Google Venture’s Design Sprint.

Regardless of their length, before considering what workshops or activities you would like to do, consider the signals your team is emitting and what you want your team to achieve.

Activities that help you understand and decide.

Building a shared understanding of the problem space as a team is vital to starting the right way. At Potato, we rely on the principles of Lean UX to guide our early product process, helping teams decide where to focus their attention for the best possible outcomes.

Assumption mapping asks the participants to unpack their beliefs about what may make the product more valuable: this could be a small assumption about a feature or a larger, riskier assumption around the most valuable user segment. Having your team write down their assumptions and then map them to a risk/known axis, will help you identify which ones are the greatest risk (or potential value) to the business and, therefore, are worth testing sooner.

Activities that help you empathise.

Central to any effective problem-solving process is a deep understanding of the pains and motivations of who you’re building the product for. Empathy mapping is a simple and effective way to get teams to start capturing how they believe their users experience the world and how their product can start to address their paint points.

You’ll want to be clear with your team that this is a starting point: as you move further along the product design process, you’ll be learning more and more about your users pains and gains. Be sure to return to the proto-personas you generated from the empathy maps to validate the original assumptions your team produced.

Activities that help you diverge and explore.

Brimming with empathy and a clear sense of purpose for your product, you’ll then need to help your team diverge in pursuit of the most effective solutions.

The Google Venture’s Design Sprint approach to sketching is a comprehensive package for getting the most out of your team’s abilities: limber up by reminding yourself of the challenge, taking notes on whats been discussed so far; next, pump out as many weird and wonderful ideas as you can in Crazy 8s; and lastly refine your strongest idea in with a solution sketch. Don’t forget to encourage your team to name their ideas!

What I’ve found with sketching is that it can often leave you with some exciting but inchoate, unconnected ideas. Storyboarding using AJ & Smarts method keeps the ‘connecting’ of the ideas a collaborative process that moves them team onwards towards testable solutions.

Whats the best approach for facilitating workshops?

Include the whole room.

During and after you’ve facilitated a workshop, consider the amount of time you’ve spent standing up talking with everyone else sitting down listening: if its a lot, you may have succumbed to what I like to call the ‘facilitator-as-noble-leader’ archetype.

The result of this dynamic is that you’re increasing the chances that the rest of the room will perceive you as the arbiter of discussion. Instead, you should be giving the room tasks, problems or questions, allowing participants to collaborate with each other and then, at the right time, helping facilitate a discussion around the output.

Whilst you might feel that commanding the room is reassuring for the team, in reality you’re closing down pathways of communication and collaboration with the rest of the room. There’s a reason you’ve pulled the people together; let them work with each other not just to you.

Use key phrases to optimise participant output.

There’s a two key phrases or techniques I fall back on most regularly to get the most out of workshop participants and their contributions:

“So let me play this back to you….”

Giving a participant a chance to hear their own thoughts repeated back to them can often be a valuable for both themselves and the whole room. It may give the participant a chance to rephrase for extra nuance or give others in the workshop who may not have understood the original statement a chance to dig a little further.

“That’s an interesting point but based on the time we have, lets put it in the car park so we can circle round on it later.”

Workshops are breeding grounds for great ideas, insights and opinions but you’ll want to be careful about which ones you let play out in the room. If you feel like some are dragging you off course, the above can be a great way of keeping the discussion focused without being dismissive.

You can’t do it all yourself.

Often I’ve seen facilitators try to ‘capture’ — writing down what workshop participants are saying on post-it notes or on whiteboards — and facilitate simultaneously. This can often lead to the facilitator missing key pieces of information as they scramble to write down everything they’ve heard as fast as they can.

Agree roles and responsibilities with your workshop team before hand and make sure there’s enough willing ‘capturers’ so you don’t have to try and juggle both roles.

Get some rest.

Facilitating workshops can be exhausting: get a good nights sleep, eat well and stay hydrated.

--

--