I like looking at job postings for startups. It helps me keep an eye on what kinds of emerging skills I need to know about to stay competitive in my field. As a bonus, the job postings are usually entertaining.
I’ve noticed that startups rarely hire dedicated documentation people. As you grow, you’ll start adding support staff and maybe a customer success manager. While it might not be possible for you to hire a dedicated writer in your startup’s early days, you still need to pay attention to your user docs sooner rather than later.
You should worry about having documentation style standards for one reason: consistency. Trying to scale your support team with inconsistent documentation is like trying to paint a house that’s on fire. You can do it, but you’re gonna waste a lot of paint, and someone’s gonna get burned.
Let’s say you’re super-savvy and already have some help articles hanging out in a knowledge base. Great, that’s a start. Now you just need documentation style standards. In this post, I’m going to explain why you need them.
inconsistent docs aren't helpful
The best user documentation is consistent, concise, and clear. It’s usable – clients can use the documentation to answer questions and solve problems. Calling the same feature 3 different things in 3 different articles may not cause any problems for you, but imagine how confusing that can be for clients.
Imagine this: You just got a new HyperCube. You’re poking around the knowledge base cause you want to know how to insert tab a into slot b of your HyperCube. You come across some instructions that might help:
Grab tab a and hold it in your hand. Now grasp the box with slot b and pull it towards tab a. Slide flap a into hypercube with your right hand.
What’s wrong with these instructions?
Let’s try again, but using some standards:
- With your left hand, grasp Tab A.
- In your right hand, grasp the HyperCube, and face Slot B toward your left hand.
- Line up Tab A with Slot B.
- Pull Tab A and the HyperCube together.
The first set of instructions was written without any standards. The second set had just a few standards: number the steps, use the same verb for the same action, capitalize product components. Which one might be more helpful for the average HyperCube owner? Inconsistent docs are unhelpful at best; at worst, they’re unusable (and infuriating).
Takeaway: More consistent = more helpful
inconsistent docs aren't scalable
What happens when your product becomes wildy popular and you have to scale your support team? Google “how to scale a support team”, and you’ll figure out that self-service and user docs are a key part of any strategy.
If your docs are inconsistent, they’re not scalable. You can’t just keep adding more: you’ll still have unhelpful documentation, just way more of it. To quote Tom Waits: “A tree born crooked will never grow straight” – if your docs are crap from the beginning, what happens when they when they multiply by an order of magnitude? You might end up having to hire some consulting company or something in the future just to help you sort out your document quagmire.
Takeaway: More consistent = more scalable
consistent docs build trust and a self-service culture
Creating documentation style standards early breeds consistency, and consistency builds user trust. Having usable, predictable documentation helps create a user self-service culture and trains your users to help themselves – when clients trust your documentation, they are empowered! If your docs aren’t easy-to-follow and consistent from the beginning, how can you expect your clients to trust in them?
Takeaway: More consistency = more trust
note: brand experience
I’m not a marketing person, so I’m not an expert on branding. However, consistency in your documentation goes a long way when it comes to building cohesive brand experience. You need to be careful when you’re creating documentation standards – don’t think for a second that your docs don’t need to align with your brand. They do. Your future marketing team will thank you.
You don’t need a documentation team to build a good foundation now, you just need some guidelines that will keep your docs consistent.
In the next few posts, I’ll explain how you can create your own documentation style standards, even if you can’t hire a writer yet.