DX is a new UX
In the global village, fewer projects will be able to cope as standalone products and they will have to look for their competitive advantages in integration with popular tools or being active in terms of building synergy strategies thanks to their integration offer
Let’s start by defining the DX concept
Developer Experience is the equivalent of User Experience when the primary user of the product is a developer. DX cares about the developer experience of using a product, its libs, SDKs, documentation, frameworks, open-source solutions, general tools, APIs, etc.
DX from two perspectives
If you provide a product such as an API, you should look at it from two perspectives — how does it work and how does it look like?
How it works — end-point structure, language clarity, good practices, there are better resources how to do it on the web, e.g. Zalando guidelines so this article will not compete with it or be about it, but it’s homework that you should do
In this article, we will focus on the key non-technical aspects of the developer’s experience related to the API offer
DX best practices with examples
In my opinion, the best two examples of DX on the market are Twillo and Stripe, which is probably because their product is delivered mainly via API services
Let’s break down each of these examples into prime factors, what are their strengths
Stripe
UI/UX:
Although this is an offer addressed mainly to the developer, the Stripe is obsessed with good design, always in line with current UX/UI trends.
Clear, simple page layout and aesthetic showcase of selected functionalities, animations on the page shows the simplicity of Stripe integration
Code snippets:
Another nice result of the guys from Stripe is the idea of code snippets which are literally everywhere. What’s more — they support in terms of that most popular programming languages
..as a result, the development process seems to be less frictionless, faster to start.
For each API request, Stripe shows an example of the response structure which you can modify as well by defining your own param values
Built-in integrations
For every success of each platform a sensible, thoughtful offer of integrations with the most popular tools allowing the use of 3th-party providers, and thus enabling developers to be productive from the very first day and shortening the development time
Examples:
- the entire large repository is available here — https://stripe.com/en-pl/partners/apps-and-extensions
“Little pleasures”:
There is much more of stripe advantages, there are a lot of little things that make using a stripe easy and nice to use:
- thoughtful REST vocabulary — I mark it here as just a small point, but it’s really a lot of work of architects, the result of which seems to be an obvious structure of endpoints and thus easier understanding of the API platform
- Offline access
- API live status
- Changelog
- Dark mode
A few open-source libraries that will give you a fairly smooth landing on this topic:
Documentation:
https://v2.docusaurus.io/ (free, open-source)
API Reference:
https://swagger.io/ with https://github.com/Redocly/redoc (free, open-source)
Paid resources:
https://stoplight.io/ (api docs, developer portal)
Twilio
Another example of good practices related to designing an API-based experience can be Twillo, there can also be considered as an API-first offer so let’s break down each of these examples into details, what are their core strengths?
On-boarding
The first step is to identify the persona by dividing them into technical and non-technical users, the consequences of this decision are important for the next steps of on-boarding.
In the technical path, a subset of default developer tools which twilio offer are sandbox, pre-build helpers or cli-tool is a great help for the technical user.
Studio
A strong direction in the context of the development of technical tools is no-code, on the one hand it gives easy opportunities to start working with the tool, create relatively complex workflows for a non-technical user but it raises other tradeoffs such as problems with maintaining and optimizing the code, but it allows you to easily define business logic
Similar practices can be noticed on the Polish market, e.g. makeitright test automation tools or among global players, e.g. uiPath
SDKs
An example of a ‘black belt’ in the DX context is the creation of an SDK for the most popular languages or frameworks, this practice significantly minimizes the cost of integrating the service with the current tech stack
The Twillo SDK supports all popular programming languages: C, Java, Node, PHP, Python, Ruby
Each SDK has a list of its own tutorials ensuring easy E2E on the basis of the most popular use cases
Conclusions
DX seems to be crucial for ease of integration, adoption of your tool, below are some simple points you can do to make life easier for developers and business users using your platform
Focus on:
- Good, comprehensive documentation
- Defining popular use cases and tutorials that allow you to easily reproduce them
- frictionless experience for major programming languages
If your platform is a bit more mature, you can focus on refining your offer:
- thoughtful traceability
- integration offer with third-party providers
- SDK
_
Find&ping me on Twitter(https://twitter.com/WojtekSmajda) or Linkedin(https://www.linkedin.com/in/wsmajda)
