Successfully reported this slideshow.
IM2044 – Week 6: Lecture
Dr. Andres Baravalle

1
Interaction design
• The next slides are based on the
companion slides for the textbook
• By the end of this week, you sho...
Overview
• What is Interaction Design?
– Importance of involving users
– Degrees of user involvement
– What is a user-cent...
What is Interaction Design?
• It is a process:
– A goal-directed problem solving activity informed by
intended use, target...
Importance of involving users
• Expectation management
–
–
–
–

Realistic expectations
No surprises, no disappointments
Ti...
Degrees of user involvement
• Member of the design team
– Full time: constant input, but lose touch with
users
– Part time...
What is a user-centered
approach?
• User-centered approach is based on:
– Early focus on users and tasks: directly studyin...
Interaction design activities
•
•
•
•

Establishing requirements
Designing alternatives
Prototyping
Evaluating

8
A simple interaction design
lifecycle model
•
•
•
•
•

Who are the users?
What do we mean by ‘needs’?
How to generate alte...
Who are the
users/stakeholders?
• Not as obvious as you think:
–
–
–
–
–

Those who interact directly with the product
Tho...
Who are the stakeholders?
Check-out operators
• Suppliers
• Local shop
owners

Customers

Managers and owners
11
What do we mean by ‘needs’?
• Users rarely know what is possible
• Users (typically) can’t tell you what they ‘need’ to he...
How to generate alternatives
• Humans stick to what they know works
– Considering alternatives is important to ‘break out ...
How to choose among
alternatives
• Evaluation with users or with peers, e.g.
prototypes
• Technical feasibility: some not ...
How to choose among
alternatives

Test the alternatives!
15
How to integrate interaction
design in other models?
• Agile software development is one option:
– Have development and de...
Software requirements: what,
how and why

• What:
1. Understand as much as possible
about users, task, context
2. Produce ...
Software requirements: what,
how and why (2)
•Why:
Requirements
definition: the
stage where
failure occurs
most commonly
•...
Volere shell

19
Volere requirements template

20
Establishing requirements
• What do users want? What do users ‘need’?
• Requirements need clarification, refinement,
compl...
Different kinds of requirements
• Functional:
—What the system should do
—Historically the main focus of
requirements acti...
Different kinds of requirements (2)
Environment or context of use:
— Physical: dusty? noisy? vibration? light?
heat? humid...
An extreme example

24
Different kinds of requirements (3)
• Users: Who are they?
— Characteristics: ability, background, attitude
to computers
—...
What are the users’
capabilities?
• Humans vary in many dimensions:
– Size of hands may affect the size and positioning of...
Kinds of requirements
• What factors (environmental, user,
usability) would affect the following
systems?
• Self-service f...
Personas (stereotypes)
• Capture user characteristics
– Not real people, but synthesised from real
user characteristics
– ...
Personas

29
Data gathering for requirements
Interviews:
— Props, e.g. sample scenarios of use,
prototypes, can be used in interviews
—...
Data gathering for requirements
(2)
Questionnaires:
— Often used in conjunction with other
techniques
— Can give quantitat...
Data gathering for requirements
(3) observation:
Direct
— Gain insights into stakeholders’ tasks
— Good for understanding ...
Data gathering for requirements
(4)
Studying documentation:

— Procedures and rules are often written
down in manuals
— Go...
Problems with data gathering
(1)
• Identifying and involving stakeholders:
users, managers, developers, customer reps?,
un...
Problems with data gathering
(2)
• Requirements management: version control, ownership
• Communication between parties:
– ...
Problems with data gathering
(3)
• Political problems within the organisation
• Dominance of certain stakeholders
• Econom...
Some basic guidelines
• Focus on identifying the stakeholders’
needs
• Involve all the stakeholder groups
• Involve more t...
Some basic guidelines (2)
• Support the process with props such as
prototypes and task descriptions
• Run a pilot session
...
Data interpretation and analysis
• Start soon after data gathering session
• Initial interpretation before deeper
analysis...
Task descriptions
• Scenarios
― An informal narrative story, simple, ‘natural’,
personal, not generalisable
• Use cases
— ...
Task analysis
• Task descriptions are often used to envision new
systems or devices
• Task analysis is used mainly to inve...
Hierarchical Task Analysis
• Involves breaking a task down into subtasks,
then sub-sub-tasks and so on. These are
grouped ...
Example Hierarchical Task Analysis
0.
1.
2.
3.
4.
5.

In order to buy a DVD
locate DVD
add DVD to shopping basket
enter pa...
Example Hierarchical Task Analysis
(graphical)

44
Hierarchical Task Analysis (2)
• More in the tutorial

45
Upcoming SlideShare
Loading in …5
×

Usability requirements

1,133 views

Published on

Week 5 lecture for im2044 2012-2013

  • Be the first to comment

  • Be the first to like this

Usability requirements

  1. 1. IM2044 – Week 6: Lecture Dr. Andres Baravalle 1
  2. 2. Interaction design • The next slides are based on the companion slides for the textbook • By the end of this week, you should have studied all chapters of the textbook up to chapter 10 • Today we will covering chapters 9-10. 2
  3. 3. Overview • What is Interaction Design? – Importance of involving users – Degrees of user involvement – What is a user-centered approach? • Some practical issues: – – – – Who are the users? What are ‘needs’? Where do alternatives come from? How do you choose among alternatives? 3
  4. 4. 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 4
  5. 5. 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 5
  6. 6. 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 6
  7. 7. 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) – 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 7
  8. 8. Interaction design activities • • • • Establishing requirements Designing alternatives Prototyping Evaluating 8
  9. 9. A simple interaction design lifecycle model • • • • • 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? 9
  10. 10. 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 (Eason, 1987): – Primary: frequent hands-on – Secondary: occasional or via someone else – Tertiary: affected by its introduction, or will influence its purchase 10
  11. 11. Who are the stakeholders? Check-out operators • Suppliers • Local shop owners Customers Managers and owners 11
  12. 12. 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 do 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 12
  13. 13. 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 13
  14. 14. How to choose among alternatives • 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 14
  15. 15. How to choose among alternatives Test the alternatives! 15
  16. 16. 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 16
  17. 17. Software requirements: what, how and why • What: 1. Understand as much as possible about users, task, context 2. Produce a stable set of requirements • How: Data gathering activities Data analysis activities Expression as ‘requirements’ All of this is iterative 17
  18. 18. Software requirements: what, how and why (2) •Why: Requirements definition: the stage where failure occurs most commonly •Getting requirements right is crucial 18
  19. 19. Volere shell 19
  20. 20. Volere requirements template 20
  21. 21. Establishing requirements • What do users want? What do users ‘need’? • Requirements need clarification, refinement, completion, re-scoping • Input: requirements document (maybe) • Output: stable requirements • Why ‘establish’? • Requirements arise from understanding users’ needs • Requirements can be justified & related to data 21
  22. 22. 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)? 22
  23. 23. Different kinds of requirements (2) 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 23
  24. 24. An extreme example 24
  25. 25. Different kinds of requirements (3) • Users: Who are they? — 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 25
  26. 26. 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) 26
  27. 27. Kinds of requirements • What factors (environmental, user, usability) would affect the following systems? • Self-service filling and payment system for a petrol (gas) station • On-board ship data analysis system for geologists searching for oil • Fashion clothes website 27
  28. 28. 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 28
  29. 29. Personas 29
  30. 30. Data gathering for requirements Interviews: — 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 Focus groups: — Group interviews — Good at gaining a consensus view and/or highlighting areas of conflict — But can be dominated by individuals 30
  31. 31. Data gathering for requirements (2) Questionnaires: — Often used in conjunction with other techniques — Can give quantitative or qualitative data — Good for answering specific questions from a large, dispersed group of people Researching similar products: — Good for prompting requirements 31
  32. 32. Data gathering for requirements (3) observation: Direct — 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 Indirect observation: — Not often used in requirements activity — Good for logging current tasks 32
  33. 33. Data gathering for requirements (4) 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 33
  34. 34. 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 • Getting ‘real’ users, not managers: traditionally a problem in software engineering 34
  35. 35. 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 35
  36. 36. Problems with data gathering (3) • Political problems within the organisation • Dominance of certain stakeholders • Economic and business environment changes • Balancing functional and usability demands 36
  37. 37. 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 techniques 37
  38. 38. Some basic guidelines (2) • 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 38
  39. 39. 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 objectoriented systems, entity-relationship diagrams for data intensive systems 39
  40. 40. Task descriptions • 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 40
  41. 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) 41
  42. 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 42
  43. 43. Example Hierarchical Task Analysis 0. 1. 2. 3. 4. 5. In order to buy a DVD locate DVD add DVD to shopping basket enter payment details complete address confirm order plan 0: If regular user do 1-2-5. If new user do 1-2-3-4-5. 43
  44. 44. Example Hierarchical Task Analysis (graphical) 44
  45. 45. Hierarchical Task Analysis (2) • More in the tutorial 45

×