2015-02-04-best-practices-for-api-documentation-podcast-with-andrya-feinberg.html

---
title: Best practices for API documentation -- podcast with Andrya Feinberg
categories:
- api-doc
- podcasts
podcast_link: https://www.podtrac.com/pts/redirect.mp3?https://s3.us-west-1.wasabisys.com/idbwmedia.com/podcasts/andryafeinberg.mp3
podcast_length: 45586553
---

{% include toc.html %}

<p>I recently talked with <a href="https://www.linkedin.com/in/andryafeinberg">Andrya Feinberg</a>, a documentation manager and content strategist for Emotient, about best practices with API documentation. Below is a writeup Andrya has provided that summarizes some of the points she makes in the podcast.</p>

{% include audio.html %}

<p>Here is Andrya's summary of the best practices:</p>
<div style="border:1px solid #dedede; padding:12px; background-color: whitesmoke;">
<h2>API Documentation Best Practices, by Andrya Feinberg</h2>
<p>In the world of Technical Communication, Content Strategy, User Assistance, Information Architecture, and User Experience, there have always been best practices and industry standards. Each type of content, independent of which industry you are in, has its own set of rules, a style guide, and a terminology usage guide. </p>
<p>I live and breathe best practices and industry standards. Why? This is what helps me to create content that is easy to use, easy to read, easy to understand, and minimal. There's nothing more appealing than content that is simple, clean, and gives you exactly what you want. </p>
<p>When I created my survey on API documentation, I put myself in the user's shoes, as we should always do, and I wanted to make sure that I performed an exhaustive audience analysis. </p>
<p>Why would I put myself in the user's shoes and create content solely focused on the user's needs? Creating content for a specific user is what it's all about, and I can't emphasize this enough. It's my passion and my purpose. People don't have time to read through a sea of text to find the information they need. We are in a hurry and have a task in mind. At that exact time, we must find exactly what we're looking for. If we don't, we are left irritated and frustrated and must go somewhere else to find the answer. </p>
{% include ads.html %}
<p>I know that if I have to spend more than two minutes looking for what I need, I get a tad bit irritated. Okay, probably more than a tad, but you get the idea.</p>
<p>Every user has expectations, and it is the technical communicator's purpose and goal to not only meet the user's expectations but to exceed them. Make this your priority and your focus, and your users will thank you over and over again.</p>
<p>Here are the best practices for API documentation. These came directly from the responses that I received from engineers and developers that spend their lives in APIs with API documentation.</p>
<h2>Create content that is easy to use, read, and understand.</h2>
<ul>
<li>Create an exhaustive and concise plan for API documentation.</li>
<li>Make sure that you talk to all of your SMEs, engineers, and developers to create what they need and what they want.</li>
<li>Keep related topics together.</li>
<li>Focus on how you can provide the right information to the right user at the right time.</li>
</ul>
<h2>Make sure that the content is consistent and accurate.</h2>
<ul>
<li>Don't leave anything out, such as missing segments or examples of code. This is all levels of wrong! Leaving out part of a command or a call leaves users frustrated and irritated. What's worse is that they can't use (and don't trust) the API!</li>
<li>Make sure that the documentation reflects the way that the API works.</li>
</ul>
<h2>Include an 'overview' or an 'introduction'</h2>
<ul>
<li>Put this at the very beginning. Think of this as the 'landing page'. The most difficult part of adopting an API is at the beginning. If there is a learning curve, or if the developer is new to the programming language, this makes the content in the introduction even more critical to their success!</li>
<li>Make this 'minimalistic' (think simple, easy, minimal steps) that provides developers with how to use this API.</li>
<li>Include only the essential, critical information that developers need to know. The rest of your documentation will include the details or specifics of these items and more advanced concepts.
</li>
<li>Include information about the architecture and 'why' the developer should use this API.</li>
<li>Make it easy for a developer to get started!</li>
</ul>
<h2>Make it easy to scan.</h2>
<ul>
<li>Make this a single, long page document with hyperlinks. Don't go overboard on the hyperlinks. This just gets too messy and shows that you haven't organized the information clearly for the user.</li>
<li>Make sure that the hyperlinks work. There's nothing worse than clicking a link, and you get an error.</li>
<li>Keep related topics together.</li>
<li>Provide examples. This reduces the time developers spend learning and implementing the product. It also enables developers to make a call quickly and easily.</li>
</ul>

<h2>Make it clean, simple, and minimal.</h2>
<ul>
<li>Make it minimal. The most important piece of information isn't the home page, the sign-up page, or other pages on the website. It's the API documentation.</li>
<li>Make it simple. API documentation is core to the user experience. </li>
<li>Make it simple. Yes, I said it again, because it really is that important.</li>
</ul>
<h2>Focus on tasks.</h2>
<ul>
<li>Focus on tasks. Yes, this is redundant, but I can't emphasize this enough.</li>
</ul>
<h2>Emphasize code samples.</h2>
<ul>
<li>Provide as many API code samples as possible.</li>
<li>Make sure that the code samples are accurate. This removes the ambiguity when the developer implements a call.</li>
</ul>
</div>
<p>You can <a href="mailto:andryafeinberg@gmail.com">contact Andrya</a> with any questions you may have.</p>