Usability of APIs – Developer experience (DX) and Developer Journey

Developer Journey

I have not found a lot of references or a formal definition for Developer Journey on the web. So here is my personal take on it.

To define the term in perspective to writing an application around a concrete API that the developer has in the beginning no previous knowledge let’s look at what the words means by themselves:

The developer in this case is a self-motivated, often external software development professional and/or aficionado.

The journey is the inauguration to the specific software ecosystem that exists around a specific API or platform. More literal, it is the trip someone has to take from becoming aware of a specific API, or a category of APIs including selection of a specific API from a set of competitors, finding out how to implement a certain idea, signing up for API access, implement (hack) the first simple use case around the API, make it to a fully-fledged app(lication), publish it, and eventually monetize it.

Overall it is about how developers experience their first and repeated encounters with an API and how they and their perceptions of the API change along the way. The journey starts with a first encounter or before with just hearing or reading about it, goes on through onboarding to releasing an application using the API in question.

Some factors that are influential are API Discovery (How do potential developers find out the API exists at all?), Developer Evangelism (How do they find out if they want to use it?), API Onboarding (How do they sign up? How easy is it to implement the first “Hello World”? Do they get an SDK is case the API is very complex?), Developer Relationship Management (If they stick with the API how do they receives update about changes and enhancements? Is the price right, are terms and conditions in a way that they want to stay with it? Do they get any help to publish and advertise their applications?)

Developer Experience (DX)

The way I would see it, it is the part in a Developer Journey that is most closely related  to the concrete hands-on experience of an API integration developer (be it a mobile app development hipster or a traditional SOA-type integration developer) and the daily ups and downs of developing an app(lication) around a certain API and platform.

It is influenced by key elements as the technical design of the API (how RESTful is it, how adequate for a purpose, certain protocols and common practices respected) and documentation (is it concise, well-structured, interactive, …).

Purely technical / API centric DX discussions derive from UX, and interaction design. In this case the user is the developer and the interface being used is an API. In this context there is currently a lot of discussion proper ReST style of APIs, “hackability” of URLs, etc. When you extend the term to SDKs or libraries that wrap an existing, the discussion is not so much about the URLs, RES and HTTP, but on the interface this piece of software provides to the potential user.

DX - Additional reading

For DX there is some published material available. Some additional can be found in the attached article (PDF) which takes it very scientific and was presented an IEEE conference (http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6225984). If you want it somewhat lighter look at the Pam Fox presentation in SlideShare (http://de.slideshare.net/wuzziwug/developer-experience), or the UX Mag article (http://uxmag.com/articles/effective-developer-experience).