Content Strategy in Technical Communication

Why A? Why not C? Who? What if? Where? Why again? This is how content strategists get started and the only goal is to bring value to the business.

When I think how technical communicators generally work, there can be a lot of common ground. If you are about to start a new project as a technical communicator, do not start with the questions that are relevant to your immediate goals such as:

  • I think MadCap Flare should be a good option. Let me see a few more tools too.
  • Should I propose XML? May be DITA?
  • Let’s see if we can reuse the topic files to publish PDF manuals as well. If we cannot, we can come back to it later.

Such questions mean that you are disconnected from the larger content strategy of the business. As if, you are not too concerned with the long term ‘content goals’ of the organization.

Your three most important questions to begin with are:

  • How the organization is communicating its message to all its audiences, whether it is for marketing literature for leads, the promotional content at events or webinars, its stories, or the training content for customer onboarding.
  • Who are the audiences and why the organization is publishing all the content in the current deliverables?
  • What is the content culture in the organization, and how technical documents can contribute to the ‘content goals’?

So you should start with the most important questions that really matter, for example “How the audience may prefer to use the technical information, in what all deliverables, where exactly in the customer journey, on what devices, and in what languages?’ It is important to forget for a moment that the organization cannot afford (or do not want to invest in) a tool A, B, or C.

As writers, the best start is to document what all you need and why, keeping in mind the business goals, customer needs, and the available sources. So, for example:

  • Will a product knowledge base help?
  • Will videos help? Are these really required? Is it expected that a few customers may be struggling in the absence of videos?
  • If the organization has a product suite, where do the documents of different products merge and then part away?
  • How frequently and how fast the product is being updated for new features? Does it make sense to plan for ‘new features’ and ‘announcements’ in the documentation? (For example, see Formstack support.)
  • Do you expect that users may prefer to download quick guides (PDF), or getting started guides (PDF) for offline reference?
  • What is the organization social media strategy? If we make the help topics shareable on social media, is there a process to engage customers on social media?
  • Does the organization has a blog that talks about product features? If yes, do we need a cross reference process for blog posts to help topics? (For example, see this Harvest blog post.)
  • Do you want that customers can open a support ticket for their unanswered questions? If yes, is there a helpdesk support in place and can it be integrated with the planned technical content environment? (Squarespace support helps it beautifully.)
  • Do we need customer engagement, such as seeking votes on whether the documentation is helping them? If yes, how does it help?
  • How do you plan to use Analytics? Is there a team who can plan campaigns and goals?
  • Who are the content strategists? Are they on board or consultants? For how long they are working with the product team?
  • Do you have access to the organization’s content strategy deliverables-the inventory, the message architecture, and style guide?
  • Is the documentation required in only one language?

Now you know what all information you need to develop, the deliverables, and the customer engagement strategy. It is the time to do what we often love to do, evaluate tools. A few more factors that help you make a decision are:

  • Does the organization have writers on board or they plan to outsource the work on long term? It helps you plan for the budget.
  • What is the expected frequency of product updates and hence possible updates in documentation too? It helps you prepare a calendar.
  • Do they maintain multiple versions of the manuals? If yes, does it mean that the earlier versions are also available to customers who might be using older instances of the program? See an interesting example where users can see the documentation for different product versions.
  • What is the scope of content reuse, and how each unit of information is managed for reuse, not only by the technical communicators but by any team or individual in the organization? It gives some directions on the authoring process and it also defines the integration points with other teams for the content workflow.
  • Do we need to make the information available on smaller devices? It gives you directions for an adaptive content strategy.
  • How technical documents can be an important step in the customer onboarding, or for customer journey? It brings you closer to UX and customer service teams.
  • Unless there are some compliance concerns or the information is restrictive in nature (healthcare, security), is it fine to make the information indexed by Google? A few deliverables in a few authoring tools may not support it.

When you consider all these points, the whole technical communication process is not too different from how content strategists work. Also, when we consider that technical writers:

  • Plan and use style guide (voice and tone, consistency, collaboration)
  • Prepare documentation plan for calendar and milestones
  • Design information to ensure structure and findability

And, when we see a few technical documentation trends:

  • Product instructions are available on Google as customers often tend to use Google to find information.
  • People can post a support question on social media such as twitter. Many organizations have social media as part of their customer support process and they provide awesome customer experience to their customers. (I have experienced it by Basecamp, Envato, and Citrix.)
  • Organizations share product features as insights and blog posts and these posts are referenced from related knowledge base articles for more context and background. (As I shared the Harvest example earlier in the post.)
  • Product documentation is a part of customers’ buying decision and hence all content even in technical documents is marketing content. (Scott Abel has been saying it for years.) (There are exceptions of course such as API Documentation though organizations sell the API docs value too when planning integrations with external services.)

Technical communicators can really work like content strategists. This is not to say that technical communication and content strategy are same. Content strategy on the other hand is much more than technical communication.

One notable content strategy skill where most of the technical communicators either struggle or where they are not active, is focus on metrics and a ROI-oriented approach. Writers do not generally align their documentation goals with the business goals. Not many companies encourage it and this is another area where technical communication and content strategy part ways.

Technology such as AR, VR, or IoT may challenge all of us. To ensure that everyone’s efforts align with the business goals, it is important that communicators and marketers work with strategists, and work like strategists.