Want to save this article for later?
All products and apps require some level of existing knowledge to use.
Thankfully, most users are tech-savvy enough to have a baseline understanding of standard elements like buttons, checkboxes, forms, etc.
In fact, no matter how advanced your audience is, technical documentation is recommended for users to effectively use your product, app, API, or SDK.
If your audience is advanced and your product more complex than average, technical documentation can be one of your highest performing assets in terms of ROI. Great technical documentation can lead to great user experience and retention, not to mention the time saved on customer service.
In this article, we discuss the different types of documentation, what makes for great technical documentation, and provide examples.
Technical documentation is the foundational information about the underlying architecture, materials, and process for interfacing with, or building on top of, existing technology.
In software, technical documentation outlines the various API routes and endpoints the developer can access, or it can explain the libraries, integrations, and dependencies of the SDK.
Every engineer who has ever written code in any language has referenced technical documentation at one time or another. Even the programming languages themselves have technical documentation.
The documentation process can be used for a number of reasons.
Documentation helps others (and sometimes yourself) verify and validate the results.
Documentation is like cartography. After exploring new territory for ourselves (building our innovative apps and products) we must provide detailed directions for users to find their way as well.
Some of the various types of documentation include:
This list of documentation types is not exhaustive and although each of the above types of documentation have their ideal use cases, there is no one-documentation-fits-all. In fact, most businesses will have more than one type of documentation.
Technical documentation shouldn’t require a Ph.D. to understand.
Even if your app is intricate and complex, your documentation should be clear and concise, which is easier said than done. One thing that helps make this happen is being as detailed as possible at every step of the way, even if it feels repetitive.
You have to give readers an organized way to quickly find information about the features, functions, and resources available to them. This is where a table of contents and active contents outline comes in handy.
Another important feature of technical documentation is the version, compatibility, language, and revision date associated with the documentation. This information helps give the reader a quick check to make sure they are in the right place to find solutions to their problems.
Great technical documentation includes the following:
Other simple features, like pagination, for example, allow the reader to easily transition between pages within the documentation without having to use the table of contents or search function to continue reading.
Opportunities to provide feedback and connect with an alternative support channel are also immensely helpful for understanding what documentation is not clear and prioritizing updates to those sections.
Within our own developer docs at CleverTap we have a feature that allows readers to “suggest edits.” This helps our team clarify areas in our documentation that could use more context and detail.
Writing technical documentation is no easy task.
Thankfully, the people with the most knowledge on the subject are those who work with it every day: your team. Unfortunately, having the most knowledge on the subject does not always result in the most easy-to-understand documentation.
Let’s cover a few challenges to watch for and resources to include to level up your documentation.
No matter how intuitive you believe your product is or how intuitive it actually is, there will always be someone who doesn’t understand.
We are hardwired to think about problems from our perspective, which is why our solutions are often riddled with cognitive biases and false assumptions. For example, if you use an iPhone every day, you may forget that Android has a different user experience that must be considered in the docs.
The curse of knowledge (in regards to documentation) is when you assume the reader has the same level of understanding as you and will be able to decipher acronyms, code samples, and other resources you have provided.
Even if it seems clear to you without additional context, being repetitive and comprehensive will benefit your documentation and engage more readers.
According to American educator Edgar Dale, we remember 10% of what we read, 20% of what we hear, 30% of what we see, and 50% of what we see and hear.1
If this is true, only 10% of the most well-written documentation will be retained, but including screenshots and screencasts can bring this number into the 30%–50% range.
Documentation is like an open book test, users and developers can use it as a reference at any point and on any problem. Screenshots and screencasts effectively mirror what the user should see, and verifies whether they are using the app properly.
If your app, product, API, or SDK is complex and requires more effort and time for users to grasp the underlying concepts and use it effectively, consider offering in-depth learning resources.
Google Analytics, for example, has a helpful academy for all levels of knowledge and experience.2 But not everyone has the resources that Google does. And we’re not advocating everyone should have this level of detail.
Guides, tutorials, articles, and other learning materials can create the basis for your “academy.” Even a sample use case or application can help users learn the intricacies and subtleties of your tool.
As discussed, documentation can range from a one-page requirements sheet to a thick reference manual documenting a new open-source framework. Today, documentation for apps, APIs, SDKs, and even most hardware products are available online.
Below are a few top-notch examples of various types of technical documentation.
Apple’s documentation is simple and clear with an option to select the iOS version the user currently has installed, a table of contents for referencing other features, device-specific screenshots, and even the option to connect with the support team directly.
The technical documentation of an API allows developers to quickly find their footing with the tool and solve problems that arise during development.
Google provides many helpful features in their technical documentation for their scripting platform, Apps Script, which allows developers to extend their G-Suite platform.3
For example, Google provides a field for user-generated feedback on the quality and helpfulness of the documentation. This user feedback can help reveal areas within the documentation that need improvement.
Google also provides learning guides and samples for developers to quickly grasp how their software can be used.
The ability for developers and users to interact with the product, app, API, or otherwise within an easy to use sample environment is a great way to get users onboarded.
GitHub, for example, provides developers with an easy way to verify their database queries are formatted properly and successfully returning the requested data.4 This split screen view also allows the user to dig into the technical documentation and understand what information the GraphQL API requires as input.
Proper documentation can help improve user adoption, experience, and retention. Developers will rely on the depth, detail, and accuracy of your technical documentation as the reason to continue using your tools.
We’ve taken our own advice to heart in our developer documentation as well as our user documentation. But before you dig into our documentation, sign up for a brief demo to see how our intelligent mobile marketing platform can help you grow, engage, and retain your mobile app users.
See how today’s top brands use CleverTap to drive long-term growth and retention