1. COMP 5620/6620/6626 Chapter 8: Design, Prototyping and Construction
Section : Kevin Richardson
Section : Kevin Schwieker
Section 8.3: Shirelle Sharpley
Section : Raghu Neelisetti

2. 8.1: Introduction Prototyping Standards, guidelines, and rules
Types of prototyping
Prototyping activities
Use of scenarios and prototypes in conceptual design
Standards, guidelines, and rules
Tool Support

3. 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.”

4. 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.

5. 8.2.2: Why prototype? Benefits to users Benefits to developers
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

6. 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

7. 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

8. Low vs. High Fidelity Type 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

9. 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

10. 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

11. 8.3: Conceptual Design - Moving From Requirements to First 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!

12. 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

13. 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?

14. 8.3.1: Three Perspectives for Developing a Conceptual Model
Which interaction paradigm will the product follow?
Ubiquitous computing
Pervasive computing
Wearable computing

15. 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.

16. 8.3.3: Using Scenarios in Conceptual Design
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

17. 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)

18. 8.3.4: Using Prototypes in Conceptual Design
Question
Could one project group share how their prototypes progressed from low-fidelity to higher-fidelity?

19. 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

20. 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.

21. 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)

22. 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

23. Screen Design Two aspects Bottom line
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

24. 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.

25. 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.

26. 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

27. Failures User Interface Management Tools Formal Language based tools
Constraints
Model Based and automatic techniques