Documentation Manager · Content Strategy · Information Architecture · UX Influence
Confluence was the answer for our documentation pathway when originally implemented in 2014, but after a year of release cycles, it was becoming obvious that it was not sustainable. We had 50 spaces related to publishing (although not all public) and the number continued to grow with each release. Even with help from Atlassian, we couldn’t come up with a feasible solution, so I began researching other options. I saw an opportunity to bring clarity, structure, and a more human-centered approach to the experience.
I, along with the group of Technical Writer III’s evaluated several options – CMS type solutions (which we determined we would have the same issues with eventually) like Docusaurus and Palagio, blog-like solutions like Jekyll, and docs-as-code solutions like Hugo using a git repository. After evaluating the options in test environments, we determined moving to a docs-as-code workflow made the most sense and decided on Hugo.
As the documentation manager, I guided the transformation of the cPanel docs by focusing on clarity, consistency, and usability. My work included:
• Reorganizing the documentation structure and information architecture
• Establishing clearer content patterns and standards
• Improving navigation pathways and reducing user confusion
• Collaborating with engineering and product teams to ensure accuracy and alignment
• Introducing a more approachable, supportive voice and tone
There was no easy way to do this. After evaluating the current documentation, it was determined that there were close to 700 documents that would need to be moved. Exports from Confluence in HTML produced a lot of cruft that would have to be removed, making the process even longer. It was determined that a copy of only the content would be used and each file would be created individually.
The migration was completed by the documentation team. It took a team of 10 Technical Writers and myself 2 months to get the content completely migrated and in a state that would be acceptable for a beta release to our customers. The content was not only copied over, but in some cases, large tables had to be converted to HTML for proper display.
There were some learning curves in this process for the entire documentation team. Most of us were vaguely familiar with markdown but had not actively used it recently. We also had to become more familiar with git. I have an amazing team! They learned and adapted quickly and now are full-on experts in both areas.
• More intuitive navigation and clearer content hierarchy
• Increased consistency across documentation sections
• Reduced friction for users searching for answers
• A foundation that supported future scaling and modernization
The previous documentation got the job done, but the landing page was very busy and had a lot of information. Even with the amount of information, there was a lot of white space and lack of direction for the user. We also couldn't use any of this content outside of Confluence.
The new documentation takes advantage of the whole page and provides direction for the user. A collaboration with Marketing, led to our documentation being on brand and in line with the rest of our assets.
You can view this documentation here.