Week 7 lecture, CN5111 Usability Engineering (2014-15)

1. Cn5109 – Week 7: Design
rules and usability
requirements
Dr. Andres Baravalle
1

2. Interaction design
• The next slides are based on "Interaction
Design – Measuring the user interaction"
• By the end of this week, you should have
studied all chapters of the textbook up to
chapter 8!
2

3. Outline
• Design rules
• Interaction design
• Requirements: introduction
• Requirements elicitation
• Requirements specification
• Hierarchical Task Analysis
3

4. Design rules
4

5. Design rules: principles,
standards and guidelines
5

6. Design rules: principles,
standards and guidelines
• Design rules are mechanism to restrict the
domain of design options
– Usability-related principles, standards and guidelines
support the developer
• Principles
– General understanding of design as a subject area
• Standards and guidelines
– Direction for design
• Design patterns
– Capture and reuse design knowledge

7. Types of design rules
• Design rules differ in generality and authority
• Principles
– Abstract design rules
– Low authority
– High generality
• Standards
– Specific design rules
– High authority
– Limited application
• Heuristics and guidelines
– Lower authority
– More general application
increasing authority
increasinggenerality
Standards
Guidelines
increasing authority
increasinggenerality

8. Principles to support usability
• Learnability
– The ease with which new users can begin effective
interaction and achieve maximal performance
• Flexibility
– The multiplicity of ways the user and system
exchange information
• Robustness
– The level of support provided the user in determining
successful achievement and assessment of goal-
directed behaviour

9. Principles of learnability (2)
• Predictability
– Determining effect of future actions based on
past interaction history
• Synthesizability
– Assessing the effect of past actions
– Immediate vs. eventual honesty

10. Principles of learnability (3)
• Familiarity
– How prior knowledge applies to new system
• Generalizability
– Extending specific interaction knowledge to
new situations
• Consistency
– Likeness in input/output behaviour arising
from similar situations or task objectives

11. Principles of flexibility
• Dialogue initiative
– Freedom from system imposed constraints on input
dialogue
• Multithreading
– Ability of system to support user interaction for more
than one task at a time
– Concurrent vs. interleaving; multimodality
• Task migrability
– Passing responsibility for task execution between
user and system

12. Principles of flexibility (2)
• Substitutivity
– Allowing equivalent values of input and output
to be substituted for each other (e.g. text and
audio)
– Representation multiplicity
• Customizability
– Modifiability of the user interface by user
(adaptability) or system (adaptativity)

13. Principles of robustness
• Observability
– Ability of user to evaluate the internal state of
the system from its perceivable representation
• Recoverability
– Ability of user to take corrective action once
an error has been recognized
– Reachability; forward/backward recovery;
commensurate effort

14. Principles of robustness (2)
• Responsiveness
– How the user perceives the rate of
communication with the system
• Task conformance
– Degree to which system services support all
of the user's tasks
– Task completeness; task adequacy

15. Standards
• Set by national or international bodies to
ensure compliance by a large community
of designers standards require sound
underlying theory and slowly changing
technology
• Examples include:
– W3C HTML and CSS standards
– ISO 6385:2004: Ergonomic principles in the
design of work systems

16. Guidelines and heuristics
• Guidelines are detailed rules for design,
often platform or task-specific
• (Usability) heuristics are principles and
rules of thumb that govern the overall
design approach
– Many textbooks and reports are full of
guidelines and heuristics
– Understanding justification for guidelines
aids in resolving conflicts

17. Heuristic collection
• Nielsen’s 10 Heuristics (see Chapter 9 of
Dix et al)
• Shneiderman’s 8 Golden Rules
• Norman’s 7 Principles

18. Nielsen’s heuristics
• Developed by Jacob Nielsen in the early
1990s.
– Based on heuristics distilled from an empirical
analysis of 249 usability problems.
– The heuristics have been revised for current
technology
18

19. Neilsen’s heuristics
• Visibility of system status:
The system should always keep users informed about what is going
on, through appropriate feedback within reasonable time.
• Match between system and the real world:
The system should speak the user's language, with words, phrases
and concepts familiar to the user, rather than system-oriented terms.
Follow real-world conventions, making information appear in a
natural and logical order.
• User control and freedom:
Users often choose system functions by mistake and will need a
clearly marked "emergency exit" to leave the unwanted state without
having to go through an extended dialogue. Support undo and redo.
• Consistency and standards:
Users should not have to wonder whether different words,
situations, or actions mean the same thing. Follow platform
conventions.

20. Neilsen’s heuristics (2)
• 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.
• Recognition rather than recall:
Minimize the user's memory load by making 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.
• 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.

21. Neilsen’s heuristics (3)
• 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.
• 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.
• Help and documentation:
Even though it is better if the system can be used without
documentation, it may be necessary to provide help and
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.

22. Shneiderman’s 8 Golden Rules
1. Strive for consistency
2. Enable frequent users to use shortcuts
3. Offer informative feedback
4. Design dialogs to yield closure
5. Offer error prevention and simple error handling
6. Permit easy reversal of actions
7. Support internal locus of control
8. Reduce short-term memory load

23. Norman’s 7 Principles
1. Use both knowledge in the world and
knowledge in the head
2. Simplify the structure of tasks
3. Make things visible
4. Get the mappings right
5. Exploit the power of constraints, both natural
and artificial
6. Design for error
7. When all else fails, standardise

24. Interaction design
24

25. 25
What is Interaction Design?
• It is a process:
– A goal-directed problem solving activity
informed by intended use, target domain,
materials, cost, and feasibility
– A creative activity
– A decision-making activity to balance trade-
offs
• Four approaches: user-centered design,
activity-centered design, systems
design, and genius design

26. What is a user-centered
approach?
• User-centered approach is based on:
– Early focus on users and tasks: directly studying
user characteristics (cognitive, behavioural,
anthropomorphic & attitudinal) and the task for which
we are designing a system
– Empirical measurement: users’ reactions and
performance to scenarios, manuals, simulations &
prototypes are observed, recorded and analysed
– Iterative design: when problems are found in user
testing, fix them and carry out more tests
26

27. 27
Importance of involving users
• Expectation management
– Realistic expectations
– No surprises, no disappointments
– Timely training
– Communication, but no hype
• Ownership
– Make the users active stakeholders
– More likely to forgive or accept problems
– Can make a big difference to acceptance and
success of product

28. 28
Degrees of user involvement
• Member of the design team
– Full time: constant input, but lose touch with
users
– Part time: patchy input, and very stressful
– Short term: inconsistent across project life
– Long term: consistent, but lose touch with users
• Dissemination devices, as newsletters
– Reach wider selection of users
– Need communication both ways
• User involvement after product is released
• Combination of these approaches

29. Interaction design activities
• Interaction design activities should be
iterative:
– Establishing requirements
– Prototyping
– Evaluating the prototypes
29

30. Used-centered design questions
• Who are the users?
• What do we mean by ‘needs’?
• How to generate alternatives?
• How to choose among alternatives?
• How to integrate interaction design
activities with other models?
30

31. Who are the stakeholders?
• Not as obvious as you think:
– Those who interact directly with the product
– Those who manage direct users
– Those who receive output from the product
– Those who make the purchasing decision
– Those who use competitor’s products
should be also considered!
31

32. Who are the stakeholders? (2)
• Three categories of stakeholders (Eason,
1987):
– Primary users: frequent hands-on
– Secondary users: occasional or via
someone else
– Tertiary users: affected by its introduction, or
will influence its purchase
32

33. What do we mean by ‘needs’?
• Users rarely know what is possible
• Users (typically) can’t tell you what they ‘need’ to help
them achieve their goals
• Instead, look at existing tasks:
– Their context
– What information they require
– Who collaborates to achieve the task
– Why is the task achieved the way it is
• Envisioned tasks:
– Can be rooted in existing behaviour
– Can be described as future scenarios
33

34. How to generate alternatives?
• Humans stick to what they know works
– Considering alternatives is important to ‘break
out of the box’
• Designers are trained to consider alternatives,
software developers generally are not
• How do you generate alternatives?
– ‘Flair and creativity’: research and synthesis
– Seek inspiration: look at similar products or look at
very different products
34

35. How to choose among
alternatives?
• Evaluation with users or with peers, e.g.
prototypes
• Technical feasibility: some are not possible
• Quality thresholds: usability goals lead to
usability criteria set early on and check regularly
– e.g.:
– Utility: which functions are superfluous?
– Effectiveness: appropriate support? task coverage,
information available
– Efficiency: performance measurements
35

36. 36
How to choose among
alternatives
Test the alternatives!

37. How to integrate interaction
design in other models?
• Agile software development is one option:
– Have development and design running in
separate tracks
– Maintain a coherent vision of the interface
architecture
37

38. Requirements: introduction
38

39. Requirements: what?
39
1. Understand as much as possible
about users, task, context
2. Produce a stable set of
requirements

40. Requirements: how?
• Requirements are often collected in an
iterative way:
– Elicitation (also known as gathering or
collection)
– Specification
– Analysis & negotiation
• Prioritization
• Selection
• Validation (are the req. correct, are these the
correct requirements)
40

41. Requirements: why?
• Getting requirements right is crucial
– Requirement definition is the stage
where most failures are rooted
41

42. 42

43. Software Requirements
Specification
• According to IEEE 830-1998, a software
requirement specification (SRS) is a
specification for a particular software
product, program, or set of programs that
performs certain functions in a specific
environment.
43

44. Requirement types
• IEEE 830-1998 organises requirements in
the following categories:
– Functional
– External interfaces
– Performance
– Attributes
– Design constraints
44

45. Functional requirements
• Functional
– What is the software supposed to do?
45

46. Non functional requirements
• External interfaces
– How does the software interact with people, the system os
hardware, other hardware, and other software?
• Performance
– What is the speed, availability, response time etc.?
• Attributes
– What are the portability, correctness, maintainability,
security, etc. considerations?
• Design constraints imposed on an implementation.
– e.g. by standards or legislation
46

47. Functional vs non functional
requirements
• Usability engineering focuses on non-
functional requirements
47

48. 48
An extreme example

49. Requirements elicitation
49

50. Requirements elicitation
• “…the process of discovering the
requirements for a system by
communication with customers, system
users and other who have a stake in the
system development.” (Ian Sommerville)
50

51. Elicitation techniques
• In the next slides we are going to look at the most
common requirements elicitation techniques that are
used in usability engineering:
– Interviews
– Group interviews
– Observation
– Task demonstrations
– Questionnaires
– Brainstorming
– Studying documentation
– Researching similar products
51

52. Elicitation techniques (2)
• The techniques used are not dissimilar from the data
collection techniques that we have seen for the past
weeks
• We are just going to focus on their suitability for
requirements collection
52

53. Interviews and observation
• Interviews
– + Getting to know the present (domain, problems) and ideas for
future systems
– - Hard to see the goals and critical issues, subjective
– - Time consuming and may be infeasible to visit
everyone
• Observation
– Look at how people actually perform a task (or a combination of tasks) –
record and review
– + Map current work, practices, processes
– - Critical issues seldom captured (e.g. you have to be observing when
something goes wrong), usability issues seldom captured, time
consuming
53

54. Group interviews and
brainstorming
• Group interviews and focus groups
– + Stimulate each other, complete each other
– + Good at gaining a consensus view and/or highlighting areas of
conflict
– - Censorship, domination (some people may not get attention)
• Brainstorming
– Gathering of stakeholders and the exchange/gathering of ideas
in an open atmosphere where no one risks being ridiculed for
their ideas and no ideas are rejected/criticized
– + Many ideas (none are rejected)
– - Many ideas (have to be sorted and prioritized), hard to create a
good atmosphere, hard to get everybody involved, small groups,
time consuming
54

55. Task demonstrations and
prototyping
• Task demonstrations
– Ask a user to perform a task and observe and study what is
done, asking questions
– + Clarify what is done and how, current work
– - Your presence and questions may influence the user, critical
issues seldom captured, usability problems hard to capture
• Prototyping
– + Visualization, stimulate ideas, usability centered, (can be
combined with e.g. use cases)
– - Solution oriented (premature design), “is it already done?!”
55

56. Questionnaires
• Often used in conjunction with other techniques
• Can give quantitative or qualitative data
• + Gather information from many users (statistical
indications, views, opinions)
• - Difficult to construct good questionnaires,
questions often interpreted differently, hard to
classify answers in open questions and closed
questions may be to narrow…
56

57. Use cases and scenarios
• Description of a particular interaction between the (proposed)
system and one or more users (or other terminators, e.g.
another system). A user is walked through the selected
operations and the way in which they would like to interact
with the system is recorded.
– + Concentration on the specific (rather than the general) which can give
greater accuracy
– - Solution oriented (rather than problem oriented), can result in a
premature design of the interface
57

58. Studying documentation
58
•Procedures and rules are often written down in manuals
•+ Good source of data about the steps involved in an
activity, and any regulations governing a task
•+ Good for understanding legislation, and getting
background information
•+ No stakeholder time, which is a limiting factor on the
other techniques
•- Not to be used in isolation

59. Researching similar products
59
• Good for prompting requirements

60. Problems with requirements
elicitation (1)
• Identifying and involving stakeholders
– Availability of key people
• Getting ‘real’ users, not managers:
traditionally a problem in software
engineering
60

61. Problems with requirements
elicitation (2)
• Requirements management: version control,
ownership
• Communication between parties:
– Within development team
– With customer/user
– Between users… different parts of an organisation
use different terminology
• Domain knowledge distributed and implicit:
– Difficult to dig up and understand
– Knowledge articulation: how do you walk?
61

62. Problems with requirements
elicitation (3)
• Political problems within the
organisation
• Dominance of certain stakeholders
• Economic and business environment
changes
• Balancing functional and usability
demands
62

63. Some basic guidelines
63
• Focus on identifying the stakeholders’
needs
• Involve all the stakeholder groups
• Involve more than one representative
from each stakeholder group
• Use a combination of data gathering
techniques

64. Some basic guidelines (2)
64
• Support the process with props such as
prototypes and task descriptions
• Run a pilot session!
• You will need to compromise on the data you
collect and the analysis to be done, but before
you can make sensible compromises, you need
to know what you’d really like
• Consider carefully how to record the data

65. Data interpretation and analysis
65
• Start soon after data gathering
session
• Initial interpretation before deeper
analysis
• Different approaches emphasize different
elements e.g. class diagrams for object-
oriented systems, entity-relationship diagrams
for data intensive systems

66. Requirements specification
66

67. Establishing requirements
• Requirements typically need
clarification, refinement, completion,
re-scoping
– Input: requirements document
– Output: stable requirements
67

68. Level of detail
• The level of detail can vary:
– One sentence
– One paragraph
– A figure
– Unstructured or structured
– A table or matrix
– A legal document
– A design document
– A formal specification
68

69. Requirement specification
techniques
• A number of requirement specification
techniques are in use
• We are going to see Volere shells, user
stories and personas
69

70. Requirements specification:
Volere shells and user stories
• The Volere shells provide "template […]
sections for each of the requirements
types appropriate to today's software
systems"
70

71. 71
Volere shell

72. Volere requirements template
72

73. User stories
• A user story is a short description of a
feature that has a clear value to a user.
• User stories represent the
requirements from the point of view of
the user, not the developer.
– They don’t fully describe design details.
73

74. User stories: template
• User stories follow a template determined
together by the team and stakeholders.
• User stories are typically written with the
following template :
– As <an actor> I would like to <action> so
that <achievement>
74

75. User stories: template (2)
• Actor: A customer type who benefits from
this story
• Action: The goal of the story. This is a
feature or function
• Achievement: The benefit to the customer
or user when this feature or function is
used.
– This is optional ant it’s typically left out when
the reason is apparent.
75

76. Personas (stereotypes)
• Capture user characteristics
– Not real people, but synthesised from real
user characteristics
– Should not be idealised
– Bring them to life with a name, characteristics,
goals, personal background
• Develop multiple personas
76

77. Personas
77

78. Developing personas: who are
your users?
78
• Characteristics:
– Ability, background, attitude to computers
• System use: novice, expert, casual, frequent
– Novice: step-by-step (prompted), constrained, clear
information
– Expert: flexibility, access/power
– Frequent: short cuts
– Casual/infrequent: clear instructions, e.g. menu paths

79. Developing personas: what are
the users’ capabilities?
• Humans vary in many dimensions:
– Size of hands may affect the size and positioning of
input buttons
– Motor abilities may affect the suitability of certain input
and output devices
– Height, if designing a physical kiosk
– Strength - a child’s toy requires little strength to
operate, but greater strength to change batteries
– Disabilities (e.g. sight, hearing, dexterity)
79

80. More on personas?
• Read this article in the MSDN web site:
– Kreitzberg, C. B. and Little, A. (2009) The
Power of Personas. Available from:
http://msdn.microsoft.com/en-us/magazine/dd5697
80

81. Hierarchical Task Analysis
81

82. Working with UI designers
• User interface designers need to have
enough data to work
• Requirements tell the UI designer what the
application will do
– How are the tasks organised?
• You can use different notations, including
scenarios
82

83. Task descriptions
83
• Scenarios
― An informal narrative story, simple, ‘natural’,
personal, not generalisable
• Use cases
— Assume interaction with a system
— Assume detailed understanding of the
interaction
• Essential use cases
— Abstract away from the details
— Does not have the same assumptions as use
cases

84. Task analysis
• Task descriptions are often used to envision new
systems or devices
• Task analysis is used to investigate an existing situation
or to specify the requirements for a software
• It is important not to focus on superficial activities
– What are people trying to achieve?
– Why are they trying to achieve it?
– How are they going about it?
• Many techniques, the most popular is Hierarchical
Task Analysis (HTA)
84

85. Hierarchical Task Analysis
• Involves breaking a task down into subtasks,
then sub-sub-tasks and so on. These are
grouped as plans which specify how the tasks
might be performed in practice
– HTA focuses on physical and observable actions, and
includes looking at actions not related to software or
an interaction device
– Start with a user goal which is examined and the main
tasks for achieving it are identified
– Tasks are sub-divided into sub-tasks
85

86. Breakdown of tasks and plan
• Your HTA must include both a breakdown
of tasks and a plan.
• There are alternative techniques to
represent HTAs (textual and graphical;
see the textbook for more)
86

87. HTA examples
• We are now going to look at 3 HTA
examples:
– Example 1: Buying a DVD from a shop
– Example 2: Withdrawing cash from an ATM
– Example 3: Using Outlook Web Access to
send an email
87

88. 88
Example 1: buying a DVD
0. In order to buy a DVD
1. locate DVD
2. add DVD to shopping basket
3. enter payment details
4. complete address
5. confirm order
plan 0: If regular user do 1-2-5.
If new user do 1-2-3-4-5.

89. 89
Example 1: graphical notation

90. Example 2: withdrawing cash
from an ATM
• Withdrawing cash from an ATM requires
tasks from the user...
• What are those tasks?
90

91. Breakdown of tasks
0 Withdraw cash
1. Check machine will work
1. 1.1 Look at status indicator
2. 1.2 Look for card logo
2. Insert card
3. Enter PIN number
4. Initiate withdrawal transaction
1. 4.1 Select withdraw cash
2. 4.2 Enter amount
5. Complete transaction
1. 5.1 Take card
2. 5.2 Take cash
91

92. Adding plans
• Hierarchical diagram / text specifies what
subtasks are part of a task
– Does not specify how the subtasks are carried
out
• Plans are used to describe
– Order of subtasks
– Conditional or optional subtasks
– Repetition
– etc.
92

93. Plans
• A plan is needed for each decomposed
task
– Plan 0: do 1; if possible do 2; repeat 3 until
PIN correctly entered; do 4; do 5.
– Plan 1: do 1.1, 1.2 in any order
– Plan 4: do 4.1; do 4.2
– Plan 5: wait until card available; do 5.1; wait
until cash available; do 5.2
93

94. Example 3: filing cabinet
• You probably act differently if you have a
lot of documents to file rather than a few...
– 0. Store documents in filing cabinet
– 1. File lots of documents
– 2. File one or two documents
– Plan 0: Do 1 or 2
94

95. Filing one or two things
• Simply find the appropriate folder and put
the documents in...
– 2. File one or two documents
– 2.1. Open cabinet
– 2.2. File each document
– 2.3. Close cabinet
– Plan 2: Do 2.1., (2.2. repeatedly) then 2.3.
95

96. Filing each document
• 2.2. File each document
• 2.2.1. Find appropriate file
• 2.2.2. Open file
• 2.2.3. Place document in file
• 2.2.4. Close file
• Plan 2.2: Do 2.2.1, 2.2.2., 2.2.3., then
2.2.4.
96

97. Filing lots of documents
• Sort the documents into order first
• Then split the sorted documents up into
‘categories’ (ie all the documents whose
author begins with ‘A’)
• Then work through the filing cabinet,
putting each category into the right file
97

98. Filing lots of documents
• 1. File lots of documents
– 1.1. Choose criteria on which documents
are sorted
– 1.2. Sort all documents to be filed into order
– 1.3. Split documents up into categories
– 1.4. Open cabinet
– 1.5. Place each category of document into
file
– 1.6. Close cabinet
• Plan 1: Do 1.1., 1.2., 1.3., 1.4., (1.5.98

99. Choosing sorting criteria
• 1.1. Choose criteria on which
documents are sorted
– 1.1.1.Choose alphabetical by title of
document
– 1.1.2.Choose alphabetical by author of
document
– 1.1.3.Choose date order
• Plan 1.1: Do any one of 1.1.1., 1.1.2.,
or 1.1.3.
99

100. Placing categories in files
• 1.5. Place each category of document
into file
– 1.5.1.Open file
– 1.5.2.Place each document in file
– 1.5.3.Close file
• Plan 1.5: Do 1.5.1., (1.5.2. repeatedly)
then 1.5.3.
100