know the user john kelleher it sligo. 1 designing for the user
Post on 21-Dec-2015
233 views
TRANSCRIPT
Know the User
John KelleherIT Sligo
2
Designing for the user
3
Word & Line numbering
Consider how you would place line numbers alongside a body of text
Where would you start?
4
Word & Line Numbering
Not here Not here Not here Obviously
here!
5
Basic Activities of Interaction Design Identifying needs and establishing
requirements [Part 2] Developing alternative designs
[Part 3] Building interactive versions of the
designs [Part 3] Evaluating designs [Part 4]
6
Overview of Needs Identification The importance of requirements Different types of requirements Data gathering Task descriptions: Scenarios
Use Cases Task analysis: HTA
7
Task analysis techniques focus on: understanding users' tasks breaking them down into tasks and actions
It clarifies and organizes user’s knowledge about a system.
Work-flow patterns are identified Frequency of different tasks performed What tasks are done with what tasks Order of work tasks Communication pathways Exceptions – when is task A not done?
Information Gathered from Task Analysis
8
Why do Requirements? Uncovered information may lead to:
abandoning a bad ideavideo-phones, recipe management programs
very good ideasWindow usage matches a working set model –
E.g. Rooms basis for driving design
protects from building a useless program Often assumptions designers have about
users and interface are wrong E.g. Ackroyd study of English Detectives
9
Information Gathered
Users’ conceptual model What is the external representation that is used to do the
task - worksheets, patient charts What organization or model do users keep in their head as
they are doing the task? Interrelationships among objects & tasks
Task specificity of various task objects - eraser for removing marks on a page
Organization of objects into larger task objects, page->section->chapter->book->library
10
SharpReaderConceptual model derived from user’s knowledge of Outlook
11
Information Gathered
Use of other systems and/or applications Use of accelerator keys Use of command-based rather than GUI
applications Use of telephones, voice mail systems and fax
machines
User Characteristics Task experience and knowledge of the domain. System experience Application experience, e.g., other WPs Computer literacy
12
50:34 Controller: Scandinavian 515 route direct to Detling.50:42 SK515: Roger, direct Detling, SK515.51:14 [Controller takes phone call] ... If you like.. OK.51:49 Controller: SK515, descend now to flight level 100, one-five
miles before Detling.52:00 SK515: Roger, level 100 to be level fifteen miles before Detling,
SK515.52:04 Controller: ’kyou.
[Controller sorts flight strips]53:22 [Controller to assistant] Ferry 201 ... is Ferry 201 past?53:27 Controller: Air Ferry 201 continue with Amsterdam 125 decimal
7, good-day.53:34 BAF201: 125 er 7, good-day.
[Discussion with other controllers]55:21 Controller: SK515, what’s your present heading?55:25 SK515: Roger, ’ding 240, SK515.55:28 Controller: Roger, turn left, heading 220, keep you clear of the
danger area.55:25 SK515: Roger, heading 220, Scandinavian 515.
[Controller sorts flight strips]55:47 Controller: Speedbird 723, you can turn, er, for Lambourn,
descend when ready to flight level 150.55:56 BA723: Roger, recleared, when ready level 150 and turning
direct for Lambourn, Speedbird, er, 723.
Transcription of 6 minutes of an ATC exchanges with flights traversing a sector in the London area
13
Establishing requirements
What do users want? What do users ‘need’? Requirements need clarification,
refinement, completion, re-scoping Input : requirements document
(maybe) Output : stable requirements
Examples: Too little information:
http://www.oscaroscar.com/pp_AB-9.asp Printers don’t mention need to buy printer cable http://store.compuvest.biz/551000012-00.html Also hard to find “add to cart” button
14
Different kinds of requirements
Functional: What the system should do Historically the main focus of requirements
activities
(Non-functional: memory size, response time... )
Data: What kinds of data need to be stored? How will they be stored (e.g. database)?
15
Different kinds of requirements
Environment or context of use: physical: dusty? noisy? vibration? light?
heat? humidity? …. (e.g. OMS insects, ATM)
social: sharing of files, of displays, in paper, across great distances, work individually, privacy for clients
organisational: hierarchy, IT department’s attitude and remit, user support, communications structure and infrastructure, availability of training
Users – who are they?
16
Different kinds of requirements
Usability: learnability, effectiveness, flexibility,
utility, memorability, efficiency, safety.
Note that user requirements and usability requirements refer to different things
17
Kinds of requirements
What factors (environmental, user, usability) would affect the following systems? A system for use in a university’s self-
service cafeteria that allows users to pay for their food using a credit system.
A system to control the functioning of a nuclear power plant
A system to support distributed design teams, e.g. for car design
18
Define goals for your application
Can be learned in less than 2 minutes User will perform 2 error-free purchases per session The error rate will be lower than 2 per 10 operations Tasks will be performed in 30% of the time it takes using
the competitor’s system
Users will have a high satisfaction with the system as measured by a survey.
Explicit, specific, measurable metrics. Tradeoffs, so have to pick relevant metrics e.g.
learnability versus efficiency
19
Categories of Users
Mandatory Discretionary Intermittent Level of Expertise
Novice Intermediate Expert
20
Level of Expertise Novice
frequent feedback; actions prompted by choices safe exploration supported - robust easy undo selective disclosure
Intermediate knowledge of broad aspects need easy access to the details can be amalgam of novice and expert
Also true of novice and expert.
21
Levels of Expertise (contd.)
Experts critical help system user lower, more subtle support and feedback accelerators required customisability desired to facilitate cross-
application usage only assumption – experts less risk-averse in
usage pattern
22
User categories (anecdotal)
Novice usersomeone who is afraid if they touch the keyboard they will break the system.
Intermediate usersomeone who has broken the computer and doesn’t know how to fix it.
Expert usersomeone who breaks other people’s computers.
23
Data gathering techniques (1) Questionnaires
Keep the number of questions low Only questions with answers that you can’t get other ways Only questions that will have a direct impact on functional
requirements Avoid asking for everything
Ask clear questions Ask questions that users can answer validly and reliably
Does the user store information in this way? Does the user remember such information? Will the user be inclined to answer your question truthfully?
Good for answering specific questions from a large, dispersed group of people
24
Data gathering techniques (2)
Interviews: Forum for talking to people Structured, unstructured or semi-
structured Props, e.g. sample scenarios of use,
prototypes, can be used in interviews
Good for exploring issues But are time consuming and may be
infeasible to visit everyone
25
Data gathering techniques (3)
Workshops or focus groups: Group interviews Good at gaining a consensus view and/or
highlighting areas of conflict
26
Data gathering techniques (4)
Naturalistic observation: Spend time with stakeholders in their
day-to-day tasks, observing work as it
happens Gain insights into stakeholders’ tasks Good for understanding the nature and
context of the tasks But, it requires time and commitment
from a member of the design team, and
it can result in a huge amount of data Ethnography is one form
27
Data gathering techniques (5)
Studying documentation: 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 Not to be used in isolation Good for understanding legislation, and
getting background information No stakeholder time, which is a limiting
factor on the other techniques
28
Data gathering techniques (6)
Contextual Enquiry Way of understanding users’ needs and work
practices Master – apprentice model allows customer to
teach us what they do!master does the work & talks about it while
workingwe interrupt to ask questions as they go
The Where, How, and What expose the Why Presence Project1
1 Gaver et al (1999) Cultural probes. ACM Interactions Magazine, January and February, 21-29Cultural Probes
29
30
Choosing between techniques
Data gathering techniques differ in two ways:1. Amount of time, level of detail and risk
associated with the findings2. Knowledge the analyst requires
The choice of technique is also affected by the kind of task to be studied:
Sequential steps or overlapping series of subtasks?
High or low, complex or simple information? Task for a layman or a skilled practitioner?
31
Problems with data gathering (1)
Identifying and involving stakeholders:users, managers, developers, customer reps?, union reps?, shareholders?
Involving stakeholders: workshops, interviews, workplace studies, co-opt stakeholders onto the development team
‘Real’ users, not managers:traditionally a problem in software engineering, but better now
32
Problems with data gathering (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?
Availability of key people
33
Problems with data gathering (3)
Political problems within the organisation Dominance of certain stakeholders Users are not always right
cannot anticipate new technology accurately job is to build system users will want
not system users say they want be very careful about this (you are outsider)
if you can’t get users interested in your hot idea, you’re probably missing something
Economic and business environment changes Balancing functional and usability demands
34
Some basic guidelines
Focus on identifying the stakeholders’ needs Use information that is readily available
Internet comments and user hotline reports Suggestions fostered by offering incentives
Involve all the stakeholder groups Involve more than one representative
from each stakeholder group Use a combination of data gathering
techniques
35
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 data
36
Data interpretation and analysis
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
37
Task descriptions
Scenarios an informal narrative story, simple, ‘natural’,
personal, not generalisable illustrate using storyboards
sequences of sketches showing screens & transitions
good to demonstrate to management, marketing and customers
can replace much textual specification similar to Use Cases in Software Engineering See Brad Meyers at 0:46.05
38
Scenario for shared calendar
Victoria is a bright young college student looking for a gift for her younger sister, who is turning 16 in two weeks. Like most college students, Victoria is on a tight budget, but wants to get something memorable and useful for her sister on this important birthday for a young girl.
She’s heard some of her friends talk about ebirthdayz.com, and so she decides to check it out. On the ebirthdayz.com homepage, she sees that the Web site has a gift recommendation feature. Victoria finds the recommendations screen and sees gifts based on her sister’s age and general interests, as well as her own limited finances.
The site shows some suggestions, and Victoria chooses a popular favourite and buys it, including gift-wrapping. Total time spent: 20 minutes.”
39
Scenarios (cont.) Scenarios are design specific, tasks
aren’t Scenarios force us to
show how various features will work together
settle design arguments by seeing examples
only examples sometimes need to look beyond
Show users storyboards sequences of sketches showing
screens actions users can take get feedback
40
Storyboards
41
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)
GOMS is also used
42
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
43
Example Hierarchical Task Analysis
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
44
Example:Hierarchical Task Analysis (plans)
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 do 2.2-2.3-2.4.
45
Example Hierarchical Task Analysis (graphical)
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 catalogue
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
46
Group info & find relations between groups Post-Its on
large surfaces haptic UI immersive persistent brainstorming
Also used forcreating web info architecture Reprinted by permission from Contextual Design by Hugh Beyer &
Karen Holtzblatt, InContext Enterprises, http://www.incent.com, © Morgan Kaufmann, 1998
Affinity diagramming
47
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, and 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
48
Exercise
Appreciate tacit knowledge of users Mechanical syringe design
Doses may be in range 0 – 9999 Draft a prototype
49
Automatic syringe
1 3 6 7 27 8 9
654
321
0
1 4 7 2+ + +
---+
-
Before consulting users After consulting users
50
Further Reading
Interaction Design,Preece et al,Chapter 7
51
Readings Lewis C. & Rieman J., “Getting to know users
and their tasks”, Shareware book. Gould J. (1988), “How to design usable
systems”. In Baecker et al. Web Sites
Beyer, Hugh, "Getting Started with Contextual Techniques" http://www.incent.com/connection.indx/techniques.html
Norman D. & Draper S. (eds.) (1988), “User Centred System Design”.