User Experience Re-Mastered Your Guide to Getting the Right Design- P6

User Experience Re-Mastered Your Guide to Getting the Right Design- P6: Good user interface design isnt just about aesthetics or using the latest technology. Designers also need to ensure their product is offering an optimal user experience. This requires user needs analysis, usability testing, persona creation, prototyping, design sketching, and evaluation through-out the design and development process.
Nội dung trích xuất từ tài liệu:
User Experience Re-Mastered Your Guide to Getting the Right Design- P6 236 User Experience Re-Mastered: Your Guide to Getting the Right Design ITERATION 5: FROM PAPER PROTOTYPE TO CODED PROTOTYPE In the last stages of prototyping, many open design and technical questions can be answered. The required functionality, the audience, and the business case are already firm (see Fig. 7.10) and no longer the source of focus. Now, a high- fidelity prototype like the one shown in Fig. 7.11 is used to firm up the remain- ing requirements and design details. Coded Prototype Assumptions Requirements Development Business Functional Audience User needs Design 5 Technical Paper Prototype Assumptions Requirements User needs Business Design Functional Technical Audience Development User needs FIGURE 7.10 Late high-fidelity prototypes come closer to resembling a software product as well as the requirements.Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Verify Prototype Assumptions and Requirements CHAPTER 7 237 FIGURE 7.11 Late prototypes resemble the real software as the requirements become firmer, and more advanced prototype development can take place with greater confidence.Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 238 User Experience Re-Mastered: Your Guide to Getting the Right Design ITERATION 6: FROM CODED PROTOTYPE TO SOFTWARE REQUIREMENTS In the last step, specifying the requirements from a late high-fidelity user-facing prototype (here in the form of a coded prototype) enables us to, finally, say that we have validated all the software requirements (see Fig. 7.12). The worksheet that was the basis for evaluating the prototype requirements could now almost double for a table of contents or central reference point for the software require- ments. So the journey from the interplay of assumptions and requirements is now complete with the final product shown in Fig. 7.13 ready to ship; prototyp- ing has been the primary aid in validating assumptions and transforming them into requirements. Although, it is important to note that prototyping has been an aid, not the sole source of requirements validation, such as focus groups, usability testing, market research, and competitive analysis. Software Prototype Assumptions Requirements Business Functional Audience User needs Design Technical Development 6 Coded Prototype Assumptions Requirements Development Business Functional FIGURE 7.12 ...