Brainstorming a Creative Project Part 2: The Challenge Space

Follow us on LinkedIn for our latest data and tips!

, , ,

Brainstorming a Creative Project Part 2: The Challenge Space

innovation brainstorming wordle creativity

In Part 1 of this series we talked about how to set goals and how to avoid the challenge space. In this section we will go into what exactly the challenge space is and how to use it effectively.

The Challenge Space

The Challenge Space is the phase of a creative project during which you task yourself and your team with finding the many paths to the end goal. Up until now you have only defined and redefined what your goal is in your project. For example purposes, we’ll continue with the web application project.

Let’s say that we have defined the goal of our web application to be ‘sell our product online’. With such an open goal, we can use the challenge space to define how the consumer will do this in several different ways. The challenge space is also going to be used for application design and the user’s flow throughout the search and checkout processes.

So how do we effectively use the challenge space? We explore. We explore all possible ways to achieve the end result and since our goal is pretty vague, there are going to be a lot of options! The trick is, and you’ll begin to understand whether or not this is true for your project, to determine how many paths to the end goal there could be. In some projects, you may want to only identify the paths and plans for users following any of them. In other cases, you may want to reduce the number of paths to one or two.

Start Some Fires

A common way to kick off this phase of a creative project is called firestarting; a term used because of the way events happen when questions are asked. You simply ask a question that could have many answers and spurs discussion amongst the team. There are no ‘wrong’ answers, so write everything down that actually answers the question directly. There are, however, right questions. There are plenty of probing questions that don’t do you any good, like asking off-topic question; you need to identify those early and make sure to stop them before they start any fires. Ask specific questions to get a feeling of what your team members think about a certain aspect of the project.

Use firestarting to your advantage early in this phase. Some questions you might ask for the example web application could be:

  • How does the application look and feel?
  • What is the target demographic for our product and does this affect the look and feel?
  • What is the checkout process?
  • What is the item selection process?

Organizing Your Flames

Asking and answering questions is just the start. You need to keep the outpouring of ideas from those answers organized, or in some cases dis-organized. Either way, you need to write down all the ideas that came from the firestarting questions. As you’re gathering ideas from your sparking questions, you want to try and keep your brush fire under control by organizing the team’s thoughts.

Idea Nodes

You may have heard of mind-mapping before. This is a concept that uses another concept of idea nodes. Basically, you take a core idea and work your way out to finer and finer points until there are no more questions to be asked on the topic. For our web app, we may start with the question, “What pages are included in the application?”. In the figure below you can see how you might continue on this line of questioning to “What sections are there in each page?” and even further with “What does each section contain?”


This type of ‘flow’ mapping is great, but don’t forget about others as well. Sometimes it makes sense to use a web for mapping so you can see how each page relates to one another. UML diagrams are excellent for this purpose and are used by a lot of software developers when they want to see how database tables will interact, but using them to map the application is just as helpful.


A lot of creative projects use what are called artifacts. Artifacts are things that contain or represent information in a organized way. If you wanted to write down all of your firestarting ideas on post-it notes, those would be your artifacts. Many creative project directors find that physical artifacts are easier and more fun to work with than a digital whiteboard of sorts. If you put your ideas down on movable artifacts like post-it notes, you can get physically involved with a non-physical project and that could get your team motivated to participate if they aren’t already. If you don’t have the capability to use physical media for idea artifacts, maybe you can find or create a digital analog that achieves the same results. There’s plenty of collaborative software out there like Google Drive and mind-mapping applications that let users edit the same document at once. Once you have one of those, you only need a meeting space like Google Hangouts, GoTo Meeting, or

Be Random

It’s been said that the human brain works on patterns and that we humans will make patterns from anything. We fill in the unknown subconsciously, however, the ideas that come from your firestarting questions are undoubtedly random.

When that first question is asked, about what pages should be included in the application, the Cart, ToS, and Checkout pages are probably the first to be uttered by the team, but those pages are clearly not browsed by a user in that order, nor will they be the first pages to be coded. At this point, it doesn’t matter in what order they happen. In terms of this phase of the project, you simply want to know that they exist and what content they have. Make your patterns after you are done with the first firestarting phase, but right now, just get the thoughts on paper in any order. In short, don’t try to organize your thoughts, just let them come out. This is one of the key values in a creative project. You can always update them or have further conversation on them later.

(Un)Categorize Your Ideas

Sometimes it’s difficult to organize different ideas coming from all the team members. It may be best not to create any named charts at first. After a question is asked and all answers from each team member have been explored, create some artifacts to hold those ideas, mix them up and put them all in the same space. Next, provide two or three other areas and try to lump the ideas together using only those areas. It’s best if you do not name or categorize the secondary groupings and squash any argument that they should be categorized. At first, this is difficult, but as you put the artifacts into secondary groups, you’ll start to see a pattern and it becomes much easier. After all the artifacts have been moved, name the groups, if you even need to.

Make a Model

When you’re firestarting your project, it may be helpful to draw what the team is suggesting. Use a whiteboard or something similar that can easily be changed. One team member may say, “I think the home page should look like this…” and then draw his thoughts. Another member may say, “I agree, but we should change {this} to {that}.” and that person will make an incremental change to the drawing. In a sense, the whiteboard will be your knowledge artifact. It holds the collaborative information for the team to share and you can take this artifact model one step further by breaking it up into sections like the sections of the web application. Perhaps the sidebar can be used in more than one place, or the ‘featured product’ is a module that can be used over and over too. When you draw your model, keep this stuff in mind. Start a new fire with each smaller section of the model.

Explore the Possibilities

What can be said here? Your project is a creative one. You aren’t confined to preconceived notions of what a web application should look like or perform like. Never limit yourself. Explore all possibilities. Don’t stop at the ‘good idea’. Your creative process is a journey. Don’t stop believing.

Part 2 Wrap Up

Don’t forget that this early phase of your creative endeavor is all about exploring and nothing is set in stone except your final goal. Even if you are on a time budget, early discussion and planning are extremely important. Building a web application can have many blocking mechanisms, but if you’ve planned extensively and gone over all the ‘what-ifs’ before you begin coding, you’ll find that your project will go much smoother later on. Be sure to get all your ideas out in the open, even if no one agrees, it’s still a good idea and may be of some use later on.