Brainstorming is a part of a lot of jobs, whether you work on “creative” stuff or not, and whether you work alone or in groups. There are lots of good ideas in your head, and you just have to get them out.

Easier said than done.

But brainstorming for functional solutions is a little different than just being creative or extracting something new. It has to solve the problem, too. And in User Experience Design, if you’re not solving the problem, you’re just an expense.

The Brain Trust Method is something a colleague and I developed a few years ago, as a loose procedure for solving big, difficult problems (not little details) efficiently and creatively.

It is a way of keeping you focused, realistic, and objective, while still allowing your imagination to be unrestricted and your time to be spent wisely. Best of all, it gets results. We call it the Brain Trust because it allows you to trust your brain… it works with your intuition instead of against it.

The only rule is: the team goes into a room, follows the steps, and doesn’t come out until there is a solution. The longest I have ever been in a room with this method is 2 hours.

Step 1: Identify the Problem

If you don’t know what you’re solving, this will never work. So take a moment to discuss what the bottleneck is, or the difficulty in the current flow, or the part that requires lots of manual labor or searching or whatever. That’s your problem. One problem at-a-time is best for this method, but the bigger, the better.

For the sake of example, I will use a real problem we solved with this method: We were designing a piece of software that salespeople used to book banner campaigns on news sites. Those sales teams had a person with the painful responsibility to review sales data in a gigantic Excel file and adapt the team accordingly. This took one person a whole afternoon, once per week, and the rest of the sales team not only depended on it, but had to wait for it.

We thought that seemed stupid, so that was our problem. Step 1, complete.

Step 2: In a Perfect World…

One you have identified your problem, you switch gears and do the exact opposite: Imagine a future where your problem no longer exists. This is where you are allowed to be unrealistic. Forget time, money, skills, and resources. Just imagine the problem has been solved in an ideal way, and say — out loud — what that allows the user to do instead. What is the new behavior that has replaced the old problem?

Now, you might be reading this and thinking I am full of shit. Where are the wireframes and user testing?! If so, you’re missing the point.

Our objective is not to focus on the design, but to imagine an impossibly perfect result, regardless of the solution. It puts you in a frame of mind where you leave the details of the current, problematic solution behind, and start thinking of “possibilities” instead of “difficulties”. You’re solving the problem now, not building on top of it.

In our case, we said “Well, ideally every salesperson should have this information in front of them so they can describe it on the phone as they sell. Then they would click what they want, and it would be sold, and everybody else’s screen would update. Done.”

Doesn’t seem unreasonable, until you remember that we were talking about a manually updated Excel sheet with hundreds of columns and rows. All numbers. All independently changing.

Step 3: Work backwards…

So now you know what your harsh reality looks like — The Problem — and what the perfect solution looks like… so what’s the difference between them?

In this step, you should start by naming the parts of the Perfect World behaviour that are magical (i.e., not possible), and then discuss what you could do to get as close to that as possible.

“Well, we don’t have X, but we can do Y, and to get Y we need Z…” and so on. You may not get all the way to the Perfect Solution, but you’d be surprised how close it is sometimes.

In our example, we realized that a computer could calculate the inventory of the products and subtract whatever had been sold, so that was part of the perfect world that was doable. Not the simplest thing to build, it turns out, but doable. Check!

Our real challenge was the speed in Perfect World. It had to be so easy-to-read that you could use it and talk on the phone at the same time. Nobody can read an Excel spreadsheet of numbers that fast, so that had to change.

It took about 45 minutes to solve that.

First, to simplify the Excel sheet, we realized that percentages were easier to read than straight inventory numbers. But 2000 cells of percentages is still a lot of information, and not great for finding trends, etc. We needed something easier than numbers. Then we had the epiphany. If you put the percentages on a scale of colors (red = 0%, yellow = 50%, green = 100%) and made all of the cells colors instead of numbers, voila! A heatmap of inventory data. Even a kid could point to the products that were selling well.

In the end, the final solution was damn close to our Perfect World scenario. You could analyze trends, products, and inventory in a second or two, months in advance or in real-time, and you could select the cells you wanted to book and hit “enter”, all while on the phone. Colors would change before your eyes!

We had never seen that problem solved in that way, and yet, in a relatively short meeting, we fixed it with the Brain Trust Method.

J.