Organization & Role
Helpshift (acquired by Keywords Studios) is a mobile-first customer support platform. As their first Content Designer, I created and managed all in-app copy and knowledge base content.
Project
I was hired to take over management of Helpshift’s two separate ‘Support’ and ‘Success’ knowledge hubs and combine them into a redesigned Knowledge Base built in WordPress.
Problem
Prior to my joining Helpshift, the two portals were built using in-house tools and had a pretty traditional, old-school one-tier layout.
In each portal, a search bar and contact button were provided in the header, with main categories displayed in a three-column layout with the first five FAQs listed beneath each one. The support and success portals combined contained 18 main categories housing approximately 180 FAQs.
The primary problems with two-portal system, and with knowledge management in general, were as follows:
- Customers often got to one portal or the other and did not know where to start (neither one provided a ‘getting started/basics’ section).
- Customers could not search in one portal and get results from another – there was a lot of cross-referential content that was siloed to either one or the other. Even worse, many articles were duplicated across both, which then became horribly outdated.
- There was enough content to warrant an urgent need for a 2-tier solution with main and subcategories, but the in-house CMS did not allow for this type of architecture.
- The interface only allowed for minimal custom branding, so it looked significantly off-brand compared to the marketing website and product.
- A number of customizations were desired that could not be achieved with the in-house tool that other CMSs offer out-of-the-box, such as a better search experience, a custom landing page, and a better flow for contacting support.
Most significantly, the fact that no one person had full ownership of these portals had created a “kitchen with too many cooks” problem. The existing content had been written in so many different voices, it did not have a unified communication style, and enough of it was out of date to frequently and continually break trust with customers.
Approach
CMS Selection
To achieve the type of taxonomy, customization, and branding flexibility that we wanted, I researched several options and opted to rebuild the Knowledge Base in WordPress, specifically using the Flatbase theme.
This decision to use WordPress was based on the budget allocated to the project, research done by existing team members which was handed off to me, and the fact that WordPress offered a high level of customization. The fact that we had in-house designers who were experienced with WordPress and willing to help us customize the site was also a major factor.
Taxonomy
Within my first 90 days, I conducted a thorough audit of the existing content and assembled all my findings into a spreadsheet. I mapped the current taxonomy, added notes about content that appeared to be out of date or which should be located elsewhere (ex. marketing content, such as “Helpshift vs. competitor” which should be moved to the website) and conducted competitor research to design a new taxonomy with 9 main categories and 26 subcategories nested beneath them.
At the time, Helpshift’s product offerings were clearly cut into three products. Since customers often asked questions based on which product they wanted to learn more about, I started off with three product-based categories:
- In-app Support 📱
- Knowledge Management 🧠
- Email Support 📩
I also reviewed support tickets and checked Salesforce for customer feedback about our current documentation offerings. I discovered that the role of the customer played a large focus in what type of questions they needed answers to (and the type of access they had to make changes). Three of the nine main categories were established based on these roles:
- For Agents 👷🏽♂️
- For Admins 👩🏽💼
- For Developers 🤖
To make it crystal clear that these categories were meant for team members in those roles, i.e., ‘Agents’ wasn’t about managing Agents, it provides answers to questions that agents have., I added ‘for’ before them. This divide also helped to distinguish which content was accessible for who. For example, Agents do not have the permissions to change many of the settings that Admins can, and Admins usually don’t have the API expertise needed to understand the content for Developers.
Last but not least, we had advanced features for higher-tier customers as well as integrations. Grouping these together, the final three categories were established as:
- Analytics 📊
- Workflow Management ⚙️
- Integrations 🔗
I presented the information architecture and my rationale for it to leaders of Support, Success, and Marketing, and was gifted with their approval with no suggested revisions.
User Experience
To figure out what the frontend of the site should look like, I spent time looking at competitor sites as well as innovative, industry-known knowledge hubs, and took notes on what they did well that we could emulate. To get the branding piece down, I scheduled a meeting with leaders of Marketing and Design, presented the customizations available with the WordPress theme, and we worked out which customizations would be best to meet our branding needs.
Since I studied frontend development, I was able to use HTML, CSS, JavaScript and PHP to complete most of the customizations on my own. I also contracted a wonderful WordPress developer to handle select backend changes.
Content Revision & Migration
We (the team leads and I) agreed that the content was so far out of date, it warranted revisions on top of a migration to the redesigned portal. I repurposed my content inventory spreadsheet to function as a checklist for the migration project. This way I could track which articles had been revised, which were pending external review (i.e. for a support agent or developer to confirm the revised article’s accuracy), and which had been successfully migrated, along with all of the old and new URLs for when the time came to set up redirects.
As a note, I really, really wish I had screenshots of this spreadsheet to show you in this case study. Unfortunately, I did not save it prior to my departure from Helpshift. Thus, you must conjure up a mental image of an immaculately organized spreadsheet with tidy rows and columns representing the before and after of the information architecture, with a ‘Yes/No’ row indicating which articles had already been migrated.
As I went through the revisions and approval process, I took notes on the voice, tone, and use of terminology that I was applying consistently across these articles. These notes would become the bedrock for our first-ever style guide. When I figured out a new guideline, I backdated which articles had not been revised according to that guideline, and later completed a follow-up project where I went through and revised those articles.
Analytics
To make sure we would be able to track engagement with the knowledge portal, I installed Google Analytics on the site and completed the Google Analytics for Beginners certification.
I would later apply this knowledge to set up a weekly knowledge base email sharing highlights and interesting trends about our knowledge content. Here’s a sample of one of those emails, including the top status with a comparison to the week prior.
There were a lot of metrics provided, so I’ve provided a gif skimming over these. These metrics were determined by my exploration of our content and feedback given by team leads. I would later update this email to include pageviews by referrer and platform based on expressed interest in those numbers.
Outcome
The end result was a modern, branded knowledge hub with an intuitive, two-tier taxonomy populated by freshly revised content with a unified voice. No longer were the days of two detached portals with fragmented, duplicate writing and outdated screenshots!
To align with popular knowledge portal elements of the time, the landing page featuring a prominent search bar, links to companion resources such as our getting started guides and developer documentation, an embedded video that links out to a brand-new video library, a ‘recent articles’ section, and a minimalistic footer.
To support new customers, I created a Getting Started page which provides a series of guides in a recommended order to help them quickly set up Helpshift for the first time.
Results
I wasn’t very good about documenting my awesomeness at the time that this project launched, so though I do not have any screenshots or direct quotes, I received a wealth of positive praise both internally and from customers when this launched.
I continued to evolve the Knowledge Base, adding new content and revising the information architecture a second time a year after the project, all the way up until my departure. Here are some informative stats about my work there from my official goodbye message.
Reflection
This was my very first time taking on this type of mass-redesign, mass-migration project, which was completed in 2017. If I could go back and do it all over again from the perspective of December 2020, here’s what I’d do better.
Success metrics established at the beginning of the project to prove it’s value over time. Budget was a big issue, which was predominantly because the value had not been effectively conveyed to leadership prior to my being hired. At the time, I made the case for this via qualitative feedback (customer complaints) and from the support of team members who had experienced the pain of these lackluster resources (support and success) as best as I could.
A style guide agreed upon and written out at the beginning. This was also my first time creating a style guide, so I was learning to sail the ship while building it, so to speak. I did some self-study by exploring resources from excellent writing communities (looking at you, Content + UX Slack group!) on what a style guide is and how to write one along the way of completing the knowledge base redesign. Most importantly, this would have saved me the pain of having to go back and revise content that did not match the guide the first time around. I also wish I’d pulled in marketing and design more when creating the guide, as it initially left out key nuances those teams have when writing for our product.
More advanced planning in anticipation of product roadmap changes. Like many startups, Helpshift tended to ideate and ship fast, often so fast it was a scramble catching up with content updates. The taxonomy went through several short-notice, rapid shifts as our product offerings grew. As I’ve grown as a documentarian, I’ve learned to ask about the future of the product as often as I can to anticipate and plan for these big changes.
More customer feedback (always). I never had direct access to customers, and my one attempt at gathering qualitative feedback (a 10-question knowledge base survey emailed via our marketing list) received zero replies.
Last but not least: screenshots (or saved copies) of my project management materials so I can more effectively show off this part in these case studies.
I learned from all of these points of reflection in my next project and role. Learn more about it in The origin story of the Heap Help Center.
