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

  1. Put the user first
  2. Keep the user in the centre
  3. Remember the user at the end

Software Development Lifecycle

  1. Requirements capture
  2. Design
  3. implementation
  4. Verification
  5. 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