In an ideal world interfaces are self explanatory to the extent that users can figure them out on their own, but in the case of TrustYou‘s web app the complexity and variety of its features made for quite a steep learning curve. To flatten this curve and enable our users to become proficient faster meant addressing deeply rooted issues of usability, information architecture, and even product market fit. Until we could tackle these I wanted to at the very least least provide our users with an accessible and easy to use knowledge base that could help them get more out of our products, a knowledge base that I ended up designing and implementing from scratch.
Up until when I started this project, documentation in TrustYou was primarily managed in Google Docs and distributed as PDFs. These were help manuals in a very literal sense and the user experience of using them was far from ideal, not to mention the flow of maintaining them.
With limited team capacity and more pressing product issues to tackle, we did not initially have the resources to treat this as a proper project, but because our company fosters a culture of trust and autonomy I ended up taking this on by myself as a sort of side-project to see how I could improve things.
Designing a better way
Defining the needs
As with any project, setting the right goals is what gives direction, and by talking with my stakeholders I understood that this new help center had to be:
- Quickly updatable and translatable
- Relevant to specific user roles
- Comprehensive but not verbose
- Easily navigable and searchable
- Flexible and scalable with the products
Before even sketching out a first wireframe I already knew that WordPress would tick all of those boxes. At over 25% of the market share with a growth trend at the time of writing, its powerful Custom Post Types (CPTs) and strong community support meant that I would have a stable enough foundation on which to build this with enough flexibility to also scale things in the future if needed.
Structure & hierarchy
Because our web app was primarily used on desktop, this meant that most of the incoming traffic would also come from there so I could therefore focus on a desktop-first solution with mobile support coming in second.
With three core product documentations already existing as PDFs, a first step was to adapt these into web pages and to make them easier to navigate by using a side menu. This menu would double as a table of contents, auto-scrolling the page to whichever section was clicked.
Turning a PDF into a web page is one thing, but making that same content dynamic via a CMS (Content Management System) is another, especially when it comes to having a table of contents that matches and links to whatever documentation is written. Going back to the project goals I was reminded that this had to be “quickly updatable” and “easily navigable”, so expecting content managers to do all this work was not realistic. What’s more, from my interviews with them I quickly learned that the convenience of using Google Docs was that they could simply write without much concern for anything else.
Inspired by this approach I developed a CPT where content managers could write in WordPress just as they did in Google Docs, with the caveat that text had to be properly formatted using appropriate headings. Why? Because apart from improving the reading experience, I could also use headings as references to parse that content in PHP, add unique IDs to each heading’s markup and integrate everything with a jQuery plugin to dynamically build a living table of contents.
In other words, content managers could just write documentation as usual and the system would handle the rest. In turn, users could easily jump from section to section via the table of contents or even directly open up specific sections via deep links from our web app.
Similar to the table of contents, videos would also be grouped into categories and made accessible via the same kind of menu. Since these would be nothing more than WordPress taxonomies at their core, I mapped out the URL structure in order to get a better understanding of how pages should behave for different content types.
Expecting users to always follow the happy path to get the support they needed was unrealistic, especially when we consider that the information they were looking for might’ve sometimes been available in several sections of our documentation. Based on the premise that most of the users accessing our help center were not as tech savy to begin with—hence why they were likely looking for support—I wanted to make it as easy as possible for them to search for what they needed.
Because at the time there was no standard when it came to built-in browser searches, and considering how the majority of our users were still using legacy versions of Internet Explorer, I opted for a custom component that I could design and build myself.
With a little bit of jQuery and some UI inspiration from Bootstrap, this custom search component quickly took shape and offered the a consistent experience across all browsers with all of the nice-to-have’s one would expect from such a feature: text highlighting, result counting, stepping, auto-scrolling, field clearing etc.
Even though this was not a mobile-first design, sketching out rough ideas for how it would look like on mobile helped a lot when defining media queries and making the layout fluid. With a fluid layout already in place for content to auto-adapt to the screen space, the only thing that I still had to figure out was the navigation.
The most common design pattern for mobile menus at the time was the drawer, but in my case I had different desktop menus competing for the same space on mobile:
- Primary navigation: shown as a top bar on desktop with languages, categories and search.
- Secondary navigation: shown as a side menu on desktop with table of contents for docs.
Given the limited mobile space, my initial approach was to collapse all menu items into icon-only versions with each of them opening a different menu drawer.
In terms of usability this was far from ideal because unless the icons were explicit enough for our culturally diverse user base then they should have also been accompanied by labels. On top of that, this icon-only approach was also not scalable with any new content we might have added in the future so I decided to merge all menus into one single drawer with collapsible sections and explicit labels.
The only exception here was the search component, not only because the icon was indeed explicit enough but also because the text field had to be visible while navigating through the search results.
Scaling & growth
New content types
Having content managed by our Customer Support Team allowed them to cross-check the most common requests that were coming in from users and identify areas of the documentation that may have not been comprehensive or accessible enough. Gradually our knowledge base grew richer as it included more imagery and embedded videos, as well as new content types.
Recurring questions were bundled together in a collection of FAQs, best practice guides were pulled from our website and added to the help center for easier access, and extra languages were supported via translations. This kind of fast scaling was only possible because of WordPress’ flexible CPTs (for new content types) and strong plugin support (for translations).
On top of that, because content was only accessible to users that were authenticated in our web app, this enabled us to show cross-check their account type and only show content which was relevant to the products they were using, therefore reducing noise and creating a more personalized experience.
Help is everywhere
As the help center was maturing so were our products. With a layout built mostly on cards and tiles (think of these as square “card previews”), visual inconsistencies were gradually being ironed out as UI components began adhering to styleguide standards.
Apart from aesthetics, new components also brought with them the opportunity to offer more contextual support to our users. So the question was how could we offer help that was relevant at any given time but but without distracting them?
The idea was to introduce a new UI pattern for our card component which was non-intrusive by design, by deep linking cards with very specific sections of the documentation. Help would then be available as needed but without getting in the way of the task at hand or job to be done (JTBD).
Initial feedback on this proposal was positive and the assumption was that once familiarized with the pattern, users would know they could get contextual support any time by simply clicking the blue icon box.
More products, more docs
With the acquisition of Checkmate in 2016 and its subsequent rebranding as TrustYou Messaging, an entire product documentation had to be migrated into our help center and with it a restructuring of existing content.
Because the system was already designed to be scalable, this was mostly a matter of coordinating with content creators (i.e. Customer Support Team) to ensure that the transition would be as frictionless for them as for our users.
What started off as just an experimental side-project ended up becoming a full-blown knowledge base with all the bells and whistles one would expect of a modern help center. That being said, there were still plenty of potential improvements as made aparent by findings from continuous research and usage, but then again it was already an ever growing product in and of itself.
To say that it has been a good learning experience would be an understatement. More than that, this was an opportunity to touch on all aspects of building digital products, from project management and stakeholder communication, to research, design and coding. As a designer these aspects are essential in knowing what we build and how we build it, because the final result is more than the sum of its parts and good user experience is more than skin deep.