In the final part of our series looking at the strategies businesses are using to engage with developers (B2D), we summarize three Developer Experience (DX) models from Brian Koles (ChallengePost), Pamela Fox (Khan Academy), and Ronnie Mitra (Layer 7). In the first part of our series, we looked at the API-coming-soon landing page and how to use this approach to draft up developer personas. In Part 2, we discussed the private beta release and how it helps to gain valuable feedback from early adopters. In Part 3, we reviewed API documentation and pointed to ways API providers are trying to provide the benefits of documentation without needing developers to leave their coding workflow.
Model 1: The B2D Checklist
Brian Koles, Business Development Manager at Challenge Post, has been guest posting a Developer Evangelist Playbook series on ProgrammableWeb since June this year. His first entry summarized the components that make up a strong B2D strategy. These include some of the mainstays - like a developer portal page and documentation - as well as encouraging ongoing communication via social media and by providing marketing asssistance to help developers who are making use of a provider's API.
Model 2: The How-Not-to-Suck Model
At the recent API Strategy and Practice conference, Frontend Engineer at Khan Academy, Pamela Fox, posed five questions that API providers need to ask to design a rewarding on-boarding experience for developers. Fox reminded API providers that a positive developer experience creates a multiplier effect in innovative usage of an available API and increased evangelism where developers are motivated to talk up and market an API (for free!) on a business' behalf. Fox's five question approach asks business API providers to imagine themselves as consumer-developers and ask:
- Do I want to use it? Here, consumer-developers are looking for trust signals like whether there is documentation available, whether licensing allows appropriate uses, and that API calls are affordable.
- How do I sign up? Fox believes the best approach is to avoid the issuing of API keys altogether, or to issue them automatically, with the worst experience being one where developers have to wait to hear back before being able to start playing around with an API.
- How do I get started? Fox urges providers to provide client libraries in common programming languages and to set a benchmark of enabling developers to be able to create a 'Hello World' case within 15 minutes.
- How do I use it? Fox insists that documentation should be comprehensive. Even shortcomings can be useful to let consumer-developers know when something isn't available, rather than remaining silent so that users potentially waste hours trying to code something that isn't going to happen. Fox encourages API providers to use interactive explorer tools - like JSFiddle - within the documentation.
- How do I get help? While Fox notes the importance of ongoing communication along the lines suggested in Koles' model (emails, forums, feedback forms, social media, etc), she recommends, above all, providing detailed error messages as a priority DX strategy. Providing sufficient detail for consumer-developers to receive a continual feedback loop heightens the satisfying experience of using an API and decreases the potential churn rate of developers who have a try and move on to another business' API solution.
Model 3: The 3-tiered pyramid
After surprising attendees at September's NordicAPIs event with a presentation that started with Powerpoint bullet lists and Comic Sans font to drive home the message of poor design, Ronnie Mitra from Layer 7 Technologies presented a three-tier model to designing an effective API and providing a great developer experience as a result. Mitra's tiered model focused on:
- Functionality: At the base of Mitra's model is an assessment of functionality, what does the API do and how reliable is the implementation, he asks. This is fine for an SOA deployment, where APIs can be described in a service catalog and developers are made to use what's available. But in these days of the 'API revolution', APIs are now deployed in competitive markets and need to attract developers to use them. As a result...
- The next tier of Usability comes to the fore: Here, usability trumps usefulness. So no matter the functionality, if it is difficult for API consumer-developerss to use, it will be left by the wayside regardless of how much it could change the world.
- With this in mind, the top tier of Mitra's DX Model is the Experience: Along the lines of Fox's model, Mitra urges developers to ask "how does using the API make me feel?" Like Fox, Mitra believes the strength of a B2D strategy is not just in the sum of the interactions between an API provider- and consumer-developers, but in the emotive impact using the API has on the developer.
Mirroring Jerome Louvel from APISpark's approach in Part 1 of our B2D series, Mitra encourages businesses to define developer personas, noting: "You can't design for usability if you don't know who is using your API." Mitra is still working on his DX model in full, but is finding that when an API has been designed with consumer-developers in mind, it is much more likely that it rates higher on key aspects of a successful API experience: engagement, pleasure, familiarity, trust and safety. Perhaps some of Mitra's suggested design aspects could be used by businesses when initially releasing their API, in order to measure the potential strength of their DX. Things like how quickly a new user can make their first API call, how difficult errors are to fix, and how many new concepts and terms must be understood before using a new API could all help track the potential level of future developer onboarding. As Brian Koles points out in his Developer Evangelist series, the battle to engage with developers is on. The number of APIs is growing at a much faster rate than the number of developers, so having a solid B2D plan is set to become an essential component of API design and deployment, if that moment hasn't already arrived...