According to PwC survey (2018) one in three consumers (32%) say they will walk away from a brand they love after just one bad experience. 73% of all people point to customer experience as an important factor in their purchasing decisions. 65% find a positive experience with a brand to be more influential than great advertising. Empathy towards customers has been important for success among B2C.

Empathy is the ability to understand other people’s feelings. It is about becoming aware of what other people feel and sharing their emotions. It serves as a way to link yourself and another person together. When talking about “putting yourself in someone else’s shoes”, you’re referring to empathy. (source)

Of course the survey was about “traditional” B2C business and customer experience, not about Business to Developer (B2D) and developer experience, but still it gives us some hints about the importance of experience. Why would that differ too much with developers? They are people and consumers as well. Of course there’s differences. Developers are more allergic to marketing and force sales. They do not like fluffy texts filled with hype word. Developers prefer proof and direct practical solutions. In other words developers have better bullshit detectors and lower tolerance for such.

What great DX looks like in numbers?

Take for example Stripe which is globally known as top payments platform. Analysts estimate its revenue is about $1.5 billion in 2017 and valuation of $9.2 billion. The goal behind Stripe was simple—create a payments platform that “didn’t suck.” and “that there should be a developer-focused, instant-setup payment platform that would scale to any size.” Stripe has considered developers as the neglected force in global economy. According to Stripe “Developers act as force-multipliers, and if used effectively, have the collective potential to raise global GDP by $3 trillion over the next ten years.”

Developer eXperience is about interaction

Part of building and maintaining great API developer experience is to understand the consumers’ (aka app developer) daily life and how they prefer to interact with your API. I’ll return to this in the end of this article. Interaction is more than just consuming your API. Before developer can reach that point they need to explore and learn how your API works.

The API interaction is more and more built on top of 3rd party tools available on the markets already used by the API consumers

API Documentation is the most crucial support format of your API. Great API documentation is much more than just list of endpoints and parameter descriptions. Great API documentation offers code examples which can be copy-pasted to own development environment or even run on developer portal. This kind of live testing (console and alike) is an example towards what developer portals are going. Developer portals are not just collections of guides and documents. Those are more and more interactive environments which are expanded with help of 3rd party tools.

Browser based API consoles

API consoles are offered to interact with the APIs without writing a single line of code. For example Nordea Open Banking provides browser based API console.

The implementations of API consoles differ, but many of them suffer from too steap initial success. As a developer I should be able to run first API call without any extra steps. Requiring users to register first and then access token causes extra trouble for the exploring developer. That developer might be seeking out the API for their next killer app and if “sales” falls short on your API onboarding you’ll lose revenue.

Most of the browser driven consoles are part of the API management solution selected to be used. API Consoles implemented with API management keep the operations inside own territory and development. Thus API consoles have been quite common addition to developer portals and have provided means to interact with your APIs without coding.

Shopify sandbox environment console

The above example was Graphical API Console. Shopify offers command-line (CLI) tool as a console. In this Dungeons and Dragons version of API consoles, developer works in text input/output world. To be honest it looks more like a traditional code library which simplifies operations on the platform. Shopify console is intended to be used in sandbox alike environment to fiddle with stores.

In contemporary application development APIs are connected to own backend or sometimes directly to frontend. APIs are used instead of reproducing the logic again and again in different applications. More over some of the APIs are taken into use as a service. In other words someone else produces and maintains the API for you and you just enjoy the benefits in your application. This enables faster application development (shorter time to market) and less code to maintain and debug. The same logic can be found from developer experience implementation which often get the shape of a developer portal.

Expand outside your own territory

Nowadays developer portals are becoming more like one-stop-shops to get started with your API, but the interaction is more and more and more built on top of 3rd party tools available on the markets already used by the API consumers.

Technical support is the classical example of “3rd party tools” as many API providers have lively community in Stack Overflow (SO). SO is the place to ask other developers for help. Aside from technical support other aspects of productized APIs can be built upon 3rd party tools. This is the step we at Platform of Trust took in March 2019. We entered Stack Overflow and push our preview release customers to ask technical questions in SO as well as in our Slack. We encourage all developers to ask Platform of Trust related questions in Stackoverflow. Example https://stackoverflow.com/questions/55381785/how-to-list-all-products-in-platform-of-trust

Famous Stripe code console on their frontpage offers code examples how to get started with just around 5 lines of code. The console looks good and convinces prospecting customers both managers (decision makers) and coders. The practical value of it is still minimal. Guess what? That example is built on top of 3rd party tool - Runkit (https://runkit.com).

At Platform of Trust we have created initial developer portal which contains section for live API testing console. The most common application environment used by the developers is Javascript driven. I also did a small survey among the developers around Platform of Trust and they wanted to see code examples for javascript above all. Thus our developer portal will most likely have Runkit driven console with examples too.

Offering Postman collections is one popular option. Postman collections are offered as a quick start package for API consumers to explore your API easily and fast. Postman was the big success of API testing tools and more similar alternatives have emerged such as Insomnia. Many people use Postman Collections to document their APIs, either as a collection of example requests that can be easily shared among team members, or as public API documentation for customers.

At Platform of Trust we are about to enter creation of interactive elements of Developer eXperience. At first early 2019 we created 3-column API documentation with easy process to maintain it. The latter is important to make sure the API documentation is up-to-date. The result contains code examples (or at least placeholders) for the endpoints.

While taking advantage of 3rd party tools is fast and often cost effective way to build slick onboarding support, it also contains some risks. Just like with building applications on top of APIs, you should be prepared for the changes in the markets. Some of the tools you would use might radically change their business model, retire or just die. What happens to your API or platform business at that point? One alternative is to lean towards open source tools even if you buy them as a service initially. In case the service provider vanishes, raises the pricing too much or just pivots totally, you’ll have the opportunity to ramp up the service your self. Of course that is not cheap either but you don’t lose the support your product needs.

Don’t fall in love with your product

Fall in love with your customers, not your product. Regardless of the tooling selected to interact with your APIs, you should make sure your view of the developer solar system is correct. In the Developer eXperience solar system developer is always the “sun”. Too many API providers think they are next to the “sun” with their Developer Portal.

The above is right way IF you are doing Product-centric development. In reality if you look at the solar system from Developer’s point of view you and your APIs and developer portal are not that close. In the below picture you are doing developer-centric development (just like Stripe and other success stories).

Developer is most concerned about the application under development. Developer has problems to solve while crafting the application. Your APIs should provide slick and easy to use solutions to the problems. Developers are not flocking around your Developer Portal - it’s not the sun (nor the Earth) of their solar system.

Take the steps towards your customer

Step into the shoes of your customer (developer), analyze their bahviours, discuss with them, analyze their discussions in forums. Simple start is to build applications on top of your own APIs first, then push them to customers. Second thing is to use your APIs in own service development.


Some more to read from 100 Days DX