Ignoring Users when Designing
I have recently read Hoekman’s “Designing the Obvious”. For me it ranks amongst one of those books you should read if you are in this business. Anyway, one thing that I found interesting while reading it is the fact that Hoekman suggests that you should ignore the users. This goes against everything we are taught but he is able to support his argument very well. The core of his argument, as I understood it, is to design for the Task as opposed to designing for the User. This makes perfect sense. People, regardless of their nature, uses an application to accomplish a certain task, whether it is a chatting with a friend or performing complex calculations. Furthermore, I think that users have no idea what they want and they also don’t really understand what is possible. What one person might perceive as a great feature is useless for the next person.
The worst thing you can do though, is design for the client. It is an absurd notion that has taken hold of my class lately. I can’t imagine a dumber thing to do. It is like asking the manager of the webshop you are designing what he wants on the site, as opposed to asking the user or looking at the task at hand. Dilbert seems to have experience with this. Anyway you can follow some conversation about Application Centered Design here and Rogier Bikker has a similar post about designing usable interfaces instead of nice looking, unusable applications which please the client.
Dr. Pete Says:
Although I agree with you in theory, it’s a bit different outside of the classroom. Designing for the client isn’t so much something many of us want to do, as it is a necessary part of the client relationship. Since I was a psychologist first and then a businessman, I always work to educate my clients and help them be effective, but it’s their dime at the end of the day, and I can’t build good, effective sites if they stop working with me.
There’s another way to think about it, too. Any specific client exists in a particular industry or domain, and the client knows that domain and its users better than we do. So, doing our job well means compromising between our general knowledge of usability and their domain-specific knowledge. Even with task-based design, you have to know what tasks to anticipate, and it’s usually the client who gets that ball rolling. So, in some ways, the distinction is artificial, at least in practice.
Andrew Says:
I’m afraid to say I don’t agree that “The worst thing you can do though, is design for the client.” At least not entirely.
I would argue that you design for the user to use, and for the owner to own; each set of needs is different and not necessarily incompatible.
I think Dr. Pete said it: the distinction is artificial in practice. A site the user loves but the owner hates will end up removed or defaced in fairly short order.