From Analysis to Design Sketching and Prototyping Brad Myers 05863 08763 46863 Introduction to Human Computer Interaction for Technology Executives Fall 2014 Mini 2 2014 Brad Myers ID: 403342
Download Presentation The PPT/PDF document "1 Lecture 4:" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
1
Lecture 4:From Analysis to Design:Sketching and Prototyping
Brad Myers05-863 / 08-763 / 46-863: Introduction to Human Computer Interaction for Technology ExecutivesFall, 2014, Mini 2
© 2014 - Brad MyersSlide2
Administrative
Homework 1 dueStart on Homework 2© 2014 - Brad Myers
2Slide3
Enrollment
Total: 82© 2014 - Brad Myers
3Slide4
Going From Analysis To Design
Analysis produces lists of issues/problems = requirementsRequirements also from elsewhere – e.g., marketingText (ch. 5) discusses requirements specifications
How deduce the requirements themselvesVague vs. specific requirements“User Friendly” vs. “ENTER key should work in all text fields”How to write up the specificationsNot further covered in this course – ref. software engineeringBut not necessarily how to address those requirementsTradeoffs between conflicting goalsGap between Analysis and DesignNote: design of UI, not design of the software
4
© 2014 - Brad MyersSlide5
5
DesignDesign is
CreativeInformedRespectfulResponsible“Design Thinking”http://designthinking.ideo.com/?p=49
© 2014 - Brad MyersSlide6
6
TradeoffsTime-to-market vs. good design
Cost“Curse of individuality”Has to be differentLegal considerationsWhen usability is not desiredUncomfortable chairs; exit hereClient isn’t the userMarket Forces: Creeping Featurism / “Bloat”
© 2014 - Brad MyersSlide7
How Design?
Don’t know up front exactly what to designDon’t know real requirementsDon’t know appropriate designsCan’t get perfect information from users
Very little of the software is independent of the user interfaceDatabase design, data structures, architecturehttp://www.cs.cmu.edu/~bej/usa/So need to build and test = Iterative DesignBut too expensive to build the real system and test itToo hard to redesignToo much is already unchangeable© 2014 - Brad Myers7Slide8
Low Level vs. High Level
Need to design at multiple levelsHigh level: Overall metaphors, styles, approachesLow level: Detailed interactions and contentHigh level:Conceptual Models, Mental Models, Mappings
Designer’s vision of the systemOverall metaphors and organizationOften inspired by other designs, e.g.“Folders like Outlook” (vs. Gmail’s search, later tags)“Scrolling like iPhone”8© 2014 - Brad MyersSlide9
9
Encourage Accurate User Model
Design modelDesignerSystem
User’s model
User
© 2014 - Brad MyersSlide10
10
Norman’s Refrigerator
pp. 14-15, DOET
© 2014 - Brad MyersSlide11
Low Level Design
How the specific Interactions work
Widget ChoiceE.g., many types of menusPull-downCascadingTear offPop-up menusContext menusPhysical buttons11
© 2014 - Brad MyersSlide12
12
“Affordances”“Perceived and actual properties of the thing, primarily those fundamental properties that determine how the thing could possibly be used.” (Norman
DOET book, p. 9)“When affordances are taken advantage of, the user knows what to do just by looking”© 2014 - Brad MyersSlide13
13
Incorrect assessmentsThree Mile IslandIncorrect meaning of indicator light that a valve was closed, when it really meant that the valve was
told to closeThere was no actual indicator of the status of the valveAegis: Ascent vs. Descent Provide accurate and appropriate feedback© 2014 - Brad MyersSlide14
© 2014 - Brad Myers
14Answer: Sketching andEarly Prototypes
Sketch – used to decide what to design“Prototype” – Simulation of interfaceBuxton differentiates:Getting the right design, vs. Getting the design rightQuick and cheap to createSlide15
15
Sketches & IdeationDesigners invent
while sketchingDon’t have design in their head first and then transfer it to paperAristotle: “The things we have to learn before we do them, we learn by doing them”Sketching aids the process of inventionIdeation --Coming up with ideas to help solve the design problemsEveryone sketchesWhiteboards, paperFor collaboration and private investigations
Don’t have to be “artistic
”
Be creative!
© 2014 - Brad MyersSlide16
16
Properties of Sketches
From Buxton’s article and bookQuick: to produce, so can do manyTimely: provided when needed, done “in the moment”Inexpensive: so doesn’t inhibit exploration early in the design process.Disposable: no investment in the sketch itselfPlentiful: both multiple sketches per idea, and multiple ideasClear vocabulary: informal, common elementsDistinct Gesture: open, free, “sketchy”Constrained Resolution: no higher than required to capture the conceptAppropriate Degree of Refinement: don’t imply more finished
Ambiguity
: can be interpreted in different ways, and new relationships seen within them, even by the person who drew them.
Suggest & explore rather than confirm
: foster collaborative exploration
© 2014 - Brad MyersSlide17
© 2014 - Brad Myers
17
Multiple Sketches, AnnotationsLinus Pauling: “The best way to a good idea is to have lots of ideas”In our survey, over 90% of designers explore multiple designsAnnotations are important for understanding intent, differencesSlide18
© 2014 - Brad Myers
18Examples of SketchesSlide19
© 2014 - Brad Myers
19“Storyboards”
Multiple sketches of a behavior = “storyboards”Comic strip of what happensExample: from M-HCI project on a photo browserSlide20
20
More ExamplesFrom SRI M-HCI project
© 2014 - Brad MyersSlide21
21
Movie Ticket Kiosk, 13 different example designs
© 2014 - Brad MyersSlide22
22
Movie Ticket Kiosk, 2
© 2014 - Brad MyersSlide23
23
Movie Ticket Kiosk, 3
© 2014 - Brad MyersSlide24
24
Sketches vs. PrototypesDifferent purposes:
Sketch for ideation, refinementPrototypes for evaluation, usabilityPrototypes: more investment, more “weight”More difficult to change, but still much easier than real system© 2014 - Brad MyersFigure from Buxton
bookSlide25
25
Sketches vs. PrototypesDifferences in intent
and purposeSketch
Prototype
Evocative
Didactic
Suggest
Describe
Explore
Refine
Question
Answer
Propose
Test
Provoke
Resolve
Tentative
Specific
Noncommittal
Depiction
© 2014 - Brad MyersSlide26
26
PrototypesDon't worry about efficiency, robustness
Fake data Might not need to implement anything – fake the system (no “back end”)May not use "real" widgetsJust show what looks like Storyboard of screensSome support for behavior: typically changing screensLike a movie of the interactionGoal: see some of interface very quickly (hours)© 2014 - Brad MyersSlide27
27
Types of Prototypes
Paper “Low fidelity prototyping”Often surprisingly effectiveExperimenter plays the computerDrawn on paper drawn on computer“Wizard of Oz”User’s computer is “slave” to experimenter’s computerExperimenter provides the computer’s output“Pay no attention to that man behind the curtain”
Especially for AI and other hard-to-implement systems
Implemented Prototype
Visual Basic
Adobe (MacroMind) Flash and Director
Visio
PowerPoint
Web tools (even for non-web UIs)
Html
Scripting
(no database)
Real system
Better if sketchier for early design
Use paper or “sketchy” tools, not real widgets
People focus on wrong issues: colors, alignment, names
Rather than overall structure and fundamental design
Increasing fidelity
© 2014 - Brad MyersSlide28
28
Types of PrototypesFewer features = Vertical Realistic on part
Less Level of functionality = Horizontal Overview of all
Horizontal Prototype
Vertical
Prototype
Real
System
© 2014 - Brad MyersSlide29
Uses of Prototypes
What questions will the prototype help you answer? Is this approach a good idea? Usually only need to test a few people for test:
Most results with first 3 people Can refine interface after each test Look what a cool design we have! Transfer design from UI specialists to programmers Often better than written specifications Design A versus Design B Rare, except in academic environments What are the real requirements and specifications?As a basis for “Participatory Design”Involve users in the design process, not just the evaluation29
© 2014 - Brad MyersSlide30
30
Example of Full PrototypePrototype of interface for controlling the paths of a robot
© 2014 - Brad MyersSlide31
31
Resulting Prototype andFinal Design
© 2014 - Brad MyersSlide32
32
Another ExampleFrom
Jingjing Xia in a previous year’s class: washing machine done in PowerPoint (one of 7 screens)
Default-
>Temperature->Level->Mode
Do you want to use the default settings?
Water Temperature: Cold 10 ̊C
Water Level: Low 1/3
Wash Mode: Delicate
Make sure you loaded clothes and added detergent.
BACK
Tech Support
Change Settings
Yes
START
Please contact
1-800-JNJ-WASH
for any questions or feedbacks.
© 2014 - Brad MyersSlide33
33
Another exampleVideo of the process (4:55)
© 2014 - Brad MyersSlide34
Evolve Sketches intoWorking Prototypes
(Homework 4)Make the controls actually work“Wireframe” prototype
Just the outlines of the controls, not the “real look”But not the “back end”Use prototyping toolsHTMLVisual BasicPowerPointSpecial-purpose tools: Axure, etc.Also, prototype final looks, graphics, design elementsOften using Photoshop, etc.Handoff prototypes as part of the specification to implementation team34
© 2014 - Brad MyersSlide35
© 2014 - Brad Myers
Hand-off to ImplementersAnnotated screenshots from sketches or prototype as specification
35