Slide 1

Slide 1 text

Get to know your user for a better API | @ashmchang

Slide 2

Slide 2 text

Ashley Chang Product @ ReadMe @ashmchang | @ashmchang

Slide 3

Slide 3 text

The API Universe | @ashmchang

Slide 4

Slide 4 text

Why are we here? | @ashmchang

Slide 5

Slide 5 text

| @ashmchang

Slide 6

Slide 6 text

The average company spends 3-4 weeks writing & editing documentation. | @ashmchang

Slide 7

Slide 7 text

Documentation shouldn’t be so hard. | @ashmchang

Slide 8

Slide 8 text

Let’s fix the API Design Process | @ashmchang

Slide 9

Slide 9 text

This Talk 1. What’s a good API? 2. How we can change the API process to make our APIs better | @ashmchang

Slide 10

Slide 10 text

1. What’s the goal of an API? | @ashmchang

Slide 11

Slide 11 text

Communicate | @ashmchang

Slide 12

Slide 12 text

A good API is empathetic to the people using it | @ashmchang

Slide 13

Slide 13 text

Example: Slack | @ashmchang

Slide 14

Slide 14 text

Example: Star Wars API | @ashmchang

Slide 15

Slide 15 text

✨ MAGIC ✨ | @ashmchang

Slide 16

Slide 16 text

Example: Clearbit | @ashmchang

Slide 17

Slide 17 text

People want to use APIs (& things in general) that are easy to use. | @ashmchang

Slide 18

Slide 18 text

There are options Thanks, ProgrammableWeb! | @ashmchang

Slide 19

Slide 19 text

Your docs are your UI | @ashmchang

Slide 20

Slide 20 text

Your docs are your UI Your API is your UI | @ashmchang

Slide 21

Slide 21 text

2. How we can change the process to make our APIs better | @ashmchang

Slide 22

Slide 22 text

Creating an API looks something like... 1) Users request an API 2) You decide its worth engineering time to make an API (but not that much time) 3) Find the simplest way to expose the necessary endpoints 4) Write some docs 5) ! ! ! | @ashmchang

Slide 23

Slide 23 text

Product > API > Users | @ashmchang

Slide 24

Slide 24 text

| @ashmchang

Slide 25

Slide 25 text

Scaling your API → API users increase → Types of users on your API increases → They need more help Instead of an easy win, time is sucked into supporting partners on your API | @ashmchang

Slide 26

Slide 26 text

| @ashmchang

Slide 27

Slide 27 text

Users > API <> Docs | @ashmchang

Slide 28

Slide 28 text

User Centered API Design | @ashmchang

Slide 29

Slide 29 text

User Centered Design Design based on an understanding of users, tasks, & environments | @ashmchang

Slide 30

Slide 30 text

Example: Foursquare | @ashmchang

Slide 31

Slide 31 text

Let’s take this for a spin → Start by getting to know our user → Expose endpoints in a way that makes sense for them → More time up front, less time writing docs & supporting users later | @ashmchang

Slide 32

Slide 32 text

How to get to know your users 1) Talk to users 2) Make it usable 3) Make it stick | @ashmchang

Slide 33

Slide 33 text

Why talk to users → Perspective. How you feel might not be how other people feel. → Refine the problem. A good solution comes from a clear understanding of what the problem is. → Insight. What workarounds have people created? How successful is your solution? Users are experts on the problem, not the solution | @ashmchang

Slide 34

Slide 34 text

Interview Plan → Goal: What are you trying to learn about? → Target Audience: Define your target audience → Hypothesis on the Audience’s Goal: How & why the audience is using your API. → 5 questions: These should evaluate if your hypothesis is right or wrong. They are starter questions. | @ashmchang

Slide 35

Slide 35 text

Tips → Record it, if possible (take good notes if not) → Make participants feel comfortable → Use active listening techniques to focus their thoughts without leading → Pay attention to body language → Let it be organic | @ashmchang

Slide 36

Slide 36 text

Reaching People → Talk to inbound people → Send out emails → Use pop-up options in the service → Rewards → Set up a qualifying survey | @ashmchang

Slide 37

Slide 37 text

Starter questions → How did you find our API? → What do you do at [their company]? → Who from your team spends the most time with our API? → Did you already use something that does the same thing? → Can you tell me about a specific time our API has helped your team? | @ashmchang

Slide 38

Slide 38 text

Why | @ashmchang

Slide 39

Slide 39 text

Goals You want to understand: → motivations → workflow → expectations (what do they see as a competitor) → their decision making power | @ashmchang

Slide 40

Slide 40 text

Make your research usable Synthesize it into something → Personas → Jobs to be done (JTBD) | @ashmchang

Slide 41

Slide 41 text

Make it stick → Make sure your persona/JTBD is referenced in every step of building your API → Try to see your API and docs from the user’s perspective → Bring actual users back in for every step of the process! | @ashmchang

Slide 42

Slide 42 text

In Summary → Get to know your user before you start building your API → Release endpoints, and APIs, that make sense for the way they will use it → Write fewer docs! → Win developer ! and build a strong dev community | @ashmchang

Slide 43

Slide 43 text

Let’s start building delightful APIs | @ashmchang

Slide 44

Slide 44 text

Thank you! | @ashmchang

Slide 45

Slide 45 text

@ashmchang | @ashmchang