comp 5620/6620/6626 chapter 8: design, prototyping and construction section 8.1-8.2.2: kevin...
TRANSCRIPT
COMP 5620/6620/6626Chapter 8: Design, Prototyping and Construction
Section 8.1-8.2.2: Kevin Richardson
Section 8.2.3-8.2.6: Kevin Schwieker
Section 8.3: Shirelle Sharpley
Section 8.4-8.5: Raghu Neelisetti
8.1: Introduction Prototyping
Types of prototyping Prototyping activities Use of scenarios and prototypes in
conceptual design Standards, guidelines, and rules Tool Support
8.2.1: What is a prototype? “A prototype is a limited representation
of a design that allows users to interact with it and to explore its suitability.”
“A prototype allows stakeholders to interact with an envisioned product, to gain some experience of using it in a realistic setting, and to explore imagined uses.”
8.2.2: Why prototype? They are…
a useful aid when discussing ideas with stakeholders.
a communication device among team members.
an effective way to test out ideas for yourself.
8.2.2: Why prototype? Benefits to users
Prototypes can help the user to realize what it is they really want.
Benefits to developers Testing out the technical feasibility of an idea Clarifying vague requirements Perform some user testing and evaluation Check that a certain design direction is compatible
with the rest of the system development
8.2.3: Low-Fidelity Prototyping Low cost, simple, quick to produce Easy to modify Types
Storyboarding Sketching Prototyping with Index Cards Wizard of Oz
8.2.4: High-Fidelity Prototyping Looks much more like the final product Useful for selling ideas to people and
testing technical issues. Many tools to assist in creation, such
as Macromedia Director, Visual Basic, Smalltalk
Some disadvantages
Low vs. High FidelityType Advantages Disadvantages
Low-Fidelity Prototype Lower development cost Evaluate multiple design concepts Useful communication device Address screen layout issues Useful for identifying market requirements Proof-of-concept
Limited error checking Poor detailed specification to code to Facilitator-driven Limited utility after requirements established Limited usefulness for usability tests Navigational and flow limitations
High-Fidelity Prototype Complete functionality Fully interactive User-driven Clearly defines navigational scheme Use for exploration and tests Look and feel of final product Serves as a living specification Marketing and sales tool
More expensive to develop Time-consuming to create Inefficient for proof-of-concept designs Not effective for requirements gathering
8.2.5: Compromising in Prototyping Nature of prototyping involves compromise Trying to create a representation of final
product, but in a short time Horizontal prototype vs. Vertical prototype
Horizontal: Wide range of functions but with little detail
Vertical: A lot of detail for only a few functions
8.2.6: Construction - Design to Implementation
Evolutionary Prototyping Evolving a prototype into the final product Requires rigorous testing
Throwaway Prototyping Uses prototype as stepping stones to final
design Thrown away and final product started from
scratch
8.3: Conceptual Design - Moving From Requirements to First Design Conceptual Design
Transforming the user requirements and needs into a conceptual model
Conceptual Model A description of the proposed system in terms of a set of integrated ideas
and concepts about what it should do, how it should behave, and what it should look like, that will be understandable by the user
Key Principles Keep an open mind but never forget the users and their context Discuss ideas with other stakeholders as much as possible Use low-fidelity prototyping to get rapid feedback Iterate, iterate, iterate!
8.3.1: Three Perspectives for Developing a Conceptual Model Which interaction mode would best support
the users’ activities? Depends on the activities the user will engage in
while using it Activity-based or Object-based
8.3.1: Three Perspectives for Developing a Conceptual Model Is there a suitable interface metaphor to help user
understand the product? Erickson’s three-step process
Understand systems functionality Identify potential user problems Generate metaphor
Erickson’s five-question evaluation Structure? Relevancy? Understandability? Ease? Extensibility?
8.3.1: Three Perspectives for Developing a Conceptual Model Which interaction paradigm will the product
follow? Ubiquitous computing Pervasive computing Wearable computing
8.3.2: Expanding the Conceptual Model What function will the product perform?
I.e., how the task will be divided up between the human and the machine
Task allocation - deciding what the system will do and what must be left for the user
How are the functions related to each other? The relationships between tasks may constrain use or may indicate
suitable task structures within the device. Example: obtaining a list of attendees and meeting constraints before
scheduling a meeting on a shared calendar What information needs to be available?
What data is required to perform the task? How is this data to be transformed by the system? Example: booking a meeting would require the user to tell the system
the attendee list, time length, location, and the date.
8.3.3: Using Scenarios in Conceptual Design Scenario
Informal story about a user task or activity; used for expressing proposed or imagined situations to help in conceptual design
Bødker’s Four Roles for Scenarios As a basis for the overall design For technical implementation As a means of cooperation within design teams As a means of cooperation across professional boundaries, i.e.,
as a basis of communication in a multidisciplinary team Bødker’s Notion of “plus” and “minus”
Two types of scenarios “Plus” and “Minus” denotes the most positive and the most
negative consequences of a particular proposed design solution
8.3.4: Using Prototypes in Conceptual Design Prototyping
A mock-up that allows some evaluation of the emerging ideas/designs to take place
How do I know what type of prototype to use?
Start of Project End of Project
Low-Fidelity Prototypes(example: paper-based scenarios)
Higher-Fidelity Prototypes(example: limited software implementations)
8.3.4: Using Prototypes in Conceptual Design Question
Could one project group share how their prototypes progressed from low-fidelity to higher-fidelity?
8.4: Physical Design Involves considering more concrete,
detailed issues of designing the interface, such as screen or keypad design, which icons to use, how to structure menus etc. e.g. design of a cell phone
Shneiderman’s Eight Golden Rules of Interface Design Strive for consistency Enable frequent users to use short cuts. Offer informative feedback Design dialogs to yield closure Offer error prevention and simple error
handling Permit easy reversal of actions Support internal locus of control Reduce short term memory load.
Different Kinds of Widgets Menu design
Grouping options in a menu Should be grouped within a menu to reflect user
expectations and facilitate option search Logical groups
Options should be grouped by function or into other logical categories which are meaningful to users.
Arbitrary groups Should follow the rule g=n^(0.5)
Icon Design Need to be widely acceptable to the
user group Are often cultural and context-specific Internationally recognized symbols now
exist for to wash clothes fire exits road signs
Screen Design Two aspects
Splitting the task across a number of screens All pertinent information must be easily available at
relevant times. How the individual screens are designed
Good organization helps users to make sense of an interaction and to interpret it within their own context
Bottom line A trade off is necessary between sparsely
populated screens with a lot of open space and too overcrowded screens
Information Display Make sure that the relevant information
is available for the task. Choose proper format as different types
of information lend themselves to different kinds of display.
8.5: Tool Support Help design the interface given a specification of the end users’
task. Help implement the interface given a specification of the design. Create empty-to-use interfaces. Allow the designer to rapidly investigate different designs. Allow non programmers to design and implement user
interfaces. Automatically evaluate the interface and propose improvements. Allow end users to customize the interface. Provide portability. Be easy to use.
Successes and Failures for User Interface Tools Successful tools
Window managers and toolkits Event languages Interactive graphical tools or interface builders,
e.g. VB Component systems, e.g. Sun’s JAVA Beans Scripting languages, e.g. Python and Perl Hypertext
Failures User Interface Management Tools
Formal Language based tools Constraints Model Based and automatic techniques