Graph by Dave Corby (2010) based on Guide to the Software Engineering Body of Knowledge (SWEBOK) by IEEE Computer Society (2004) Customer Requirements Requirements Specification Functional Specification Design Specification Validation Review Verification Study the requirements Clarify the requirements Write the software Test the software Validate against requirements Review with customer Define new requirements Software Development Life Cycle
Customer Requirements Requirements Specification Functional Specification Design Specification Validation Review Verification Study the requirements Clarify the requirements Write the software Test the software Validate against requirements Review with customer Define new requirements Software Development Life Cycle PLEASURABLE USABLE RELIABLE FUNCTIONAL
Personas • Are descriptive representations of the people who use your product and the context they operate in • They make assumptions about users visible • They provide a frame of reference for your team • Validate with user interviews and surveys
Persona Context • Relationship with product • Platform, programming language • Experience / skill level • English proficiency • Motivation • Resources • Role in the organization
Who are my users? BENNETT backend web developer, prefers Java, CS degree from UC Davis, full time developer, advocated to use our product RACHEL web designer/developer, prefers JavaScript/Node, no degree but strong developer, had no input on using our product JANE iOS developer, "unicorn" designer and developer, self-taught, moonlighting on her own projects, makes recommendations on products ANDY self-proclaimed geek, comes from IT background, likes to script things together using Python, hobbyist hacker
Passive Usability Testing • Examine support requests • When are they asking for help? • Frequently asked questions • Frequently misunderstood concepts • Frequently hit errors
Passive Usability Testing • Examine support requests • API usage during an integration • How long between app registration and first request? • What are the first requests and first errors? • How long before going to production?
Passive Usability Testing • Examine support requests • API usage during an integration • API usage after an integration • Detect based on IP address, user auth, requests increase • What endpoints are being used? How are they used? • Anti-pattern detection based on request volume or type
Active Usability Testing • Existing APIs: “Dumb Pair Programmer” • With a user you trust in their natural environment • Silently observe as they work: • Interactions with team: how do they talk about you? • How do you fit into their application? • How does the user approach the integration with you? • What problems do they encounter? • How do they test the integration?
Active Usability Testing • Existing APIs: “Dumb Pair Programmer” • New APIs: Throw-away prototypes • Create a mock API: just enough functionality to be used • Document it: reference docs, just enough conceptual info • Create a well defined project ready for an integration • Hire an outsider who doesn’t have insider assumptions • Have user record screen, face, voice with Silverback • Have user commit to Git at regular interval
Active Usability Testing • Existing APIs: “Dumb Pair Programmer” • New APIs: Throw-away prototypes • Analyze the data for moments of emotional response • Happy • Sad • Confident • Frustrated • Confused
Active Usability Testing • Existing APIs: “Dumb Pair Programmer” • New APIs: Throw-away prototypes • Analyze the data for moments of emotional response • How long did it take to accomplish tasks? • What worked? What didn’t work? • How can the good things be more affirming? • How can the bad things be prevented? • How can the situation be corrected better?
jeremiahlee
jmatsu
heronshoes
kinocoboy2
hitokun
cer
shoheihosaka
yucamm124
squer
dalance
fornewid
ayaka1230
nearme_tech
zakiwarfel
malarkey
kneath
morganepeng
geeforr
jmmastey
kastner
keathley
cherdarchuk
lemiorhan
jonrohan
trallard