1. Design, Prototyping and Construction In “ pure ” waterfall, design begins after requirements development has finished However, in the real world there is overlap between requirements and design –This is a good thing, not bad! Two conditions: –Starting from scratch –Modifying an existing system Prototypes are essential to get user input

2. Conceptual vs. Physical Design Conceptual Design –Development of a conceptual model –Crafting of flows supporting this model Physical Design –Design of the elements with which users will really interact (e.g. widgets) –Design of the “ conversation ” (e.g. dialogs)

3. Generating Alternative Designs Don ’ t settle for “ good enough ” – force yourself to find real alternative designs –Your first design might be okay, but –Your second one will be much more creative Find inspiration in objects and events around you (e.g. steam kettle lid => steam engine) Look at other similar systems for ideas about both what works well and what doesn ’ t Caution: Copyright and Patent law applies!

4. Choosing among alternative designs Two categories of choices: –Externally visible and measurable features –Internal features/functionality, invisible without dissection User involvement –Documentation, prototyping Measurable usability requirements greatly help in the selection process –E.g. using a prototype, how many steps does it take to complete a particular task?

5. Prototypes for Evaluation Prototypes can be used in human factors experiments to determine usability of potential product –e.g.: in the mid-80s speech recognition word processors were evaluated, even though they couldn ’ t be built –A human typist behind a curtain was used to prototype such a tool

6. What is a Prototype? A model of a prospective system –Pencil and Paper –Storyboards –Hardware –Software Permits stakeholder interaction –e.g.: Jeff Hawkin (creator of Palm Pilot) carved and carried a wooden shape and pretended to use it

7. Why Prototype? Provide a framework for discussion and development of additional requirements and design details Test technical feasibility Allow performance testing of concepts

8. Low-fidelity Prototyping Doesn ’ t look much like the final product –Very different materials –Less precise functional mapping Simple and cheap A common example: Storyboards –Derived from the drama/film industry –Naturally compatible with Scenarios –Can be paper and pencil (sketched) –Can be a series of index cards –PowerPoint is a useful tool

9. Exercise: Storyboard Consider a sketched storyboard for the electronic calendar proposed before Would you choose “ screen shots ” ? Which ones? Which interaction paths would you follow? Why?

10. High-fidelity Prototyping Prototype very similar to final product For software systems, a variety of prototyping tools exist (e.g. Macromedia Director) May be integrated into final product (though this is controversial) More accurately reflect product But take longer to build, and can constrain imagination

11. Low Fidelity Summary Pro: –Low cost, short time –Multiple design concepts –Allows user/designer room to create Con: –Low detail w.r.t. requirements specification –Doesn ’ t accurately reflect future product –Not useful as part of product

12. High Fidelity Summary Pro: –Complete functionality, maps to requirements –Fully interactive –Readily tested Con: –Expensive, time-consuming –Not practical for evaluating many alternatives –Constrains imagination of user/designer

13. Compromises in Prototyping Breadth vs. Depth of functionality –Horizontal: wide range of functions, little detail –Vertical: lots of detail for limited cases Spaghetti code Lack of testing The dilemma: –Evolutionary vs. Throw-away prototyping

14. Project Prototypes Prototypes for your projects can include physical objects, sketches, Powerpoint presentations, and actual programs Students receiving CS credit for the course are expected to include some prototypes programmed in a high level language