Scoping a workshop for non-designers
This is a 3 part case study on scoping, delivering and reflecting on a one-day design thinking workshop for non-designers.
Since joining IBM in Sept of 2015 I have tried to absorb and learn everything I can about design thinking, an incredible framework to aid in the problem solving process.
In July of 2016 I took on the role of Design Thinking Practice Lead. A big part my job is to organize and lead workshops. The sessions bring together engineers, sales, offering management, product owner and solutions architects. By using design thinking activities we gain alignment, creating solutions for their toughest problems through collaboration. The workshops I have run have been great. The teams I have been fortunate enough to work with were able to pick up the simplicity of design thinking. They were able to use it as a common language to communicate quickly. As a facilitator it has been a joy to see this in motion.
As with anything in life, nothing is perfect.
A few months back, I was talking to some participants of a workshop about their experiences. Many spoke about their enthusiasm toward design thinking. In the war room experience, they felt like everything was working well and they saw the vision of our solution.
But throughout the process I was constantly reminded that they are just a small part of the product development process. For many IBM’ers, you work in a large team spread out across the globe. In an on-site workshop where decision makers are in the room it is easy to “drink the Kool-Aid,” forgetting that you are in a facilitated session. At the end of the day, we all have to go back to our teams and our daily routines.
I took this critique to heart and reflected with several workshop stakeholders. Until then, I had not seen one of the biggest problems that designers and facilitators face.
How do you help non-designers adapt and use design thinking in their everyday workflow?
I scoped this problem the same way I would a UX problem, with research.
1. Identify my user
I wanted to better understand an interesting role we have at IBM called the Offering Manager (OM). IBM classifies an OM as someone who, “defines, develops and delivers differentiated offerings that focus on winning in markets and delivering iconic user experiences.”
I wanted to talk to people in the field who both had a wide reach of influence and people who dial into daily tasks. This included OMs who focused on training and on-boarding, senior-level OMs who oversaw whole product portfolios, and associate OMs who were just starting out their careers.
All-in-all I was able to talk to 10 different OMs at various levels.
2. Understanding their problems
I began by conducting generative interviews, and was amazed at how willing people were to give me 30-to-40 minutes of their time. Especially if it meant that I might be able to solve some of their daily problems. The first thing I noticed was, their jobs were anything but simple.
When prompted on, “take me through a day in your life.” I heard everything from managing 20 other people to constant client-related travel. Many kept development schedules on track by creating deadlines, some established the annual budget, and all of them said they helped or lead the scoping and delivery of product releases. Needless to say, I learned that their job was hectic. It is reliant on many people to move the needle forward.
Jotting these comments and frustrations down, I started to see a pattern. I started to recognize a problem that design thinking might be able to solve.
Many of the OMs had a lot of frustration around keeping alignment during a development cycle. Many OMs feel like they have to be the mediator between several different parties. More often than not, they feel like the walls are closing in. One of the biggest commonalities was the desire to become user focused. As more competitors enter the domain and consumer options increase, a good user experience is essential. But at the end of the day nobody really had a true, first-hand understanding of their users.
I have seen that in product development we think we know a user’s problems. Instead we should be asking a user, “what are your biggest challenges or pain points?”
By asking my users, the OMs, that same question I found that one of their biggest challenges involved their evaluation on a metrics-driven performance model. They needed to know how they could set up a clear user-centered metrics for success. In the end, I found that their problems were very different from the ones we had been using design thinking to solve for in the past.
With more empathy for my fellow colleagues and a better understanding of the real problems we should be trying to solve, it was time to find a way to make our tools work for them.
3. Scoping the Problem
One of the most common problems I see teams making at the beginning is scope, they often bite off more than they can chew. That is why even the biggest problems need to be scoped to have the most impact. In the end it helps mitigate those half-ass solutions that generally end up making the problem more complex.
For this workshop in particular we set out to solve these key problems:
- How can we show that facilitation of design thinking is an inclusive process?
- How can we adapt design thinking tools to help OMs align their team?
- How can design thinking help aid in communication and speed up product releases?
I gave a lecture recently around public speaking. This quote about preparation from Benjamin Franklin resonated with me.
I think it directly applies to how a facilitator gets ready for a workshop, sometimes we over prepare and other times we prepare the wrong things. In the end, we end up creating a prescriptive workshop that becomes repetitive and loses its impact.
Tim (co-facilitator) and I took three new steps to make sure everyone enjoyed the experience.
- Creating exclusivity. We wanted to cap the participant total to 15 people. This would allow us to make sure that we were not spread too thin. It also allowed us to actually engage with the participants, something that is generally tough for a lead facilitator to do.
- We did not invite anyone. Rather, we sent out the information to the directors of certain business units. We asked them to distribute it to people who had interest. This put the ball in the participant’s court, and forced them to ask themselves: “Do I want to spend my whole Friday learning about design thinking from strangers?” The idea was to reduce forced attendance and meet enthusiasm with enthusiasm.
- We kept it loosey goosey. During preparation we kept the schedule loose and transparent. We started the session off by saying, “This is the first time we’ve run this type of session. We want you to be constructive in your comments. If you think these principles hold value to your work tell us, if not, we will move on to something else.” We as facilitators got to see what activities actually resonated, and which ones might only be good for a larger group setting. It allowed us to acknowledge that they are not designers, that their work is different than ours. In the end, we knew that we needed to build empathy with them and how they would use these tools in their everyday lives.
Continue to part two of the three part case study on scoping, delivering and reflecting on a one-day design thinking workshop for non-designers.
Naveen Raja is the head writer for Educate and Iterate, a design thinking resources website. His passion for design has allowed him to vision, scope and scale design facilitation programs for companies both large and small. Through helping various teams at IBM, Fidelity Investments, Citibank, Marriott Hotels and more he is perfecting his recipe for how to help people to achieve more by using design. He is passionate about how people, places and cultures intermix and the significance it can play on creating an experience.
Please heart & share this case study and please voice your questions, comments or concerns below!