Review
• Intro- HCI / Interaction Design• History of HCI• Design Life Cycle – Bin-IT case study• Design Principals – Don Norman• User Centered Design• Evaluation - Assignment
What is Design?
Simply put, its
Achieving Goals within Constraints
It is your job to figure out what the goals are, and what the constraints are….
Imagine you want to build a wireless personal DVD player…
Goals
Who is it for?
Why do they want it?
What is it for?
Where will they use it?
When will they use it?
Imagine you want to build a wireless personal DVD player…
Constraints
How does user interact with it?
What materials are used?
What standards must be adopted?
Do we need to build in copyright protection?
eg
Sharing the view of the DVD on the monitor is a goal……
Eye mounted display is the most stable while walking,
stability is a constraint……
You might decide that sharing is a priority, while walking around busy streets watching video might be too distracting to be safe..
How to establish the Goals and Constraints.
Observe, talk to, interview, collaborate with, involve, ASK, THE END USER.
Who are the USERS / 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
• Three categories of user— primary: frequent hands-on
— secondary: occasional or via someone else
— tertiary: affected by its introduction, or will influence its purchase
W h o a r e t h e s t a k e h o ld e r s ?C h e c k - o u t o p e r a t o r s
C u s t o m e r sM a n a g e r s a n d o w n e r s
• S u p p l i e r s• L o c a l s h o p
o w n e r s
Rem tutorial question, who are the ‘Stakeholders’ at a club???
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)
How to establish the Goals and Constraints.
Observe, talk to, interview, collaborate with, involve, ASK, THE END USER.
This can be difficult..
• Users rarely know what is possible
• Users can’t tell you what they ‘need’ to help them achieve their goals
Instead, study/observe existing tasks:
– their context
– what information do they require?
– who collaborates to achieve the task?
– why is the task achieved the way it is?
Rem – observation
interviews
questionaires
focus groups
Also….
Use tools to help get the information
A research team matches the appropriate methods for gathering user information with,
• the people they are designing for • the environment/context they are
designing for • and the product they are
designing.
Evaluate
(Re)DesignPrototype
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Final product
Data Gathering
Facing Problems• Identifying and involving stakeholders:
users, managers, developers, customer reps?, union reps?, shareholders?
• Involving stakeholders: workshops, interviews, workplace studies, co-op stakeholders onto the development team
• ‘Real’ users, not managers:traditionally a problem in software engineering, but better now
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Facing Problems • 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?• Availability of key people
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Facing Problems
• Political problems within the organisation
• Dominance of certain stakeholders
• Economic and business environment changes
• Balancing functional and usability demands
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Some basic guidelines
• 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
techniquesIdentify needs/ Identify needs/
establish establish requirementsrequirements
Some Basic Guidelines
• 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 dataIdentify needs/ Identify needs/
establish establish requirementsrequirements
Data Interpretation and Analysis
• Start soon after data gathering session
• Initial interpretation before deeper analysis
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Task descriptions
• Scenariosan informal narrative story, simple,
‘natural’, personal, not generalisable
• Use cases—assumes interaction with a system—assumes detailed understanding of
the interaction
• Essential use cases—abstract away from the details—does not have the same
assumptions as use cases
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Scenario for Shared Calender
“The user types in all the names of the meeting
participants together with some constraints such as
the length of the meeting, roughly when the meeting
needs to take place, and possibly where it needs to
take place. The system then checks against the
individuals’ calendars and the central departmental
calendar and presents the user with a series of dates
on which everyone is free all at the same time. Then
the meeting could be confirmed and written into
people’s calendars. Some people, though, will want to
be asked before the calendar entry is made. Perhaps
the system could email them automatically and ask
that it be confirmed before it is written in.”Identify needs/ Identify needs/
establish establish requirementsrequirements
Use case for a Shared Calendar
1. The user chooses the option to arrange a meeting.2. The system prompts user for the names of
attendees.3. The user types in a list of names.4. The system checks that the list is valid.5. The system prompts the user for meeting
constraints.6. The user types in meeting constraints.7. The system searches the calendars for a date that
satisfies the constraints. 8. The system displays a list of potential dates.9. The user chooses one of the dates.10. The system writes the meeting into the calendar.11. The system emails all the meeting participants
informing them of them appointment
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Some alternative courses:
5. If the list of people is invalid,5.1 The system displays an error
message.5.2 The system returns to step 2.
8. If no potential dates are found,8.1 The system displays a
suitable message.8.2 The system returns to step 5.
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Example use case diagram for shared calendar
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Administrator Departmentalmember
Arrange ameeting
Update calendarentry
Retrievecontact details
arrangeMeeting
USER INTENTION SYSTEM RESPONSIBILITYarrange a meeting
request meeting
attendees & constraints
identify meeting attendees & constraints
search calendars for suitable dates suggest potential
dates
choose preferred datebook meeting
Task Analysis
• Task descriptions are often used to envision new systems or devices
• Task analysis is used mainly to investigate an existing situation
• 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)
Identify needs/ Identify needs/ establish establish
requirementsrequirements
HTA• 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
Identify needs/ Identify needs/ establish establish
requirementsrequirements
HTA example
0. In order to borrow a book from the library 1. go to the library 2. find the required book
2.1 access library catalogue2.2 access the search screen2.3 enter search criteria2.4 identify required book 2.5 note location
3. go to correct shelf and retrieve book4. take book to checkout counter
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Borrow a book from the library
go to the library
find required book
retrieve book from shelf
take book to counter
321 4
0
access catalog
access search screen
enter search criteria
identify required book
note location
plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4.
plan 2: do 2.1-2.4-2.5.If book not identified from information available, do 2.2-2.3-2.4-2.5
2.1 2.2 2.3 2.4 2.5
Graphical HTA
SUMMARY• Getting requirements right is crucial
• There are different kinds of requirement, each is significant for interaction design
• The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups and workshops, naturalistic observation, studying documentation
• Scenarios, use cases and essential use cases can be used to articulate existing and envisioned work practices.
• Task analysis techniques such as HTA help to investigate existing systems and practices
Identify needs/ Identify needs/ establish establish
requirementsrequirements
(Re)DesignPrototype
Evaluate
(Re)DesignPrototype
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Final product
Write a Design Brief using the requirements established…
- Who?- Why?- What?- Where?- When?- How?
A design breif will state the goals, the constraints and the trade-offs…
(Re)DesignPrototype
– we did not have to consider the actual iron or, fork to see the design flaws, we only considered pictures of them
– prototyping is concerned with the design process leading up to production of the final system
– our prototypes are not the final system, but representations of it
– we talk about the fidelity of user interface prototypes
The low fidelity - high fidelity continuum…
(Re)DesignPrototype
Why Prototype
LOW FIDELITY PROTOTYPESPurpose
• depict concepts• present design alternatives• suggest screen layouts/interface
affordances• enable rapid development and revision of
designs• demonstrate general look and feel of
UI/object• iron out usability issues as early as
possible(Re)DesignPrototype
LOW FIDELITY PROTOTYPES
Form
• simple, normally pencil and paper
• non-functional
(Re)DesignPrototype
LOW FIDELITY PROTOTYPES
Use
• design team can reason about the design
• can be presented to sample users, although require a facilitator
(Re)DesignPrototype
LOW FIDELITY PROTOTYPES
– storyboards present sequences of activity in the interface
– they indicate the flow from one state or screen to the next
– to begin with they may not include much detail of the interface
(Re)DesignPrototype
– this example gives an overview of the layout
without any detail - a good starting point
– numerous alternatives can be quickly created without worrying about details
– should be produced in pencil (easily changed)
– should be hand-drawn (rulers take too much effort)
(Re)DesignPrototype
– it might be tempting to draw more 'tidy' pictures like this example
– but it's difficult to change, even if in a drawing package
– and there is no benefit over the hand-drawn sketches
– it is highly unlikely that the first (or 2nd, 3rd or 4th) designs will be completely correct
– but if they are hard to amend, they won't be amended
(Re)DesignPrototype
– once you are happy with your overview of the layout
– (for multiple windows/dialogues) if necessary
– you can start to focus on details of the design
– such as example data values, menu content, buttons, labels etc
– and more specific arrangement of interface objects
(Re)DesignPrototype
– once you are happy with those details you can create your interface 'toolkit'
– by cutting out each of the components into its own 'window'
– e.g. windows, dialogues, menus etc
– these can be used to dynamically simulate the interface
– following the storyboard
– perhaps with users in an evaluation
(Re)DesignPrototype
Advantages• low development cost• can evaluate multiple design concepts
quickly• useful communication device• good for considering screen layout issues• and user navigation through the interface
Disadvantages• not detailed enough to implement from• need to be facilitated when presented to
users• do not address issues that arise from
implementation
(Re)DesignPrototype
Low fidelity prototypes….more
Low fidelity prototyes can be simply stories that explain how a user interacts with an imaginary interface…in narrative form.
Called ‘Scenario-Based Design’
(Re)DesignPrototype
Low fidelity prototypes
Low fidelity prototypes can be used in co-design sessions with end users to extract requirements…..
(Re)DesignPrototype
Medium fidelity prototypes
– provide a development path from the 'rough' low-fidelity prototypes
– can provide more sophisticated simulations for users to try out
– normally only for some of the system's features that need particular attention
Disadvantages
• users need to realise that they aren't the final versions
• …to get correct level of critique
• can set focus on small details rather than larger flaws
(Re)DesignPrototype
Medium fidelity prototypes
– Wizard of Oz prototyping is a useful prototyping technique
(Re)DesignPrototype
(Re)DesignPrototype
IDEO TECH BOX
•Library, database, website - all-in-one
•Contains physical gizmos for inspiration
High fidelity prototypes
– have functionality and are interactive– may be programmed (e.g. Visual Basic) or
created in a tool such as Macromedia Director
Advantages• user-driven• provide look and feel• can be used as a specification for final
implementationDisadvantages• expensive and time-consuming to develop• not good for gathering requirements• or for proof-of-concept designs
(Re)DesignPrototype
How to choose which Prototype• Evaluation with users or with peers, e.g.
prototypes• Technical feasibility: some not possible• Quality thresholds: Usability goals lead to
usability criteria set early on and check regularly
—safety: how safe?—utility: which functions are
superfluous?
—effectiveness: appropriate support? task coverage, information available
—efficiency: performance measurements
(Re)DesignPrototype
Evaluate
(Re)DesignPrototype
Identify needs/ Identify needs/ establish establish
requirementsrequirements
Final product