AskTog: Interaction Design Solutions for the Real World
Interaction Design Section   Living Section   About Bruce Tognazzini
NN/g Home > AskTog > Columns > Denial: Elephants in the Living Room Ask Tog, September, 2000

Elephants in the Living Room:
The Destructive Role of Denial in Web Design

Four of your fellow development team members, all trying to do their specific jobs to the best of their abilities, have the power to sink your best effort at interaction design. As an interaction designer, it is your job to see they don't do so. (If you are not an interaction designer, read on anyway; you may be surprised to learn that you may be part of the problem.)

The elephant in the living room

This metaphor was developed by people involved in drug and alcohol recovery to describe the phenomena of the dysfunctional family, where family members focus closely on Mom's unexplained crying jags, Billy's misbehavior at school, and Mary's inability to keep food down, while ignoring Dad, who starts drinking when the alarm goes off in the morning and doesn't stop until he passes out on the couch at the end of the day, after berating his family for three hours. Dad's "little problem" is never mentioned, it is a "given" that the rest of the family has grown so used to that they don't even recognize its existence anymore. After all, what could be done about it?

Many web sites I review have elephants every bit as egregious as a drunken father, elephants that trample the user experience to death, resulting in revenue losses that can be measured in the millions of dollars. When I speak to the interaction designers, they typically expect me to commiserate with their difficult position; after all, what can they do? My answer is simple, if harsh: Whatever it takes to fix the problem.

The four handlers and their beasts

It would be unfair to label the people responsible for the problem as elephants. Indeed, they are typically people doing the best job they can to ensure that their responsibility is executed perfectly. (As you will see, sometimes its just a little too perfectly.) Let's meet these well-meaning handlers and see what we can do about their great, gray beasts.

1) Engineers

Engineers, of course, are vital to a successful site, but their power to help is balanced with an equal and opposite power to cripple the designer's effort.

I have worked with engineers who really get into the design, moving heaven and earth to implement what the rest of the team has come up with. Some engineers go further, whipping up prototypes of cool ideas overnight that no one else even considered possible. These all are truly the good guys.

A different group of engineers seems stuck in neutral, bent on doing the minimum required to "get the job done," defined as uploading partially-debugged code to the server. Often this attitude is encouraged by an engineering management team that is bent on mediocrity, prepared to punish superior effort where ever it can be found as a waste of time. Regardless of the source of the problem, you can detect its presence by the two great engineering lies:

(The third great engineering lie is, of course, I promise to debug the code before I check it in. Engineers lead dull lives.)

Good engineers may well declare that your design is unimplementable, but the next day they will show you how they cleverly overcame that impossibility through the brilliance of their coding. ("Here, check this out! It works!") It's the ones who never even try that present you with the Dumb Code Elephant.

If the individual engineer is responsible for an embarrassing user interface, work with him or her first. Learn to prototype, using a tool like GoLive from Adobe, so you can give them something more than pencil sketches and handwaving. Sit down with the engineer on a weekly, or even daily, basis, and reiterate each and every one of your concerns. Do not expect him or her to appreciate why the line they coded is one pixel too low; let him or her come to understand how important it is to you.

If this approach doesn't work, move slowly up the chain of command. If engineering management is responsible, form an alliance with the marketing people and get marketing management to come to the rescue.

You can strengthen your position, as always, with well-documented user testing.

2) Security

As reported elsewhere (Maximum Security, April, 1999), security people tend to focus entirely on keeping people out, rather than letting them in. If they were responsible for our laws, they would put everyone to death who'd ever been stopped for a traffic violation, just to prevent the possibility, however slight, of a murderer going free.

Do field tests and statistical analysis to show that their requirement of a new 128 character password every two weeks is causing people to a) return to pencil and paper just to avoid your site and b) write down the password and paste it to their monitor (duh!) for all the world to see.

Some people have augmented these techniques by "keying" the offending security person's car (using a public key, of course). This is a bad strategy for two reasons. First, security people are really good at finding out who's responsible. Second, they are only doing their job according to their training. (The real problem is that their teachers were idiots.) You need to help them learn security for the real world. Of course, if they are not open to learning, escalate, armed with real data.

3) Lawyers

Lawyers also have idiot teachers. Why else would they reduce a web site to total unusability with agreements, warnings, threats, and special Java extensions that send 440 volts through the keyboard of any hapless user who has the temerity to actually use your site.

Lawyers can screw up a web site more effectively, more thoroughly than any other handler. And they do so knowing that God (or whomever it is that lawyers report to) is on their side. Their job is to keep your company from being sued and, by golly, if they can successfully prevent anyone from doing anything on your site, you aren't going to get sued!

My experience has been that there is no more point in arguing with a lawyer than debating a ferret. You are a non-lawyer (i. e., subhuman life form). If you have a lawyer reducing your site to Latin derivatives and upper-case sludge, prove the damages through user testing, surveys, and web site logs, then escalate the written result all the way to upper management. The folks at the top understand the bottom line. They can, and will, do something about it.

4) Graphic Designers

A lot of my readers and a lot of my friends are graphic designers, so I want to tread lightly here. However, I feel compelled to point out that graphic designers, given sufficiently disproportionate power, can screw things up rather badly. One need look no further than Apple's System X to see that effect.

Graphic designers have what are, to me, magical powers. However, they are also taught by idiots with no knowledge or interest in interaction techniques. When the balance between interaction designer and graphic designer is skewed, you are likely to end up with a site that is really pretty to look at, but unusable.

It has been my experience that the graphic designer is rarely, if ever, responsible for the unbalance of power. You can most often find they have an unsolicited champion in management or marketing that comes from a static background, such as publishing, and has fallen in love with the possibilities of having swinging graphics effects such as 2 point light-yellow type on a cream background—the sorts of effects that have infected the print medium in the last decade.

Your job is to find this unwanted ally and silence her. Telling the security person you saw her keying his car could result in a nice double-play. Failing that, get ahold of the site logs and prove that no one entering the site can find anything. Back up those stats with user testing.

Cure is the lesser of two evils

If you now divide existing interface problems into those you can control and those you can't, it is time for a change. All usability problems are your problems, and they are your responsibility to address. If you open your eyes and see elephants, get the great big gun of usability statistics and go take them down. Choose your battles carefully, and you will succeeed. If you do it dispassionately, with the facts at your command, you will be seen as a hero—albeit an unwelcome one—not a trouble maker.

Of course, you could just continue to sit back. All these problems smooth themselves out with time. Unusable sites have already started dropping like flies, and we haven't even had an economic downturn yet. Still, it's kind of hard on the workers when the whole company gets laid off.

Don't miss the next action-packed column!
Receive a brief notice when new columns are posted by sending a blank email to asktoglist-subscribe@yahoogroups.com.

return to top

Contact Us:  Bruce Tognazzini
Copyright Bruce Tognazzini.  All Rights Reserved