Dwolla has always valued keeping our API well-documented because we believe in the importance of growing the adoption of our product and providing tools for a seamless experience. While we get many compliments from our current documentation, users that work closely with the Dwolla API, including integrating partners, know there’s always more than meets the eye. As a product evolves to grow its offerings and functionality, the solution that was built previously may no longer be optimal. Thus we set out on a journey to level up Dwolla’s Developer Portal. 

The process of updating the experience and content of the documentation supporting a product can be time-consuming. However, understanding the objective of the updates is crucial to an effective result. Information that will ultimately influence the updated solution will arise from questions similar to those below: 

  • What are the main points of confusion or drop-off in the existing documentation?
  • What are the advantages of an optimized developer portal?  
  • What type of feedback has been gathered from users of the documentation?
  • How will you measure the success of the updates?
  • How will these updates add to the bottom line of the business?

Backing up the investment of improving documentation is something every developer relations team needs to consider.

Building Value With Your Core Audience

The core goal of any developer portal is to allow users to be productive at all stages of their journey, from pre-sale, to integration, to launching their integration and beyond. 

Whether that’s assisting a product manager with clearly defining requirements or walking developers through  their first successful call to the API, a developer portal is the gateway to a product from the outside—and a key resource used when acquiring new clients. Well-constructed documentation can also assist in the timely activation of a product—shortening your customers’ time-to-value and ensuring their investment into your API can bear returns quickly. During the integration, API customers should have a reliable way to retrieve information they need to solve their problems. Finally, expect active customers to refer to this documentation from time to time even after going live with a product. The quickest way to drive adoption of a new feature or enhancement released in the API is to provide users with a resource with thorough documentation, making it easy to access and even easier to integrate.

Being able to effectively speak to a wide variety of user personas at different stages of their API integration is indeed an incredible challenge, but also where a developer portal derives its value.

Building Value With Your Organization

A less obvious value proposition of an optimized developer portal is understanding the benefits yielded internally within an organization that simply allows teams to work smarter, not harder. For example, the Dwolla Developer Relations team builds quality documentation to help drive more natural adoption among clients and prospective users; in addition to reducing the number of technical questions coming into our more general developer forums. Teams across Dwolla feel confident handing off quality documentation containing information that will help prospective clients through their own buying journey, allowing them to experience the product, rather than simply hearing about its functionality. 

Customer support uses our developer portal to surface new feature enhancements to existing clients that allow them to expand or enhance their own product offering. Organizational development scales with great onboarding documentation, but a developer portal is another easily-accessible resource for internal stakeholders.

Where to Start

While it’s evident why engaging your core audience has value, one can find that there’s no true out-of-the-box solution to a developer portal. Looking at the API landscape, documentation varies greatly in how each organization pursues product education and integration, making getting started, building or overhauling a portal a daunting task. However, patterns will emerge if you keep an eye on your own ecosystem that may warn you of what actions need to be taken. 

We can break these patterns down into two categories: quantitative and qualitative.

Quantitative Metrics

At Dwolla, we use metrics as key indicators in determining how well the content is connecting to our core audience. Key performance indicators (KPIs) and other metrics will vary for each API provider, but these are two that we use at Dwolla to help define the greatest opportunities within our documentation.

Time to First API Call

When looking at documentation, it’s important to first understand ease of use and how quickly a developer can get started making successful calls to the API. Having a first impression of an API not only comes down to the design and UX of the documentation, but how easy it is to get going. A general high-water mark is to have a new user land on the documentation and subsequently interact with the API in around three minutes. 

sandbox dashboard report
A report to track time-to-first-request in the Dwolla Sandbox environment. There are definitely outliers within this particular sample, can we dig deeper and find patterns between these outliers to determine what barriers to success they had?

Drop Off Points When Integrating

While tracking success metrics is great for determining how your developers are finding value with the API, looking at road blocks to an integration can also bring value. Building trust with a user in order to capture their information, such as an email address upon sign up, should be treated as a type of win for your organization. 

So what happens if a potential platform user drops off during the onboarding process? Are there common API endpoints that integrating developers are experiencing 400-level errors with? What was the last API request the user tried before they left your service and stopped interacting? 

Use these data points to hypothesize what sections of the docs are challenging for users. This information should influence the updates to the developer portal so the next time a user signs up, you can have confidence they will find their way to making a final buying decision with your product.

use logging tools
Using logging tools to view requests resulting in a 400 error. In this case, a developer was having a particularly difficult time initiating a transfer. Are other developers experiencing the same? If so, how can the docs be modified to reduce friction?

Qualitative Metrics

Keeping track of various KPIs is definitely important in identifying improvements, but you should also be keen to observe and track common questions from internal and external users, even after you’ve revised common issues and roadblocks. Gathering internal feedback from your sales, customer success or technical support teams around what general inquiries keep coming up related to the product or developer documentation is another component to help with the analysis.

Here at Dwolla, we use Slack as a communication method for direct API and operation support for clients in our Scale pricing tier. This has been a great tool for us, as it doubles as a searchable repository for common questions. 

Other channels you can look for include:

  • Developer Forums Internally (your own hosted forum)
  • Developer Forums Externally (stackoverflow)
  • Intercom & Hubspot Chat Bots
  • Email & Social Media 

Ultimately, the qualitative and quantitative metrics you collect will greatly assist in how you optimize your dev portal.

Validating Assumptions

After taking stock of the quantitative metrics and finding repeating qualitative questions, start the process of following up and learning more about these issues with your core audience. While this project is centered around being a great resource for developers, the documentation as a whole is not exclusive to them. It’s a good idea to take a deeper dive to further identify your users and assess which personas are regularly visiting the documents. This will help with understanding what information is important to them.

Because different personas require different information, the Dwolla Developer Relations team performed some internal and external usability testing with a collection of our customers, which were made up of developers, product managers and UX designers. After interviewing them, we were not only able to validate our assumptions on weaknesses of our current developer portal experience, but also find opportunities of things to include in our next iteration.

Next Steps

There are many challenges to building an effective developer portal. Better understanding your weaknesses can help lay a solid foundation for improvement.

In our case, the Dwolla API had simply evolved over the past three years. And while our documentation content  remained effective, the content delivery was in need of improvements to effectively meet the expectations of our core audience.

Check out some of our initial updates to the developer portal and stay tuned for another blog that dives into the different technologies that we used for the enhancements. 

Stay Updated