290 likes | 329 Views
Prototyping. Teppo Räisänen http://www.oamk.fi/~teraisan/ Teppo.raisanen@oamk.fi. General Information. Prototyping is commonly used as a part of user-centered design paradigms Prototyping was introduced during 1980s Prototyping has a strong position in Contextual Design method.
E N D
Prototyping Teppo Räisänen http://www.oamk.fi/~teraisan/ Teppo.raisanen@oamk.fi
General Information • Prototyping is commonly used as a part of user-centered design paradigms • Prototyping was introduced during 1980s • Prototyping has a strong position in Contextual Design method
General Information • What is a prototype? • Looks like a finished product? • Behaves like a finished product? • May have small faults or missing functionalities? • Prototypes can be used in many ways • To try out new features of an application • Test a complete family of applications
Prototyping vs. Traditional methods • According to some sources prototyping does not fit very well in ’waterfall’ design paradigm • results of intermediate phases are not suitable for prototyping • In waterfall model it is expensive to go back a step (e.g. from implementation back to design)
Prototyping vs. Traditional methods • An experienced usability expert will be able to see some of the usability issues from the documentation • This kind of practice is, however, inadequate • Many usability issues will not be found • One solution is to separate UI design to an independent subproject
Prototyping vs. Traditional methods • Especially important is to use prototyping, when new product concepts are introduced • Prototypes can also be used as a means of communication between project units • Often parts of requirements spesification are intepreted in different ways • Prototypes are useful for completing formal spesifications
Functional Prototypes • Functional protoype is essentially a product with fully implemented functionalities • The goal is still to keep the costs lower than those of a finished product • There are basically three ways to cut the expenses
Functional Prototypes • Cut down the product features • only part of all features are implemented • the implemented features are fully functional • Cut down the functionalities • all features are implemented • some functionalities are missing
Functional Prototypes • Cut down resources used in implementation • Memory optimization is not implemented • Efficency is not maximized • Very effective computers are used during testing to make up missing efficency • Error hanling is not fully implemented
Functional Prototypes • Often mixtures of aforementioned methods are used to cut down the costs of developing a prototype
Paper Prototypes • In some cases it is practical to use paper prototypes instead of functional ones • E.g. Contextual Design stresses use of paper prototypes • Piece of paper is used to represent UI • A member of usability staff arranges the UI according to user’s actions
Paper Prototypes • Changes to the UI can be illustrated by • Using Post-it labels • Drawing to the paper • Using various pieces of paper • The person responsible for arranging the UI must know the underlying system well
Paper Prototypes • E.g. heuristic evaluation methods can be used • We will go into heuristics later in the course • Use of paper prototypes is not restricted to just desktop applications • Wood block => mobile device • Cardbroad box => laptop computer • Pencil => bar code reader
Paper Prototypes • Various software tools can be used to sketch the contents of paper prototypes, e.g. • Visual Basic for the UI views • Flash for mobile device emulations • It may be psychologically easier for the test person to suggest changes to a ballpark drawing
Paper Prototypes • Compared to functional prototypes, paper prototypes are easier, faster and cheaper to produce • Several degrees of accuracy can be used during iterative cycles
Wizard of Oz • Wizard of Oz is a spesific technique of prototyping • Used to test and demonstrate technically ’impossible’ features • E.g. speech recognizing text editor in 1970s • User believes he/she is using a computer-based system
Wizard of Oz • In reality user’s actions are transmitted to a person, who processes actions and forms the feedback of the system • Because of that, the response times can be quite long • User can be told, that advanced processes are time-comsuming • Several ’wizards’ can be used to speed up system’s actions
Emulation Techniques • Emulation = imitating a product’s functions using another product • E.g. mobile devices can be emulated using desktop computers • More processing power, thus no need for code optimization • Ability to test device’s UI before hardware examples are manufactured
Emulation Techniques • Emulator’s do not transmit a truthful image of a product, e.g. • no physical buttons of the actual device • different display format
Simulation Techniques • Simulations are used to mimic a device by using another kind of technical enviroment • E.g. flight simulators used for pilot training • The difference between simulation and emulation is, that simulation utilizes the actual UI of a device
Simulation Techniques • Simulation can be used during early design phases of a product, e.g. • Model can be made of wood or plastic • The hardware buttons are included in the model • Buttons are wired to a computer system, which gives feedback according to the user’s actions
Simulation Techniques • Simulations are effective means of • marketing a product • localization • testing the physical adequacy of the product • Simulations are generally more expensive than other forms of prototyping
Manuscripts • A manuscript (like in a case of a movie) can be written of a product • Manuscript will represent a spesific task, which is completed by using the product • The goal is to demonstrate the product in daily use and advantages of using the product
Manuscripts • Suitable formats of manuscripts are • animations • comic strips • theater plays • etc. • Manuscripts are not to be used as testing methods • Instead they are good for demonstrating a product to a large audience
After Prototype Has Been Used • Usually the best choice is to throw the prototype away • It is meant to be used as a sketch • There are many real-world examples of failures, when code parts of prototypes have been used in products
After Prototype Has Been Used • Prototypes, which ’look too good’ can be potentially dangerous: • Customer may think, that the product is almost finished • Management is not willing to throw ’almost finished’ parts of prototype away • One way of avoiding prototype’s code to be used is to implement prototype with a language unsuitable for for the product