BrainStorming or just Storming?
Somehow, brainstorming has gotten a bad rap. I was actively brainstorming at the white board with a product manager one day. As we were having excellent success at nailing the key elements of the design, he looked at me and said, “My business professor told me this wouldn’t work”. Hmmm. I wasn’t sure what to say other than I’ve heard that theoretically, bumble bees cannot fly, yet somehow they do.
By the way, rigorous usability testing later on confirmed that the concepts we came up with in that brainstorming session were dead on target. So, I am still a little confused about who is saying brainstorming doesn’t work and why. Perhaps they’re just doing it wrong?? Or maybe I am just using the term too loosely to describe using your brain to analyze and solve problems. ??
As with all recipes, ingredients are important. So first of all, before you begin, make sure to have an ample supply of good quality brains on hand. This will make things go better as the process gets messy. Having these ingredients will enable you to improvise in case something doesn’t work as expected or you spot a new opportunity that was not anticipated.
Having been trained in Six Sigma, my tendency is to look for root causes of pain points following the five whys to begin forming hypotheses. Of course, Six Sigma was invented for manufacturing where a given product or process was already defined and typically the tools were used for trouble shooting to reduce defect rates, hence the name. That has always made it a weird fit for design, where the purpose is the define the not yet defined product or process.
But wait. Here’s the deal, Flipping this method on its head, one can use the same cause & effect logic to trace the root causes of a good effect, such as customer delight. Brainstorming potential causes of customer delight based on things you know about the audience (personas), their tasks, the context, the business domain, etc. can produce some very good hypotheses for taking into design. This can feed the lean methodology. I have named this my “fish bone to wishbone” method. i.e., Fish bone (Ishikawa diagram) leading to an A B test (wishbone). Get it?
Maybe my point here is to not simply open the table to ideas, but to have some cause & effect rationale for forming hypotheses that can then be explored and tested. Testing hypotheses need not always require a design exercise. In fact whether you do proceed with a design to test or not, you should attempt to prove or disprove each hypothesis with existing available data. Sometimes this along is enough. Or it may direct you to a more focused design exercise.
Typically, there maybe multiple ideas swirling as to what is the way forward. Simply gathering up everyone’s assumptions and ideas is constructive IF you restate all of them as testable hypotheses. This can be a great way to cut through folk lore, eliminate churn and move the team forward. Of course (here comes the disclaimer) group dynamics are still at work and your mileage may vary. Cheers.
copyright 2013 Roger Belveal 😉