Is DX the new UX?
And by the way - how does this relate to APIs?
UX – or User Experience – has been a great differentiating factor, separating sites that succeed in the digital era and those that do not. Great user experience gives the user clear guidance on what to do on the site, what the site is about and how you should go ahead completing the task that you are there to do. With the growth of the API economy and the importance of a well-thought-out API strategy, the way your APIs are designed is becoming more and more an important aspect of your IT strategy. The Developer Experience – known as DX – has therefore become a crucial factor in the success of your APIs. A good DX can effectively streamline your implementation process without leaving room for much confusion, or the need for assistance. A good DX will ultimately leave more chances for a good UX and determine the success of the product. Examples of good DX are:
- The documentation of how the developer should use the product. There should be tutorials and code examples including examples of best practices for code organisation and platform integration. Different tools or sample apps should be included.
- The APIs should be as standardized as possible, with known models, schema and naming conventions.
- The developer should have explanation on design decisions, but more importantly, it should have information on where the API is going: By including a roadmap for the API and information on changes or coming revisions, it makes it possible for developers to plan ahead and maintain consistency in the use of the API.
By developing APIs with a product management principle in mind (API as a product) - and having a clear view of how and by whom the product will be used - you are well under way to success in API-development. There are several examples of failing APIs exactly for the lack of such an approach:
One of the best known is Netflix and their first open API. The first Netflix API had a string of issues that complicated the developer experience and finally, in 2014, led to it closing down. The API was managed without users in mind and changes was made without communication with the developers who utilized the service. This meant that several of the applications that used Netflix data stopped working. Without the proper API management, the API also did not innovate as expected, and developers started to move off the API. This lead to a negative spiral with the closing of the public API as a result. However, the whole Netflix API story did not stop there. In that same year, a new Netflix API was developed and released. With their new private API-system they seemed to have learned from earlier mistakes and the new API became a success.
The message is as follows - treat your API as a product. Gain knowledge of the users of your API, and their users again. Respect the information that they require, and be open about the API-roadmap and further developments. By doing so, you keep developers happy. And a happy developer is - as we all know - a good developer!