review intro- hci / interaction design history of hci design life cycle – bin-it case study design...

Review

• Intro- HCI / Interaction Design• History of HCI• Design Life Cycle – Bin-IT case study• Design Principals – Don Norman• User Centered Design• Evaluation - Assignment

Designing from Scratch

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?

Trade-offs

Choosing which goals and constraints can be relaxed so that others are meet.

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

RCA Cultural Probs ref. William Gaver

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



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



Facing Problems

• Political problems within the organisation

• Dominance of certain stakeholders

• Economic and business environment changes

• Balancing functional and usability demands



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/


Data Interpretation and Analysis

• Start soon after data gathering session

• Initial interpretation before deeper analysis



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



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/


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



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.



Example use case diagram for shared calendar



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)



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



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



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



(Re)DesignPrototype

Evaluate

(Re)DesignPrototype



Final product

Prototyping

(Re)DesignPrototype

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

(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

(Re)DesignPrototype

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


Use

• design team can reason about the design

• can be presented to sample users, although require a facilitator

(Re)DesignPrototype


– 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

– now you could choose to return to the storyboard and provide some detail

(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


– Wizard of Oz prototyping is a useful prototyping technique

(Re)DesignPrototype


Video Prototyping…

(Re)DesignPrototype


(Re)DesignPrototype

(Re)DesignPrototype

IDEO TECH BOX

•Library, database, website - all-in-one

•Contains physical gizmos for inspiration

IDEO TECH BOX

(Re)DesignPrototype

(Re)DesignPrototype

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

So at what point do you build prototypes?

(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



Final product

(Re)DesignPrototype

review intro- hci / interaction design history of hci design life cycle – bin-it case study design...

Documents