Mind the Developer Experience
Developer experience is a lot like customer experience. It can have a big impact on the end-customer experience of the API-using application as well. Depending on maturity level there are different aspects to developer experience.
Developer experience is linked to both business, product, and technical features but also to marketing and communications
"Finding the API"
" Getting Access to It "
" Compatibility of features to needs, does using the API save time and effort or bring some advantage that you wouldn’t have without using it "
"Knowing what it can be used for "
" Understanding Specifications "
" Sustainability of formats, endpoints and authentications "
" Cost of using it "
" non-functional requirements: latency, reliability, security and error handling of the API to suit the needs of a particular application. "
" Being able to give feedback, knowing about changes, the image, and brand of the company offering the API "
Developer experience design starts when the API is designed with API Canvas. See also API Consumer Interview -template to understand the specific technical needs of your API consumers.
In addition to the API it self, there are many assets that help developers to learn a new API.
Developer portal or documentation site UI design. Usability and graphics are both important.
Use company branding and content creation guidelines. But remember, your audience is much more technical than the average customer.
Can all your API consumers access all APIs?
Depending on developer portal capabilities and API -specific configuration developers can subscribe access to APIs with
self-service with approval workflow
Content and communication guidelines
All human readable API documentation pages should be created automatically from API productization and OpenAPI documents. Masters should be stored and edited using version control, not just in the developer portal / documentation site.
Content, language, what information is shared, which channels and formats are used, etc. should be planned and optimized for your developer community.
Terms and conditions for using our APIs are important. Remember to create them together with business, legal and technology people. They need to address privacy and re-use, service levels and data ownership. Try to still keep them understandable.
You can create SDKs or provide code snippets. Remember that not all developers undestand cURL and that maintaining SDK will require work. Your Developer Portal may provide you a way to generate code snippets automatically from an Open API definition.
Presentations and demos help developers understand what they can use the API for. They may also need help in using the tools or figuring out the authentication. so make sure you address that, too.
Think how you are going to collect feedback and feature suggestions.
Choose your identities carefully
Pay a few moments of attention to how your API Consuming applications and developers need to authenticate to your APIs and your developer portal. Your priority maybe to make it very easy, but remember to make it secure enough.
Some additional things that can impact developer experience:
Marketing communication (ads, swag, press releases…)
Monetization (API pricing and payments handling) can be used, if your API business model requires it and your own or your API management platform supports it natively or by connecting to payment gateways.
Customer stories (testimonials, interviews etc.)
Release notes/change logs
Plugins and ready-made integrations