5 Points Concerning Designers Vs. Usability Folks

Web designers and usability folks don’t seem to get along very well. Web designers say that they don’t need usability folks because they design with inherent usability: it’s simply a part of good design. Usability folks, on the other hand, say that everything must be tested. Who’s right?

Designers have History

Visual design (loosely: the layout aspect of web design) has been around for centuries and is well documented. The intelligent use of line, color, contrast, whitespace and other principles will guarantee a good design. How did we come to trust in these principles if they weren’t so usable?

Usability Folks have Numbers

Usability is about measuring how well something works, making changes to it, and then seeing if there was improvement. You make improvements by finding a metric that you believe in (revenue, conversion rate, time to complete) and then making suggestions to the designers to improve that metric. In most cases there is improvement over time. This sort of incremental improvement is not possible without usability testing.

Designers Say Content is Design

Visual designers know that content is the design. You cannot separate presentation from the “thing”. Therefore, design is at least as important as content in whatever project you’re working on.

Usability Folks Say Content is King

Design is nothing without content, usability folks say. You cannot have design without content, but you can have content without (much) design. Therefore, we know which one is most important.

But Wait: Don’t We Have the Same Goals?

These arguments are two sides of the same coin. Both designers and usability folks want to make great products for people, so why the difficulty? Can’t everyone just get along?

Part of the reason, I think, is that designers feel threatened by usability folks and usability folks act like they’re dispensing gospel. It’s a vicious cycle.

Let’s look at what might happen in a typical project where usability is peripheral. That is, usability is “done” to a design in the later stages of the project, when the design is almost complete and there isn’t much time to change anything anyway. Simply put, the usability folks are brought in to find problems. They perform some sort of usability test and then report back to the project manager the dozens of problems they see in the design. They’re like the Cops. Who wants to talk to Cops if all they tell you is what you are doing wrong? Harboring resentment is sure to follow.

Let’s look at a project where usability isn’t peripheral, but built in. The usability team has more than enough time to do various testing across the lifecycle of the project. They bring in users early BEFORE the design is finalized and looking pretty. They’re suggesting what the design team should keep because it’s working well. They’re highlighting those parts of the design that are top-notch and shouldn’t be changed, while also pointing out where users are having trouble. Since it’s not near the completion of the project yet, the designers aren’t feeling like the project is their baby: that is, they don’t feel like it’s the best that they could do yet. At this point, I think, they are much more susceptible to any suggestions (especially suggestions backed up by evidence of user frustration).

A major part of the puzzle, I think, is to recognize that designers and usability folks do two very different jobs. Designers should be the only ones who design, and usability folks should be the only ones who do usability testing. (well, they can observe and learn about the other’s role, but not do it for them or tell them how to do it). And if given enough time to work with each other on a project, both sides may realize that they have the same goals. Great things are done only when people have the same goals.

bokardo