Paper Prototyping http://www.flickr.com/photos/21218849@N03/3901372331/sizes/l/

Customers and users should be your friends They probably know much more about the problem than you do. They probably have some ideas about how to solve the problem. They are your best resource for discovering your own mistakes before you start to code.

Risk: an unwanted event that has negative consequences Risk impact: the loss that would result if a risk turns into a problem Measured in time, quality, cost Risk likelihood: probability that the risk will turn into a problem Risk exposure = impact * likelihood Useful for comparing risks Risk control: the degree to which you can reduce exposure A problem when you have a number of possible risks is that it can be difficult to decide which risks are worth putting effort into addressing. Risk Exposure is a simple calculation that gives a numeric value to a risk, enabling different risks to be compared. A limitation of the risk exposure calculation is that it will give the same scores to high-probability/low loss risks and low-probability/high loss risks. If you are concerned with these differences, a Risk Matrix may be a better way of evaluating risks.

Example risks in an e-commerce application Risk: credit card validation component cannot handle debit cards Impact: 10% of revenue? Likelihood: 20%?? Risk: mobile phones (unexpectedly) need to be supported Impact: 30% of revenue? Likelihood: ??? For the mobile phone risk, any likelihood over 6 2/3 percent will mean its risk exposure greater than the credit card risk.

Risk management activities Risk assessment Risk identification Risk analysis Risk prioritization Risk control Risk reduction Risk management planning Risk resolution

Risk management and prototyping Traditional requirements-gathering Good for controlling risks regarding what the system should do But don’t know what the system should look like Prototyping Good for controlling risks regarding what the system should look like Not so good for non-visual aspects of the system

Boehm’s top ten risks Which does prototyping address? Personnel shortfalls Unrealistic schedules and budgets Developing the wrong software functions ** Developing the wrong user interface *** Gold plating *** Continuing stream of requirements changes ** Shortfalls in externally performed tasks * Shortfalls in externally furnished components * Real-time performance shortfalls Straining computer science capabilities * Personnel shortfalls Unrealistic schedules and budgets Developing the wrong software functions Developing the wrong user interface Gold plating Continuing stream of requirements changes Shortfalls in externally performed tasks Shortfalls in externally furnished components Real-time performance shortfalls Straining computer science capabilities

The general idea of prototyping You depict what you think the system should look like. You test the prototypes with customers or (preferably) users. You fix up the prototypes and use what you learn to implement the real system.

Waterfall kinds of processes Requirements analysis Prototyping Design Implementation Testing Operation

Spiral kinds of processes Draft a menu of program designs Analyze risk & prototype Draft a menu of architecture designs Analyze risk & prototype Draft a menu of requirements Analyze risk & prototype Establish requirements Plan Establish architecture Plan Establish program design Operation Testing Implementation

Different kinds of prototypes Throwaway prototypes Paper prototypes: sketches on pieces of paper Low-fidelity prototypes: implemented with a tool (e.g.: Photoshop) Evolutionary prototypes High-fidelity prototypes: implemented on the target platform… not fully functional, but destined to be incorporated into the final product

Paper prototypes Sketch on paper and/or post-it notes Don’t worry (much) about colors, fonts, icons Doesn’t need to be beautiful Does need to show all important UI elements Does need to be intelligible by users

Example system Here are the functional requirements: System will have web pages for mobile phones where citizens can report panhandlers Certain users called “volunteers” will view reports and “claim” panhandlers After visiting a claimed panhandler to offer social services (e.g.: counseling), a volunteer can mark a panhandler’s report as “done”

Example system Here’s a panhandler report state chart Report status New (just reported) Done (visited by volunteer) claim unclaim Claimed (by volunteer) mark done succeeds

“Testing” prototypes Let the user interface speak for itself Pretend to be the computer while a user tries to perform a use case with your prototype Let the user interface speak for itself So shut up and see if the user can do it himself!!! If the user misunderstands the user interface, then fix it on the spot if you can. Principle: the user is always right (in prototyping)

UC#1: Report panhandler Actor: any user Preconditions: user views site in mobile browser Postconditions: system records report Flow of events: User selects a city User enters information about the panhandler System validates inputs System records report in database

User selects a city User enters information about the panhandler System validates inputs System records report in database

UC#2: Process panhandler Actor: volunteer (member of task force) Preconditions: volunteer logged in via mobile browser Postconditions: panhandler marked as “done” Flow of events: Volunteer reviews list or map of panhandlers Volunteer marks report as “claimed” System records report as claimed Volunteer visits the panhandler Volunteer marks report as “done” System records report as done

Volunteer reviews list or map of panhandlers Volunteer marks report as “claimed” System records report as claimed Volunteer visits the panhandler Volunteer marks report as “done” System records report as done

Volunteer reviews list or map of panhandlers Volunteer marks report as “claimed” System records report as claimed Volunteer visits the panhandler Volunteer marks report as “done” System records report as done

Some problems revealed by prototype What happens during “validation” of a panhandler report? How does the volunteer navigate from the “list view” to the “map view”? What happens if there are lots and lots of reports… how does the user make sense of it? So what happens when the user marks a panhandler report as “done”?

Non-visual problems that the prototype might not catch What if there are duplicate reports? How do new cities get added to the system? Do users need to be authenticated to make a panhandler report? Why/why not? Is the mapping interface really going to run properly in a mobile browser? Sounds risky. Identifying such problems requires techniques beyond prototyping.

Low-fidelity prototypes Fidelity = “faithfulness” or closeness to what the ultimate product would look like Paper prototypes are “ultra low” fidelity Low-fidelity prototypes can be made in Photoshop PowerPoint HTML Any other tool that’s cheap and easy to use

Promoting health awareness with a “know your numbers” card & system “HealthCard for info junkies on the left... quickie sketches for a more mass audience 'know your numbers' design on the right. Ultra early prototypes.” Promoting health awareness with a “know your numbers” card & system http://www.flickr.com/photos/juhansonin/347137175/sizes/o/

Prototype splash-screen for Anaconda, an installer framework for Linux http://www.flickr.com/photos/sstorari/3671284171/sizes/o/

Prototype of what an iPod might look like with a 960×640 resolution “iPad - iPod touch's bigger brother I just knocked this up in photo shop. What if you took the iphone/Ipod touch screen count of 480 pixels vertically, by 320 pixels horizontally and just doubled them to 960 by 640. Rescaling might make some of the graphics apps look blocky, but this could be solved with an app update. Safari would be great on a screen with a resolution that size. UPDATE: 16 months later, Apple announce a device just like this, I even got the name right!” http://www.flickr.com/photos/ben30/2866006814/sizes/o/

Prototype of a site for managing and sharing photos http://www.flickr.com/photos/ missrogue/68077527/sizes/o/

Paper vs low-fidelity Low-fidelity lets you explore Colors, fonts, iconography, etc But low-fidelity (compared to paper prototyping) Is more expensive Requires somebody with design “skillz” Is harder to fix on the fly And neither one can detect certain problems…

What’s next for you? Finish your HW2 Get a head start on HW3! Due Tuesday (9/20) before start of class Get a head start on HW3! Hint: You’ll be making paper prototypes “Tiny Fingers” article is a nice guide to paper prototyping Book a room for paper Req. Eval. Day! UC’s Technology Hub: 901.678.3323 Thu, Sept 22, 2:40-4:40 p.m.

Copyright (c) Christopher Scaffidi 2009 All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Oregon State University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Modified by Scott D. Fleming <Scott.Fleming@memphis.edu> 2011.