Teaching How To Brainstorm: Reflections
This summer, I’m working with would-be entrepreneurs on startup teams as a UX designer. The job is challenging me to come out of my comfort zone: my UX portfolio consists of mostly non-digital work, a rarity for most UX designers. Most of the time I’ve walked teams of people through design challenges, helping them come up with ideas, differentiate assumptions and insights, iterate their prototypes, and test effectively. In this sense this position is a perfect opportunity not just to use my existing skills, but also grow more into the digital space.
My challenge here was to design a brainstorming activity for a group of so-called “non-creatives”: finance and business people, but mostly computer programmers. It’s not secret that these folks tend to think linearly and logically, and are eager to jump straight into the technical details rather than examining the larger picture first. I wanted to create a base so that these small “startup teams” could brainstorm ideas they were passionate about, but at the same time establish a platform to better understand the task at hand and provide a foundation for soliciting user feedback and pivoting parts of the plan in the future.
In order to convince a group of people who had never been exposed to design thinking before that this would be a worthwhile activity, I sought to qualify it. I told the group that the activity they were about to take part in had first been tested with a group of entrepreneurs. This was mostly true — I had been learning design thinking for a while, but the first adaptation of design thinking for a non-designer audience had been for a group of sub-Saharan African agribusiness entrepreneurs and professors needing help with implementing their business ideas.
Everyone got into groups of five or six, armed with a stack of post-it notes. I had each person spend five minutes writing down insights — anything useful, challenging, or interesting about the task at hand. Any ideas that people had during this process would go in the “idea fridge”.
After everyone’s insights had been collected, the groups talked amongst themselves about anything interesting they had observed. I asked each group to organize the post-it notes as they saw fit. If a lot of the post-its had similar themes, cluster them together. If they’re steps in a process, make a timeline.
I was surprised to see how each group’s ideas came together. Even though every group was tackling the same challenge, each approach was markedly different. One group realized their post it notes corresponded to different stages in a process, and sought to highlight bottlenecks. Another realized all their clusters were symptoms of a larger problem, and tried to discover the root cause. Yet another saw their clusters as attributes in a model, and worked to organize which factors were important and which weren’t. Despite the lack of diversity in profession, there was a great proliferation of ideas.
I challenged each group to take their models and write challenge questions, starting out with “How Can We”. The groups had their problem spaces — it was now time to write problem statements that could guide ideation and narrow into problem spaces. By the end of this time, each team had an overarching question that they were trying to solve.
Originally, I had planned a set of creativity games for this next section, like the famed “What’s In the Box?” and a round of Mockuptionary. Unfortunately, time was short and the teams needed to start coming up with ideas. So I challenged the teams to come up with as many ideas as possible.
This was the most difficult part of facilitating the challenge. Everyone was so anxious to have ideas that were legitimate and well-planned, and this really stunted the flow of ideas. Even when I prodded teams with tactics like blue sky ideas (“If you had unlimited money, unlimited time, and unlimited resources, how would you go about solving this problem?”) and offered to write random things as they shouted ideas at me, I was unable to make the teams jump-start their creativity.
After the brainstorming session, I let the teams continue coming up with and building on their ideas, walking around the room to help teams work through their further solution-building.
What was surprising was just how receptive the teams were to what I was pitching them. For a crowd that was STEM focused and hadn’t seen design thinking before, they reacted very well to the challenges I posed for them. One team, upon hearing the hundred-solution challenge, went so far as to make a numbered list with all of the possible options they were brainstorming up.
A lot of the teams really benefited the most from the visualization components of the exercises, helping to build strong foundations for their ideas. The teams are even still building off these diagrams today, using them to prepare their business models.
The real downside to this activity is that it should have been done immediately after onboarding, not the next day. I would have loved to have teams gather their insights right after learning about the problem, and then return the next day to brainstorm and play creative games. This would have put the teams in a much better mindset and helped them get ready to come up with wilder ideas. I would also have gone over some of the brainstorming ground rules, but because the brainstorming activity was so crunched for time, I wanted the teams to have as much ideation time as possible.
The reason I wanted to get the teams in a creative mindset is because the teams had already been working on their own solutions, with their own assumptions. One team flat-out told me that they were still going to participate in the activity for backup ideas, but that they just wanted to stick with the idea they currently had because it had been suggested to them by upper management and they didn’t want to take too much of a risk. This influence was another reason why it was so hard to tease solutions out of these programmers.
… and The Ugly (Just kidding)
If I was to repeat this exercise with a different group of people, here are some of the changes I would make. I would have extended the time we had, put in place more brainstorming prompts (like the 100 solutions idea and the blue sky ideas), had a much better workspace (teams were working on an assortment of chairs and coffee tables because there was no large space in which to hold the activity) and organized some primary research. One of the biggest pitfalls of this exercise was that there was no opportunity to do any sort of primary research at all. I had expressed my concerns to others, but they said that there just wasn’t anything they could do at the present time to get actual users and clients in the room. This put the very fundamentals of the brainstorm on shaky foundations. But I know that sometimes, secondary research is better than no research at all, and teams will have the opportunity to validate their ideas later, in prototype form.
For those of you looking to implement this exercise to help spur ideation in your company, or your department, or your organization, this is actually a very good activity to use. I will probably iterate this activity a couple more times, consult other people’s experiences, and hopefully make it better for future brainstorming opportunities. This post is less of a how-to guide and more of a case study in how my particular brainstorm went, and I hope that you can read it, see what went well, and learn from my shortcomings.