Amplication Doubles Documentation Engagement with Abundant.dev
A developer documentation case study — How Amplication doubled user engagement and transformed their docs process
Amplication is an open-source low-code platform with more than 13,000 stars on GitHub. After they partnered with my technical content agency, Abundant.dev, I helped them completely revamp their developer docs, write high-quality technical content, and ultimately double documentation engagement.
The specific results? First, documentation page visits per user increased by 53%, more than double. Next, Amplication got 63,487 unique documentation visits in 6 months. Finally, I established for them a completely asynchronous GitHub-based editorial process to manage their docs from start to finish.
This success directly led to more users for Amplication and an increase in trial-to-paid conversions. This case study goes into the specifics.
Case Study Highlights
Amplication’s Challenges
- Increase user onboarding and trial-to-paid conversions
- Create engaging and informative docs for new features
- Ensure documentation is up-to-date and accurate
Abundant.dev’s Solution
- Docs-as-code approach and GitHub-based content management
- Fully Asynchronous Pull Request-based Editorial Process
- High-Quality, Docs-as-code Technical Content Creation Process
- Collaborative and supportive partnership
Results
- 53% increase in average documentation page visits per user
- 63,478 total documentation page visits within 6 months
Amplication’s Challenges: Improve User Onboarding and Engagement Through Documentation
Paz, VP Product, wanted to transform Amplication’s docs into a valuable resource for users.
He understands that comprehensive, well-crafted documentation is for a technical product targeting developers. Without great documentation to assist and guide developers, the product was missing a crucial component for success.
“Documentation is a must for a technical product where the target audience is developers. If you don’t have great documentation that can assist developers, then you have one missing leg,”— Paz Yanover, VP Product, Amplication
Specifically, he wanted docs that would increase user onboarding and trial-to-paid conversions. He also needed an efficient system to manage the entire documentation process.
But, Paz faced several challenges in making this happen. With a rapidly evolving product, Amplication struggled to keep the docs up to date with the new features. There were no internal technical writers and Amplication’s developers were tasked with all the technical writing, which often took a backseat to their primary coding responsibilities.
Paz saw all these challenges. He understood the need for good developer documentation, a strong system for managing it, and someone with the necessary writing and technical skills.
Abundant.dev’s Solution: Transforming Documentation to Drive User Onboarding and Conversions
Amplication recognized the need for expert help so they partnered with my technical content agency, Abundant.dev. I had the technical knowledge and experience needed to solve Amplication’s documentation challenges.
These challenges were solved by implementing a 6-step strategy. First, I gained a deep understanding of Amplication’s audience through research, followed by a thorough audit and overhaul of their existing documentation. Then, I implemented a streamlined GitHub-based workflow, wrote comprehensive user-centric documentation for new features, established an efficient editorial process, and provided ongoing support for continuous improvement.
By combining these strategies, I helped Amplication transform their documentation into a valuable resource that doubled documentation engagement, increased onboarded users, and increased trial-to-paid conversions.
The following sections go into the specifics.
Step 1: Understanding Amplication’s Audience
To gain a deep understanding of Amplication’s audience, I conducted interviews with the team and performed in-depth research into Amplication’s open-source GitHub repository.
I gained insights into the needs, pain points, and expectations of their current users. This research helped us develop a comprehensive understanding of Amplication’s target audience.
I discovered that Amplication’s audience consisted of two main segments:
- Developers who use Amplication directly, focusing on the generated code and making customizations in git.
- Technically proficient managers who leverage Amplication’s low-code capabilities to make changes through the user interface.
Step 2: Conducting a Thorough Documentation Audit and Overhaul
Based on the audience findings, I did an in-depth audit and overhaul of Amplication’s existing documentation. I prioritized the most important areas: the README file, navigation, welcome page, and Getting Started guides. Amplication’s data shows these are the most visited pages. They’re important to properly shape the user’s first experience.
To optimize the documentation, I:
- Rewrote the README to provide a concise and informative introduction to Amplication, highlighting its key features and benefits.
- Redesigned the documentation’s welcome page to create a more engaging and user-friendly entry point, making it easier for users to find the information they need.
- Restructured the navigation to improve accessibility and help users quickly locate relevant content.
- Updated the Getting Started guides to offer a streamlined onboarding experience, taking into account the varying levels of technical expertise among Amplication’s audience.
- Rewrote key feature pages, like Sync With GitHub and Custom Attributes, to ensure content was tailored to specific needs of their audience
The overhaul and newly tailored content helped users understand Amplication’s features and benefits more easily, leading to higher adoption rates and improved user retention.
Step 3: Implementing a GitHub-based Documentation Management System
I implemented a GitHub project board to manage the documentation lifecycle. We created this system so the Amplication team and I could work together remotely without meetings.
GitHub is already where Amplication’s developers contribute code. Managing the docs there too made it easier for everyone on Amplication’s team to review and provide feedback.
The GitHub project board has 8 columns. A ticket moved through the columns and handled all areas of the docs.
- Backlog: Captured initial task entries awaiting classification and scheduling.
- Baking: Served as the development ground for tasks, enriching them with specifics before they entered the active queue.
- Todo: Organized tasks in order of importance, setting the stage for active development.
- In Progress: Denoted the phase where tasks were actively worked on, using Markdown for documentation updates and creation.
- Waiting for Product Review: Acted as a quality gate where the product team reviewed tasks to ensure consistency with product goals.
- Waiting for Technical Review: Extended the quality check with a broader review process, including editorial and peer evaluations.
- Waiting for Merge: Positioned tasks on the brink of completion, ready to be integrated into the main codebase.
- Done: Confirmed the finalization and integration of tasks, indicating a successful merge and deployment.
This process made managing the docs much simpler. It also improved communication about the documentation because it was in a single place.
Step 4: Writing Detailed Feature Documentation Through Research-Heavy, Docs-as-Code Approach
I wrote the documentation for some of Amplication’s most important features. This includes Custom Types & Actions, Break The Monolith, Import Prisma Schema, and many more.
I used a research-heavy, data-focused, docs-as-code approach to write each page. This included:
- Asking Amplication’s developers questions to get insights into the technical parts of the feature.
- Reviewing technical specifications shared on Notion to ensure accuracy and completeness of information.
- Reviewing the code for a specific feature contributed to Amplication’s GitHub repo.
- Conducting independent research to find necessary information using external sources.
After I did the needed research for a feature, I thought of the best way to write it for Amplication’s audience.
One specific feature is Break The Monolith. To cater to Amplication’s two audiences, I wrote two separate documentation pages.
The first page, Break The Monolith, appealed to technical managers. They care about high-level concepts, benefits, and general usage. Understanding Break The Monlith, the second page, is for developers. It provides a deep technical explanation of how the feature works.
Several key factors were considered during the drafting process. Here are a few:
- Information Architecture: Considering where to put each page so it makes sense in the context of the entire docs.
- Content Structure: Organizing content in a clear and logical manner.
- Linking and Referencing: Including links to other appropriate parts of the docs. Also, include links to specific sections of the page from the Amplication app itself.
Following this detailed drafting process and the docs-as-code approach, I created clear documentation properly explaining that feature to Amplication’s audience.
Step 5: Establishing a PR-based Asynchronous Editorial Process
After completing the first draft, there’s a collaborative 4-step review process:
- Product Review: Paz reviews the draft. He checks that it is accurate and matches Amplication’s features from a product perspective.
- Technical Review: For more technical pages, a developer reviewed the content to ensure its technical accuracy.
- Revisions and Refinements: I write a new draft implementing all the feedback and make any necessary stylistic refinements.
- Final Approval: After incorporating all the feedback, the final draft is marked for approval by Paz.
All collaboration takes place in a GitHub pull request. Feedback is given through comments and GitHub’s PR review system. Revisions are implemented through additional commits to the existing branch where the PR resides.
The review process continues until the Amplication team is happy with the content. After the PR gets approved, the ticket moves to the Done column. Then, the page merges into the production documentation site.
Step 6: Providing Ongoing Support for Continuous Documentation Improvement
Documentation, like the product, is not a one-time effort, but an ongoing process that requires constant updates. Even after a specific documentation page is marked as “Done,” the work doesn’t stop there.
I work with Amplication’s team to track user feedback and analytics and identify areas where the docs can be improved. Through Discord, GitHub, user surveys, and email, we gather insights from users to help us refine the docs.
We create new issues when existing features are updated, or, when user feedback requires changes. These update-focused issues go through the same drafting and review process as before.
Amplication’s Results: Doubled Engagement, Transformed Documentation Management, and Increased Conversions
The partnership with Abundant.dev yielded impressive results for Amplication. Over a 6-month period, the average number of pages visited per user increased by 53%. This significant boost in user engagement demonstrated the effectiveness of the new content strategy and the quality of the documentation produced by Abundant.dev.
In total, Amplication’s documentation site received approximately 63,478 total documentation page visits over 6 months, showcasing the increased discoverability and relevance of the content. The improved documentation not only helped attract new users to the platform but also empowered existing developers to make the most of Amplication’s features and capabilities, ultimately leading to increased user onboarding and trial-to-paid conversions.
Ready To Transform Your Documentation?
Abundant.dev is a technical content agency to help your company grow with developer-focused content writing. Are you ready to get results like these for your company?
Message me on LinkedIn, DM me on Twitter, or fill in the form below and let’s get started.
