As technical communicators, we focus most of our effort into delivering quality documentation for users so they can find the information they need. Getting them what they need quickly means they can knock out their task and get on with their day. But at MailChimp, we think about our Knowledge Base as more than just a repository for procedurals and reference guides to supplement our app. We treat our work as a product in its own right. Working in a place so heavily ingrained with product thinking helps inform our approach to creating content. It gives us the right perspective to empower our users to do great work and be successful.
Products are for people
As a people-first company, this is a no-brainer for any team that works at MailChimp. When you put your audience first, it gives you a framework to create a meaningful content experience. From this starting point, you’re better able to identify the information users need to solve their problem and package it in language that’s tuned for their situation.
Speaking directly to users in a shared vocabulary make the material easier to understand and increases the likelihood that they’re able to achieve their goals.
After we home in on our audience and their needs, we put the draft through the language wringer. First, it’s filtered through our voice and tone guide, followed by our company and team style guides. Then, we refine the copy even further through several rounds of peer and editorial review. We agonize over the language so the user doesn’t have to.
(Sometimes we even enjoy the agonizing part.)
Products have features
Like any other product, your docs should have features. Site search and navigation are key to helping a user discover your content and reach their goals. At MailChimp, we’re lucky to have experts that are able to help us fine-tune our site search and tweak our site navigation. Creating content without considering those aspects can result in users hitting walls and becoming frustrated.
A Knowledge Base environment should give the users a map and compass to choose their own adventure, but provide enough clear signage that they don’t get lost on their journey. A help site is the most effective when it creates the shortest distance between where the user is and where they want to be.
Products make promises
All products make claims about their purpose and the way they’re intended to make people feel. Help docs are no different. Every element of your content makes a tiny promise to users. Those promises help to form a user’s expectations about what your docs do and how they’ll feel when using them. For us, the expectations start with the word “help.” When a user doesn’t find the help they’re looking for, they’ll feel like their time was wasted. And to be fair, it was. This undermines their confidence in your product.
What’s the best way to avoid that disappointment? Don’t let the user down in the first place, of course! But what happens if you do? We receive lots of feedback from a bunch of different sources—our article feedback form, MailChimp support agents, and other internal teams like partnerships and customer relations, just to name a few. All of that feedback keeps our team busy—and humble. When you realize you let the user down, the best course of action is to stay true to the promise of helping them. You can make it up to users by weighing their feedback and implementing a solution that best serves their needs.
Products make promises. Great products keep them.