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