CS459559 HumanComputer Interaction

1
CS459/559Human-Computer Interaction

• User-Centered Design
• 9-17-2007
• Prof. Searleman, jets_at_clarkson.edu

2
Announcements

• Shipley Lectureship Michael Kasha
• "The Solar 11-Year Cycle of Giant Proton Storms
  and Their Geophysical Consequences" today,
  Monday, September 17, at 415 p.m. in Science
  Center Room 360.
• "History, Art, Science and Music of String
  Instruments" tomorrow, Tuesday, 9/18, at 415
  p.m. also in Science Center Room 360.
• Both presentations will be preceded by a 330
  p.m. reception.
• Career Fair this week
• IBM Info Night Wed., 845 945, SC160
• Greg Lacey from IBM will talk on software
  development Thurs., 400, SC162

a horrible death to die
3
Outline

• Recap User-Center Design Principles
• Lifecycle Models
• Identifying needs establishing requirements
• read ID2 Ch 9, pp.440-470 Ch 10, pp.472-489
• also see Cooper (www.cooper.com personas)
• and HCI dictionary entry on personas

4
User-centered design principles

• From Gould and Lewis
• Early focus on users and tasks
• Understand who users are
• Study their needs
• Empirical measurement
• Empirical evaluation
• Benchmarks before technology is developed
• Iterative design
• Design, evaluate, redesign

5
User-centered design principles

• Users tasks and goals are the driving force
  behind the development
• As opposed to technology
• Users behavior and context of use are studied
  and the system is designed to support them
• Understanding priorities, preferences, intentions
• Users characteristics are captured and designed
  for
• Design for users abilities

6
User-centered design principles

• Users are consulted throughout development from
  earliest phases to the latest and their input is
  seriously taken into account
• Users should be respected
• All design decisions are taken within the context
  of the users, their work, and their environment
• Does not necessarily mean that users participate
  in design decisions

7
User Centered Design

• Making users a central part of the development
  process
• Observation and interviews to obtain requirements
• Various levels of participation during design
• Many opportunities to help through
  feedback/evaluation/testing

8
but I know better than the users

• It is unwise to be too sure of one's own wisdom.
  It is healthy to be reminded that the strongest
  might weaken and the wisest might err.
• Mohandas K. Gandhi
• True wisdom comes to each of us when we realize
  how little we understand about life, ourselves,
  and the world around us.
• Socrates
• The doorstep to the temple of wisdom is a
  knowledge of our own ignorance.
• Benjamin Franklin

9
Why involve users?

• Users most of the time are different from
  developers
• Users most of the time are different from their
  managers
• Ensure understanding of users needs and goals by
  involving users in development process
• Users are experts at being themselves

10
Other advantages

• Makes users aware of expectations
• Ensure technology is not misrepresented
• Less likely users will be disappointed by
  technology
• Helps users understand why technology is the way
  it is
• Sense of ownership
• Buy-in

11
Recap

• Four basic activities in the design process
• Identify needs and establish requirements
• Design potential solutions ((re)-design)
• Choose between alternatives (evaluate)
• Build the artefact
• User-centered design rests on three principles
• Early focus on users and tasks
• Empirical measurement using quantifiable
  measurable usability criteria
• Iterative design
• Lifecycle models show how these are related

12
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 competitors 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

13
Stakeholders Personas

• Stakeholders are any key members of the
  organization commissioning the design work
• includes managers, engineers, sales, marketing,
  customer support, usability
• may include business partners in other
  organizations
• Type of information to get from stakeholders
  vision, budget and schedule, technical
  constraints, what is the business hoping to
  accomplish, what are the stakeholders
  perceptions of the user
• Expert consultants

14
SMEs

• Some stakeholders may be SMEs (subject matter
  experts)
• expert users
• knowledgeable (but not designers)
• necessary in specialized domains (e.g. may have
  safely regulations or best practices)
• should be involved throughout the design process

15
Who are the stakeholders?
Check-out operators
Suppliers Local shop owners
Customers
Managers and owners
16
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 childs toy requires little
  strength to operate, but greater strength to
  change batteries
• disabilities(e.g. sight, hearing, dexterity)

17
What are needs?

• Users rarely know what is possible
• Users cant 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

18
Where do alternatives come from?

• Humans stick to what they know works
• But considering alternatives is important to
  break out of the box
• Designers are trained to consider alternatives,
  software people 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

19
IDEO TechBox

• Library, database, website - all-in-one
• Contains physical gizmos for inspiration

From www.ideo.com/
20
The TechBox
21
How do you 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

22
Testing prototypes to choose among alternatives
23
Lifecycle models

• Show how activities are related to each other
• Lifecycle models are
• management tools
• simplified versions of reality
• Many lifecycle models exist, for example
• from software engineering waterfall, spiral,
  JAD/RAD, Microsoft, agile
• from HCI Star, usability engineering

24
A simple interaction design model
Exemplifies a user-centered design approach
25
Lifecycle models

• Many flavors
• Waterfall, Spiral
• Rapid Application Development (DSDM)
• Xtreme Programming (XP, an agile methodology)
• Usability Engineering Model, Star
• Iteration
• Guide you through steps in development of
  technology
• Sometimes institutionalized

26
Waterfall model

• Mother of all models
• Outdated but still widely used (variations)
• Five stages
• Requirements
• Design
• Code
• Test
• Maintain

27
Waterfall model

• Very difficult to get requirements right at the
  beginning of process
• No iteration expected, although some modified
  versions allow for iteration
• No testing of design before coding starts
• Cost to make fixes greatly increases after coding
  begins

28
Spiral Lifecycle model
29
Rapid Application Development (RAD)

• Developed during the 1980s, published in 1991
• Use of computer-aided software engineering (CASE)
  tools
• Turn requirements into code quickly
• Five core elements
• prototyping
• iterative development
• time boxing
• team members should be experienced
• management enforce tight deadlines, facilitate

30
Rapid Application Development (RAD)

• Keep development cycles short (time-boxing)
• Create interactive prototypes quickly in order to
  get user feedback
• Each cycle increases features of application
• Small, experienced, motivated teams
• Remove paperwork/bureaucratic barriers

31
Rapid Application Development (RAD)

• Joint Application Development (JAD) workshops
• Get stakeholders and programmers together to
  develop requirements
• Users involved in providing feedback after each
  cycle
• Still code before getting feedback from users on
  design

32
A Lifecycle for RAD (Rapid Applications
Development)
33
DSDM lifecycle model