Usability is Money
Users will have a poor experience and they wonât use the site again
Should consider usability for all users not just the developer
Rules of Interaction Design
- Understand the Computer - Limitations, capacities tools and platforms
- Understand People - Phycology, social aspects and human error
- Understand Human Error - Human Error is common
An unclear interface is often blamed on user error when it is actually designer error
User centered design
- Put the user first
- Keep the user in the centre
- Remember the user at the end
Software Development Lifecycle
- Requirements capture
- Design
- implementation
- Verification
- Maintenance
Requirements Capture
Elicitation
work with the stakeholder Interviews and Questionnaires - ask users Ethnography - observe users Scenarios & stories - real life examples
Types of Requirements
- Functional
- A service provided by the system
- What it should not do
- Non Functional
- Constrains on the functions
- can affect the whole system
Specification
What the system does not how it does it
Describe using:
- Natural Language - easy for anyone
- Structured Language - pseudoscope
- graphical notation - paper prototypes
- Cheap and easy to create
- easy to edit
- Design language - Cant be used by everyone
- Mathematical specification - very precise
Usability
- Learn-ability - How easy it to accomplish basic tasks on first encounter
- Efficiency - Once users have performed the design, how quicly can they perform tasks?
- Memorability - When users return to the interface how easily can they use it again
- Errors - How many, What are they , Are they recoverable
- Satisfaction - How pleasant is the design
Visibility
How easy is it for the user to recognize and use a control function. A more visible function is easier to use. Position of the controls and what they do is also important
Affordance
Properties of an object, what can be done with it.
When you first see something how do you know what to do with it?
- Text
- Icons
- Instructions
Donât make non-working buttons or things that donât look like buttons
Constraints
Limiting the cations the user can take at any one time
Common is deactivating certain menu options by shading and restricting use
- Physical - DVDs , USB, Keyboard : can only be pressed
- Logical - The users understanding of how the world works and allows the user to deduce what happens next
- Cultural - Cultural conventions: A red light means stop / warning almost anywhere it is shown in the western world but in China celebrates new year and brings good luck. This is a result of culture and fairly arbitrary not any form of logical process.
Feedback
Gives the user a response to an action and what has been accomplished could be
- Visual - hourGlass , new page load
- Auditory - Beep on mistake
- Tactile - Keyboard , vibration
- Verbal - Warnings or welcome messages
Mapping
Relationship between the controls and their effect
Good - Steering Wheels, Slider Bars
Poor - Taps: which side , Light switch: Which light?
Consistency
Similar operations for similar tasks
Cut and pase in the same menu File Menu top left
Similar both within systems and cross systems / applications (Xbox controller and PlayStation are similar)
Usability Heuristics
- Visibility of System Status - Keep users informed of status by providing feedback e.g 1/10
- Match Between system and Real World- Use userâs language rather than systems terms
- User Control and Freedom = Provide âescape routesâ for users (undo)
- Consistency and Standards - Avoid making users wonder if deferent terms mean the same thing (apply / save)
- Error prevention - Prevent users form making errors (Do you want to save)
- Recognition rather then recall - Make objects ,actions and objects visible
- Flexibility and Efficiency of use - Provide accelerators that allow experts to do things faster
- Aesthetic and Minimalist Design - Avoid irrelevant functions or information
- Help users recognize, diagnose and recover from error - Use Plain language to describe the error. Be informative and non-technical
- Help and Documentation - Provide information that is easily searched and provides solutions
Accessibility and the Web
Inclusive practice of making websites usable for all abilities
Required by Equality Act 2010
- Meet level AA of the web content Accessibility Guidelines (WCAG 2.1)
- Otherwise: you could be sued for discrimination
The site should
- Programed using semantically meaningful HTML
- Has text equivalents for images
- Meaningful link names
Needs
Visual - Blindness, poor vision , colour Blindness Motor - Fine motor control , tremors, slowness Auditory - Deafness Seizures - Epilepsy form flashing lights Cognitive - Learning difficulties (dyslexia,dyscalculia) memory problems
Examples
- Making images/ text enlargeable with functionality or browser CSS
- Underline Links - for colour blind people
- Make clickable areas large - Helps users with poor motor control
Assistive Technologies
- Screen Reading Software - Reads to the user with synthesized speech
- Braille Terminals - Outputs text as Braille
- Screen Magnification
- Speech Recognition
- Large TrackBalls
WCAG
Web content accessibility Guidelines (WCAG) are published by the Web Accessibility initiative WCAG 2.0 published in 2008 and became an ISO standard in 2012 WCAG 2.1 published in 2018
Principles Behind the Quidlines
- Perceivable - Information should pe presented to users in ways they can perceive
- Operable - User interface components and navigation must be operable
- Understandable - Information and the operation of user interface must be understandable
- Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Evaluation and Testing
Evaluation
- Gather Data about the usability of the design
- what the user does
- The characteristics of the user
- The environment and the context where the evaluation will take place
- The nature of the artefact being examined
Types of evaluation
- Formative Evaluation - Evaluation of an existing product, Predictive evaluation
- Summative Evaluation - Evaluation at the completion of a product
Evaluation should be done regularly and after each step in the product design development and testing.
Analytical Evaluation
Include Keystroke Model Measure
- k (Key-stroking)
- P (Pointing)
- H (Homing)
- D (Drawing)
- M (Mental timing of the operator)
- R (Response time fo the system)
Observational Evaluation
- Observer users interacting with the system
- Users complete a et of predetermined tasks
- Users can be asked to âThink aloudâ - give description of what they are doing and thinking about
- Their thoughts are analysed later
- Assess the extent of System functionality
- Assess the effect of the interface on the user
- Identify specific problems
Usability Testing
- Introduce a list of tasks
- Watch Quietly
- Record behavior (take notes, recorded)
Measuring Usability
- Ratio of successes to failures
- Time to compete a task
- Number of errors made
- Number fo times the user expresses frustration