Imagine an arena where the participants are brought in with their eyes closed. The participants are then asked to describe an elephant with their eyes remains closed.
The first participant says that an elephant is long and skinny like a snake.
The second participant says that the elephant is like the trunk of a tree, round and thick.
The third says that an elephant is wide and circular like a giant disc.
Being creative is often like being a participant with closed eyes, we are dealing with a problem that we cannot see.
We all have been to brainstorming sessions like above in which the participants discuss the topic in their own frame of view which is difficult for the other participants to comprehend. We have also been to sessions in which the participants jump from one topic to another without connecting the dots or analyzing any of the topics thoroughly.
Example of this could be customer research discussions or discussions where teams from multiple domains join together to solve a business problem. The participants may come from diverse domains and may have difficulty in communicating in the same language. They may also find it difficult to understand and comprehend each other’s view easily.
In a creative process which involves multiple domains such as business, product, application, user interface, and customer experience there are at least two levels of analysis required. First, one must analyze the available domains to identify the correct problem. Second, with the identified problem in hand, one must scan through the domains again to discover the best possible solution. In other words, one has to jump back and forth until it clicks. This is difficult to achieve in one go.
Creativity has no beginning and no ending, One has to jump back and forth until it clicks!
An effective approach to brainstorm in scenarios that involves creative discussions is to divide the brainstorming session into two phases, a problem discovery phase, and a solution discovery phase.
How do we navigate the problem discovery phase effectively?
Let’s introduce a role called, “the problem solver”. The role of a problem solver in the problem discovery phase to simply act as an observer and try to understand the problem clearly. In simple words, observe and understand the problem. Observing doesn’t mean being passive, it also means asking the right questions, debating preliminary ideas with just one goal, to discover the problem from the participant’s minds.
As a problem solver, it is very important to understand the problem correctly, most important to make sure they have identified the correct problem. This is important, without which our solutions may not work, worst, we may continue to iterate the new solution without the realizing that we are attacking a wrong problem.
As engineers, we have an inherent bias to seek solutions quickly or trying to fit an existing pattern or solution to the problem that we are trying to discover.
In the problem discovery phase, all the participants must be mindful that they have joined together to discover the problem. This is important so that we don’t focus on seeking answers quickly. As engineers, we have an inherent bias to seek solutions quickly or trying to fit an existing pattern or solution to the problem that we are trying to discover. Trying to arrive at answers quickly might also trick our minds into confirmation bias. Understanding these nuances will help all the participants to navigate this phase effectively.
Be an observer
Keep your mind in absorbing the problem
Keep yourself in a state of neutrality
Don’t’ accept anything
Don’t reject anything
Be skeptical, let the future research and proof to convince you
Be aware of the confirmation bias both from participants and in yourself
Don’t ask questions that directly lead to answers
Always keep yourself in a position of open-mindedness
Another useful approach is to divide the problem into smaller units and analyze them independently. In any creative process, when we try to model the solution, there would be many moving variables, especially at the initial stages of the design. It will be therefore difficult to build a model by analyzing all the variables at once.
In a problem that has multiple variables, try to lock the variables as soon as you can. Though there will be a level of abstraction and guesswork, this will allow you to picture the complete prototype of the model. Then, iterate each variable to perfection.
Dividing the problem into smaller units will help the problem solver because it’s easy to analyze the variable at a micro level than at a macro level, we can also lock the variables quickly in this approach. This technique, in the end will enable the problem solver to preview an abstract model with all the variables locked-in. Though there will be guesswork, the problem solver can then pick each variable and iterate them to perfection. In simple words, once we construct a model, we can iterate the model against real-world experience to test its validity. This approach is similar to the scientific approach discussed by Richard Feynman.
In a multi-domain system, the problem and the solution may also lie across the domains. Dividing the problem into smaller units will also allow the problem solver to classify and prioritize them effectively. It will also expose the interconnectedness of the problem between the domains and let the problem solver to identify the correct problem domain or combination of domains to apply the solution.
Solution discovery is a big topic in itself ,which requires a detailed discussion. There are many techniques to solve problems effectively, I have discussed some in my previous post called problem-solving.