user interface requirements in the real world experiences and lessons learned bob nicholson...
TRANSCRIPT
1
User Interface Requirementsin the Real World
Experiences and Lessons Learned
10/29/14
2
My BackgroundBS, 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/14
3
“Requirements” Mix
• User Interfaceo Design, Interface Elements, etc
• User Experienceo Data Model, Process (Context)
• Specific Functionality• Use Cases• Devices & Platforms• Performance
10/29/14
4
“Requirements” Phases
• Pre-Project:o Research Requirements from scratcho RFP (Request For Proposal) *o Marketing Requirements
• Project Initiationo Requirements Gathering / Refining
• In-Progress Project Review(s)o Change Requirements
• Web / Desktop Applications / Mobile Appso Different Release Cycles
10/29/14
5
Why Requirements are WRONG (1)
• Wrong PeopleoManagers, administrators, executiveso Limited understanding of the problemo 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/14
6
Why Requirements are WRONG (2)
• Wrong Problemo Focus on “Pain Points” rather than business
prioritieso Focus on legacy systems rather than future
(“fighting the last war”)
10/29/14
7
Why Requirements are WRONG (3)
• Copying Other Applicationso Often not appropriateo Interface Pizzao Backward-looking (legacy and technology*)
10/29/14
8
Why Requirements are WRONG (4)
• Lack of Technology / Industry Knowledgeo Not knowing what is possibleo Geolocationo Image recognitiono Audio Inputo Language translationo Expert Systems / artificial intelligenceo Back-end database verification services
10/29/14
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 goalso 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, Question10/29/14
10
Getting Good Requirements (2)• Written Requirements
o Create Use Caseso Validate with Users and Decision Makers
• Build prototype (wireframe tools, prototyping tools, RAD tools, web) and validateo May require multiple iterations
• Actual User Testing, A/B Testing• Documentation, Help, Messages and Training• UI Transition Plan
o Leverage Legacy Learningo Some Users Will Resist Changeo Incremental Change Sucks!
• Bottom Line: Redevelop the Requirements
10/29/14
11
Pre-Project Requirements• Need to Commit Based on Bad Requirements• Minimize the Risk:
o Conditional Commitmento Specify Requirements Gathering Phase
oRequire access to users and systemso Allow Time and Budget for Changes
• May Cost You Jobs! (But may get you better jobs)o Filter out problem clients
10/29/14
12
Requirements Management
• People Management / Project Management• Insist on a Single Authoritative Contact
o Assemble input from multiple peopleo May not be decision maker, but must have
direct access to decision makero You still need access to actual users
• Put Everything in Writingo Meeting minutes
• Get Everything in Writing (including approvals)• Timetable for Requirements Review by Client10/29/14
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 / Rollout10/29/14
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/14
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 typeso 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/14