Echo Interaction Design

CONVERSATIONS WITH TECHNOLOGY

Thoughts

Deep Thought:
Methodologies are no substitute for creative thinking

Shane Morris

(This article appeared in “Simplicity”, the newsletter of the Computer-Human Interaction Special Interest Group of the ESA, in 2002.)

I had this great product idea once. In-shower whiteboards. You could stick one on the wall of your shower and jot down important ideas whenever inspiration hit you. Yuppies and novelists everywhere would buy them. I would sell them through trendy gadget shops everywhere and appear on lifestyle TV shows around the world. “This morning we speak with bathroom whiteboard mogul, Shane Morris”. In no time there would be inferior rip-offs on the market and I would resign myself to spending the rest of my life pursuing copycats through the world’s intellectual property courts, and living on the proceeds of my shrewd team of extremely litigious patent attorneys.

Unfortunately, it turned out that whiteboard markers and water don’t mix. (Thank goodness for low-fidelity prototyping, since there was still time to ring the factory and stop production.)

I still maintain though, that the idea was a good one. It must have been good, because I came up with it in the shower – the place where some of my best deep thinking happens.

The importance of deep thought

I haven’t shared this story with you because I want to sell you a whiteboard, but because I want to discuss the importance of deep thought in the user interface design process.

By deep thought, I mean time spent considering the problem in depth – mulling it over, toying with different ideas, doodling and meditating in the shower. It’s by thinking deeply about the problem at hand that the design team moves beyond the obvious solution, or the safe solution, and begins to seek out the excellent solutions.

Creative thought is just as crucial to the user interface design process as more structured activities, like contextual inquiry or usability testing. However, when project pressures are great, it tends to be the first activity dropped from the schedule. There are three main reasons for this:

Thinking Time Is Flexible
When project timeframes are tight, it is easier to compress unstructured activities than those with a well-defined process. The result is that project compression is not applied evenly across the whole project timeline, and thinking time suffers.

Thinking Doesn’t Seem Productive
At the same time, there is also pressure (sometimes self-imposed) to be “busy” – always engaged in activities which have well-defined steps, which produce tangible outcomes and which are visibly moving the project forwards. (This is particularly true where user-centred design activities are being introduced for the first time.) Once again, we can make the mistake of over-emphasising structured activities, in order to look, or feel, busy.

Thinking is Hard
Finally, because of its unstructured nature, thinking work can seem hard – we don’t know where to start, we don’t have a recipe to follow, and we’re not sure what the results will be. So once again we tend to eschew thinking work for process work– activities with well-defined steps and outputs: diagrams, tables and reports. Ironically, we see this happening most often when deep thought is most needed – when the design problem is challenging, or when the design team lacks confidence or experience.

Giving Structure to Creative Thought

We can go some of the way towards addressing this problem by applying more structure to the creative thinking process. By doing so, we can make the process more approachable, more visible and better defined. There are various techniques available to do this from the less structured, like Brainstorming, to more structured techniques like DeBono’s Six Thinking Hats, group collaborative design and Synectics.

One of my favourite techniques for giving structure to creative thought is simply Affinity Diagramming. People often get hung up about this technique. What are the rules? What is the result? However, I often describe “affinity diagramming” as code for “thinking about it”. Probably this technique’s most valuable contribution is the structure and tangible output it gives to the thinking process.

Group Thinking

In my opinion the sorts of techniques above are most valuable as a way to facilitate group thinking. However creative thought in groups has its own problems. In my experience, group thinking is great for generating initial ideas and requirements, but less effective for exploring those ideas in detail. The reasons for this are related to group dynamics.

It is human nature for groups to strive for consensus. This is particularly evident in group collaborative design activities. While the idea is that each participant contributes from his or her own expertise, in reality group collaborative design is often more of a democracy than a meritocracy. Unfortunately, this leads to compromise, particularly as there is pressure to produce a “result” at the end of the session. On top of this, user interface designers usually find it difficult to contribute design ideas in these sessions because they are either occupied with facilitating and recording, or because it is not appropriate to “trump” the other participants with the designer’s own ideas.

So while we can apply more structure to group thinking activities, it is still necessary to set aside time for deeper contemplation of the ideas produced. This thinking may be done individually or perhaps in pairs. Unfortunately, this type of thinking is very hard to “schedule”.

Setting Aside Time for Deep Thought

This is where the shower comes in.

Deep thought requires time, and it doesn’t always happen “on demand”. It’s hard to schedule an activity called “have a brilliant idea” into the typical project timeline. Planning for a miracle to occur between 3pm and 5pm on a Friday afternoon because that’s where it fits into the project plan can be asking for trouble!

Projects that are able to spread design activities out over time have the advantage that thinking work can happen in the background (e.g. in the shower). I often tell my clients that they’ll get more value out of 2 days of design stretched over (say) four days, then they will from two days of intense effort. Yes, I know this is not always possible!

The Attraction of Methodologies

Structured processes or methodologies play an important role in the user interface design process. Methodologies provide

Accountability (ensuring all the required steps are completed)
Consistency (knowing what is required)
Measurability (what should have been done by now, and how much is still to go?).

Methodologies have another appeal: approachability. When we are unsure of how to approach a problem, we are naturally attracted to methodologies that, we hope, will guide us step by step to a result. However, we can be lulled into a false sense of security as important but unstructured activities, that are harder to distil in to a “recipe”, are neglected.

Software development methodologies, like the Rational Unified Process (RUP) suffer from the same problem. Particularly when a methodology is first adopted, there can be type of a blind faith that all will turn out well, as long as we follow the process. However in practice methodologies (including RUP) tend to emphasise structured activities with clear outputs over “think about it” type steps. The consequence for user interface design tends to be that it is neglected in the overall process and emerges piece-meal at coding time (often largely designed on the fly by the development team).

The Importance of Usability Testing

While this is not an article about usability testing, it is important to note that usability testing is an essential tool to allow us to explore diverse or novel ideas. It gives designers the confidence to explore alternative solutions, knowing that the ‘duds’ will be identified in testing.

Without usability testing (and I have certainly been in this situation), the reverse applies. The most responsible thing to do is to resort to safe ideas. (There used to be a saying: “no-one ever got sacked for buying IBM”. I guess the equivalent statement here might be something like: “no-one ever got sacked for copying Amazon.com.”)

In Conclusion

User interface design practice is not yet at the stage where design solutions can be produced by merely following a recipe. Structured activities and methodologies are important tools to control quality and budget, however, user interface design, like all good design, still requires plenty of good-old thinking time.

To create great user interface designs, designers need to take the time to move beyond initial ideas and safe ideas, and to explore, refine and combine options to find the “right” solution.

When project timeframes are tight (and they always are) we need to be careful that we do not neglect “thinking work” in favour of “process work”.

Think about that next time you’re taking a shower…

Shane Morris
shane@echointeraction.com.au

(0438) 818 888 info@echointeraction.com.au