---
published: true
layout: post
title: Talking About Human Experiences Instead of the API Lifecycle
tags:
  - Experiences
  - Lifecycle
image: >-
  https://kinlane-productions2.s3.amazonaws.com/algorotoscope-master/america-immigration_dumping-ground-times-square-corner.jpeg
---
After talking with [Lorna Mitchell about OpenAPI overlays the other day](https://apievangelist.com/2024/12/12/api-evangelist-conversation-with-lorna-mitchell-openapi-specification-maintainer-with-the-openapi-initiative/), and continuing work on my API Evangelist platform, I found myself thinking a lot about API experiences. Human experiences like onboarding (ie. Documentation, Sandboxes), reliability (ie. Testing), integration (ie. SDKs), trust (ie. Performance, Security), access (ie, Registration, Authentication), and how we (API producers) tend to  conflate the API lifecycle for how people experience the APIs we are producing.

I’ve spent way too much time arguing about what the stages in the API lifecycle are with pundits and analysts from across the API universe over the years, and I have ultimately landed in a place where I don’t care what you call the stages of your lifecycle, just that you have them defined and agreed upon. However, as I sit back and think more about it this week, I still think we should be defining stages to better understand when something happens or should happens, but I really think those stages should reflect the human experiences of teams who are producing as well as consuming APIs. 

It is important to separate the human experience from the property of that experience as I have done above. Like onboarding is the experience, with documentation and sandboxes being a property of that experience. Now, if we come at this from a lifecycle perspective, but for both API producer and consumer--when should they experience documentation and sandbox? Well, as someone producing an API, when I need to produce documentation or a sandbox will vary on whether I am designing first or code first, and as an API consumer, the documentation and sandbox will come early on in my onboarding process, probably right after discovery.

When engaging with people around APIs, the number one challenge I encounter is that people aren’t grounded in time, space, or experience when trying to address common challenges. When should I do this? Are we talking about it from the perspective of teams producing an API or by the consumers of an API? I guess the point of my story is that we should be looking at and discussing human experiences over loose technical phrases and perspectives. Let’s talk about the experience a new team has producing an API, and what they will need to properly produce API documentation and sandbox. Let’s talk about what it is like for a new API consumer to onboard with those APIs. I feel like lifecycle is a very hand-wavy API producer, service provider, and analyst term we throw around, and instead we should be explicit about who we are talking about, what their experience is, and when that experience occurs.