Client-Centered Design

By Peter-Paul Koch

What is the difference between user-centered design and usability? Until writing this column I didn’t have the faintest idea. Fortunately, a quick search turned up a page that explains the difference quite nicely:

UCD [user centered design] is often mistakenly considered a synonym for usability. UCD is much more encompassing – it addresses the total user experience, which is broader than usability. UCD is a multidisciplinary approach.

I’ve encountered user-centered design in some of my projects, though it didn’t know that its principles had a name. Indeed, this approach must be multidisciplinary or fail miserably.

Multidisciplinary approach

Although a Web site development team generally includes a usability expert–whose task it is to make sure that the forms are simple, the navigation is easy to use and that users can find what they’re looking for–user-centered design is the responsibility of every single member of the team, programmers no less than graphical designers, database wizards no less than usability experts.

Graphic designers think in terms of images, forms, and colors. Programmers think in terms of code. Those mindsets aren’t wrong – they’re the expression of the strengths of each team member. However, the same team members can get carried away by the disadvantages of specialization. When that happens, someone has to put on the brakes and say:

Please think of your users.

In fact, think of your users usually means keep it simple, and any sufficiently experienced Web development professional can breakthrough complex technical or artistic arguments and say this. Sometimes even people who don’t actually build the site, like salespeople or project managers, express excellent ideas about user-centered design.

More than once I’ve seen that of all the team, the project manager was best able to think like a user, because the other team members were too absorbed in the mindset of their specialization. This is not a general rule; some project managers will fail miserably in this role, but it does show that you cannot exclude any team members from the process of user-centered design.

Intuitive navigation

Complicated thinking within the development team usually has a counterweight in the broad mandate of the project manager. The largest danger to user-centered design, however, comes from the outside.

One day a salesman, who’d sold a site to a client, came to my desk and informed me of his promise that the navigation would be “intuitive”, and that the whole site would download within 5 seconds even on old modems.

Both of those aspects of design and production–user-friendliness and short download times–are important for user-centered design, but in this case, they contradicted each other. In the context of the proposal made to the client, “intuitive navigation” clearly meant “images”. Apart from the question of whether these images would be intuitive for every user, graphical navigation usually takes longer than 5 seconds to load over an old (say, 33.6kbps) modem.

Therefore I sent the salesman back to the drawing board. Needless to say, we lost the Web site to another company.

If the salesman had forgotten about the intuitive navigation and had instead concentrated on the download speed, he would have given an excellent example of user-centered thinking, and we might have gotten the job.

Client-centered design

But he didn’t. What did he do wrong?

1. First of all, he didn’t have the experience to appreciate simplicity. That’s something he’d have learned in time. Besides, any other team member could gently correct him (as I did).
2. Second, and most importantly, he didn’t practice user-centered design but client-centered design.

Thinking purely from we’ve got to sell this proposal point of view the salesman wasn’t wrong. Most clients are impressed by moving bits and graphical stuff, regardless of whether the subject of the site calls for it.

As soon as a client expects something “multimedial” it’s hard to guide the site back to something its users will appreciate, unless, of course, the purpose of the site is to provide “multimedial” entertainment.

Thus we’ve defined one reason for creating complex sites: client expectations. How do we counter these expectations? How do we keep it simple?

Countering client expectations

Unfortunately there is no general rule for the task of keeping a client’s expectations within reasonable limits. Some clients are easily convinced by someone who knows what he’s talking about, while others will rigidly maintain their point of view, aided by their nephews who’ve gone through a Front Page book and therefore know everything there is to know about Web sites.

Nonetheless there are some specific rules. They won’t always work, but they’ll give you some rough guidelines on how to work with the client toward the goal of simplicity.

1. First of all, don’t promise too much, which is an easier mistake to make than you’d think. Avoid talking about multimedia, applications, animations and such. Once you’ve mentioned these possibilities, the client is more likely to assume they’ll be used in his site, than to assume you’re suggesting them.
   Not promising anything is far better than going back on what the client perceived as a promise.
2. Find out what the client expects from his site. If this is different from what the users of the site expect, count on some hours of patiently convincing the client. If you don’t have the budget for this, either refuse the job or resign yourself to client-centered design.
3. Don’t try to explain your job to the client. Don’t talk about usability, accessibility or compatibility, unless the client specifically asks for information.
   Good clients assume you’ll take care of these issues, because that’s what you’re paid to do. Bad clients will disagree with you without having the slightest idea what they’re talking about, and will get angry because you disagree with them.
   All clients will get a slightly hazy look in their eyes and might interpret your words wrongly, leading again to perceived promises on which you can’t deliver without sacrificing user-centered design.

Professionalism

The issue underlying all these problems is professionalism. Site design and development has only existed as a professional trade for ten years at most… and more likely something like eight years. Further, there are a lot of amateurs, good and bad.

Therefore Web design is seen by a lot of people not as a job, but more of a glorified hobby. Thus people will assume they know all about it and will only think of what they themselves like, instead of what their users will like, and will generally work against the goals of user-centered design.

This problem will be solved when Web design is universally recognized as a profession. Meanwhile, the best you can do is to keep it simple.

Peter-Paul Koch is a freelance Web developer, writes and maintains the JavaScript Section and is an Administrator of the WDF and WDF-DOM mailing lists.