1. CS2003 Usability Engineering
Principles, requirements & prototyping
Jane Coughlan

2. The New Computing
The old computing is about what computers can do; the new computing is about what people can do.
The New Computing movement stems from the book "Leonardo's Laptop: Human Needs and the New Computing Technologies" by Ben Shneiderman (MIT Press, summer 2002) as a result of research initiatives from the Human-Computer Interaction Lab at the University of Maryland (e.g., studies of user frustration).
Successful technologies are those that are truly useful and therefore in harmony with users' needs. They must support relationships and activities that enrich the users' experiences.

3. What is NEW Computing ... ... Usable
Users’ experience with information and computing technology could be dramatically better. It’s time to get angry about the quality of our computing environments: too many crashes, too many confusing designs, too many frustrations. We need to pressure software, hardware, and network developers to work together to develop more reliable and comprehensible products.

4. Too many people find computers frustrating
What do users want – what’s most important to them?
Trust?
Privacy?
Reliability?
Security?
Simplicity?
Ease?
Etc. Etc.

5. New Computing is also ... ... Universal
The New Computing is also about empowerment for everyone. Effective designs should be usable by every one: young and old, novice and expert, well and poorly educated, owners of new and older computers, speakers of English and other languages. Universal designs can improve the quality for all users.

6. Universal Usability
UU has been linked to meeting needs of disabled users.
Likely to meet and benefit the needs of all users so it is a democratic endeavour.
If we adapt for users with diverse physical, visual, auditory or cognitive disabilities we are likely to benefit users with different preferences, tasks, skills, hardware.
EXAMPLE:
Think of curb-cuts – are they just for wheelchairs?
If it was a technology feature it would make good business sense and create mass appeal

7. New Computing is ... ... Useful
The New Computing is about enabling users to concentrate on their personal needs and support their relationships with others. Users appreciate information and communication technologies most when they experience a sense of safety, mastery, and accomplishment. The New Computing technologies will enable users to accomplish their tasks and to relax, enjoy, and explore.

8. User-centred design
Design philosophy and process where needs, wants, and limitations of users are given extensive attention at each stage of the design process.
Below an example of the process as associated research methods at every stage

9. User-centred design Consistency - invisible
Predictability – familiar (creates confidence)
Metaphors – shopping basket
Controllable – you can do what *you* want
We recognise and value GOOD design
Example: e-business is tied to interface design improvements e.g., more ticket sales
Think of how do we use technology?
-Support relationships with family/friends
-Teach/learn
-Shop
-Gather info, communicate, collaborate, distribute ideas
We are not particularly interested in the technology, we are more interested in our own information needs and relationships.

10. The User Experience
User experience – refers to how a product behaves and is used by people in the real world and applies to all products (from mobile phone to your jumper).
Also refers to how people feel about their product and their pleasure and satisfaction when looking/holding it etc to achieve that overall impression.
Remember it is about designing for a user experience – i.e., you can create the design features that can evoke it.
Apple – have they got it right?
Does the iphone/ipod/ipad create a quality user experience?
How realistic is it for designers to take all the user experience factors into account? (e.g., usability, functionality, aesthetics, content, look and feel, emotional appeal).

11. User Experience goals Satisfying - aesthetically pleasing
Enjoyable - fun
Engaging - supportive of creativity
Pleasurable - enhancing sociability
Exciting - emotionally fulfilling
Entertaining - stimulating
Helpful
Motivating

12. Usability Efficiency – how much effort to complete tasks? E.g., time
Effectiveness – can users do what they want to do?
Satisfaction – ease of use?
Dependent on:
Users - who is using the product? e.g. experts or novices?
Goals - what are the users trying to do?
Context - where and how is the product being used?

13. Relationship between user experience and usability
Flow is an important concept for informing the design of user experiences.
Refers to an intense emotional involvement that comes from being completely involved in an activity such as a restaurant meal.
"the holistic experience that people feel when they act with total involvement" (Csikszentmihalyi, 1975: 36)
REF: Csikszentmihalyi, M. (1975), Beyond Boredom and Anxiety, Jossey-Bass, San Francisco, CA.

14. Constituent elements of the flow experience
challenge & curiosity
an activity should trigger curiosity and allow the learner at the same time to formulate goals, while preserving some element of surprise regarding the outcome.
control
Providing levels to play (in gaming), technical difficulties in project, some liberty to select goals strategies & tactics
fantasy
imagination and freedom (make believe + voluntary activity)
feedback
clear and immediate feedback should be provided if the goal or not has been reached.
self-esteem
tasks should be adapted (see above) and encouragement to learn & augment results should be provided.

15. Emotion
Positive correlations between aesthetics and usability has led some such as Don Norman to change way of thinking.
The good looking ATM example
Three levels of emotion for design
Visceral – look, feel, sound (appearance)
Behavioural – use (pleasure and effectiveness)
Reflective – impression (self and personal satisfaction)

16. Emotion
A way of thinking about technology as a vehicle for emotions rather than for function and make more considered design decisions.
Reference: Norman, D.A Emotional Design. Basic Books. New York.

17. Screen design and layout
Seminal work of Norman (1988)
Constraints
making use of properties to tell users what they can and cannot do
Mappings
making links clear and obvious
Visibility
making clear what is happening
Consistency
making things work in the same way at different times
Experience
making use of what users know
Affordance
making use of the properties of items to suggest use
Simplicity
making tasks as simple as possible
SOURCE: Norman, D. (1988). The Psychology of Everyday Things. Basic Books, New York.

18. Norman - a design should…...
make sure users can
figure out what to do
tell what is going on
if user asks:
“how am I going to remember that”, the design has failed
Several steps to achieve this…
method
use KITH / KITW
simplify the structure of tasks (velcro shoe ties)
make things visible (bridge ex/eval gulfs)
get the mappings right
exploit constraints
design for error
- if all else fails - standardise!

19. Norman’s 7 UCD design principles
Use both knowledge in the world and knowledge in the head
Simplify the structure of tasks
Make things visible
Get the mapping right
Exploit the power of constraints, both natural and artificial
Design for error
When all else fails, standardise
recognition
vs.
recall

20. Norman’s 7 UCD design principles
Use both knowledge in the world and knowledge in the head
Simplify the structure of tasks
Make things visible
Get the mapping right
Exploit the power of constraints, both natural and artificial
Design for error
When all else fails, standardise
Shoelace
Velcro

21. Norman’s 7 UCD design principles
Use both knowledge in the world and knowledge in the head
Simplify the structure of tasks
Make things visible
Get the mapping right
Exploit the power of constraints, both natural and artificial
Design for error
When all else fails, standardise
Electric Showers

22. Norman’s 7 UCD design principles
Use both knowledge in the world and knowledge in the head
Simplify the structure of tasks
Make things visible
Get the mapping right
Exploit the power of constraints, both natural and artificial
Design for error
When all else fails, standardise ?

23. Norman’s 7 UCD design principles
Use both knowledge in the world and knowledge in the head
Simplify the structure of tasks
Make things visible
Get the mapping right
Exploit the power of constraints, both natural and artificial
Design for error
When all else fails, standardise
Door open, microwave off

24. Norman’s 7 UCD design principles
Use both knowledge in the world and knowledge in the head
Simplify the structure of tasks
Make things visible
Get the mapping right
Exploit the power of constraints, both natural and artificial
Design for error
When all else fails, standardise

25. Norman’s 7 UCD design principles
Use both knowledge in the world and knowledge in the head
Simplify the structure of tasks
Make things visible
Get the mapping right
Exploit the power of constraints, both natural and artificial
Design for error
When all else fails, standardise
QWERTY layout Sholes 1880

26. Where do you plug in the mouse? SOURCE: www.baddesigns.com

27. Which way do you go? SOURCE: www.baddesigns.com

28. How do you operate the lift? SOURCE: www.baddesigns.com

29. User requirements what is a requirement?
A statement about an intended product that specifies what it should do and how it should perform.
requirements aren’t usually a ‘given’ factor:
they aren’t always what they initially appear to be, or what designers are told that they are
stakeholder conflicts can arise
some req’s can arise within the design/development phases
expect this and prototype carefully!
Goal is to establish requirements from a process of understanding user needs
Requirements need to be clear and we need to know when they have been fulfilled

30. How to identify requirements
start by asking people, then go looking yourself it need not be a formal process although there are lots of formal approaches to choose from
follow a user-centred approach and use an appropriate form of data collection

31. What does the requirements process look like?
Source:

32. one way: Volere requirements process
5 steps - need to identify the following requirements types (adapted from the Volere Requirements Specification Template):
drivers (the business-related forces)
project constraints (how the eventual product must fit into the world, e.g. interfacing with existing hardware)
functional requirements (fundamental subject matter of the system)
non-functional requirements (behavioural properties that the specified functions must have, such as performance or usability)
project issues (conditions under which the project will be done)
Read Robertson & Robertson (2006) Mastering the Requirements Process

33. The “Volere requirements shell”
Requirement Numbering
Give each requirement a unique identifier to make it traceable throughout the development process. The numbering scheme suggested in the requirement shell is:
Requirement # is the next unique requirement number
Requirement Type is the section number from the template that corresponds to this type of requirement
The inclusion of the section number is not absolutely necessary because each requirement has a unique requirement id. However it serves as a reminder of what this requirement relates to and helps to remind why the requirement is considered important. Also the ability to compare requirements of the same type makes it easier to identify contradictions and duplications.
For example:
A functional requirement is section 9, and the next unique number is 128.
Requirement #: 128 Requirement Type: 9
The product shall record the time when we are notified of a truck breakdown
A performance requirement comes from section 12, and the next unique number is 129.
Requirement #: 129 Requirement Type: 12
The product shall inform truck drivers of their schedule 30 minutes before leaving the depot.
Event/use case #
Event # is the identifier of a Business Event/s whose response (or business use case) has this requirement.
Use Case # is the number of the Product Use Case/s that contain this requirement. There might be several Event/use case #’s for one requirement because the same requirement might relate to a number of events.
The terms business event and use case are already widely used in the systems development world.
The term business event means a business related happening that causes an event-response (or business use case) within the scope of the work that we are studying.
The term event-driven use case (or product use case) means a user-defined (or actor defined) piece of activity within the context of the product. Each product use case is connected to a business event. Business events and product use cases provide a way of grouping business- related requirements and tracing them through into implementation; they are used throughout the Volere development process.
Description
The requirement description is a one sentence summary of the requirement. The most common form of writing the description is:
The product shall do a specific thing for a specific person.
Rationale
The rationale explains why the requirement is considered to be important. The act of writing the rationale often serves as a tool for helping people to discover the real intention and hence the real requirement.
Fit Criterion
This fit criterion is an objective measure of the requirement’s meaning; it is the criterion for evaluating whether or not a given solution fits the requirement.
Customer Value
Customer Value is a measure of how much your client cares about each requirement.
Ask your stakeholders to grade each requirement for Customer Satisfaction on a scale from 1 to 5 where 1 means mild interest if this requirement is satisfactorily implemented, and 5 means they will be very happy if this requirement is satisfactorily implemented
The stakeholders also grade each requirement for Customer Dissatisfaction on a scale from 1 to 5 where 1 means that it hardly matters, and 5 means that they will be extremely displeased if this requirement is not satisfactorily implemented
The point of having a satisfaction and a dissatisfaction rating is that it guides your clients to think of the requirement from two different perspectives, and helps you to uncover what they care about most deeply. Another advantage is that you are managing expectations by reminding your clients that it might be necessary for them to prioritise requirements if you cannot implement all of them.
Dependencies
This keeps track of other requirements that have an impact on this requirement.
If the dependency exists because requirements use the same information, then use of standard naming conventions and definitions (see Section 5) will keep track of this dependency.
Other dependencies exist because a solution to this requirement has a positive or negative effect on solutions to other requirements. Another dependency occurs when the implementation of one requirement cannot be done without the implementation of other requirements. Capture these types of dependencies by cross-referencing the requirements.
Some requirements, especially project drivers and project constraints, have an impact on all the other requirements.
Conflicts
This keeps track of other requirements that disagree with this one. Conflicts that are caused by mistake are solved simply by bringing them to the surface and resolving them. Other conflicts are because of true differences in opinion/intention. These are the conflicts that might eventually need to be addressed using negotiation or mediation techniques. There is nothing wrong with having conflicting requirements providing you know that you have them. Then you are in a position to address the conflict.
History
We follow the requirement from the date that it was created, through all its changes. We minimize future confusion by recording the rationale for making major changes. When a requirement is deleted we record when, and the rationale behind the deletion. The date that the requirement passes its quality checks, and who passed it, is also recorded.

34. Usability requirements typically cover:
Fit criterion – a way of measuring when the solution meets the requirement
Efficiency of use
how quickly or accurately the user can use the product
Ease of remembering
how much should casual users be expected to remember?
Error rates
e.g. it may crucial that the user commits very few, or no, errors.
Overall satisfaction in using the product (e.g., user experience goals)
Feedback
how much feedback does the user need in order to feel confident that it is doing what the user expects
- adapted from Shneiderman (1992)
BUT others could be considered…
Fits with user characteristics (age, experience)
Fits with desired function (product needs to communicate, calculate, monitor x etc)
Fit with environmental context (location, busy etc)
Fit with group norms and practices (what is the context of use?)

35. Examples of usability requirements
Description. e.g.s include:
“The product shall be easy for 11 year-old children to use.”
“The product shall help the user to avoid making mistakes.”
“The product shall make the users want to use it.”
“The product shall be used by people with no training, and possibly no understanding of English.”
‘Fit’ Criterion (may be perhaps over-simplistic!)
[An agreed percentage, say 90%] of a test panel of 11 year olds shall be able to successfully complete [list of tasks] within [specified time]
One month’s use of the product shall result in a total error rate of less than [an agreed percentage, say 2%]
An anonymous survey shall show that [an agreed percentage, say 75%] of the users are regularly using the product after [an agreed time] familiarization period
These must be measurable and objective; users will determine acceptable criteria
note relatively arbitrary criteria (e.g. 70%) - derived from literature, stakeholders and users as what might be acceptable

36. Beyond the requirements specification: prototyping the interactive system
Two approaches:
using a formal specification
developing the specification out of the prototype

37. Why prototype?
design process - ‘involves searching for an acceptable design in an infinitely large design space’
Some requirements are not discovered until the user has the opportunity to use a product
problems - we...
i. may not recognise a good design
ii. may mistakenly think a bad design is good

38. What is a prototype?
Prototype = ‘building a physical working model of all, or part of the proposed system and using it to identify weaknesses in the understanding of the real requirements’
Full-size or to scale
Fully or partially functional
In HCI prototype may be a ‘virtual’ model – a ‘simulation’
Good for involving users in design

39. What do we use prototyping for?
work out details and test them (sometimes impossible to specify in advance)
in ways not possible at level of verbal description
quickly and cheaply build features of interest to try out
although hard to tell what these are
concrete approach
used to show users what inputs, intermediate stages and outputs look like
users can suggest changes...
and see if it does what they want
…and see what is technically feasible
key issues: the “-Ations”
Visualisation (see ideas in concrete form), elicitation (gather ideas from domain experts and users), revelation (uncovering any unanticipated use), communication (to others), evaluation (what works, what doesn’t?), verification (can you build it? Does it work as designed to?)
Requirements gathering feeds into the building, testing, enhancing activities in prototyping
visualisation - see ideas in concrete form
elicitation - ideas from domain experts and users
revelation - reveal the unanticipated
communication - to others
evaluation - what works, what doesn’t and compare designs
verification - can you build it? does it work as designed to?

40. In essence, prototyping provides ...
… continuous feedback on the current design situation
design guidelines will not be applicable in all circumstances
Need not be computer based or have full functionality
Greatly aided by good software tools
Prototyping does NOT mean ‘build in haste’

41. When to prototype? when... forces the designer to visualise all steps
application area is poorly defined
cost of rejection is v. high
final version is essential to be right 1st time
forces the designer to visualise all steps
and how the interface will operate in practice
Early on is best

42. Methods for prototyping
incremental
Prototyping
Section at a time, design is added to
module 1
module 2:
incremental prototype
of prototyping method
types
throw away
requirements animation
Representational (software tools to demonstrate functionality)
rapid
Prototyping
Exploratory EP
evlov
protopy
evolutionary
Prototyping
Gradual, but will not be fixing requirements at an early stage
BEGIN: with reasons for use...
communicating design information to users
evaluation and eliciting novel and information that can feed back into the design process
why use it?
product conceptualisation
task level prototyping
screen design prototyping
requirements animation: various requirements are demonstrated and assessed by users
rapid prototyping: collection info on requirements and adequacy of system. -> product is discarded!
evolutionary: initial designs are gradually changed to meet user requirements - the final design -
BUT problem with design fixing/commitment at an early stage
incremental: large systems installed in phases - requirements and usability issues can be checked as the design is added to

43. Varieties of prototype (and compromises!)
full prototype vs. paper prototype
Complete functionality vs no (real) functionality
horizontal prototype vs. vertical prototype
Breadth (a range of functions with little detail) vs depth (providing a lot of detail for only a few functions)
lo-fi prototype vs. hi-fi prototype (and med-fi!)
Little resemblance to final product (e.g., storyboarding, sketching, index cards) vs. Close resemblance (use of software tools e.g., flash, visual basic).
full prototype vs. paper prototype
Complete functionality (But slower, etc), vs. no (real) functionality
horizontal prototype vs. vertical prototype
wide, no functionality vs. deep functionality in restricted areas
lo-fi prototype vs. hi-fi prototype
close resemblance to final product (marketing love it!) vs. little resemblance (but often cheaper/faster/more appropriate)
chauffeured prototype
Watching another person ‘drive’ the system (does it meet users needs? - without having to assess low level actions)
‘Wizard of Oz’ prototype
another person does the screen movements/transitions: use of a human intermediary/hidden operator… who intercepts commands and applies suitable interpretation:
speech input
facial interpretation (via video)
also used in paper prototyping (visible to participant)
--> permits early, flaky design (and code) to be tested

44. Storyboards Sketching
Often used with scenarios, bringing more detail, and a chance to role play
a series of sketches showing how a user might progress through a task using the device
Used early in design
Identify key events or activities associated with the scenario, how many steps are involved? What are the design issues?
also called interface-flow diagrams, window navigation diagrams, or context-navigation maps
Raises: usability questions
Sketching
Sketching is important to low-fidelity prototyping
Don’t be inhibited about drawing ability
Include things (e.g., people, objects, actions, icons etc)

45. Card-based prototypes
Index cards (3 X 5 inches)
Each card represents one screen or part of screen
Often used in website development
User can step through the cards, pretending to perform the task while interacting with the cards

46. Paper prototyping in action
Prototype web mail service

47. Prototyping to support design
product conceptualisation
allows exploration of alternative designs
what might this system/application/device actually look like or do?
e.g. what might a word processor on a palm sized device look like?
task level prototyping
how suitable the design is at the level of performing users’ tasks
asks how can an individual task be performed - what steps are required?
e.g. how might cut and paste operations be performed?
screen design prototyping
focus on icons, menus and screen layouts
asks what would the screen layouts actually look like, to assess their suitability?
e.g. where are the buttons and widgets going to be placed?

48. Which prototype for what information?
low fidelity
sketches and models focus on the outward appearance and ‘feel’ of the designed system
crudeness means that people focus on the high level concepts
hard to envisage fine interaction details
Good for evaluating design concept and cheap development cost
high fidelity
slow to build
reluctance to change the design - all that hard work!
testers and reviewers tend to focus on fit and finish issues (colour of buttons, etc.) - BAD!
Good for look and feel of final product being fully interactive, but more expensive to develop

49. Reading all HCI books have sections on prototyping
but an excellent one is:
Snyder, C. (2003) Paper prototyping: the fast and easy way to design and refine user interfaces.
Content: very useful insight into and examples of the process of prototyping. A must read if doing paper prototyping.