Presentation to company division stakeholders about guidelines and best practices. The presentation was part of a series of presentations I made periodically on HCI and UX education and advocacy.
4. UX IS NOT INTERFACE DESIGN
•
•
•
UX stands for User Experience. It encompasses all aspects of the
end-user’s interaction with a company, its services, and products.
5. UX IS NOT INTERFACE DESIGN
•
•
•
•
UX is a major factor in successful software products.
6. UX IS NOT INTERFACE DESIGN
•
•
•
•
•
•
•
•
UX is a set of systematic activities in a process. The process
mirrors the software lifecycle process. UX does these things:
11. WHY IS GOOD UX SO HARD?
Software systems are complex and abstract
Users typically don’t understand how programming, DBs, computers, networks
work.
Computer screen provides a 2D flat ‘information context’
• Tasks are complex, but screen provides a limited 2D visual space to convey
meaning.
• Trying to do work on a computer screen means working in an ‘abstract
context’ removed from the real world ‘work’ context.
12. WHY IS GOOD UX SO HARD?
People are complex and not abstract
• People are task and goal oriented, practical in trying to get work done
• Abstract thinking is more difficult than thinking in a concrete, real world task context
• Meaning is perceived through context (words change meaning given a context; 2D
screen terms often misconstrued or not recognized at all).
• People have ranges of knowledge, different motivations, different job roles and
focus. One software design can’t work for all without good knowledge of the user
and the tasks.
13. 10 USABILITY PRINCIPLES OR GUIDELINES
1. Visibility of System Status
The system must always indicate to the user the system’s state.
State is indicated with visual, aural, verbal feedback, as appropriate for the state –
• Confirmation Msg – “Information Was Saved”
• Warning Msg -- “If you leave the page, your data will be lost.”
• “Ding!” [Computer sound]
• Visual, animated ‘Processing Spinner’ – System is taking time to process data
• Progress Indicator – How much of the process is complete?
• Visually Disabled Button – Grayed out, Button won’t respond, won’t function
14. 10 USABILITY PRINCIPLES OR GUIDELINES
2. Match the System to User’s Mental Model
To the extent possible, reflect the context of the task and the user’s mental
model of the task in the software UI context.
• Use labels and terms common for the task, not software terms
• Mirror the user’s task flow, even if not optimal for the system
• Format information display as the user would expect for the task –
if “real world” task normally displays data in an accountant balance sheet,
recreate a balance sheet display in the software
15. 10 USABILITY PRINCIPLES OR GUIDELINES
3. User Control and Freedom
The user should always feel in control of the system, not the other way around.
Users need a predictable world to feel “in control.”
• Users make mistakes, provide undo and reminders to “Save” data
• Provide auto-save or other recovery schemes (if the system fails)
• Label buttons and links to correctly set expectations
• Avoid controls that have two actions. Rule: one button, one action.
Dual action buttons “Save and Close” and “Accept and Continue” often confuse
users and/or create complexity.
16. 10 USABILITY PRINCIPLES OR GUIDELINES
4. Consistency and Standards
Users should not have to guess the meaning of terms. Behavior across the system must be
consistent.
• One term, one meaning. One control, one behavior.
• It is difficult to maintain consistency of terms: across menus, button labels, tooltips, page
names, confirmation and error messages, help docs
• It is difficult to maintain consistency of behavior: tasks are complex, different steps
require different controls and outcomes, different developers work on different portions
of the system
• Review platform and device UI standards written by Google, Apple, Microsoft, Sun
Systems, W3C. – know the standards for the device = consistency
17. 10 USABILITY PRINCIPLES OR GUIDELINES
5. Prevent Errors
Preventing errors is better usability than providing good error messages. Preventing is more
pleasant and satisfying than constantly being reminded that an action failed; it’s also more
efficient, quicker for the user to do and complete work
• Predictable labels on controls prevent errors.
• Consistent interactive behavior prevents errors.
• User control and Undo/Recovery prevent errors.
• Task flows that mirror the user’s mental model prevent errors.
18. 10 USABILITY PRINCIPLES OR GUIDELINES
6. Recognition Rather Than Recall
Minimize the user’s need to memorize codes and commands.
• Make functions visible or easily discoverable (use menus, toolbars)
• Display menu options and let the user select from a list
• Make instructions easy to view and “sticky.” User controls the display.
• Visually indicate the data entry field with the invalid condition.
• Provide tooltips that define terms
• Provide tooltips to supplement button and control labels to better set expectations
19. 10 USABILITY PRINCIPLES OR GUIDELINES
7. Flexibility and Efficiency
Provide adaptive and responsive user interfaces
New users and expert users require different “affordances” in the UI.
New users require more help, more instructions, less info density.
Expert users require accelerators, shortcuts, more info density.
• Don’t interrupt expert users with continual “Are you sure”” msgs.
• Provide “Preferences” for users to customize UI features
• Provide “Recents” so users can return to prior work quickly
• Provide keyboard shortcuts for frequently used actions
20. 10 USABILITY PRINCIPLES OR GUIDELINES
8. Aesthetics and Minimal Design
Reduce the cognitive load on the user
• Provide only relevant information -- avoid polite words, adjectives.
• Use simple, informal language.
• Every extra word, icon or photo requires processing by the user.
• Clutter is anything the user deems irrelevant for the task/goal.
• Minimal design requires knowing the user and the user’s task domain extremely well.
21. 10 USABILITY PRINCIPLES OR GUIDELINES
9. Help Users Recognize, Diagnose and Recover from Errors
Write good error messages
• State that an error has occurred in plain language, no codes
• Avoid terms like “kill,” “die,” “fatal error” – don’t scare the user
• Explain why the error occurred, in non-computer jargon
• Provide solutions to remediate the problem
• Provide someone to contact, if all else fails.
• Provide error code at the end, if needed for help desk
22. 10 USABILITY PRINCIPLES OR GUIDELINES
10. Help, Documentation, Training
• If a system is intuitive, it requires little documentation.
• Users have different knowledge and abilities, however.
• Provide tooltips, in-context help in the UI, especially to identify functions and provide a
full description for a label.
• If separate Help or Documentation is needed, it must be searchable, especially for tasks
and doing work
• User Help must focus on user tasks: how the user should use the system to accomplish
tasks or do work. User help isn’t a system guide.
• Research shows that most users (75-85%) never use external help or documentation.
23. SOURCES OF INFORMATION
Usability 101 - Definition of Usability - Nielsen Norman Group
https://www.nngroup.com/articles/usability-101-introduction-to-usability/
10 Usability Heuristics for User Interface Design - Jakob Nielsen
https://www.designprinciplesftw.com/collections/10-usability-heuristics-for-user-interface-design
User Experience Design - Peter Morville
http://semanticstudios.com/user_experience_design/
Elements of User Experience - Jesse James Garrett
http://uxdesign.com/assets/Elements-of-User-Experience.pdf
The What and Why of Usability
https://www.usability.gov/