Designing great API developer experiences – Part 2
Learn why it is important for your organization to recognize the developers using your APIs as customers, and give them a great developer experience.
When you start to offer APIs to developers, it is critical to design a great experience for the developers using your APIs.
There are several aspects to a great developer experience: In Part 1, I talked about how the functional aspects of APIs must be accompanied by this great experience. And in this post, I want to explain why it is important that your organization to consider the developers using your APIs as your customers.
The developers using your APIs are unlike the other customers of your organization, they form a new customer segment. This customer segment of developers exists alongside your “regular” customer segments.
For example, an airline sells flights to passengers, with passengers being their typical customer segment. If this airline starts to offer APIs, it offers the APIs not to their typical customer segment, but to developers, who make up a new customer segment. These developers build innovative apps using the airline’s APIs.
The message here is: Your APIs are being offered to a new type of customer – the developer.
How do you create great developer experiences?
Now that you have established that a developer is a customer, you also need to treat the developer like a customer. And this includes that you need to give the developer, as your customer, an experience – a customer experience.
Building customer experiences is nothing new for most organizations. Your organization probably already builds mobile apps and web apps with great customer experiences. You simply have to transfer what you do for your existing customer segment, to the new customer segment of developers. This includes the approach, methods, and rigor of building customer experiences.
Known for technology products that delight their customers, Steve Jobs never got tired to stresses the importance of customer experience, even subordinating technology to the customer experience.
“You have to start with the customer experience
and work back towards technology, not the other way around”
So, take Steve Job’s wisdom to heart and don’t start by building technology (e.g. your APIs or also your Developer Portal), but start with a deep understanding of the developer and the developers’ customer experience. Apply product management techniques such as design thinking to a tech-heavy product like APIs.
To create a good experience for developers, the minimum you need to understand before moving into building any technology is:
- Who is the developer? Create different developer profiles, taking the needs to different developer roles and their preferences into account. Developers might use different programming languages, are more or less familiar with the business domain you APIs represent, they might be deep into the code or they have a high-level architectural view. Who should your developer experience appeal to?
- Next, think about what does the developer want to do? Figure out the “tasks to be done” for each developer profile. Developers don’t just develop, they explore new possibilities, test their applications, harden the security of the applications, fix bugs, analyze logs, and debug operational issues. A good developer experience needs to support all these tasks. And a good way to accomplish this is via a developer portal.
- Based on the intended customer experience defined by (1) and (2), you can then build technology (the APIs) and the API developer portal that supports the customer experience.
In the next part of this blog series, you will dive deep into customer experience modeling. I will show you step-by-step how to perform steps (1) and (2), finding out who the developer is, and what they want to achieve. These are two crucial, but often overlooked steps for building great developer experiences.
Want to dive deeper into the topic? Check out the video below on creating great developer experiences.
Part 1: https://blog.softwareag.com/api-developer-experience/