Prototype, UI, Ux , and Risks

1. Prototype, UI, Ux, and Risks Supannika KoolmanojwongCS577

2. Outline • UI Risks • Prototype • User Experience • Human Interface Guidelines @USC CSSE

3. Types of Prototype • Throwaway prototyping • close-ended prototyping, rapid prototyping • Informal, paper prototyping, storyboard • Evolutionary prototyping • breadboard prototyping • Build a robust prototype and constantly refine it • Incremental prototyping • separate prototypes merged at the end • Extreme prototyping • HTML pages > fully functional using a simulated services layer > services are implemented http://en.wikipedia.org/wiki/Software_prototyping

4. Dimensions of Prototypes • Horizontal Prototype • Broad view of an entire system or subsystem, focusing on user interaction • Confirmation of user interface requirements and system scope • Demonstration version of the system to obtain buy-in from the business • Develop preliminary estimates of development time, cost and effort. • Vertical Prototype • Complete elaboration of a single subsystem or function • Refinement database design • Obtain information on data volumes and system interface needs, for network sizing and performance engineering • Clarifies complex requirements by drilling down to actual system functionality http://en.wikipedia.org/wiki/Software_prototyping

5. UI Risks • New to client (success criteria): IKIWISI • New to client's organization: changes in the way business is done @USC CSSE

6. Top 10 risks @USC CSSE

7. Prototype in 577ab • Focus on addressing the highest risk items • Login/logout module ? • Proof of concepts/algorithms • Check interoperability between COTS/Services/modules • Show progress to clients, consolidate the idea @USC CSSE

8. Models – Tools to Expose Risk • System Boundary and Interface Model • Benefits Realization Model • Success Models • Models of Model Clashes ("Model Clash Web") • Cost and Schedule Estimates (from COCOMO II) • Project, Transition and Support Plans (modeled in MS Project) • OCD, SSRD and SSAD • UML 2.0 Models • for client: Activity, State and Use-case • for developers: Class, … • Core-Capability Drivethru • Prototypes @USC CSSE

9. Good GUI prototyping tools • iRise • Balsamiq Mockup • IPlotz • FlairBuilder • MockFlow • Pencil Project • Hot Gloo • Cacoo @USC CSSE

10. Prototypes • Low-tech prototypes to explore concepts (not as status assessments) • “test-drivable” prototypes • Functioning prototypes • status assessment @USC CSSE

11. Low-Tech Prototypes • Kind: • throw away prototypes • to explore concepts • not as status assessments • Process • Role play use of prototype in alternative TO-BE work processes • Stimulate creative discussions with: • “What would happen if…?” • “Had you thought about …?” • “If we did X, what would happen?” • “What are strengths & weaknesses of…?” @USC CSSE

12. Low-Tech Prototypes @USC CSSE

13. “Test-drivable” Prototypes[Functional UI Prototype] • Executable Use-cases or State-machines • Simulated Application back-end; tool front end • iRise • Other tools? • Quasi-functional back-end:Produces "results", but maybe not sensible ones, as front end put through its paces • Mocked up website/pages; simplistic server • Functional (linked, …) website/pages; functional server • Prototype that evolves into system/product? @USC CSSE

14. iRise “Test-drivable” Prototype Samples @USC CSSE

15. Status Assessment Prototypes • Valuation Prototype • Sufficient for Stakeholder Commitments • Developers: clear understanding of software functionality • System/Project Requirements Engineer: can full-fill clients operational needs • Client: IKIWISI? • Foundations Prototype (even if in 577a): “Executable Architecture” • Demonstrate that you can integrate all the component types • Including COTS/OS, etc. • Stubs OK only for some (not all) to be developed capabilities • Demonstrate that something works: use eValid on integrated • Core Capability Drive-through @USC CSSE

16. Outline • UI Risks • Prototype • User Experience • Human Interface Guidelines @USC CSSE

17. Ux – User Experience Design • Focus on usability • Not look-and-feel • Attractiveness can be a part of it • Benefits for a good user experience design • More customers will be willing to purchase • More customers will resist doing business with competitors • More customers will recommend you @USC CSSE http://www.forrester.com/rb/Research/best_practices_in_user_experience_ux_design/q/id/54101/t/2

18. User Experience Design Best Practices • Become your users to know how to design for them. • Design first to avoid leaving user experience to chance. • Trust no one — test to make certain your users are happy. • Inject user experience design into your software development life-cycle (SDLC) process. @USC CSSE

19. Great user experience design @USC CSSE

20. @USC CSSE

21. @USC CSSE

22. UX 101 http://dashburst.com/infographic/ux-101-what-is-user-experience/

23. Wireframe Persona Acceptance Test

24. UX Development Life Cycle http://www.slideshare.net/ajkandy/an-introduction-to-ux-design-testing

25. Avoid Burdening Users with App-Management Tasks • “Users view your app differently than you do.” • As much as possible, restore the user’s previous state • Support Auto Save and Versions, if appropriate • Decide whether users need to explicitly quit your app • Avoid calling attention to file formats @USC CSSE

26. Mac OS X Human Interface Guidelines • Understanding of the Fundamentals • Great User Experience that Integrates Mac OS X Technologies • Attention to Detail  • Gorgeous Graphics and the Right Words Make a Positive Impression http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html#//apple_ref/doc/uid/TP30000894-TP6 @USC CSSE

27. Understanding of the Fundamentals • Resolution • Operating systems • Gestures, Clicks, and Keystrokes • User Help Is Unobtrusively Available • Multiple Users Can Use a Single System • Internationalization @USC CSSE

28. The Philosophy of UI Design: Fundamental Principles • Metaphors • file folders for storing documents • Users already have a “mental model” • E.g. - Email:  to create a new letter, select a recipient, and send the letter • Familiarity - standard user interface elements • Simplicity - streamlined and focused, not have to compete with the details for the user’s attention. • Availability – (accessible) Avoid hiding such components too deeply • Discoverability - providing cues, clickable = aqua color @USC CSSE

29. Explicit and Implied Actions • Explicit actions clearly state the result of manipulating an object • Select command that is available/active • Implied actions convey the result of an action through visual cues or context.  • Drag file into trash implies removal Consistency • Consistent to • Standard, other versions, other modules, users’ expectation @USC CSSE

30. Noun-then-verb • users can see on the screen what they’re doing and that users can point at what they see • User Control • Allow the user, not the computer, to initiate and control actions. • provide users with the capabilities they need while helping them avoid dangerous, irreversible actions • Feedback and Communication • When a user initiates an action, always provide an indication that your application has received the user’s input and is operating on it • When minimizes a window, it doesn’t just disappear. Instead, it smoothly slips into the Dock, clearly telling the user where to find it again. @USC CSSE

31. WYSIWYG (What You See Is What You Get) • no significant differences between what users see onscreen and what they receive in the final output • Use a preview function if necessary • Don’t hide features by failing to make commands available in a menu • Avoid providing access to features only in toolbars or contextual menus. Because toolbars and contextual menus may be hidden, the commands they contain should always be available in menu bar menus as well @USC CSSE

32. Forgiveness • making most actions easily reversible.  • Perceived Stability • standard graphical elements • a clear, finite set of objects and a set of actions to perform on those objects • Providing status and feedback by letting users know that the application is performing the specified task. @USC CSSE

33. Aesthetic Integrity • Your product should look pleasant on the screen • Keep graphics simple, and use them only when they truly enhance usability • Don’t overload windows and dialogs with dozens of icons or buttons. • Don’t use arbitrary symbols to represent concepts; may confuse or distract • All icons should be rendered at the highest quality • All text should be anti-aliased, which is automatic when you use the standard system fonts. • The font size and type should be consistent within a window • The control size should be consistent within a window—for example, don’t mix small and standard controls  • Always use checkboxes for multiple choices, not for mutually exclusive choices • Use push buttons for immediate commands such as “Open” • Avoid using push buttons to display pop-up menus or serve as tabs • Avoid using bevel buttons as tabs @USC CSSE

34. Focus on Solutions, Not Features • Avoid feature cascade. It can be very tempting to add features that aren’t wholly relevant to the main focus of your app, but doing so can lead to a bloated interface that is slow, complex, and difficult to use. Always ask yourself if a proposed feature directly supports the user’s goal, and if it doesn’t, leave it out. • Heed the 80-20 rule. The 80-20 rule states that roughly 80% of users use only a handful of an app’s features, while only about 20% of users might use most or all of the features. Thinking of your user audience in this way encourages you to emphasize the features that enable the main task and helps you identify the features that power users are more likely to appreciate. @USC CSSE

35. More UX readings • http://www.forrester.com/rb/Research/best_practices_in_user_experience_ux_design/q/id/54101/t/2 • http://viget.com/inspire/ux-101-the-wireframe1 • http://uxdesign.smashingmagazine.com/2010/10/05/what-is-user-experience-design-overview-tools-and-resources/

36. Team Prototype Presentation

37. Team prototype presentation • Assess from your high-priority requirements and risks of your project,  • pick 2 of the high-priority and high-risk items to prototype • 20 points  • Time: 7 minutes  • Date: Friday October 4,  • 12pm - 1:30pm in SAL 322 • 2-3:20pm in OHE 122 @USC CSSE

38. Team Prototype Presentation • Expected presentation content:  • Project overview • Requirements • Risks • Pick 2 high risk items to prototype and explain the support rationale  • Present 2 features / capabilities/ proof of concepts that you prototype • Grading Criteria • Quality of the prototype (8 points) • Quality of the presentation (5 points) • Value added to the project (5 points) Appropriateness of the choice of prototyping based on requirement & risk  • Time management (2)  • Post your presentation on your team website in the Valuation phase page @USC CSSE

39. Persona

40. Persona • Need to know exactly who your customers are • Personas provide you with the opportunity to integrate real User Experience all along your product development project. • Help product developers and product designers understand how to optimize the product around the ways the user will want to use the product • As detail as possible in all aspects that are related to your system • Generally 10 persona

41. Persona Development Timeline

42. Benefits of Persona • It requires a relatively low amount of effort, time, and cost. For example, you could interview internal users or conduct interviews with less than 10 users and create personas within two weeks. • Using personas and scenarios increases understanding and stakeholder buy-in. • Persona-creation requires fewer specialized skills, in comparison to other approaches. http://www.uxmatters.com/mt/archives/2010/10/using-personas-during-design-and-documentation.php

43. Persona mapping • Brainstorming high-level goals • Creating and decide on key personas • Taking personas • Fleshing out personas: their goals, features, scenarios and behaviors www.informit.com/articles/article.aspx?p=30099&seqNum=2

44. Persona

45. @USC CSSE Ref: http://www.youtube.com/show/onlinegamer

46. Basic Demographic: Age: Occupation: Hometown: Marital Status: Description • Goals & Aspirations Information Sources Attributes User Scenario @USC CSSE Ref: http://www.youtube.com/show/onlinegamer

47. User Stories vs Persona • “As a mom, I want to take and share videos of the kids so that I can share important moments with grandparents, aunts, uncles, and friends” • User Stories – Left brain, focus on functionality • Persona – Right brain, focus on outcomes http://www.agilemarketing.net/user-stories-agile-marketing-part-2/

48. Soccer mom - Ann Basic Demographic: Age: 34 Occupation: Teacher Hometown: Redmond, WA Marital Status: Married Description Ann is married to Jeff. They have two kids, Michael age 9 and Nicholas age 7. Twice during the week and every Saturday they’re on the sidelines at soccer games and practices • Attributes • Busy • Focused on family • Social Organizer • Goals & Aspirations • Document memories as the kids grow up • Share important moments with the grandparents, aunts, uncles and friends. User Scenario Jeff has a camcorder, but has taken limited pictures of the kids. Jeff doesn’t get to the weekday practices, and sometimes forgets to charge the camcorder before Saturday games. Ann doesn’t know how to use Jeff’s camcorder. Jeff can’t find the cord to connect the camcorder to the computer, so they watch the videos on the small screen of the camcorder itself. • Information Sources • Facebook • 5 minutes for mom website • Local paper • Grey’s anatomy http://www.agilemarketing.net/user-stories-agile-marketing-part-2/

49. http://www.agilemarketing.net/agile-marketing-user-stories/

50. http://becubed.me/2007/06/08/download-an-example-persona-used-in-the-design-of-a-web-application/http://becubed.me/2007/06/08/download-an-example-persona-used-in-the-design-of-a-web-application/ http://blog.ocad.ca/wordpress/gdes1b26-fw2010-19/2011/02/18/exercise-eight-ocad-student-personas/