How to Think Outside the Box

How to Think Outside the Box Presented at the Technology Student Association’s 2010 national conference by Dan Zollman This was originally presented to a group of middle school and high school students and their advisors/teachers. One of the goals of the presentation was to discuss design-related concepts in the context of STEM education. The presentation is only an introduction these concepts, so I encourage you to learn more from other resources. A selection of related resources is available at http://www.insteadofthebox.com/tsa. The content of this slideshow, excluding the enclosed photos and images, is distributed under a Creative Commons Universal (public domain) license. Feel free to use and re-use the text, but please keep in mind its original purpose and context. Also note that this version has been heavily modified for distribution. If you have any questions, contact me: http://www.insteadofthebox.com/contact

MAGIC! “Think Outside the Box” Two problems with this phrase: • It’s an overused cliche. • It almost implies that there’s something magical about creativity—but in reality, creativity is a skill that can be developed.

Process Way of thinking Two keys to being a really good innovator.

NOT a good way to solve problems: Richard Feynman’s Problem-Solving Algorithm 1. Write down the problem 2. Think very hard 3. Write down the answer Your first solution (no matter how clever) will only get you so far.

Richard Feynman’s Problem-Solving Algorithm 1. Write down the problem 2. Think very hard 3. Write down the answer

Instead, let’s look at a process and a way of thinking that are based on Exploration

Exploration Explore the possibilities Explore the problem Iterate “Exploration” can mean many things, but we’ll focus on three forms of exploration: • Exploring many possible solutions rather than stopping at the first idea • Exploring the problem: looking at the problem in many different ways • Iteration: repeating the problem-solving process and building upon your ideas

A great illustration of these approaches is the story of the development of the computer mouse. Most of the story is told in parts of the first two chapters of Designing Interactions by Bill Moggridge (MIT Press, 2007). The mouse was invented in the early 1960s by Douglas Engelbart and Bill English while they were trying to develop a way for users to interact directly with a computer, through pointing and selecting. The mouse was developed further at Xerox PARC and sold for the first time in 1974. In 1980, Apple hired a group of engineers and designers now known as IDEO to develop a mouse that was less expensive and more reliable. The result was the first mouse that used a ball mechanism. In 1987, Microsoft hired IDEO to develop an even better mouse, and IDEO improved the ergonomics and usability of the mouse.

Lessons from the story of the mouse 1. Try out many, many solutions 2. Build all the time 3. Rapidly iterate 4. Look for ideas in outside domains

Lessons from the story of the mouse 1. Try out many, many solutions Engelbart and his team tested many devices—light pens, joysticks, trackballs, keypads, and finally the mouse—in order to find out which one would be the easiest to use. Xerox considered many design concepts before deciding on a mouse to manufacture and sell. When IDEO designed the Microsoft mouse, they tried over 100 different models, prototypes, and existing mice and tested the user’s steering ability, targeting ability, and comfort with each mouse. As a result, their new mouse set the standard for every mouse that has been designed since then.

Lessons from the story of the mouse 2. Build all the time Xerox kept building and testing concept designs well into the 1980s. IDEO built over 80 different mouse models out of foam in order to explore the ergonomics of the product. None of them designed the mouse simply by drawing pictures—they built some sort of prototype for every possible solution.

Lessons from the story of the mouse 3. Rapidly iterate As each company built more and more prototypes, they repeatedly evaluated their ideas. They used what they learned to create new designs each time. They didn’t just built their prototypes and stop after the first test. They built, tested, built more, tested more, built more, and so on.

Lessons from the story of the mouse 4. Look for ideas from other domains Some of the best ideas come from unexpected places, so it can help to look for inspiration in unrelated areas. Be open to all ideas even when it looks like they won’t help. Engelbart’s version of the mouse used two wheels instead of a ball. He got the idea from a wheeled device that was used to calculate the area under a curve in calculus. When IDEO came up with the ball mechanism for the Apple mouse, they weren’t thinking about the trackball. One of their designers got the inspiration from a package of roll-on deodorant, and built the first prototype out of a deodorant package and a butter dish.

Lessons from the story of the mouse 1. Try out many, many solutions 2. Build all the time 3. Rapidly iterate 4. Look for ideas in outside domains All three forms of exploration came into play…

Exploration Explore the possibilities Explore the problem Iterate

The most important part of this presentation: this is a diagram of the problem- solving process, and it’s the key to integrating exploration into your process.

Divergent Convergent The design process can be seen in terms of two phases: a divergent phase and a convergent phase.

Generate Imagine Divergent Experiment Brainstorm Defer judgment In the divergent phase, you explore. The goal is to discover as many possibilities as you can—to generate lots of possible directions for your process. In this phase, you should avoid anything that will prevent you from finding new possibilities. Generate, don’t evaluate.

Evaluate Organize Select Convergent Focus Refine In the convergent phase, you evaluate and organize your ideas, select some options over others, and refine the ideas. You take all the possible directions that were generated in the divergent phase and narrow them down to a small number.

Divergent Convergent The key is to separate these approaches. When you’re diverging, focus only on diverging. Once you’ve explored a wide range of ideas, then you can converge.

And don’t stop there—iterate over and over again. Over time, this will not only refine your ideas, but transform them into something new and better.

This is a very common model of the Identify the problem design process. There are many versions of this with different numbers Research of steps, but they all follow the same pattern. You’ve probably seen this if you’ve taken a Tech Ed course. Generate solutions It’s only one way of looking at the Select a solution process, but it’s a very good guideline and a helpful tool. Implement Evaluate

One reason this interests me is that it’s Identify the problem a very natural process. Humans are natural problem-solvers, and we use Research these steps all the time without thinking about it. So there isn’t really a question of whether or not we use a Generate solutions process—the important questions are whether or not we’re aware of our Select a solution process, and whether or not we use it effectively. Implement Evaluate

Another reason this is interesting is Identify the problem that the steps can actually happen in any order. Sometimes you have to Research build a prototype before you know what the problem is. Sometimes you brainstorm solutions, but you have to Generate solutions do more research before you can select one. The “arrow of iteration” Select a solution can go from any step to any other step. Implement Evaluate

Brandon Schauer http://www.adaptivepath.com/blog/2010/06/22/the-design-plan-official-versus-how-it-feels/

My argument is that this process can Identify the problem be made more effective when the divergent/convergent approaches are Research integrated into the entire process. Divergent thinking isn’t just about generating solutions—it can be applied Generate solutions to every one of these steps. Select a solution A big part of this is, again, about being aware of the process and developing a mindset in which you “diverge” Implement regularly. However, I’ll discuss a few strategies that can help you integrate Evaluate this kind of thinking into the process.

Identify the problem Research Generate solutions Select a solution Implement Evaluate

Exploration Explore the possibilities Explore the problem Iterate

Brainstorming (only one of many ways to generate ideas)

When brainstorming, most people have a tendency to stick to a logical, straightforward path and avoid ideas that are unfamiliar or nonsensical. The idea behind this (recommended) book is that if you can get yourself out of that logical, straightforward path, you’ll free yourself to make new connections and think more creatively. The more you generate the better—it doesn’t matter whether the ideas are silly or impractical because they could lead you to useful ideas later on.

Brainstorming (only one of many ways to generate ideas) • Defer judgment • Go for quantity • Free association • “Weird” is good There are a number of “rules” for brainstorming that tend to appear in books like A Whack on the Side of the Head. There are many strategies that can help you do this—but again, the big idea is to explore, no matter where that leads you.

“Once you eliminate quality as a requirement, the entire design and development process becomes a whole lot easier.” Jared Spool Worry about quantity now—just generate and explore—and worry about quality later, when you come back to converge and refine your ideas.

Brainstorming (only one of many ways to generate ideas) • Defer judgment • Go for quantity • Free association • “Weird” is good • Build upon each idea  new connections

hands and eyes Another way to explore is to incorporate your hands and your eyes into the idea development process. This can include sketching and writing.

“I think of design as the exploration of the conceivable futures. I use my sketches and wireframes as means to make explorative moves and assess the consequences of those moves.” Will Evans (interaction designer) In a way, you can actually test out your ideas by sketching. This will help you visualize the possibilities, look at them in new ways, and begin to understand what it would mean to implement them.

You’ll discover more with your hands and eyes than you will with your brain. …always. Writing, sketching, and building will force you to develop your thoughts and help you remember them. You should have a notebook or sketchbook on hand and use it at all times.

You’ll discover more with your hands and eyes than you will with your brain. Visual thinking and physical movement actually allows your brain to process information in new ways. You will be both “smarter” and more creative when you’re using your hands to build or sketch than you will when sitting and thinking.

Visual thinking Visual thinking and sketching can mean many things: drawing pictures, mind maps, flowcharts, and diagrams are all excellent strategies. The idea is to get your thoughts out in front of you, into real-world space.

Post-it notes are an indispensable tool. One way to use them is to “dump” out a large number of items and organize them into groups.

Visual thinking “Build to think” Prototypes? (What’s a prototype?) “Build to think” is a great way to describe this. Like sketching, prototyping can help you think in different ways and explore the consequences of an idea.

Identify the problem I should clarify what I mean by Research “prototype.” Generate solutions When most people think of a prototype, they think of the Select a solution implementation stage in the design process. After you brainstorm, choose a solution, and refine it, you Implement build the final solution. However, that’s only one kind of prototype. Evaluate

Visual thinking “Build to think” Prototypes? (What’s a prototype?) A prototype is anything that helps you visualize or test a problem or a solution. You can make a prototype at any point in the design process, even when you’re still trying to identify the problem. A prototype does not have to be a complete solution or an accurate model. It only has to help you answer a question.

Sketches Diagrams and flowcharts When I think of prototypes, I include sketches, diagrams and flowcharts. Another example is paper prototyping, a cross between sketching and modeling which is becoming popular among web and software designers. Here are some examples: http://www.alistapart.com/articles/paperprototyping/ http://www.google.com/images?q=paper+prototyping

Sketches Diagrams and flowcharts Models Mockups Cardboard and tape Any kind of model or mockup can work as a prototype; you can even make a prototype out of modeling clay or cardboard.

This robot was built by Lower Merion High School’s robotics team in 2006. One of its main functions was to pick up balls using the white roller at the front.

That roller mechanism started like this.

This mockup was completely unrefined, imprecise, unusable for a robot, and ugly. But it was just enough to help the team find out if the rollers would work.

Mockups Cardboard and tape Role-playing Games Video/simulation You can also prototype situations. This can be helpful if you’re dealing with problems in architecture or services, or if you want to explore the scenario in which a device is used. Even storyboards in filmmaking are a kind of prototype.

Mockups Cardboard and tape Role-playing Games Video/simulation A few years ago, Marriott, the hotel company, prototyped an entire lobby out of foam core. They brought in customers in order to find out how they could improve their services. The foam core allowed them to build and modify the lobby quickly.

Assumptions Assumptions are one of your biggest enemies. Another objective of creative thinking is to identify your assumptions in order to move beyond them. This is illustrated by a classic “thinking outside the box” puzzle.

Connect all nine dots using only four straight lines, without lifting your pencil, and without retracing any lines.

The key to solving the puzzle is to recognize an assumption. Almost everyone initially assumes that the lines cannot extend beyond the “box”. You’ll find, however, that you can only solve the puzzle with five lines if you stay in the box.

What other assumptions have you made about the puzzle?

What other assumptions have you made about the puzzle? • Four is the best you can do (why not three, two, one, or none?) • The dots are infinitesimally small points with no diameter, as on a graph

Other assumptions: • I can’t fold the piece of paper. • I can only use a pencil. (How about a thick paintbrush?) • I can’t rip up the paper. • The only way to “connect” dots is to draw lines. The puzzle can be solved with two lines, one line, or even zero lines (by ripping the dots out of the paper and touching them all together).

The “box” Constraints Pencil or paintbrush? Tools Modify the paper? Medium Define “dots”? Materials Is 3 better than 4? Problem definition Define “connect”? Assumptions can deal with any aspect of the problem: problem constraints, the tools and materials you can use to solve the problem, and even the problem itself.

Most dangerous kind of assumption: Assuming you understand the problem

Are we solving the right problem? You should always ask this question. The solution you ultimately develop is determined by the way you understand the problem(s).

Exploration Explore the possibilities Explore the problem Iterate Brainstorming, visualizing, prototyping, and researching also apply to the exploration of problems. I want to make one key assertion about your problem…

Your problem (or opportunity) is (almost) always a people problem which is part of a system.

Your problem (or opportunity) is (almost) always a people problem All problems, even technological ones, relate to people. Solutions need to: • Solve people’s problems • Fit into people’s ways of living, working, and interacting • Avoid unintended consequences that affect people • Help and not hinder constructive change in society

Your problem (or opportunity) is (almost) always a people problem Technology always comes back to people, directly or indirectly. For example, • Building a bridge: Who’s using the bridge? Why? Do they drive carefully? Are they distracted? How well can they see or hear? • Manufacturing microprocessors: How do people use CPUs? Is speed always important? When do other design issues (e.g. durability) appear?

Address a problem or an opportunity Develop a set of needs Look for non-obvious needs Dealing with people problems: • Understand what the problem is • Find out what needs people have • Find situations where people aren’t aware of their needs

How do you find unrecognized needs? • Observe people in their environments • Identify needs, desires, fears • Examine scenarios In order to understand people and their needs, learn more about who they are. Who are you designing for? Find them, talk to them, and observe.

Your problem (or opportunity) is (almost) always a people problem which is part of a system. No piece of technology is isolated. What is the context of your design problem? • Bridges: What is the impact when roads are closed during the construction project? After the bridge is built, who will maintain/repair the bridge? How will they know when something needs to be fixed?

Your problem (or opportunity) is (almost) always a people problem which is part of a system. • CPUs: How are CPUs manufactured? Who works in the factory? What is the environmental impact of that process? What sorts of products use CPUs? Who uses those products? Why do they use those products? Are the products effective? What does a user do with the product when it breaks down?

Map the system • Flowcharts • Mind maps • Diagrams Visualizing the system can help you understand the system as a whole. Identify the elements of the system: are there elements you weren’t aware of? How are the elements connected to each other?

Look for assumptions limitations failures risks unintended consequences in your people-problem-system. Do this throughout your design process. These strategies can help you look critically at each design iteration as well as your initial problem.

“5 Whys” Get to the root of a problem: “Why does this problem exist?” A great example from an Amazon.com leadership team meeting, retold by Peter Abilla… Source: http://www.shmula.com/987/jeff-bezos-5-why-exercise-root-cause-analysis-cause-and-effect-ishikawa-lean- thinking-six-sigma

Injury at the Amazon.com Fulfillment Center: Why did the associate damage his thumb? Because his thumb got caught in the conveyor. Why did his thumb get caught in the conveyor? Because he was chasing his bag, which was on a running conveyor.

Why did he chase the bag? Because he placed his bag on the conveyor, but then it turned on unexpectedly. Why was his bag on the conveyer? Because he used the conveyor as a table.

Now we see multiple design opportunities: • Cover up pinch points in the conveyor • Improve safety policies/procedures. • Change the control system so that the conveyor will not turn on unexpectedly. • Add a warning indicator (sound and/or light) that is activated before the conveyor turns on. Plus, root cause analysis (5 whys) tells us that…

…the facility needs more tables! Photo: http://www.flickr.com/photos/85638163@N00/4651063590/sizes/l/in/photostream/

Understand the problem system Develop a strategy How will you approach the problem? Which parts of the system can you change? Work towards a strategy for transforming that system.

Focus on how you’ll solve the problem Don’t worry about the technology (for now) How the technology works is the last step. First, ask: What do you want the technology to accomplish?

Exploration Explore the possibilities Explore the problem Iterate I’ve already discussed why iteration leads you to new possibilities and ideas. It’s important to iterate at every level of the design process.

Strategy and choice of problem may co-evolve. Iteration allows your ideas to transform. However, it may require you to throw away old ideas in favor of new ones, even if you’re attached to the old ones.

Strategy and choice of problem may co-evolve. You don’t fully understand the problem until you’ve iterated many times. You may discover that your original understanding was wrong. This is a good thing—it is an opportunity to develop a better strategy. If you are open to this discovery and willing to go back to the drawing board, you can be much more flexible in your design process and truly “think outside the box.”

Discussion: Problems & Opportunities in TSA? Focus on finding opportunities and discovering new perspectives. • What are the needs of TSA members? • How does TSA fit into the lives of members? • Strategies for meeting needs and goals? • What assumptions do we make?

Some of my past (but wrong) assumptions: • Change can only come from the top. • Only some of us can lead. • Students are not teachers. • My chapter is playing against the others.

Identify the problem Research Generate solutions Select a solution Implement Evaluate

How to Think Outside the Box For resources and further reading, please visit: instead of thebox.com/tsa Dan Zollman – insteadofthebox.com/contact

How to Think Outside the Box

by Dan Zollman on Sep 26, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 1

Statistics

How to Think Outside the Box — Presentation Transcript