Running Product Design Workshops for older/non-tech groups
Last year I worked with an older, non-technical group to create a web application. I ran several Product Design Workshops and it was a learning experience for myself and the group. There were many things that were different compared to working with an IT team.
I’ll share:
- the basics of running a workshop;
- the challenges we faced;
- the tools we used;
- how to keep the team on track;
- what worked and what didn’t, and more.
The Upfront Challenges
New Processes
Older or non-technical groups aren’t used to Product Design Workshops or Design Sprints, so they now have 2 tasks to tackle at once:
They have to create a product and they need to learn how to do it, using a new process.
New Tools
Depending on the nature of the business, size of the organisation, number of people in the group; you may need to introduce new applications or tools to facilitate workshops.
This could add an additional level of complexity to a group that may not be as familiar or comfortable with learning new technologies.
Focus
The group isn’t used to the process.
They’re going to lose focus and veer off course a lot. Sometimes they’ll get stuck in the details and other times they’re going to overlook things and assume it’s obvious.
It will be an on-going challenge as the facilitator to keep them focused.
Overwhelm
We’re going to teach them a whole new way of designing their products and we’ll introduce new tools. At the same time, we’ll be probing for more detailed answers at times, while other times we’ll tell them to park a topic.
They may get overwhelmed, confused or frustrated — or all of the above. This will impact productivity, team morale and the quality of work produced.
Being a good facilitator
Facilitating a workshop isn’t easy, and working with an older or non-tech group adds even more challenges for the facilitator.
- Are you patient with the team?
- Do you give them enough time to discuss?
- Are you ensuring that the session is productive and everyone is heard?
- Is the session enjoyable for the team?
- Do they feel a sense of accomplishment afterwards?
The Foundation
Let’s talk about prep first:
Scheduling Time
A 5 day workshop, of 4 hours per day, could be all you need for smaller applications.
But large organisations with more complex products usually require more time. Booking at least 4 hours a day, twice or thrice a week, will keep the momentum going.
It’s best to send invites for all sessions ahead of time so the group can prepare their days or weeks accordingly.
Do you have the right group in the room?
It is so important to have the right people in the room during the product design phase.
Imagine spending days or weeks with a group and then presenting at a stakeholder meeting, only to find that the group hasn’t addressed the product’s main objectives.
Run the attendee list by the Product Owner, or your organisation’s equivalent, before sending workshop invites. All relevant stakeholders must be included.
Dealing with team availability
Availability is often a challenge in large organisations.
Create a basic calendar/schedule of each session with the topic that will be covered, so team members know when they must join.
Indicate mandatory attendees to be clear.
Point out key milestones to senior stakeholders, so they’re only involved in relevant sessions and not when the group is brainstorming.
Get a room
It’s important to have a regular room for sessions. It avoids confusion for attendees, which results in time wasted. It also saves setup time, for us facilitators.
Imagine carrying around flipchart paper, sticky notes, and wheeling a whiteboard around for each session? Not pleasant!
If you can’t get a regular room, maybe a quiet designated space? You need a space where everything can remain posted up, week after week, without anything getting lost.
At the workshop:
Explain the workshop format
They’ve never worked like this before.
Spend time explaining the format of the session upfront, rather than just diving in. Take time to explain things like UX, UI and other design terms.
Go over workshop etiquette & rules and pin them up.
To manage expectations, display the agenda for everyone to see during each session & repeat it at intervals, if you have long sessions.
Techniques and Tools
Don’t introduce too many new workshopping techniques/tools in a single session: 2 to 3 should be fine, depending on the learning curve.
Make sure the team understands the technique and take time to ensure that everyone is comfortable. They’re not going to get everything in one session, so recap in the next session to refresh their memory.
Facilitate to support
As a Product or UX Designer, we don’t always know the subject matter very well. That’s why we work with a group of experts in the field to design the best possible solution.
It’s important that we facilitate group discussions and make sure that everyone is heard.
The Tools
Pen, paper and sticky notes
Good old pen and paper, and it works so well with non-tech and older groups. You really can’t go wrong. At first, both groups will try to save sticky notes by combining ideas on a single note but if you join in and show them a few examples, they will soon forget about conserving sticky notes and concentrate on coming up with great, concise ideas.
Documentation
Bring along documentation related to the product. This will include technical documents, marketing proposals, feedback from user interviews, data, business objectives, competitor analysis etc.
Teams that have a good overall view, while designing products, create better products.
At some stage early on, you will need to go over the documents with the team and decide when it will be relevant to discuss. Sometimes the whole team won’t be aware of certain documents, so it’s really important to facilitate in the flow of information.
Whiteboard and Flipcharts
There are great online tools but with our group in mind, a physical whiteboard is best.
But one whiteboard is never going to be enough.
Adding a flipchart to the mix will be helpful, and you can stick pages next to each other for everyone to refer to.
You’ll need to take pictures of everything and upload it somewhere (InVision, Realtimeboard, a shared folder) for everyone to access.
InVision or similar
We need a place to house all the sticky notes, user journeys, wireframes, documents & mockups.
InVision is great. As UX/Product Designers, we’re already familiar with it and I’ve found that non-tech and older groups find it easy enough to use because they only use it as a point of reference.
There is no need for them to upload documents and using Comments isn’t necessary either. They just need to be able to access and view workshop info and progress, in their own time and as easily as possible.
How to keep on track
They will veer off course a lot. It’s your job to politely steer them back, without making them feel like what they’re saying is unimportant.
Acknowledge the item
Understand and agree that the item is important to discuss, and mention when the team will tackle the topic — whether it will be later in the session or even in following sessions.
Remember that agenda we created and circulated to everyone beforehand?
Well, it’s not only handy for management to know when to attend, it’s also useful to help manage team expectations in the long run.
Parking Lots
Use Parking Lots for ideas that the team is yet to explore. A Parking Lot could be a whiteboard or just a space on the wall, where you list topics you need to discuss.
Keep Parking Lots well organised, with related info grouped together. Encourage the team to add to the board when ideas arise. They’ll feel involved in the process & less anxious about their ideas being minimised or forgotten.
Is it more complicated than you understood?
Remember, they’re the subject matter experts. We’re facilitating and ensuring that all necessary topics have been covered and explored. So do look to the team for guidance as well.
Ask the team if the topic is important to discuss right then. Is it more complicated than you understood or could it wait until the team gets to the relevant stage?
In time, they’ll get used to this way of working and catch themselves when they veer off course.
Breakaway sessions
Sometimes it’s helpful to have an impromptu breakaway session. If you’re discussing a topic and you realise that something is more complicated that initially understood, let the experts break into a little group to discuss the issue and come to a consensus. The rest of the group can continue until the breakaway group returns with a decision.
This method also works well when you’ve told team members to park that idea, one too many times. Let them breakaway for a bit and brainstorm that idea while they fresh on it.
I’ve also used breakaway sessions when I have limited time with a group. I divide different sections of an application into logical groups and I also divide the team. I assign a team to a section and they brainstorm key functionalities, requirements and objectives. Then we come together and each group presents their section. The other groups confirm and question what the group has surfaced. I find this really helpful when we’re pushed for time.
Explaining the process with an analogy
You know how I keep mentioning that the group gets caught up in the details, while being vague other times?
That was often my greatest challenge during sessions.
I tried to help them by using the analogy of a house.
I asked the team to imagine that we’re building a house. We’re not going to decide on the flooring or number of bedrooms upfront.
First we’re going to find out all the high level details:
- what’s the budget?
- who is it for and how does that info influence decisions?
- what type of land are we building on?
- theme of the home: multi-storey, victorian…
By breaking down those items and doing some research, we may discover that the family wants a single-storey house, a large landscaped front yard and a pool in the backyard. With those 3 factors in mind, how do we use the space to its maximum, without making the house too small?
In the same way, I explained that we’re going to first keep outlining the requirements. We’re going to cast our net wide and keep reeling it in, until we start getting into the details. We’re also not afraid to rework initial solutions if we find a better solution down the line.
I referred to the house example and drew parallels in every session!
But here’s the good news: they started to catch themselves after a while and then started writing it down on sticky notes for later. Also, they were so happy with themselves whenever they identified it on their own.
Facilitating Sessions
Everyone in the team needs to feel and be involved. As facilitators, we have got to watch for that.
Try to get to know the members of the group. I’m not keen on singling people out. So if someone doesn’t talk as much, I don’t like to single them out and ask what they think of x.
I prefer to rather go round the table and give each person a chance.
When team mates dominate for too long, I’ll often ask:
“What does everyone else think about that?” — and go around the table.
Other phrases I often use:
“That’s an important topic. We’re going to be talking about Statuses next Tuesday, is there something we need to note right now?”
I’d encourage them to go add the relevant note about Statuses to the Parking Lot or relevant section.
Let’s think about that a bit more. I log in, in the morning, and what do I want to see?
That’s when I think we’re not getting enough detail. I pretend we’re in the real world, using an already completed application.
Did we get everything they’d need to capture, to be able to make a booking
What’s the goal of this section? What’s the main things a user must be able to do here?
Some days the team can go for 2 hours, take a break and be back for another 2 hours. Other days, they need a 10 minute break after each hour. There are always factors, so watch the room. Ask them if a break would help. If some people want to keep working, keep going with them and then recap, with the rest of the team, when they’re back.
There’s nothing wrong with a recap. Recaps are helpful!
Bringing snack platters really helps team morale. In larger organisations, it’s usually easier to organise and they’ll come lay it out and clear it, which is great. I’ve noticed snacks really keep the team going. You’ll just need to have the room arranged so that it’s not distracting.
Be flexible
Each team is different. Adapt as you go along. When I started working with a team last year, I thought they were going to take forever because we were going in circles. We got the hang of it by the end of the first session, but the second session took us two steps back. I started repeating myself more, and as much as it was frustrating for me, it helped the team.
And that’s the main goal.
So I learned to repeat myself more and be patient.
I also asked the same question in different ways a lot. That helped the team delve deeper into items I thought they were overlooking as easy.
Although it was a challenge, it was a good learning experience for me. When I left, I was excited to hear that the team valued the process and wanted to continue in the same manner.
There is so much value I see in this process. Besides the obvious Design Thinking & Design Workshop plus points, I found that this process replaced the corporate way of one person’s voice drowning out the rest of the team.
Having a Product Designer facilitate a session ensured that more voices were heard, more concerns raised, more info was offered; and it increased the probability of a better product being built.
