Main illustration: Molly Mendoza
In software development, shipping a product is just the beginning.
Only when a product is in the hands of its customers can you can start to learn what really works and what doesn’t. Shipping early helps the product get better: that ethos of continuous improvement makes it OK — even laudable — to release something “imperfect”.
Ideally, shipping the help content that supports a product should work the same way. Written collaboratively and sent out into the world, your customers will let you know whether it’s adequately supporting them or not. Then you iterate and improve.
And yet, despite not being hemmed in by the deadlines or inflexibility of print, we rarely follow product principles for help content. Whether consciously or not, we still want content to be perfect the first time around.
Here’s what we’ve observed by writing ourselves and by making products for content creation:
- People wait to write help content until the product’s nearly done
- Then they hoard that content and try to publish it all at once
- So it takes longer to get real feedback from real people
- And after it’s published, it’s rarely updated
With perfectionism and delay so deeply ingrained, how can we break free of this cycle? If perfect is the enemy of done (to badly paraphrase Voltaire), first we need to know what “done” looks like.
How do you know when you’re done?
In the days when software was shipped in cardboard boxes, and content was shipped between cardboard covers or on CD-ROM, it was harder to change things after launch. Mistakes could be costly.
Slow to produce and rarely updated, the legacy of printed help content remains to this day. Macintosh User Manual, 1984. Photo credit: Peter Merholz
That’s why perfectionism is one of the highest virtues in a writer or editor. An inborn ability to pick up on typos, inaccuracies or confusion is what great editorial skills are made of.
But a piece of writing is never truly perfect and never truly done. The decision to finish it is simply to say that you’re happy for other people to start telling you what’s wrong with it.
Creating great help content is a design challenge
Software products are designed and built by teams of people with different skills and points of view. Throughout the design process, we’re constantly getting feedback from each other, giving the product the best chance of success.
By comparison, creating help content can be an under-resourced and solitary task: the word “writer” evokes an image of a solitary worker, slaving over every word in a chilly attic. Working alone can make a content creator more personally attached to the results of their work — as does the fact that their name is stamped on the finished product. All this heightens the fear of not getting it right.
If you do feel this fear or apprehension when you’re writing support content, there are thankfully a few methods to get past it:
- Start planning early: your new product or feature is likely trying to solve real user problems. Start with articles about those problems.
- Talk to your customers: get insights on the answers they really need first, and focus on those.
- Answer one thing at a time: when people visit your Help Center looking for answers, they’re looking for something specific. One article can’t answer all possible questions on a given topic.
- Ask for peer input and peer reviews: collaborate with your team just as you would collaborate on any other design problem.
And above all, get past the idea that your content will ever be perfect — or that it should be.
What happens after you ship?
Once you publish, and you start getting real feedback from real people, it can be overwhelming.
Our new Educate product changes that, by making feedback manageable and actionable. It doesn’t just give you quantitative data: it links each article to real conversations, which means:
- You can reach out to your readers to solve problems if your content doesn’t help the first time round — and ask them what’s not working with the article while you’re at it
- You can track conversations started from each article, to see what kinds of questions each one prompts
- You can see which articles people search for that you don’t have, so you can fill in the gaps in your knowledge base
All of this gives you real, personal, usable feedback on your content, at scale.
And when you have that feedback, it’s easy to use it, to make sure your content does the best job it can.