Knowledge Base IA Redesign

The problem

When I first became a technical writer at HubSpot, the company was scaling our product offerings faster than we were scaling our content strategy. This created an unbalanced information architecture for articles on the Knowledge Base.

• More mature articles had detailed topics and subtopics, while articles about newer tools were categorized with broad topics that covered multiple tools and features.
• There wasn't any way to browse our Knowledge Base articles by topic, which meant:
  • it was difficult for new customers to learn and explore tools on their own, and
  • we were missing out on internally linking our articles to improve SEO.

My role

• Competitor research: first, I explored how knowledge base content was structured on competitors websites.
• UX research: Menu tree tests: I designed 2 menu tree tests for our top customer personas. I wrote 10 tasks for each study, based on trends in Customer Support ticket data. 
• Open card sort: I designed an open card sort study based on our product's navigation menu. I also asked respondents to identify how they search for help today most often, and why they prefer this method.
• Follow-up interviews: I interviewed 6 of the open card sort respondents to examined topics from the open card sort with the least agreement. I also explored where customers spend the most time in the product to understand the relationship between their primary workspace and supporting tools.
• Cross-referencing other studies: in addition to customer interviews, I analyzed existing research studies from other HubSpot teams. This was particularly helpful for clarifying which personas were using which tool sets, and the results were sometimes surprising.

Findings

Many users noted that there were a lot of tools they didn’t recognize. On the menu tree test, only about 50% of sales tasks were completed successfully, and around 67% of marketing tasks. Particularly for the sales persona, this was a surprising failure rate for an IA they are already using in the product.

• My research showed that customers are growing more diverse in the HubSpot tools that they use.
  • The mental models we've created as a company about which personas use each product no longer apply.
  • This change in behavior makes sense, because virtually all of HubSpot’s products have a freemium version available to all users. 
• There was a lot of qualitative feedback requesting easier access to tools in context. Today, each individual tool is siloed in its own separate navigational item, which doesn't reflect the way they're used by our customers.
• Customers mentioned using Knowledge Base resources most often during the initial setup phase, particularly for their CRM. But they also frequently use other resource types with Knowledge Base articles achieve their goals.

Content design decisions

Based on trends across all the data sources and interviews:

• I grouped our existing tools into 9 categories. This was slightly higher than the median average number of groupings created in the open card sort. But it accounted for the fact that some customers don't use certain tools.
• I created a new category called Account & Setup to reflect the "back office," "admin," and "internal" categories created by respondents in the open card sort.
• I defined new topics specifically for CRM Setup and Getting Started to address the segments in the journey customers rely on Knowledge Base resources the most.

Impact

• The design highlights the most-shared articles by our Support team on the homepage.
• The topic pages are linked to every article in our topic structure, with breadcrumb navigation for more internal links.
• The content structure can be updated easily via API when we make IA changes in the future.
• The top navigation menu now contains links to other resources customers might need to solve their problem. This ensures the resources any customer needs is always 1 click away.
• All elements of the content model populate directly from our localized content management system, so the site is always up to date without any additional work to localize assets.

Additional Recommendations

Since the user journey isn't linear, it's impactful to surface resources about the same topic from different self-service resource types. For example, some user problems require actions outlined in our developer documentation. Some errors that are browser or client-specific are more likely to be documented on our Community forums.

The lines we draw internally between our different resource types based on our organization structure don't exist in the user's actual journey reading and using our content. As a next step, we moved toward surfacing more related content in context.

An early proof of concept for this was recently implemented on our Knowledge Base in a flexible Related content feature at the bottom of each page, illustrated below.