User Tools
design:usability_heuristics_for_user_interface_design
Differences
This shows you the differences between two versions of the page.
| design:usability_heuristics_for_user_interface_design [2020/06/11 12:39] – created mmcc | design:usability_heuristics_for_user_interface_design [2021/06/25 10:09] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== 10 Usability Heuristics for User Interface Design ====== | ||
| + | Author: Michelle McCausland | ||
| + | |||
| + | ## 1. **Visibility of System Status** | ||
| + | |||
| + | - The system should always keep users informed about what is going on, through appropriate feedback within a reasonable time. | ||
| + | |||
| + | ## 2. **Match between system and the real world** | ||
| + | |||
| + | - The system should speak the users' language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms. | ||
| + | - Follow real-world conventions, | ||
| + | |||
| + | ## 3. **User control and freedom** | ||
| + | |||
| + | - Users often choose system functions by mistake and will need a clearly marked " | ||
| + | - Support undo and redo. | ||
| + | |||
| + | ## 4. **Consistency and standards** | ||
| + | |||
| + | - Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. | ||
| + | |||
| + | ## 5. **Error prevention** | ||
| + | |||
| + | - Even better than good error messages is a careful design which prevents a problem from occurring in the first place. | ||
| + | - Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. | ||
| + | |||
| + | ## 6. **Recognition rather than recall** | ||
| + | |||
| + | - Minimize the user's memory load by aking objects, actions, and options visible. | ||
| + | - The user should not have to remember information from one part of the dialogue to another. | ||
| + | - Instructions for use of the system should be visible or easily retrievable whenever appropriate. | ||
| + | |||
| + | ## 7. **Flexibility and efficiency of use** | ||
| + | |||
| + | - Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. | ||
| + | - Allow users to tailor frequent actions. | ||
| + | |||
| + | ## 8. **Aesthetic and minimalist design** | ||
| + | |||
| + | - Dialogues should not contain information which is irrelevant or rarely needed. | ||
| + | - Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. | ||
| + | |||
| + | ## 9. **Help users recognize, diagnose, and recover from errors** | ||
| + | |||
| + | - Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. | ||
| + | |||
| + | ## 10. **Help and documentation** | ||
| + | |||
| + | - Even though it is better if the system can be used without documentation, | ||
| + | - Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. | ||
Page Tools
