Technical documentation and recipes share an important commonality. They’re more useful without the extra fluff.
Just Answer My Question
It’s three hours before a party and I’m supposed to bring a dish-to-pass. Naturally, I’ve done nothing to prepare a dish, so it was time for some culinary cramming. No big deal, Google will help. I hop onto Google and search recipes that aren’t overly contrived nor so simple that they reveal my procrastination.
After some perusing, I landed on the perfect party dish. Upon clicking on the recipe, I was met with a wall of text about the history of the dish and its sentimental importance to the blogger. After 300ish words, my patience all but disappeared as I silently complained:
“No. This isn’t why I’m here. I’m glad this dish makes you happy, but please just answer my question and give me the recipe!”
You’ve felt this pain before and it’s not isolated to recipe wrangling. Perhaps a comparison between recipe hunting and technical documentation is outlandish, but the connection is deliciously undeniable.
Don’t Let Narrative Stifle Usefulness
Narrative is an important aspect of content, but in technical documentation, people prefer answers over flowery prose. The same applies to your recipe search. If narrative fluff is eclipsing usable answers, people will look elsewhere.
Users want helpful answers, fast.
At easyDITA, we’re always curious to see user behavior on our site. Our software solution and content are designed to solve a specific set of problems. So we can bet, with reasonable certainty, that they’re not here by accident. This makes the impression our content leaves all the more important.
In order to figure out whether or not our content is useful to our visitors, we pay attention to:
- What articles users visit
- What documentation they read
- Where they prefer to find the information they’re looking for
These tools have offered insights into user journeys as well as the effectiveness of our content. One example was a person who took a very specific path through our documentation. A user visited our documentation and took an interesting journey.
From the docs, the visitor methodically — and quickly — read or skimmed through several sections of our documentation. Some don’t interact with technical documentation at all. Others, like this visitor, use it to inform primary research before a purchase.
Docs Have Authority Because They’re Written for Customers, Not Prospects
It makes sense, doesn’t it? Marketing descriptions of complex products rarely say anything specific about how the product works, the learning curve, actual technical capabilities, and the like.
Where marketing copy might draw in a less informed prospect, well-formulated technical documentation will speak volumes to knowledgable prospects with pinpoint specific uses or issues.
Good Documentation Is Paramount to Pre-Purchase Research
This is the crux of business-to-business (B2B) purchasing. Managers task staff members determine the effectiveness of a potential new product. From websites, testimonials, reviews, and documentation, they’re studying it from top to bottom because they’ll be the ones using it. Nobody is going to choose an unwieldy tool for themselves.
When it comes to the managerial figures who ultimately do the purchasing, understanding is everything. Technical writers may know documentation inside and out, but they’re not the only people good docs need to convince. When your documentation speaks to a wider audience, that broader understanding has the power to create sweeping passion which motivates change.
In turn, staff recommendations return to management who ultimately decide to purchase or pass on the product. The technical documentation, however, remains the ideal space for educated prospective end-users to quickly find the answers they need.
The trouble is, the mere phrase technical documentation is enough to scare some prospects away. Don’t fret. Balance is easier than you think.
Technical Documentation Should Be Accessible to Prospects & Customers Alike
We know marketing copy is meant to be accessible and technical documentation is meant to address more granular points of a product. Once we stop compartmentalizing these two content powerhouses, it doesn’t take much to see how well they work alongside each other.
It’s time to think of technical documentation as a marketing and sales resource and develop it accordingly. Don’t hide technical documentation behind logins or pay-walls, limiting access to actual customers. Feature internal links to it on product pages, reference it in marketing materials, and make people want to read your docs. After all, that is the purpose of your technical docs.
Your sales team should also be familiar with your documentation and should share relevant links to it when prospects have questions about particular features.
Fashion & Function in Language Must Work Hand-In-Hand
Tone and style matter, but actionable insights and accessible answers matter, too. They have to work together for content to be useful. Engaging and accessible language should also answer questions, regardless of knowledge level.
Work with your technical content writers to develop a consistent, yet conversational voice that won’t scare away first-time visitors doing their homework.
If you’re to take one thing away from this, it’s that documentation needs to focus on all the readers. Once your docs are written such that they’re accessible to more prospective users, understanding, curiosity, and usabilit