Elements of API Excellence

Elements of API Excellence

Presented at Web Directions 2014. Video coming soon.

A1bbf2de1c3ef1db1c54d77d2ab17de2?s=128

Jeremiah Lee

October 31, 2014
Tweet

Transcript

  1. Elements of API Excellence Jeremiah Lee 2014-10-31T11:00+11:00 •

  2. Elements of API Excellence Jeremiah Lee 2014-10-31T11:00+11:00

  3. #DX #WD14 @JeremiahLee

  4. http://woodgears.ca/gear_cutting/template.html

  5. http://woodgears.ca/gear_cutting/template.html

  6. http://woodgears.ca/gear_cutting/template.html

  7. http://woodgears.ca/gear_cutting/template.html

  8. None
  9. ThatsNotHowGearsWork.tumblr.com

  10. None
  11. None
  12. None
  13. None
  14. None
  15. None
  16. None
  17. None
  18. None
  19. None
  20. None
  21. unintentionally

  22. selfishly

  23. blindly

  24. intentionally

  25. holistically

  26. Empathy as an Applied Science

  27. understand anticipate share feelings

  28. research in order to solve problems

  29. Empathy as an Applied Science

  30. 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
  31. Based on Aarron Walter’s Designing For Emotion FUNCTIONAL

  32. FUNCTIONAL RELIABLE Availability (uptime) Scalability (load, response time) Stability (consistency)

    Security Based on Aarron Walter’s Designing For Emotion
  33. RELIABLE FUNCTIONAL USABLE Intuitability Testability Corrective Guidance Based on Aarron

    Walter’s Designing For Emotion
  34. PLEASURABLE USABLE RELIABLE FUNCTIONAL Based on Aarron Walter’s Designing For

    Emotion
  35. 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
  36. Today, let’s talk about… 1. Personas 2. Passive usability testing

    with data 3. Active usability testing with real, live people
  37. 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
  38. Persona Context • Relationship with product • Platform, programming language

    • Experience / skill level • English proficiency • Motivation • Resources • Role in the organization
  39. 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
  40. Passive Usability Testing • Examine support requests • When are

    they asking for help? • Frequently asked questions • Frequently misunderstood concepts • Frequently hit errors
  41. 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?
  42. 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
  43. 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?
  44. 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
  45. 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
  46. 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?
  47. The secret to  machines talking to machines  is

    to speak human first.
  48. Thank you for your time. More content available at
 http://dx.jeremiahlee.com

    Please support the
 Electronic Frontier Foundation