Design, prototyping and construction

1
Design, prototyping and construction
Readings ID-book, Chap. 11 (through 11.3)
Also, Prototyping for Tiny Fingers
http//doi.acm.org/10.1145/175276.175288
Also, Java.net article (from 2003), Six Signs
That You Should Use Paper
Prototyping
2
Four Old Slides

• For review
• Remember these ideas?

3
A model for interaction design
4
What is User-Centered Design?

• An approach to UI development and system
  development.
• Focuses on understanding
• Users, and
• Their goals and tasks, and
• The environment (physical, organizational,
  social)
• Pay attention to these throughout development

5
ISO on User-centered Design

• ISO 13407 describes human-centered design
  processes for interactive systems
• Principles of human-centered design
• Active involvement of users
• Appropriate allocation of function between user
  and system
• Iteration of design solutions
• Multidisciplinary design teams

6
ISO on User-centered Design (2)

• Essential activities in human-centered design
• Understand and specify the context of use
• Specify the user and organizational requirements
• Produce design solutions (prototypes)
• Evaluate designs with users against requirements

7
(No Transcript)
8
What is a prototype?

• What do you think of when you hear prototype?
• What kinds of prototypes have you seen anywhere?
• in other fields or disciplines?
• on television?
• What are they for?

9
What is a prototype?

• In other design fields a prototype is a
  small-scale model a miniature car a miniature
  building or town
• Exists for some purpose
• Show the concept to some stakeholders
• Get feedback about some aspect
• Test somehow
• E.g. a wing in a wind-tunnel

10
Prototyping and Software

• Do software companies do this?
• Sometimes do it well
• But sometimes the prototype is Version
  1.0!
• Constantine and Lockwood
• Software is the only engineering field that
  throws together prototypes and then attempts to
  sell them as delivered goods.

11
What is a prototype for us?

• In HCI / interaction design it can be (among
  other things)
• a series of screen sketchesa storyboard, i.e. a
  cartoon-like series of scenes a Powerpoint slide
  showa video simulating the use of a systema
  lump of wood (e.g. PalmPilot)a cardboard
  mock-upa piece of software with limited
  functionality written in the target language or
  in another language

12
Why prototype in general?

• Evaluation and feedback are central to
  interaction design
• Developers can test feasibility of ideas with
  team, users
• Stakeholders can see, hold, interact with a
  prototype more easily than a document or a
  drawing
• Team members and users can communicate
  effectively
• To validate existing / other requirements
• It encourages reflection very important aspect
  of design
• Prototypes answer questions, and support
  designers in choosing between alternatives

13
What to Prototype and Why

• Prototyping reduces uncertainty
• It can be a major tool for risk management
• Apply on whatever you might be uncertain about!
• Prototyping technical issues
• E.g. run-time issues
• Prototyping to establish requirements
• Users see functionality
• Prototyping for usability concerns
• Our concern in this course

14
When and at What Level

• For SW, you might prototype at various times in
  the lifecycle
• Different goals, different techniques
• Conceptual Design
• Interaction Design
• Screen Design

15
Benefits of Prototyping Early

• Exploration and evaluation of different design
  options
• Increase communication among users and developers
• Rapid feedback on ideas and changes
• Identify problems and issues before construction
  (expensive)

16
Prototyping Conceptual Design

• Early in development
• Explore high-level issues
• Different conceptual models
• Interaction styles
• User needs and characteristics
• Usability goals
• High-level representations
• Far from final code or GUIs

17
Prototyping Interaction Design

• Later in development
• Focus on user work-flows
• Tasks and scenarios youve identified
• Might focus at the screen (or page) level.
  Possibly like this
• identify screens, pages, activities
• Organize these in groups
• Define flows or transitions between them
• Involve users in evaluation
• Representations
• Still probably not much like final code or GUIs

18
Prototyping Screen Design

• Before development
• Define and refine screens (pages)
• Blue-prints for final physical design
• User evaluation
• Both achieving tasks and navigation, andother
  usability criteria (as weve studied)
• Representations
• Low-fidelity or high-fidelity prototypes

19
Low-fidelity Prototyping

• Uses a medium which is unlike the final medium,
  e.g. paper, cardboard
• Is quick, cheap and easily changed
• Examples sketches of screens, task sequences,
  etc Post-it notes storyboards

20
Storyboards

• Often used with scenarios, bringing more detail,
  and a chance to role play
• It is a series of sketches showing how a user
  might progress through a task using the device
• Used early in design

21
Sketching

• Sketching is important to low-fidelity
  prototyping
• Dont be inhibited about drawing ability.
  Practice simple symbols
• Can use post-its, photo-copied widgets, etc.

22
Using Office Supplies

• Index cards, post-its
• Index cards (3 X 5 inches)
• Each card represents one screen
• Often used in website development

23
Using Office Supplies

• Post-its, index cards
• Can represent one screen, one page
• Color coded
• Draw on them
• Group them
• Put them on a wall or whiteboard, connect them
  with string or lines
• Write-on tape, clear film
• And so on See Rettigs article

24
Rettigs Prototyping for Tiny Fingers

• To get a a good idea, get lots of ideas.
• Problems with hi-fi prototyping
• too easy to focus on fit and finish
• developers resist changing software
• SW prototype sets expectations
• Bug in SW prototype kills an evaluation

25
Storyboards

• Storyboards are
• a low fidelity visual representation where
• steps or actions represented by panels, like a
  comic book
• Goals are to
• flesh out the scenarios in an interaction design
• effectively communicate with users or stakeholders

26
Principles and Variations

• (As usual in HCI) storyboards should be real
  and representational rather than abstract or
  complete
• Used in different ways at different phases
• Early focus on user tasks, work-flow, context,
  etc.
• Later lo-fi drawing of screens, menus, etc.
• Principles
• Describe a scenario -- focused on interaction
• Contains explanations, notes, etc.

27

• Example from UIDE book, p. 119
• Shows
• workflow of mail merging
• whos involved, responsibilities, etc.

28

• This shows high-level of view of users involved
  in other storyboards

From Usability Case Studies, http//ucs.ist.psu.e
du
29

• Lo-fi interface sketches
• Annotated with scenario/execution info

From Usability Case Studies, http//ucs.ist.psu.e
du
30

• Storyboard for a website
• for photographers
• Sequence of pages
• based on clicks
• Explanations / annotations

From book Designing Interactive Systems, 2005
31
High-fidelity prototyping

• Uses materials that you would expect to be in the
  final product.
• Prototype looks more like the final system than a
  low-fidelity version.
• For a high-fidelity software prototype common
  environments include Macromedia Director, Visual
  Basic, and Smalltalk.
• Danger that users think they have a full
  system.see compromises

32
High-fidelity Prototyping

• Benefits
• More realistic
• Closer to final product
• Good for developers and users
• Can collect metrics
• Limitations
• More expensive, less rapid
• Reluctance to change
• See Rettigs list

33
Compromises in prototyping

• All prototypes involve compromises
• For software-based prototyping maybe there is a
  slow response? sketchy icons? limited
  functionality?
• Two common types of compromise
• horizontal provide a wide range of functions,
  but with little detail
• vertical provide a lot of detail for only a
  few functions
• Compromises in prototypes mustnt be ignored.
  Product needs engineering

34
Possible Problems with Prototyping

• Pressure to enhance prototype to become delivered
  system
• From client
• From management
• Both see code, see almost-working system
• Why not use the prototype?
• Prototype built for quick updates, so...
• No design, so hard to maintain
• Ugly code, no error checking
• Wrong environment

35
And then Construction

• Taking the prototypes (or learning from them) and
  creating a final product
• Quality must be attended to usability (of
  course), reliability, robustness,
  maintainability, integrity, portability,
  efficiency, etc
• Product must be engineered
• Evolutionary prototyping
• Throw-away prototyping