Developer Experience (DX) for developers is akin to User Experience (UX) for end-users. The API products that streamline DX tend to increase interest and retain a following. But it’s not only public-facing services; internal and partner APIs benefit from a focus on DX as well.

Developer portals can achieve quality DX by adopting discoverability, quicker onboarding, and accurate documentation. But good DX is ingrained into a well-designed API that follows best style practices too. Developer advocates are necessary to address issues and collect feedback to refine feature sets and create tutorials. This is only a primer to the many facets of DX.

In this article, we dig into how to create outstanding developer experiences for our APIs. To that end, we interviewed three experts in the field: James Messinger, Developer Experience Director, ShipEngine, Derric Gilling, CEO, Moseif, and Srushtika Neelakantam, Developer Advocate, Ably Realtime, to discover what they are doing at their respective groups to enhance services for developer users.

DX For Onboarding

James Messinger from ShipEngine.

The hallmark of DX is meeting your user’s needs, at whatever stage they are at. During initial use, these needs fluctuate based on the developer’s knowledge. But a general rule of thumb is to get developers to “Hello World” as soon as possible.

According to James, a developer portal should adapt to the consumer at any stage of their journey, but should especially consider the initial onboarding experience.

“For brand-new users, the portal should provide a guided onboarding experience, with a ready-to-use sandbox environment, API keys, getting started guides, and step-by-step tutorials,” says James.

Derric echoes this statement, encouraging API owners to “create an awesome onboarding flow” that makes it as easy as possible to start pinging the API. He recommends that API owners focus on the minimal number of steps required to deploy your solution. He encourages code snippets, copy/paste abilities, and “successfully received” messages for asynchronous processing.

Small DX enhancements can keep developers active and engaged. But it’s also essential to consider the rate of information disclosure. If your full configuration is complex, involving multiple integration points, these can be surfaced later using what Derric calls gradual onboarding.

Srushtika adds that well-structured documentation and video tutorials can highlight use cases. She emphasizes self-service capabilities like a sandbox for debugging can improve the onboarding process tremendously.

“Self-service developer tooling and onboarding guides are incredibly appreciated by the developer customers,” says Srushtika.

DX For Developer Dashboards

But DX does not end with onboarding. As developers mature their applications, they require documentation checkups as well as a center for account information. This is where a developer account dashboard comes in.

James notes that customers who have already been converted require a portal showing metric usage, billing information, release notes, and upgrade guides. A dashboard for easy access to account information is simply necessary to sustain an API-as-a-product business.

To see a minimum viable developer dashboard setup, create an account with Dark Sky to view their API console. They have a simple developer dashboard with API consumption rates, billing information, account balance, a reset API key ability, and other ways to maintain your account.

“Seriously, though, sometimes you have to move mountains to get developers to fully adopt and use your developer platform,” says Derric. He recommends the following for maintaining great developer portals that can support developers well after initial onboarding:

• Well organized, up-to-date documentation and working samples
• Framework specific SDKs
• One-click deployments
• Awesome support

DX For Developer Advocates

We discuss machine-machine connection so often; it can be easy to forget there are actual humans on both sides! Support engineers and developer advocates must have empathy for their users, a crucial human element to sustain relations and encourage use.

Derric recommends API owners put more effort into maintaining personal relationships with their user base:

“Create personal relationships with your developers. Learn from them and understand their use cases. Developers love talking about the projects they work on and can turn out to be your largest evangelists,” says Derric.

Srushtika Neelakantam from Ably Realtime.

Srushtika agrees that personal connections with developers can significantly benefit your program. She stresses that gathering developer feedback is paramount for early programs:

“Ask your users in a friendly way what you could do better with your docs, tutorials, events, community, etc., and what else they’d find useful,” says Srushtika. “You’ll definitely get a lot of pointers and a direction to go in.”

Srushtika also recommends staying ahead of the curve when it comes to new frameworks and hot programming languages.

Derric encourages building a team of informed dedicated developer advocates that are more than liaisons to engineering.

“Developer support is one of the best ways to learn where there are obstacles getting started with your platform. For small companies, even the CEO should have their hand in support,” says Derric.

DX For Developer Communities

Each developer community is unique in makeup. Developer advocates should seek to meet their user support needs and insert themselves where developers are active.

“API advocates should be wherever their customers are,” says James. “Determining how to prioritize your advocacy efforts is a matter of observing your community’s behavior and measuring different engagement methods for effectiveness.”

Our panelists recommend utilizing community discussion forums like Stack Overflow, Discord, GitHub, Reddit, or Slack to respond to questions from developers. James also notes advocates should consider hackathons, meetups, or exhibiting and speaking at conferences.

However, for early-stage API programs, Derric notes that some community activities may put the cart before the horse. He recommends focusing on a “single user experience.” This means building self-service tools, blog content, and prioritizing support for existing adopters.

“Don’t launch a community forum if you don’t already have an existing community,” says Derric. “As your developer program grows, more effort should be invested in nurturing and empowering the growing community, especially finding key influencers and evangelists.”

Nonetheless, the sheer amount of tasks involved in DX can be daunting. Srushtika notes that learning how to prioritize tasks and time management for such tasks can be difficult. She thus stresses API providers to consider what activities are most value-generating.

DX Time and Task Management

“Dev Advocacy teams have a huge range of responsibilities which all seem
equally important,” says Srushtika. “In such cases, it really comes down to prioritizing the various activities based on the value they offer vs. the time and resources you’ll need to spend on those activities.”

For example, Srushtika notes how presenting a talk or organizing an event may require considerable effort and time, and not directly guarantee value. Whereas investment in technical support, which could take minimal effort and negligible time, could yield greater results, including insight into first-hand feedback from users.

In addition to considering the time and output value for developer relations activities, Srushtika adds that DevRel investment should match overall company goals:

“Often prioritization of various DevRel activities is done based on the broader company goals for the quarter or year, but it is often a sweet spot between spreading awareness about the product, educating people on how to use it, and retaining existing customers by continually improving their DX.”

KPIs to Improve DX

Derric Gilling from Moesif.

What sort of metrics should developer programs be considering? If you are taking all these points to heart, you will hopefully notice more onboards, sign-ups, and more API key registrations – all the hallmarks of success. Or are they?

Derric notices that some KPIs used to measure developer experience are purely vanity metrics. Pageviews and sign-ups don’t necessarily correlate to an active platform or end developer success. In his words, “these metrics only measure acquisition, and do not account for what happens after sign up.”

Instead, Derric recommends API providers align all teams on two north star metrics which are more intimately tied to actual production use:

• Weekly Active Tokens: This number measures the distinct tokens accessing the API in a given week. This better reflects actual product usage, as opposed to sign-ups, which may not be real sustained users.
• Time to First Hello World: Time to First Hello World (TTFHW) is the time it takes for a developer to sign up, create a simple app or test, and make their first hello world (i.e., their first API).

James agrees with Derric that TTFHW is a reliable metric to consider. But still, you have a choice on what constitutes your API’s Hello World. James recommends tracking an action that is more meaningful than merely a first successful API request. For example, At James’s company ShipEngine, TTFHW is measured by creating your first shipping label.

James also encourages tracking trial conversion rates and recommends the tool Haxor for quantifying developer experience and measuring KPIs.

Srushtika also agrees that measuring DevRel is more complicated than sign-ups; correlating marketing efforts to revenue generation is tricky to achieve. “Developer programs impact the revenue and sign-ups in very indirect ways which could be very hard or sometimes impossible to track or measure,” she says.

Regardless, Srushtika recommends also searching for insights in the following areas:

• Content: Views of your developer-centric content, including tutorials or videos,
• Forums: Look for trends in engagement on support questions.
• Talks: Consider feedback from events and lectures, spikes in attendance, or views.
• Hackathons: Monitor the usability and hiccups during developer onboarding at live events.

“All of the DevRel activities feedback into the product, engineering, sales, and of course marketing, so DevRel has a powerful impact on various functions of the business,” says Srushtika.

Final Thoughts on Building Great DX

There we have it. In summary, here are some quick lessons we’ve learned on how to build quality developer experiences:

• Create a quick and easy onboarding process: As Derric says, “Build something that developers love and is easy to get started.”
• Build killer self-service tools and documentation: Do not hide docs, have self-exploratory resources at hand. The more you invest in developer resources, the less one-one support is needed.
• Prioritize developer experience investments carefully. Prioritize developer support – this should come before massive marketing campaigns. Consider the stage you’re at and build community tools appropriately.
• Use the right data and feedback to improve. Monitoring DX is tricky. Source feedback from your community, and consider tracking a stable metric tied to business value, like Weekly Active Tokens or TTFW.