The Unbearable Rightness of Catastrophizing

Most people think of catastrophizing as a way of thinking that healthy people avoid. The online dictionaries agree. Wiktionary, for example, defines the act as “to regard a bad situation as if it were disastrous or catastrophic”; Go-Dictionary has it as “to envisage a situation as being worse than it is”. Clearly they’re seeing it as an unrealistically negative way of looking at events or circumstances. Perhaps it’s even a sign of mental health problems.

Psychologists go even further. According to PsychCentral, catastrophizing comes in a second form as well:

The second kind of Catastrophizing … occurs when we look to the future and anticipate all the things that are going to go wrong. We then create a reality around those thoughts (e.g. “It’s bound to all go wrong for me…”). Because we believe something will go wrong, we make it go wrong. [emphasis mine]

Yikes! But does it have to be that bad?

I say no. Not if we do it on purpose.

People who do usability assessment are accustomed to catastrophizing. When we conduct a usability review, we look for possible sources of confusion and error, so that designers can devise changes to mitigate them. However, this process need not be limited to post hoc review — nor should it; I recommend that designers do it regularly during design.

Design, of course, doesn’t need to catastrophize to the extent that assessment does — that is not its main function; and overdoing it can hamper creativity the way overediting does to writing. But I argue that a little attention paid to potential problems, during design, can go a very long way. Let me give an example.

On one of my projects — creating the interaction/interface design for a client, for another organization to build — I am the HCI specialist and my teammate is the prototyper, and we collaborate on creating the design. Very energetic and creative he is, up on all the latest interaction techniques and enthusiastic about their possibilities. More conservative about whiz-bang techniques I am, more grounded in decades of HF and HCI research findings. He enriches the design immeasurably; I keep it connected to the why. One of us proposes an idea, I catastrophize it, and we jointly come up with a way to address the problems. We both find our design sessions enjoyable and sometimes frustrating, but they produce a design that’s far better than anything either of us could do independently.

The client absolutely loves our work.

Now, I do not mean to imply that designers never consider the problems their designs might cause users. Many do; and of course the best ones do it very well. Some people, including David Malouf, professor of interaction design at the Savannah College of Art and Design, would even argue that Design as a process naturally includes such examination. I think I would agree with them. However, we all know that many if not most digital products are produced without a conscious design process along the lines that Dave teaches, let alone usability assessment. Whether or not a project has time and resources for formal usability assessment, a little catastrophizing during design can make a big difference.

If we aim to design products for the best user experiences, we must imagine the possible errors and problems that our designs might induce. This does not mean that (in the words of the psychologists) “we make it go wrong” (emphasis mine). Our looking for the possibilities has an entirely different effect, because it has an entirely different purpose, and we are doing it consciously and intentionally. Only by knowing what the potential problems are, can we prevent them. We must “look to the future and anticipate all the things that [could] go wrong.”

We must catastrophize, I say. We must catastrophize.

This entry was posted in UX design, usability and tagged , , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

One Trackback

  1. [...] can be a good thing – that would be before you leap into a new venture, not after a fall.  Elizabeth Buie of Luminize Consulting advises: We must [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>