Evolving the Hootsuite Help Center

In the past year, Hootsuite has grown significantly, which has necessitated strategic changes throughout the company. These changes include how customers learn about the product, and how they’re supported while engaging with it. A key component of our customer’s digital experience is the Hootsuite Help Center. With over 18 million customers on the platform, there is a good chance that they have come across content that either lives in the Help Center or is packaged and served up via an API to other endpoints, such as within the product. Our content management infrastructure has evolved dramatically over the past year. It consists of a multi-vendor strategy with a scalable authoring tool, flexible publishing pipeline, and a modern user experience that is tightly integrated with our support workflows. It’s a work in progress and we have a roadmap to make it even better.

In this article, I’ll walk you through the impetus for the change, some of the research we did along the way, a UX refresh that we performed while we determined and evaluated the tool we would use, and a deeper look into the technical architecture of the content management infrastructure we currently use.

So let’s rewind the tape a bit…

Why change?

Let’s start with a quick recap of an article that was published last March on our Career Blog titled Meet Susan, Senior Director of User Education at Hootsuite. Last year, Hootsuite leadership realized we needed to invest further in the content experiences and user education space, and Hootsuite started with hiring Susan, who led the efforts to build out the organization and define the overall mission. As part of that process, she laid out a few key goals for this aspect of the organizational work:

  1. Develop a best-in-class help experience for our customers. Our goal is to keep our customers in the product — not searching around for help.
  2. Develop a reimagined help center — make ours the best in class and ensure it is scalable and measurable.
  3. Retool our writing and publishing pipeline to better support writers and customers.

At the time, we were using Zendesk Guide as the solution for our Help Center. This was a good choice early on for Hootsuite, given the fact that our Support infrastructure is also built on Zendesk. Sharing the platform allowed the few support advocates that were generating content, to quickly publish and produce content as needed based on customer issues. However, as the team scaled and the needs of the business changed, it was clear that we needed a more mature system to build in scalability for the future.

We put a plan in place to do the following in phases:

  1. Enhance the User Experience to include a modern navigational model, an improved support funnel, brand alignment, richer visual elements, advance our efforts for WCAG 2.1 compliance, and better integrate with our overall digital experience at Hootsuite.com.
  2. Build a more scalable content model that would allow us to decouple our content from the code for reuse, take advantage of multi-channel publishing, improve localization efficiencies, and provide a systematic approach for workflows and automation in the future.
  3. Implement a more mature authoring environment to increase content creation and management efficiencies.

Phase 0: Gathering user feedback

We gathered data from internal and external customers. Early on, we partnered with support to understand their use cases and pain points as a way to inform both short term and longer-term plans. As a result of this effort, we developed multiple work items to make some early improvements. This included updates to the content model, content coverage, and content quality. In addition to that, this was the quarter we started getting customer feedback through the UserTesting platform on the usability of the existing Help Center.

One of the key findings during this effort is that knowledge is spread throughout the organization and is often hard to discover at the time that might be the most important. For example, you may not have the right information when you are troubleshooting an issue with a customer. Many companies suffer from this issue!

An internal survey showed that our support advocates use the Help Center content 95% of the time when accessing content to resolve cases. We knew we had to make improvements to both the content and the experience.

A graph showing the breakdown of information sources used by Support Advocates
Troubleshooting methodology breakdown

Phase I: Enhancing the user experience on the current stack

The research we did internally and externally paved the way for our UX refresh while we built our plans for upgrading the underlying infrastructure. Data showed us that we had room to improve in the following areas:

  1. Limited navigation. At the time, both site search and browsing were limited. This prevented proper wayfinding once a customer landed on an article via search. A UX refresh would bring a full Table of Contents (TOC) and other navigation elements to the experience.
  2. Challenging readability. The templates we were using did not provide enough flexibility for content models and we lacked some modern elements. While we certainly had some content design work to do, the layout of the templates needed to be addressed.
  3. Outdated experience. The UX needed a fresh coat of paint, updated CSS, updated video and image styles, full alignment with brand principles, and modern UX components such as accordions.

At the time of the UX refresh work, we were still only running on Zendesk. We wanted to make sure that the investments we were making in the refresh work, accrued value towards our future state. A cross-comparison of the early requirements phase demonstrated we were addressing 20% of the priority 0 requirements and ~15% of all requirements that had been gathered for our new site infrastructure and experience. We kept track of that in the same spreadsheet since we had two workstreams running (short term and long term). We implemented Hotjar during this phase to gather customer feedback on articles.

Here is a journey in pictures from the old user experience to the current user experience, highlighting some of the progression.

The Hootsuite Help Center in August of 2020
Hootsuite Help Center — August 2020
mockup of the UX refresh
Early wireframe of the UX refresh
Customer journey prototype
Interactive customer journey prototyping
The Hootsuite Help Center post-launch
Help Center post-launch

Phase 2: Requirements gathering, vendor discussions, and POCs

Given the small team size, we knew going into this it would be a buy versus build situation for most of the technical stack. When it came to determining which CMS we should migrate to as part of our overall infrastructure, there were many aspects we needed to consider. There are a lot of options out there, each with different benefits for specific use cases, and the solution we would go with should map back to the type of site we’re building and the overall needs of our business. As part of this process we developed, and debated, a thorough list of requirements.

We created extensive documentation outlining the current state of the industry as it related to the distinct types of content management systems (e.g., headless). We narrowed the vendor choice down to five companies and did a mix of paper analysis, demos, and proof of concepts to land on our decision. At the end of this, we felt that MadCap Flare checked the majority of the boxes and included a new connector they had recently developed that would enable publishing to Zendesk.

List of CMS and UX requirements
CMS and UX requirements

An interesting point of discussion that came up during this, was learning that the documentation team at Zendesk creates and maintains the content offline in DITA source files using Oxygen XML instead of using Zendesk Guide. Like us, they rely on a host of other features, including file search, file diff, change tracking, image management, and HTML transformations. These were some of the major reasons we were shifting our own approach.

Phase 3: Sustained engineering and continuous improvements

This really wasn’t a phase, but it’s important to note that the UX refresh we shipped in September 2020 meant that we had continuous improvements to make to that new experience while we also planned for the content and infrastructure migration that was lining up for us for Q1 of 2021. During this time, we did the following:

  1. 🐞 Improved the experience based on a backlog of work that didn’t happen for the initial launch, including bug fixes.
  2. 🔥 Implemented Hotjar to gather further insights from our customers.
  3. 🤖 Rolled out machine translation workflows for articles to increase cost efficiencies across the business and start our journey towards automation.
  4. ♿️ Executed on accessibility updates across the site (experience and content) to move closer to WCAG 2.1 AA compliance.

Phase 4: Planning and launch

Now that we had our vendor selected, decided on the pattern for our overall infrastructure (MadCap + GitHub + Zendesk), and improved the user experience, the final quarter of 2020 was spent designing and pre-planning for our content migration and infrastructure update. This included a learning phase for MadCap Flare, extensive testing on the environment, documenting and discussing our project risks, and building out our roadmap for release.

At a very high level, it looked like this:

  • October — Complete project plan; engage with IT.
  • November — Build and test infrastructure; identify risks.
  • December — Close on migration plans and activity for Q1.
  • January — Build infrastructure and acquire software, begin migration activities.
  • February — Complete migration and launch.

Help Center infrastructure — September 2021

Help Center infrastructure diagram
Help Center infrastructure diagram

Today the Help Center infrastructure consists of a MadCap Flare authoring environment connected to GitHub as our version control for both content and the Help Center codebase. This allows us to leverage content in ways we couldn’t before, sets us up for longer term activities around automation, and makes the content more portable for any future migration activities. Our build and publishing infrastructure utilizes Amazon EC2, MadCap Connect for Zendesk, and various scripts for automated builds. Our customers experience the content on the web via Zendesk as well as in the product, pulled from the Zendesk search API.

Our 3rd party integration stack looks like this:

  • Zendesk Messaging for asynchronous chat and surfacing help articles to customers looking for additional help via conversational experiences.
  • Intercom + Alvis for integration of the articles within Zendesk to be surfaced within the Hootsuite dashboard.
  • Elastic Swiftype for enhanced site search capabilities which allow us to manipulate search result rankings and improve search results for our customers.
  • Google Analytics for web analytics and reporting as well as Data Studio for dashboards and reports.
  • Hotjar behavioral analytics platform for visualizing user behavior and gathering instant feedback on content to help make improvements. We’re currently not using the session recording but intend to roll that out over time.
  • Smartling for content translation that leverages Amazon Translate for machine translation, followed by human edits based on languages.

That’s the backend. For the end-user, this is how the experience comes together:

  1. Header and Footer. The header experience is created in Zendesk with the codebase source stored in GitHub. Updates to this are done outside of the platform and then published to Zendesk as needed.
  2. Breadcrumb navigation. The breadcrumbs are autogenerated from Zendesk based on Categories and Sections using Curlybars. Curlybars is a templating language and implements a large subset of the Handlebars language. But unlike Handlebars, which render on the client-side, Curlybars render on the server-side.
  3. Table of Contents (TOC). The TOC is generated in MadCap Flare, mapped to Zendesk, and then rendered via a separate JavaScript file. Any changes made in MadCap are reflected here.
  4. Site Search. Search continues to use the Swiftype engine. Management of search happens in their SaaS application.
  5. In-article TOC. The in-article TOC is autogenerated based on article heading levels. Any changes made in MadCap are reflected here. Any experience or functionality changes are handled in a separate JavaScript file.
  6. Content. The real star of the show! All content is authored in MadCap and published to Zendesk using MadCap Connect for Zendesk. Any and all changes that are checked-in to Git are included in the build process.

Looking ahead

We’re continuing to invest in all of our digital experiences across Hootsuite — that includes continual iteration and evolution of the Help Center. We’ve learned a lot over the past year and are laying the groundwork for long range planning. Some of those items include build server infrastructure improvements, site search and discoverability enhancements, tighter integration into the product, and consistent UX frameworks across our web ecosystem. We’re currently working on a large migration on Hootsuite.com that we’ll be discussing in future articles on the Engineering blog.

Interested in helping shape the ecosystem of web properties on Hootsuite.com? Check out all the jobs at the Hootsuite Career site!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Luke Nyswonger

I lead a cross functional team of software developers, product managers, and writers responsible for the development of the global web experiences @Hootsuite.