EMMANATE
- Exploring Mental Models for Application in Networking Applications, Telephony and Environments
Design Guidelines
These guidelines are intended for developers of Internet applications, such as Web browsers, email applications etc.
The guidelines are based on the hypothesis that users need to have, or develop, a basic understanding of networks in order to be able to use networked applications effectively. Please click here for a brief discussion of why we think this is necessary, or refer to our publications.
- Take users' previous knowledge and experience into account. For example, if you are designing an email application, you should take functionality of the major email applications on the market into account, as users are likely to expect these features. One way of investigating users' previous knowledge and experience, when the user population is large, is by looking at the contemporary legends in the area
- Base your project on a design model. Before you begin implementing, you must have a single clear design model which will cover all the functionality of your application. The design model must be implemented consistently across all aspects of the application, i.e. the user interface, the built-in help system and error messages. Follow this link for an example of a design model for the Web.
- Don't expect users to know how the Internet works. You must never assume that any step of using the Internet is obvious. For example, some users are not sure how they can receive email when they are not online.
- Be very careful when using metaphors. Metaphors can be extremely useful for explaining functionality to users. However, metaphors can also restrict users expectations of what is or isn't possible. Click here for a quick test of the suitability of a metaphor.
- Provide feedback at all times. The application should provide feedback to help users diagnose problems. When videoconferencing, is the lack of sounds and pictures from a participant due to a severed network connection, due to a crashed PC, or simply because the person has stopped transmitting?
- Design for Error. Error messages are often the best clue to what has gone wrong in case of a breakdown situation. Ensure that the error messages are consistent with the design model, that they are intelligible, that they cover all potential reasons for the breakdown, and that they suggest recovery actions. Follow this link for an example of an error message.