Ideate like a pro. Brainstorming and Offline Ideation Week
#50: Cracking complex design problems with your team can be fun!
Welcome to Fundament, a weekly product design newsletter where we share actionable tips and insightful stories with the worldwide design community.
When it comes to solving design problems, designers are the first to come up with ideas for addressing them. But we aren’t alone here. We tend to work horizontally and collaborate with various functions across our organizations, such as product managers, software engineers, QA engineers, and marketing folks. After spending more than eleven years in this field, I’m sure that the best ideas come from involving entire product teams in the ideation phase of the process. Developing other team members' ideas would hurt some designers' egos, but it’s a shortsighted approach. We all play on one team and share a common goal. We must understand that designers don’t have a monopoly on the best ideas.
In today’s article, we will delve into brainstorming sessions and offline ideation, which I believe is much more effective than locking people in a room for several hours and forcing them to squeeze their brains to the last drop. I’ll demonstrate how to prepare for the ideation phase, because understanding the problem well is crucial before trying to fix it.
Getting prepared
Einstein famously said that if he had an hour to solve any kind of problem, he would spend 55 minutes understanding the problem first and the remaining five minutes finding the right solution. After a hundred years, this approach is still valid and should be followed by product teams that want to solve their problems meaningfully.
If you jump straight to Figma to draw a mockup right after talking to your product manager about the new initiative, you are doing it wrong. Instead, you and your team (or just a product trio in a super early phase) should spend a healthy amount of time digging into the problem.
Writing can be a tremendous help in the beginning. Dump everything you already know about the problem into a document. If you already have some data, link it to the statements. Form a hypothesis and make a plan on how you want to prove it, ergo, find out what you don’t know yet.
How do you form a hypothesis? Imagine you work on a SaaS product targeting a quite specific group of customers, e.g., freelance software engineers. You look at the product analytics and see a significant drop-off of users during the signup process. What is causing this? You don’t know for sure, but you may have an idea. Maybe there are too many steps in the onboarding process, or users don’t understand one (or more) of the steps? Now, let’s think about what will change after addressing the issue. Can you pick a specific metric and set a desired quantifiable change?
In this example, one could come up with the following hypothesis:
By reducing the number of steps in the onboarding process, the prospects (users who started onboarding but never finished) to activated users montly ratio will decrease by 10% within the next three months.
To find out what you don’t know, try to answer these basic questions:
Who is experiencing the problem? Is this a specific persona, segment, or archetype of your users?
What are they trying to achieve? What is the goal or job they’re trying to get done?
What issues do they face when trying to achieve it? What is stopping them from getting their job done?
When and where does the issue occur? What scenario or context is related to the problem?
What’s the reason this is happening? What is the root cause?
How does this problem impact our business? What are the measurable consequences for the users and the business?
How do our users feel about the issue?
What evidence supports the existence of the problem?
What’s the measure of success for solving this issue?
Feel free to extend this list with questions specific to your product and the problem you are trying to understand.
After you have the answers (hopefully all of them, but sometimes only a portion would be sufficient to start some ideation), include them in a document. That’s your comprehensive problem definition. It’s also a pre-read that you are going to share with the entire product team a moment before the ideation phase. This document should be concise and straight to the point. Aim to fill only a few pages, so the product team would understand the problem at a glance and wouldn’t get discouraged before the real work starts.
Share the document a few days before the ideation phase. I’d also recommend gathering everyone on the first day of the ideation week or spending some time at the beginning of the brainstorming session to go through the problem definition again and answer any emerging questions.
Brainstorming
I’m sure everyone has at least once participated in a meeting with a group of people where a specific problem was being solved using the collective minds of all participants. Brainstorming should have some structure and employ workshop techniques (more on this below in a later part of this article), but sometimes it doesn’t. The so-called facilitator locks a bunch of people in a room and says, “Guys, we have this problem. Any ideas how we solve this?”.
If you have ever found yourself in this room, I’m sorry for you.
It can look better.
This lack of structure generates another massive pain of brainstorming. The most vocal and extroverted people will dominate the meeting by throwing their ideas in a way that won’t be comfortable for rather introverted folks.
However, you can do a few things to equalize the chances of participation and being heard for everyone:
Make it explicit that all contributions are valued and there are no bad ideas.
Separate ideation from discussion. Provide a safe space for working on ideas and discussing them later to prevent participants from being discouraged.
Celebrate contributions. Acknowledge the input from all participants, even if some ideas are wild and unlikely to be implemented.
Here are some helpful techniques to make your brainstorming sessions more structured:
Round Robin Brainstorming – In this method, every participant has a turn to share ideas and must wait for their turn to come. Round Robin lets you prevent the dominant participants and express everyone’s thoughts.
Stepladder Brainstorming – In this method, a facilitator kicks everyone except two participants out of the room. These remaining two members share their ideas together while the rest of the team waits outside. The third and new participant is invited to join and share their idea first, followed by the other two. The process continues until all participants have entered the room and shared their ideas.
SCAMPER – In this method, you and the participants look at the problem through seven provocative lenses that enable innovation (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Rearrange). Learn more about SCAMPER from this article.
Offline Ideation Week
As the opposite of locking a bunch of people in a room for several hours, we have been testing a different method, which I call Offline Ideation Week.
Offline Ideation Week is an asynchronous approach that utilizes Aha! Moments and gives all participants equal chances to contribute.
The human brain works differently when it’s pushed to think about the problem right here, right now, than when it doesn’t think about the problem constantly. When we sit down and think of a solution to a problem for several hours with analytical methods, the front right part of our brain is very active. It prevents the back part of the brain from working, which is associated with the sudden realization moments, or Aha! Moments, if you will.
A classic example of an Aha! Moment (or a moment of illumination) is the story of William Wilson Morgan discovering spiral galaxies. William Wilson Morgan spent years classifying stars and studying their distribution, focusing on young, hot, and bright O and B stars (OB associations), which are typically found in the arms of spiral galaxies. In 1951, after extensive calculations of the distances to these OB associations, Morgan experienced a sudden Aha! Moment while walking home from Yerkes Observatory, he realized that the OB associations he had mapped formed a long spiral arm in the Milky Way.
In the Offline Ideation Week, you let your participants work on their usual tasks and think about the solutions for a new problem in the meantime. That increases the chances for Aha! Moments happening. Of course, there’s no guarantee that these creative bursts will happen, but chances are way higher than during classic brainstorming.
Here’s how to plan the work:
A week before. You share your pre-read, including the problem definition, with the group.
Monday. The whole group meets for a short meeting to go through the problem once again and discuss any potential questions.
Tuesday through Thursday. Everyone in the group works solo on ideas addressing the defined problem. Team members put their ideas on the board (it could be virtual). Ideally, each idea is self-explanatory or requires just 2-3 sentences to explain.
Late Thursday or Early Friday. The group meets again to review all ideas on the board and explain their ideas to the group further if needed.
Friday. The group meets for the last time to vote. Team members collectively pick the best ideas that have the highest chance of moving the needle and being implemented within the given time frame (budget). You must consider all risks during the vote, e.g., by plotting ideas on a value impact chart.
Does this sound intriguing? I wonder if other teams ideate like mine or with similar methods. If you want to try Offline Ideation Week, let me know how this worked for your team!
I love the idea of the Offline week! It's super powerful and in my experience silent brainstorming is one of the best tactics to foster creativity in a group and make sure everyone is heard. Thank you for sharing!