The Problem with Problems

There's an old joke among software developers. When something works in an unexpected but strangely effective way, the developers often kid, "Oh, that's not a bug. That's a feature." While this is usually only a joke, designers can use the same technique of reframing the problem when tackling their own projects. In fact, there's an old joke among designers: "It's not a problem. It's an opportunity."

Before a designer typically gets involved in a project, a business usually encounters or discovers a problem or a perceived problem. A current product isn't selling or working well or is simply out of stylewitness the launch of new mobile phones every six months. Or a competitor has launched a better product, as occurred in the mid 1990s as companies vied to produce the best Internet browser. Or a new market has opened up and products need to be invented for that market, which is what happened when Voice over IP (VoIP) became practical and everything from Web sites to applications to phones needed to be designed. These "problems" become the basis for involving a designer.

Unless the problem is simple and narrowly defined (for instance, users can't find the Submit button at the end of a form), interaction designers shouldn't take any problem at face value. Often, what seems at first glance to be simple, really isn't (and, rarely, vice versa).

Consider the seemingly simple problem of an online form on which users have trouble finding the Submit button at the form's end. The simple solution might be just to move the button to a better place or make the button more prominent through color, size, or shape. But this issue could also be an indicator of a larger problem. Maybe the form is too long. Maybe users don't understand why they are filling out the form, and the problem isn't that they can't find the button, but that they abandon the form in the middle, not caring to finish it. Or maybe they are afraid to click the button because they don't know what will happen next. And so on. Simple problems can be indicators of larger ones.

That being said, while working, interaction designers shouldn't overly complicate things and should pick their battles. Sometimes a button problem is just a button problem. Not every project needs to be completely rethought and broken down. The teams that interaction designers work with would hate them if they constantly did that. Butand this will be a theme in this bookbe deliberate in the choices you make. If making the button bigger will solve most of the problem, well then, make the button bigger.

But fixing buttons that are too small isn't typically the type of problem that interaction designers are asked to solve. Certainly buttons and controls (see Chapter 6) will often be part of the solution, but the situations that interaction designers typically need to address are much messier. The types of problems that interaction designers often deal with have been called "wicked problems," a term coined in the 1960s by design theorist H. J. Rittel. Wicked problems aren't fully understood and have fuzzy boundaries, they have lots of people (stakeholders) with a say in them, they have lots of constraints, and they have no clear solution. Sounds like fun, right? But these are the sorts of issues that designers, especially interaction designers, tackle all the time. Design is not for the faint hearted.