Where do your docs fall on the documentation spectrum?

I read an interesting article (which is itself a response to another article) that discusses how data analysis companies define themselves (or are defined) by the software-consulting spectrum. Basically, will the company be more focused on training users and sending them off to analyze their data, or will the company focus on a high-touch model where consultants do most of the work?

Besides being relevant to me, as someone who works at a data analysis company, there’s a very interesting mention of product documentation:

…if someone comes to you with a data problem, there are two extremes that you might offer to them:
1. Give them some software, some documentation, and maybe a brief tutorial on how to use the software, and then send them on their way…
2. Meet with the person, talk about their problem and the question they’re trying to answer, develop an analysis plan, and build a custom software solution that produces the exact output that they’re looking for.

Option 2 might seem less relevant for us technical writers, but that’s not the case at all: Palantir, the subject of the initial article, has a team of technical writers, and they’re firmly located in the “customized consulting” end of the spectrum. I worked for a smaller data analysis company on the same end of that spectrum; even though I was the only technical writer, I was certainly kept busy with requests for more documentation.

For tech writers, where our companies sit on this spectrum determines something very important to us: who are we writing for?

If your company favors customized consulting, your primary audience will be internal. Your documentation must address the needs of the consultants who are configuring and using your company’s product. Those consultants can include solutions architects and members of IT and technical operations teams. They’ll need to know how to build custom solutions, common use cases and best practices, and how to troubleshoot errors. Basically, the standard set of documentation, but it will be read primarily by your coworkers, not your customers.

Additionally, your customer support agents will use your documentation to help learn about how your product works (and identify when it doesn’t).

If your company is closer to the software side of the spectrum (like my current company), you’ll be writing for an external audience. You’ll still have the internal audience, but your primary audience will be your customers. At the extreme end of the spectrum, you might be able to provide “some documentation, and maybe a brief tutorial.” That might be enough if the product is very simple, or if the product is limited to a small number of use cases. But most data analysis software needs to have enough complexity and depth of features to be useful for a wider variety of analyses, and that requires a more comprehensive set of user assistance. This can include user guides, online help, guided walkthroughs, best practices, introductory videos…basically, any and all types of modern user assistance.

Maybe this is a little too Technical Writer 101. But just as a data analysis company (or any technology company) needs to decide whether it’s pursuing the customized consulting option, pure software, or a hybrid, the documentation team needs to decide who they’re writing for. The doc team, and everyone who contributes to the documentation, must understand their audience and create documentation (and UI text, and videos) that meets the needs of that audience.

Or multiple audiences. It’s not uncommon (maybe it’s more common?) to have hybrid models that require that you create documentation for both internal and external customers.

Advertisements