1. User Interface Requirements in the Real World Experiences and Lessons Learned Bob Nicholson bob-n@wygk.com 10/29/141

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 10/29/142

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

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 10/29/144

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 (Of course, if you are writing the requirements, you’ll get it right by incorporating the lessons we’ll discuss.) 10/29/145

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 (“fighting the last war”) 10/29/146

7. Why Requirements are WRONG (3) Copying Other Applications o Often not appropriate o Interface Pizza o Backward-looking (legacy and technology*) 10/29/147

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 10/29/148

9. Getting Good Requirements (1) Use Questionnaires or Interviews o Likes and Dislikes (especially useful for UI) o Colors and fonts (preferences, company standards) o “Mood” and UI message goals o Language(s) o Target Users (age, gender, education, training) Review Documentation and Training Materials Engage Actual Users (understand workflow, but keep priorities in mind) Observe the System End-to-End Question, Question, Question 10/29/149

10. Getting Good Requirements (2) Written 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 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 10/29/1410

11. Pre-Project Requirements Need to Commit Based on Bad Requirements Minimize the Risk: o 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 10/29/1411

12. Requirements Management 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 10/29/1412

13. Summary Take Charge of Requirements Have a Plan for Requirements Inform Client of Need for Review & Updates Schedule and Budget for Interface Review Review documentation, engage users, view end- to-end system, determine business priorities, incorporate knowledge of IU/UX technology & best practices Plan for Documentation and Training Plan for Interface Transition / Rollout 10/29/1413

14. Working with Graphic Designers Experiences and Lessons Learned Bob Nicholson bob-n@wygk.com 10/29/1414

15. 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 10/29/1415

16. Trust Your Designer Set Individual Preferences Aside Choose a Designer based on past work Make sure Designer understands requirements Tell designer what you need o Provide wireframes and screen types 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) 10/29/1416