1. User Interface Requirements in the Real World Experiences and Lessons Learned Robert Nicholson bob-n@wygk.com 2/10/151Robert Nicholson

2. My Background BS, Computer Science, California State University, Chico MS, Computer Engineering, Stanford University Hewlett-Packard, Software Engineer Sydis Inc, Engineering Manager Cognitive Concepts, Founder Plexus, Engineering Manager Oracle, Engineering Director Silicon Graphics / AT&T, Engineering Manager Sun Microsystems, Engineering Director InterSurvey, VP of Engineering StockMaster / Red Herring, VP of Engineering Ratingz Inc, Co-Founder, VP of Marketing LunaGraphica Inc, Co- Founder, VP of Technology Entrepreneur and Independent Consultant 2/10/152Robert Nicholson

3. “Requirements” Mix User Interface o Design, Interface Elements, etc User Experience o Data Model, Process (Context) Specific Functionality Use Cases Devices & Platforms Performance 2/10/153Robert Nicholson

4. “Requirements” Phases Pre-Project: o Research Requirements from scratch o RFP (Request For Proposal) * o Marketing Requirements Project Initiation o Requirements Gathering / Refining In-Progress Project Review(s) o Change Requirements Web / Desktop Applications / Mobile Apps o Different Release Cycles 2/10/154Robert Nicholson

5. Why Requirements are WRONG (1) Wrong People o Managers, administrators, executives o Limited understanding of the problem o No UI / UX expertise (and haven’t seen this talk!) Mix of People * o Different goals o Lack of priorities and process 2/10/155Robert Nicholson

6. Why Requirements are WRONG (2) Wrong Problem o Focus on “Pain Points” rather than business priorities o Focus on legacy systems rather than future o (There are always legacy systems) 2/10/156Robert Nicholson

7. Why Requirements are WRONG (3) Copying Other Applications o Often not appropriate o Example: selection spinner o Interface Pizza o Backward-looking (legacy and technology*) 2/10/157Robert Nicholson

8. Why Requirements are WRONG (4) Lack of Technology / Industry Knowledge o (Not knowing what is possible) o Geolocation o Image recognition o Audio Input o Language translation o Expert Systems / artificial intelligence o Back-end database verification services 2/10/158Robert Nicholson

9. Getting Good Requirements (1) 1.Understand the Basics: o Use Questionnaires or Interviews o Likes and Dislikes (especially useful for UI) o Colors and fonts (preferences, company standards) o “Mood” (professional, efficient, fun) o Language(s) o Target Users (age, gender, education, training) 2.Review Documentation and Training Materials 3.Engage Actual Users (understand workflow, but keep priorities in mind) 4.Observe the System End-to-End 5.Question, Question, Question (Why?) 2/10/159Robert Nicholson

10. Getting Good Requirements (2) Write (or re-write) Requirements o Create Use Cases o Validate with Users and Decision Makers Build prototype (wireframe tools, prototyping tools, RAD tools, web) and validate o May require multiple iterations Actual User Testing, A/B Testing Plan for Documentation, Help, Messages and Training UI Transition Plan o Leverage Legacy Learning o Some Users Will Resist Change o Incremental Change Sucks! Bottom Line: Redevelop the Requirements 2/10/1510Robert Nicholson

11. Pre-Project Requirements Need to Commit Based on Bad Requirements Minimize the Risk: o Make a Conditional Commitment o Specify Requirements Gathering Phase o Require access to users and systems o Allow Time and Budget for Changes May Cost You Jobs! (But may get you better jobs) o Filter out problem clients 2/10/1511Robert Nicholson

12. Getting Buy-In You are asking your clients to “buy in” to investing more time and $$$ in requirements Educate your clients: o Present UI design principles o Identify the information you need o Explain where the requirements fall short A well-written handout (with citations) on the process can help establish your credibility 2/10/15Robert Nicholson12

13. Requirements Management Requirements evolve in the course of the project Need to control and limit the changes o Requires People Management / Project Management Insist on a Single Authoritative Contact o Assemble input from multiple people o May not be decision maker, but must have direct access to decision maker o You still need access to actual users Put Everything in Writing o Meeting minutes Get Everything in Writing (including approvals) Timetable for Requirements Review by Client 2/10/1513Robert Nicholson

14. Summary Take Charge of Requirements Have a Plan for Requirements o Determine business priorities o Survey basic requirements o Review documentation o engage users o view end-to-end system o incorporate knowledge of IU/UX technology & best practices Inform Client of Need for Interface Review & Update Schedule and Budget for mid-project Interface Review(s) Plan for Documentation and Training Plan for Interface Transition / Rollout 2/10/1514Robert Nicholson

15. Working with Graphic Designers Experiences and Lessons Learned Robert Nicholson bob-n@wygk.com 2/10/1515Robert Nicholson

16. Design is Important Graphic Design is Critical to Success o Especially in Consumer Applications You are not a Graphic Designer o Designers spend years studying color theory, layout, typography, iconography, graphic development tools, etc. Design Fashions and Styles change – Magazines: by decade; web: by year – Current: Infinite pages, video backgrounds 2/10/1516Robert Nicholson

17. Trust Your Designer Set Individual Preferences Aside Choose a Designer based on review of past work Make sure Designer understands requirements o Provide wireframes and list of screen types Tell designer what you need o Unflattened Photoshop files, sized icons, font and color specifications, CSS files, etc. Get early designs and refine Incorporate graphic design in prototypes As far as possible, isolate design from code (e.g. css, WordPress themes) 2/10/1517Robert Nicholson