I read two more articles in Digital Web's ongoing series on User-Centered Design. In the first article, Peter-Paul Koch writes about Client Centered Design. Koch gives an example of a salesman who sold the client with two mutually exclusive promises. Koch suggests that web teams work to manage client expectations. His ideas: "don't promise too much," figure out the client expectations, and "don't try to explain your job to your client." These are decent suggestions, even though the first point is poorly made (it should perhaps focus on being clear with what you can and should deliver to the client). However, I think Koch left out the most important point: designers can best serve the client by designing for the end user. But, as the second article points out, this design process is often a compromise between the client's requirements and the user's needs.
Another point brought up in the article:
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.
This is, I think, a good idea. UCD is not a visual design thing or a programming thing. It should be an everybody thing.
In the second article of the day, Jeff Lash writes about The Myth of User-Centered Information Architecture. Lash presents the very rational argument that information architects (and I'd extend that to include everyone working on a web project) need to consider a number of different perspectives when creating sites. Lash writes: "At its core, information architecture is a balance between user needs and business requirements." Very true. I think the trick is to spend some time early on in the process defining the various perspectives (users, business needs, technical requirements). Blending these perspectives well can lead to a site that works for everyone involved.
Information architecture goes beyond deciding what content should go where and how it should be labeled. It's more than just blindly listening to what users say. It's more than just making the client happy. Giving all of your attention to only one of these three aspects of account service is irrational, irresponsible, and impractical. The key to successful information architecture is understanding all of the variables involved in meeting project goals, and coming up with an appropriate balance.
Posted by Karl
October 23, 2002 06:41 PM