Divergent thinking and collaboration

I watched an illustrated video of an illustrated speech by Ken Robinson on changing education paradigms. I believe the paradigm shifts he calls are also needed in the development process of software and information products.

In his speech, Robinson cites a study on divergent thinking—thinking in an unusual and unstereotyped way—which isn’t the same thing as creativity. Divergent thinking is an essential part of creativity. It is the ability to see:

  • lots of possible ways to interpret a question.
  • lots and lots of possible answers to a question.

Interaction designers engage in divergent thinking when they explore multiple ideas and try to “saturate the problem space.” Divergent thinking Initially, this exploration isn’t linear or convergent. Instead, it’s about trying different things, borrowing ideas, letting go of ownership and letting go of the idea that your idea is too good to edit or to combine with the ideas of others. Brainstorming is a structured form of divergent thinking. Only after the divergence—after the problem space is saturated with ideas—is it time to converge, to assess, to use judgement, and to make design decisions.

You can engage in a divergent-then-convergent process on your own, but for people new to the process, results are much better when they can borrow and combine each other’s ideas during the divergent stage. In the workplace this is called collaboration, and we need to add it to iterative, Agile development processes.

If development teams find collaboration difficult, it could be because of the paradigms we learned at school. As Robinson points out, the education system refers to sharing as copying, refers to re-using as plagiarism, and sees both as forms of cheating?

Although children innately engage in divergent thinking, Robinson cites a study from Break Point & Beyond that shows how our Return the fish to water ability to think divergently dries up as we pass through the education system. In school, divergent thinking is a fish out of water. At work, we need to put the fish back in the water.

It’s true. There’s a mismatch between what business leaders say they need and what schools teach, according to a 2009 Asian Development Bank publication, which reports:

What best demonstrates creativity?   (1 is highest) Business Schools
Problem identification or articulation 1 9
Ability to identify new patterns of behaviour or new combination of actions 2 3
Integration of knowledge across different disciplines 3 2
Ability to originate new ideas 4 6
Comfort with the notion of “no right answer” 5 11
Fundamental curiosity 6 10
Originality and inventiveness in work 7 4
Problem solving 8 1
Ability to take risks 9 (tied) 8
Tolerance of ambiguity 9 (tied) 7
Ability to communicate new ideas to others 11 5

In the table, above, compare where business ranks originality and inventiveness versus where schools rank it. Similarly, note the contrast between problem identification and problem solving.

Where to start? Sketching is one method that supports divergent thinking because a sketch intrinsically says: “As an idea, I am disposable. You can change me, or discard me, and then have more ideas.” Ideas are cheap, so have lots of them—that’s key to divergent thinking. There are people in your workplace who know this, already. People formally trained in design have been taught to use divergent thinking. Ask them for help. For other ways to learn to collaborate and to reward collaboration, an Internet search will identify many ideas and methods. One of the first things you’ll read is that collaboration requires support at all levels. Here’s a to-do list for executives:

  • Make sure the vision and mission are clearly communicated. This helps others to understand the problems to solve.
  • Remove the bureaucratic obstacles that strangle creativity.
  • Create a climate for an open flow of ideas, collaboration and knowledge sharing. Freedom and trust are key to creativity.
  • Embrace diversity. The more personality types (or team roles) are on the team, the more likely the project will succeed.
  • Give employees an opportunity to reap the rewards of the success they helped create. Stage celebrations to benchmark success.
  • Cultivate continuous learning. Revitalise by cultivating outside interests.

Train yourself in frustration, confusion, and inefficiency

For professional reasons, I like to mess around with software. It’s a form of training, because some of the messing around leads to frustration, confusion, and inefficiency. And that’s good.

My hope is that my experiences will help me to better understand what I put various groups of software users through when they use the software I helped design and build.

An easy way to mess around is by changing default settings. For example, my iTunes isn’t set to English. This helps me understand the experience of users who learned one language at home as children and now use another language at work as adults. It’s not just beneficial to experience the initial pain of memorising where to click (as I become a rote user in a GUI I cannot read), but also the additional moments of frustration when I must do something new—an occasional task whose command vector I haven’t memorised.

Relating to the language challenges that some users face

Another easy way to mess around is to switch between iMac and Windows computers. It’s not just the little differences, such as whether the Minimise/Maximise/Close buttons are on the left or right sides of the title bar, or whether that big key on the keyboard is labelled Enter or Return.

Switching between operating systemsIt’s also the experience of inefficiency. It’s knowing you could work faster, if only the tool weren’t in your way. This also applies to successive versions of “the same” operating sytem. This is the frustration of the transfer user.

It’s noticing how completely arbitrary many design standards are—how arbitrarily different between operating systems—such as the End key that either does or doesn’t move the insertion point to the end of the line.

Another easy way to mess around is to run applications in a browser that’s not supported. I do it for tasks that matter, such as making my travel bookings.

All this occasional messing around is about training myself. The experiences I get from this broaden the range of details I ask developers to think about as they convert designs into code and into pleasing, productive user experiences.

In a separate IxDA discussion thread, a few people reacted to this blog post:

  • Try a Dvorak keyboard instead of a Qwerty keyboard (Johnathan Berger).
  • Watch children’s first use of a design (Brandon E.B. Ward).
  • Use only the keyboard, not the mouse (CK Vijay Bhaskar).
  • Sit in at the Customer Support desk for a day (Adrian Howard).
  • Search Twitter to find out how people feel about a product (Paul Bryan).

See also the comment(s) below, directly in this blog.

Design requires courage and trust, not just user involvement

Designing is usually a rewarding activity, but the path from start to finish can be filled with frustration and even panic. I’ve seen design processes work—and come to the realisation that “My own designs benefited from rapid iteration!”

The benefit of designThese humbling experiences helped me learn to trust the process, even in the face of frustration or panic. It’s these experiences that give me the courage to follow the design process, even when it isn’t clear how to resolve the tension between conflicting design constraints.

In the face of an unknown, individuals and especially teams tend to turn to knowns. If needed, they’ll manufacture the known data, by deferring the choice to users. Here’s part of what Larry Constantin wrote about courage in software design, in a paper that advocates for user involvement at the right time:

Most damning and least recognized among the limitations of user-centered design is the way it subtly discourages courage. Courage is one of the central tenets of extreme programming and agile development methods. […] User-centered design makes it too easy for designers to abdicate responsibility in deference to user preference, user opinion, and user bias. In truth, it is hard to stick with something you know works when users are screwing up their faces at it. What if you are wrong? What if you are not as good a designer as you thought you were? It takes real courage and conviction to stand up for an innovative design in the face of users who complain that it is not what they expected or who want it to work just like some other software or who object to certain sorts of features as a matter of course. It takes responsible judgment to know when to listen to users and when to ignore them.

In the many design sessions I have facilitated, three times I’ve seen that lack of courage expressed by a participant. Each time, it sounded like a mix of panic and frustration:

The solution has been on the wall since the first round!

The design sessions I facilitate ask participants to saturate the design space with lots of ideas. They each bring five sketches—five substantially different ideas—and then, after sharing their ideas with the other participants, they rapidly iterate the first 15 or 20 sketches to develop even more. All this takes place before any analysis.

When the goal is to saturate the design space—to identify as many solutions as possible in a short time—there’s more to influence the design once the analysis begins. Inevitably, the design that the team decides on was not already on the wall. Motivated design participants quickly learn this, and—in most cases—become advocates of the process.

For most development teams, the Five Sketches™ process I introduce is a departure from the status quo, so it takes courage for their team members to take a stand, to say “I will use this process” for design problems that need it.

Developers can learn ¾ of Design

Microsoft’s Bill Buxton recently wrote an article for Business Week, titled On Engineering and Design: An open letter. In it, Buxton explains that developers can improve the user experience of the product that they’re building by learning three of the four layers that engage designers:Four layers of design
  • Design awareness.
  • Design literacy.
  • Design thinking.

Buxton also mentions a fourth layer, design practice. He explains that design practice represents a fulltime job for highly trained professionals, and that it’s rare to find a developer who straddles both. (In my experience, small- and mid-sized companies may get by without a design practitioner, if their designs are constrained by the rules and standards of the operating system and hardware, and if their competitors do no better.)

Buxton thinks non-designers can easily learn about and appreciate the first three layers of design. On the third layer, design thinking, Buxton writes:

Cognitive science makes it clear that the strategies designers use in approaching problems or questions are different (not “better”) than those employed by those trained in engineering disciplines. Both strategies are complementary. Given the complexity of the problems that confront us, it seems to me that expanding our collective arsenal of techniques is something we could all benefit from.

This difference in problem-solving strategies is the ideation-judgement axis that I wrote about in Please exit your comfort zone. Learning to use these different strategies—at the right time in the design and development process—is what Five Sketches™ teaches to developers and other non-designers.