At my first company, we had a gong. Nobody was sure exactly where it came from, but it showed up in the office one day with some badly watered house plants and cemented itself as a permanent part of our culture soon after. In the beginning, every time we signed a new customer, we rang the gong. After a while, we were signing too many customers to regularly keep ringing it without making the other offices on our floor angry.
It’s a dream scenario: you grow, then grow more, and have a solid customer pipeline. But your early system probably involved personal account management for those customers in the form of emails or calls for every little need. That works with 10 clients, but not 1000.
An often overlooked but crucial step to scaling is customer documentation. Depending on your product, that might be text, or text and photos, or video clips (or all of the above, if you’re truly prepared). Ten different customers could be reading the same how-to guide at the same time, but only one customer can speak with their account manager at any given moment. Take time zones and distributed teams into consideration, and the benefit of asynchronous customer help becomes clear.
What Makes Good Customer and User Documentation? 🤔
A common pitfall I see early stage companies make is the tone and intended audience of their docs. You love your product. You live and breathe whatever it is that you do. Your customer may not. Assume that they need to be introduced to any acronyms, industry terms, or niche concepts. A glossary, or a quick screenshot to identify menu items, can be your best friend.
That said, keep it as brief as possible. Your reader wants answers, now. Break up text with spacing and images and bullet points to allow for digestion rather than huge blocks of paragraph text.
Style guides are often an afterthought; a rapidly moving team will throw docs up online and think that any docs are good. But as your product grows, and your docs grow alongside it, the backlog of material to triage and update to a later style preference will become intimidating and costly. Save yourself money and manpower later on by adopting a style guide from day one, even if it’s just simple formatting, key term and tone setting. When in doubt, adopt someone else’s standards.
The Feedback Pipeline 🗣️
If you’re successful, many people will be reading your docs. Potentially, you have a huge audience from which to gather feedback. Give your customers and users a clear path to submitting their questions or concerns about the content of help articles and user manuals. My suggestion is always to make it an email address that’s dedicated to just that purpose, or a submission widget if you’re able to get fancy. Letting users comment on help docs, when we know that most comments will come from frustration at either documentation limitations or user error, can leave negative impressions right on the page for the next person who comes to your documentation looking for help.
And once you collect that feedback, do the right thing and use it. If you have a document that has multiple responses of confusion or frustration, that’s a good indication that you need to tweak the wording, check the content for validity, and even pass that feedback along to QA and Product as a consideration for future releases and design updates.
Quantity or Quality? 🤝
My answer: why not both? There’s a myth that good documentation requires big expensive tooling. You don’t need a full Adobe Suite to create impactful and professional images. Tools like Renderforest and Camtasia can get you far enough to produce current visuals that are easily and quickly updated as your product evolves. Plenty of good, solid documentation starts out in Google Drive rather than MadCap Flare or (cringe) Salesforce Knowledge.
Good customer documentation is about intent, not pedigree. 🐩
Leave a Reply