Download Prototyping for Usability Engineering - Human-Computer Interaction | CS 3724 and more Study notes Computer Science in PDF only on Docsity!
Prototyping for usability
engineering
CS 3724
Doug Bowman
Problem scenarios
summative evaluation
Information scenarios
claims about current practice analysis of stakeholders, field studies
Usability specifications
Activity
scenarios
Interaction scenarios
iterative analysis of usability claims and re-design metaphors, information technology, HCI theory, guidelines formative evaluation
DESIGN
ANALYZE
PROTOTYPE & EVALUATE
What is prototyping?
Prototype: A concrete but partial
implementation of a system design
Creating an artifact to represent the
system during design
Simulating the appearance and
behavior of the final system
Making something tangible to test
(evaluate) for usability
Goals of Prototyping
Prototyping enables evaluation, happens throughout
Exploring requirements Market analysis, participatory design, envisionment Choosing among alternatives Risky or critical features, go/no-go decisions Empirical usability testing As early as possible, try out ideas with target users Evolutionary development May deliberately choose a malleable software platform, building software in incremental, iterative fashion
Do scenarios as used in SBD serve as prototypes?
Some Key Tradeoffs
Quality vs. premature commitment
Realism (e.g. timing, content) vs. early
availability or throw-away efforts
Constant iteration vs. radical change and/or
re-factoring of a design
Dynamic (highly malleable) platforms vs.
organized, well-structured code base
Horizontal vs. vertical
Low-fidelity vs. high-fidelity
Horizontal vs. Vertical
Horizontal prototype:
broad coverage of features
less detail for each feature
less realistic evaluation
Vertical prototype:
fewer features
more detail for each feature
more realistic evaluation
Fidelity in Prototyping
Fidelity: how much like
the final product is the
“look and feel” of the
prototype?
High fidelity
Prototypes look like the final product
Low fidelity
Artist’s rendition with many details missing
Why Use Low-fi Prototypes?
Traditional methods take too long
Sketches -> prototype -> evaluate -> iterate
Can simulate the prototype
Sketches -> evaluate -> iterate
Sketches act as prototypes
Designer “plays computer” Other design team members observe & record
Kindergarten implementation skills
Allows non-programmers to participate
Narrative scenario machine
example Wizard of Oz example
Video Prototype example
Apple “Knowledge
Navigator” - 1992
“Off-the-Shelf” Prototyping
Jump-start the design and iteration process
Recruit existing tools and devices
Integrate into approximation of a “system”
Example as used in virtual school project
Telephone for audio conferencing
Netmeeting for video conferencing, chat
Web pages for project questions and answers
Email for interaction with mentors
Can be very useful in requirements exploration
and in activity-oriented feasibility studies
Prototyping Tools
Presentation tools
Paper sketches/printouts PowerPoint
Scripting languages
Tcl/Tk Director SuperCard
Visual languages
Visual Basic SILK/Denim
Markup languages
HTML
UIML
Image/drawing editors
Photoshop Illustrator
Animation/video tools
Flash QuickTime
Features of a good tool
Easy to develop and modify screens
Supports many interface styles
Supports many I/O devices
Easy to create and modify links
Is itself usable
Allows transitioning of prototype to
product
Prototyping with PowerPoint
Create general look-and-feel of interface with
essential functionality
Generate interface widgets using Visual Basic
macros
Available through toolbar that can be turned on
Must set security level to “Low”
Actual control functions can only be tested in
“slideshow mode”
Supports creation of an output file for testing
Integrating HCI with Software
Construction
Classic problem in designing from specifications
The “specification-design” gap: a written spec is never
enough, always ambiguous, always interpreted
Who does the interpretation, using what knowledge?
There are many ways to create tighter linkage
OO analysis and design enable simultaneous attention
to user task and software design issues
Early and continued prototyping is essential
But, do we want to do this?
Only for projects that allow (welcome) requirement shift,
that view design as an inquiry process
