How to Win at Developer Adoption When You Only Have A Few Minutes to Impress

Accelerate growth & conversions with these key developer onboarding strategies

James Messinger
Feb 14, 2020 · 6 min read
ShipEngine’s Redesigned Documentation Landing Page
ShipEngine’s Redesigned Documentation Landing Page

Developers can be a skeptical bunch, particularly when it comes to sales pitches and product marketing. They may land on your API because of a successful pay-per-click ad on a Google search, but their clickthrough means nothing if you can’t convince them to integrate.

You only have a developer’s attention for a couple minutes, if not seconds, so how you use that time can be critical to success. While product awareness will always be a necessary piece of the puzzle, simplifying the adoption process is ultimately going to have a greater impact on converting trialists to paid users. Developers want to be able to put your API under the microscope before recommending the integration, which means actually making calls to various endpoints to make sure things function as they expected.

So, the question becomes: How can you quickly and effectively demonstrate value through the way you onboard developers?

ShipEngine put together three key strategies that will help you accelerate growth by making it easier for users to adopt and consume your API.

1. Reduce Friction

A big responsibility when it comes to developer adoption is reducing the time to first ‘Hello World’. It is your goal to show developers the features they will care about the most — the ones that solve their biggest pain points. Developers already spend more than 10 hours per week working on APIs, and attention spans are shorter than ever before, so it’s important to make the onboarding process as frictionless as possible.

The first place developers are going to look is the first place you should optimize: the documentation.

UX should be a guiding principle regardless, but particularly when building out your documentation as it’s the gateway to your product. By implementing usability rules, like the UX Honeycomb, you’re able to foster a better experience for developers and users.

Is it optimized for “skim-ability”? Let’s face it, very few of us ever read instruction manuals front to back. Is it organized by section, popular feature, or using bold headers to segment the copy? Poor information architecture is a surefire way to lose trialists and create more support requests, therefore losing you money.

Multi-language code sample drop down allows users to select their preferred programming language

API documentation should include code samples for every API endpoint — ideally in multiple programming languages. If you can give them the information they need in the format they want, you’re one step closer to conversion. And be sure to provide a “copy” button to make it easy for developers to copy-and-paste those samples into their code.

By limiting the number of steps developers have to take to integrate effectively, you increase the chances of them having a favorable experience with your API. According to a 2019 survey, more than half of respondents cited better examples and sample code as the best ways to improve API documentation.

“Ease of use may be invisible, but its absence sure isn’t.”
- IBM

Another great way to reduce friction is by providing a sandbox environment where developers can “kick the tires” of your API without worrying about incurring costs or affecting production data. When a user is signed-in, they should see their actual API keys in your documentation code samples, rather than “insert your key here” placeholder text. That way, they can copy and paste fully functional code into their integration.

Access ShipEngine’s sandbox API key directly from the documentation

By reducing the friction developers experience throughout this process, you directly impact the reputation you hold within the developer community. Everyone wants to find ways to make their job easier and more efficient. If you can solve that problem for one developer, chances are they’ll share it with others.

2. Show, Don’t Tell

The best way to solve a problem is not to talk about the solution, show it. This strategy can be applied in many ways — from providing more descriptive error messages that actually give context to what went wrong, to case studies that demonstrate how its been successfully implemented for other users.

While code samples go a long way toward reducing onboarding friction, they still require developers to invest the time it takes to setup a new project and write whatever boilerplate code is necessary. Some developers may not be willing to invest that time unless you first demonstrate the value of your API. That’s where Postman Collections come in.

As ubiquitous as PSD files are for graphics designers, Postman Collections are a familiar format that lets API developers experiment with your API in a tool they already know and love. They can explore the various endpoints and test the functional features that they’re interested in — all without writing a single line of code.

Postman’s new visualizers feature makes it easier for developers — and break the barrier of entry for non-developers — to better understand the data being returned by your API. Instead of scrolling through hundreds of lines of JSON data, Postman visualizers show the information in an easily-digestible format that clearly demonstrates the value your API provides. Visualizers also encourage developers to experiment and interact with your API, which leads to discovery of new features and the formation of new ideas and use cases.

Postman’s Beta Visualizer helps simplify the way you digest data returned from any given API call
Postman’s Beta Visualizer helps simplify the way you digest data returned from any given API call
Postman’s Beta Visualizer helps simplify the way you digest data returned from any given API call

At ShipEngine, we’ve created an onboarding campaign around our new Postman collections, including a demo walkthrough, which acts as a way for potential users to experiment risk-free with an interactive tour of our robust shipping APIs, as well as current users to test workflows and debug their customized integration. Not only are you alleviating your support team of a few commonly asked questions, this interactive onboarding element provides users an effortless way to become a master trialist of your API.

3. Sit Back, Then Iterate

After these optimizations have been implemented, it’s time to sit back and start watching for the conversions. But, not all results are instant — part of the game is allowing time for your efforts to show results. Creating a tight feedback loop, by giving users a convenient way to provide input, allows you to gather results on what developers liked, didn’t like, and suggestions on features that should be implemented in the future.

Once you know what worked and what didn’t, iterate and evolve your strategy and your road map. Your API could be the most revolutionary on the market, but if developers don’t have a great experience integrating, and don’t get what they need, you’re not likely to convert them to loyal users.

These three key steps will help you establish a strong foundation for an onboarding experience that developers love, and a product that has a reputation for its ease of integration. To recap, here’s a list of elements that make for a great developer onboarding experience:

  • User-friendly and “skim-able” documentation
  • Multi-language code samples
  • Convenient, auto-populated sandbox API keys
  • Clear information architecture
  • Visualized data
  • Interactive tools
  • Data-driven design

If you’re able to tap into the experience developers want and need from your product, you will not only improve your trial metrics, but also improve the quality of your product for future users.

No matter how you look at it, it’s a win-win.

Better Practices

For individual engineers to the largest teams, Better…

Better Practices

For individual engineers to the largest teams, Better Practices is intended to distill knowledge from the Postman community. This is a place to learn about modern software practices together! Read more: https://medium.com/better-practices/introducing-better-practices-e9cf14cf0c88

James Messinger

Written by

Developer Experience Director @ ShipEngine

Better Practices

For individual engineers to the largest teams, Better Practices is intended to distill knowledge from the Postman community. This is a place to learn about modern software practices together! Read more: https://medium.com/better-practices/introducing-better-practices-e9cf14cf0c88