引用「Why Johnny can’t build a decent user interface.」

Most user interfaces are poorly designed. This is so widely understood that it’s become a common humor trope.

For instance, from xkcd:



And from Dilbert:




Funny because it’s true.

So why do most user interfaces suck?

In my experience, it’s usually a combination of these reasons:

A self-serving agenda. The person designing the interface often has an agenda other than helping out the users. The above xkcd comic illustrates how most universities are more interested in glorifying themselves than in helping visitors find the information they need. Another example is the web designer who wants to show off his mad skillz at web programming technologies, and packs the web page with enough flashing Disneyesque eye candy to send the casual visitor into transports of epilepsy. (See Web Pages That Suck for some examples, unless you’ve just had breakfast.) The designer has let his/her ego take precedence over the users’ needs.

Intellectual arrogance. Many programmers have a gross overconfidence in their ability to design user interfaces. As I discussed in this post, incompetent individuals tend to overestimate their abilities and fail to recognize their inadequacies. Just because someone can write good code does not mean he/she can design an effective user interface. The common attitude among many programmers that the user interface is “just more code” can contribute to this arrogance.

Lack of ability. (This one often goes hand in hand with the preceding.) In my experience, good user interface design involves a lot of inherent ability: you can either design pretty good interfaces or you can’t. If you naturally suck at it, a human factors degree and all the latest UI design books won’t help much — and may just instill a sense of false confidence (again, refer to the preceding point).

Lack of intellectual empathy. Many people lack the ability to see things fairly from the viewpoints of others–specifically, in the case of user interfaces, to put oneself in the place of a user. This can especially be the case for those developing software in user domains with which they are not familiar (e.g., a programmer with no medical background developing clinical database applications).

A disregard for human factors. It’s been my experience that human factors engineers tend to get marginalized. Most organizations that develop interactive software don’t even hire human factors engineers, and most software engineers don’t understand the value of true human factors engineering — in particular the cognitive psychology and human-computer interaction expertise that human factors engineers bring to user interface design.

The wrong kind of mentality. I’m admittedly generalizing here quite a bit: Database programmers tend to have a data-centric mentality, and build data-driven applications organized around the way the data is modeled and stored. C/C++ programmers who build desktop apps tend to have a functionality-centric mentality, and build applications organized around the capabilities implemented. Web programmers can have a technology-centric mentality (as described under “the wrong agenda” above) or sometimes a content-centric mentality, and build sites organized around providing access to content. These are all the wrong mentalities.

The right mentality is a user-centric mentality. User interfaces should be designed from a mentality that focuses on the users and the work they must accomplish.

When building user interfaces, developers should research the answers to the following questions:

Who are the users? What are their abilities and backgrounds? Are there different groups/types of users, and how do they differ? For example, a church website has two distinct user groups: (1) current members, who are coming to the website for “insider” information (when is the next choir practice?); and (2) potential new members, who are visiting the website to find out more about the church.

What are their goals? What is it that users are trying to accomplish when they sit down to use the system?

What are their tasks? What tasks do users have to perform in order to accomplish each goal? How do these tasks decompose into subtasks? What is the sequencing and dependencies between these subtask?

And what are the information needs of these tasks/subtasks? At each step of the way, what does the user need to see on the screen in order to perform the tasks/subtasks – in particular those involving decisions? This, more than anything else, should drive the way the user interface is designed.


引用來源：http://jeffreyellis.org/blog/?p=8897