Users & Usability

Requirements
Lecture 4
 Today’s Lecture

Review UCD process (for the Assignment)

Define Users
Define Usability Requirements
Model User Tasks
Aspects of Task Analysis,
The Task Model,
Task Context Notes
User-Centred Design Process
Four Principles of User Centred Design

1. Early and continual focus on users

2. Integrated Design
3. Early and continual user testing
4. Iterative Design
The User Centred Design process
Starts with identifying the end-users and their usability
requirements;

Continues with users’ tasks and mental models;

Involves end-users participating in analysis, design and

prototyping;

Concludes with end-user evaluation of the usability

prototypes.
Relates to work for the Assignment
1. Interface Requirements Capture
Assemble a suitable group of users (this can be
time-consuming so start early!).
Talk to them about how they would like the
interface set out. Drawings are useful for this.
When choosing users remember the
requirements of the Disability Discrimination Act -
since October 1999, service providers have had to
consider making reasonable adjustments to the
way they deliver their services so that disabled
people can use them.
Cont…

Model user tasks at the interface. Make sure

that your model provides a final list of actions
on objects at the interface which will provide
useful information for the design of your
interface.
Define the application style guide.
Examples to demonstrate the process
A simple GUI
A system for Remote Home Environment Controller – this
enables the user to control heating, lighting, open curtains
and windows, switch on cooker etc remotely.
A complex GUI
A personal organiser similar to Palm V with facilities for
diary organisation, address book, memos etc

Bear in mind
We will look at these two systems, however the simple
GUI is very simple and some of the processes seem too
obvious and the complex GUI is so complex that it would
take longer than this lecture to document and design.
We will for example find some of the object models for
the complex GUI but certainly not all of them.
Relates to this part of User Centred Design theory
Early and continual focus on users
• Define a major group of potential users (if you can)
• Talk to them about good and bad points of their present job
and/or system.
• Watch them doing their present job.
• Ask them to think aloud as they work.
• Try their jobs (if possible)
• Do a formal task analysis
• Develop testable behavioural goals for proposed systems.
 Define Users and Usability
Requirements (1)
User System Scope (How much is included)
Roles System Requirements (What does it need to
do)

Define Users and

Users Usability
Requirements

User Usability
Classes Requirements
 Define Users and Usability
Requirements (2)
The process as described for complex systems
Redmond-Pyle and Moore (Pg 70)
• Identify user classes
• Describe the users in each class
• Identify critical usability requirements
• Specify measures and performance criteria
• Define performance levels
• Review and agree usability requirements
specification
Define Users & Usability Requirements for
Remote Home Environment Controller (3)
User roles
– Busy executive (wants to control the home from work)
– Disabled User (wants to physically control elements when home)
– Disabled person’s carer (wants to physically control elements on the
disabled person’s behalf)
– Busy Housewife (wants to control the house when home or away)

System’s scope and requirements

– House has three bedrooms, sitting room, dining room, kitchen,
bathroom.
– System could be used remotely to control:
• Front, back and garage doors
• Windows and curtains
• Cooker, lights ….
 Define Users and Usability Requirements for
Remote Home Environment Controller(4)
User Classes
– Novice
– Expert
– Mobility impaired, visually impaired (depends on legislation and
marketing considerations)
Usability Requirements
– The user must be able to use the system without training.
– All instructions for the system must be embedded in the interface
(i.e. no user manual)
– The interface must use as little text as possible and should be
intuitive
– Interface elements must be easy to see
– Interface elements must be easy to manipulate
Define Users and Usability Requirements for a
Personal Organiser (4)
User roles
– Busy executive
– Personal assistant to busy executive
– Home user with no computer experience
– Computer experienced home user
System scope and requirements
– Must be quicker to use than a paper diary and
address book.
– Easy and quick to learn
– Attractive to use
Define users and usability requirements for a
personal organiser (5)
User classes
– (Standard user classes for office and home based
software)
– Novice user
– Expert user
Usability requirements
– Easy to learn with a Wizard
– Shortcut keys for experts
– Restful colours
– Easy to move between different parts of the
organiser
User-Centred Design Process
 The Aim of Modelling User Tasks

Conceptual Interface
Conceptual
Actions functions
Actions on
Model User Tasks
conceptual
objects Conceptual Interface
Objects objects

When we model user tasks, we continue to break the tasks down

(Stepwise Refinement) until the sub-tasks consist of a Conceptual
Action on a Conceptual Object. We can then map these onto an
Interface Function and an Interface Object
 Model User Tasks (1)
Business User
Processes Classes
(or Functionality)

Model User Tasks User Object Model

Task Task
Models Scenarios
 Model User Tasks
Task Analysis is:
• Study of what a user will want to do.
• documentation of the information and control facilities used
to carry out a task
• a methodology to help the analyst collect and organise
information then use it to make design decisions
• a method to provide a model of human involvement in a
system
Why use Task Analysis
• to ensure efficient and effective integration of the human
element into system design
• to establish a two way flow of information between
– human requirements & limitations
– design preferences & constraints
• to avoid the design of sub-optimal systems
Imagine designing this complex Palm V interface!!
 The Objectives of Task Analysis
1. To understand
– user task goals
– user actions
– task context
2. To produce task models
To create an abstract interaction system
using the system objects
3. To produce task scenarios
 The Task Model
• is an abstract model of task structure (in GOMS or Task
Hierarchy Diagram)
• shows the subtasks involved
• ultimately identifies the conceptual actions and
conceptual objects of the system.
• In larger complex systems, this includes relevant
information about each task including (n.b. In simple
systems some of the task information is not necessary )
as different users might complete different tasks:
– who performs it
– frequency
– average performance time
– user error frequency
– notes about the context in which the task is performed
 Well Known Task Models
GOMS
• Goals, Operators, Methods, Selection Rules

Task Hierarchy Diagram

• goals, tasks, operations, plans
• hierarchies, redescription, stopping rules
 The GOMS Model
• similar to wordprocessor outline format
This is a fragment of a much larger GOMS model for a whole
wordprocessor.
• The Goal EDIT-DOCUMENT is the overall goal of editing all the bits in a
document that need editing.
• This is broken into goals EDIT-UNIT-TASK the goal of editing a particular
unit of the document.
• The goal of GET-UNIT-TASK is to find the next bit to edit and the operator
GET-UNIT-TASK means to find where it is.
• The goal DO-UNIT-TASK is to actually edit this bit which is broken into the
goals of LOCATE-LINE i.e. move the cursor to the part that needs editing
using either the USE-MARKER-METHOD or the USE-BAR-METHOD
followed by the goal CHANGE-TEXT i.e actually make the change again
using two possible methods
GOAL: EDIT-DOCUMENT (goal)
* GOAL: EDIT-UNIT-TASK (goal)
* * GOAL: GET-UNIT-TASK (goal)
* * * GET-UNIT-TASK (operator)
* * GOAL: DO-UNIT-TASK (goal)
* * * GOAL: LOCATE-LINE (goal)
* * * * [select: USE-MARKER-METHOD (operator)
* * * * USE-BAR-METHOD] (operator)
* * * GOAL: CHANGE-TEXT (goal)
* * * * [select: USE-D/LINE-METHOD (operator)
* * * * USE-D/WORD-METHOD](operator)
* * * * VERIFY-EDIT (operator)
 Task Hierarchy Diagram
Plan 0: 1, 2, 3 or 2, 1, 3
0
Plan1: if order exists 2 else 1, 2
Task X

1 2 3
Subtask 1 Subtask 2 Subtask 3

Subtask 1.1 Subtask 1.2

 The GOMS Model v Task
Hierarchy Diagram
The strength of GOMS is that it makes clear for
the designer the instances of User Actions on
User Objects
You can see the operators listed on the right hand
side. These indicate an Action on an Object at
the interface.
It is perhaps easier to see the breakdown of tasks
in the Task Hierarchy Diagram but it is more
difficult to see the list of actions on objects as
they often do not appear on the same level.
 A Task Scenario
An example of a task
Not a task model which is an abstract structure and
includes includes variants and subtasks
A task scenario is:
– a single concrete instance
– with specific, initial circumstances, input, subtasks
A scenario includes typical data and may include
exceptions can be thought of as a test case for a task
including;
– a situation or set of circumstances for a task
– a script describing how a user performs a task
 Example of Task Scenarios
Consider the Personal Organiser Example
Task: Write in my friend’s birthday on 20th January 2017
Task Scenarios or instances for this task:
1. Initial circumstance – User is currently in Address Book
– Select Calendar
– Find 2017
– Find January
– Find 20th
– Type in friend’s name
2. Initial circumstance – User is currently typing a meeting in 2nd January
– Select 20th January
– Type in friend’s name
3. Initial circumstance – User has typed the friends name in 20th February
2017 by mistake
– Find January
– Find 20th
– Type in friend’s name
 Task Analysis the Process
• Identify tasks
• Select task scenarios
• Analyse and model tasks
• Describe task content
• Identify subtasks requiring computer
support
• Express scenarios as actions on user objects
 Model user tasks
Business User
Processes Classes
(or Functionality)

Model User Tasks User Object Model

Task Task
Models Scenarios
Specification for a Remote Home
Control Environment
Design the interface for a remote home environmental
control system for a three bedroom house.
1. The user must be able to use the system without training.
2. All instructions for your system’s use must be embedded
in the interface and the interface must use as little text as
possible (i.e. no user manual).
3. The system must be as visual as you are able to make it.
 Cont…
1. The system is required to control a house with three
bedrooms, sitting room, dining room, kitchen and bathroom.
2. The functions it must control are:
Switch on/off lights in each room.
Open/close curtains in each room
Open/close a window in each room
Switch central heating on/off.
3. Constraints on the system are:
Lights cannot be switched on in a room unless the curtains are
drawn
Windows cannot be opened unless the central heating is off
Central heating cannot be switched on unless all the windows are
closed
 Model user tasks for a Remote Home
Environment Controller(1)
• Functionality
– Functions:
• Switch on/off lights in each room.
• Open/close curtains in each room
• Open/close a window in each room
• Switch central heating on/off.
– Constraints:
• Lights cannot be switched on in a room unless the curtains
are drawn
• Windows cannot be opened unless the central heating is
off
• Central heating cannot be switched on unless all the
windows are closed
 Cont…

User Classes
Novice
Expert
Possibly mobility impaired, visually impaired
(depends on legislation and marketing
considerations)
 Model user tasks for a Remote
Home Environment Controller (2)
(These are examples but there are many more in this proposed
system. Most of the tasks are very simple and do not need to be
broken down further)
Tasks
Start up the system
Switch off a light in a bedroom
Switch on a light in a bedroom
Switch on a radiator in a bedroom
Switch off a radiator in a bedroom
etc
Task Scenarios
Switch on a light in Bedroom 1 when the curtains are not drawn
Switch off a light in Bedroom 1 when the curtains are drawn
etc
 Model user tasks for a personal
organiser (3)
Business process or functionality
Organiser provides diary, address book , to do list
and memo pad facilities
Runs on a desktop and a handheld device

User Classes
Novice user
Expert user
 Model user tasks for a personal
organiser (4)
(These are examples but there are many more in this
proposed system)
Top level tasks Decomposition of one task
Add a birthday
Add a birthday
Delete a birthday
Get to Date mode
Add meeting
Find right month
Delete meeting
Find right day
Add a new address
Activate day
Delete an address
Enter birthday – may need further
Edit an address decomposition
etc
 Model user tasks for a personal
organiser (5)
Example Task scenarios
When in Memo Pad add Mary’s birthday on 1st
August
When in Calendar add Mary’s birthday on 1st
August
When is Address Book add Mary’s birthday on 1st
August
When looking at November check appointments
on 3rd December
Etc….
End of Lecture 4