Engage: Publish And Listen To The Feedback

You’ve planned it, written it, and reviewed it. Now it’s time to publish your documentation and engage with your readers to find out how they benefit from it and what you can improve.

Publishing isn’t just about hitting Share or Export or Publish. It’s a critical step in the documentation life cycle; it’s the first touchpoint between your audience and your new content. It’s where the public testing phase starts. Let’s take a closer look at both the best practices for publishing and subsequent engagement with your readers, and the questions you should answer to make sure that this part of the documentation lifecycle is useful for you and your audience.

Last Minute Sync

Hitting the publish button is, of course, the moment that gives the team the sense of accomplishment. You define what Done means—both on the content strategy level and for any particular release (see the Release and Communication section in Plan: Before You Start Writing... ).

Before you share the news and your new documentation with the target audience, we advise running a last-minute sync, a pre-flight check, with your internal stakeholders, especially if you’re working in software development—with your product manager/owner, team lead, legal, marketing, product release team, sales.

You can hold a 10-minute meeting, use Slack, etc.; this is up to you. Just make sure that this checklist is a part of your overall process.

Release Notes and Internal Communication

For the purpose of this part, let’s assume the following:

• Release notes - a document with news about your product and product documentation updates shared with a wide audience (customers, internal stakeholders, etc.)

• Internal communication - a document distributed to employees of your company, for example, about new HR policies, changes in a C-level post, mandatory health and safety courses, etc.

When it comes to which communication channels you use to reach your audience, you are really spoilt for choice today - Slack, social networks, email, videos…. But there should always be one source to which all messages, posts, etc. lead and link to - a proper, accessible page on the internet or in your intranet.

Release notes

In its purest definition, a Release notes document provides the summary of changes between two releases. But it can be more versatile - you can share details about upcoming changes to give your customers the chance to prepare.

On the other hand, Release notes should not replace documentation. It should provide an overview - a brief scope of the update, outline the benefits to end users. If you link to the full documentation pages for the respective features, you will also improve traffic on your site.

It might be a good idea to subject the Release Notes text to both peer and subject matter expert review. Why? Distilling complex technical issues to a release-notes-sized bit may distort the messaging, so it never hurts to review that.

Internal release notes version

Your end-users are not the only audience. You also have the internal audience: support team, professional services, customer success managers, sales team.

Now, you may ask, why would they need a dedicated internal release notes version? Well, all of the above-mentioned groups need more details - name of the product manager, links to your project management tools (such as Jira), internal-only resources (product demos), technical details of the updates that were not shared with end-users, etc.

Internal Release notes will become a single entry point to related content for internal stakeholders. For example, Sales and Customer Success teams, that are in the front line when it comes to getting new clients and preventing churn, will be able to work with extra details.

Internal communication

In our scenario, newsletters address everyone in the company. And as such, you need to find a way to make sure that everybody ‘gets the message’ and/or can find content easily.

Intranets make this really easy because in most implementations, everyone in the company has access to them.

After You Publish

Now that your documentation and release notes/newsletter are published, you may want to see how your target audience is engaging with your content. Did everyone get the message about the new clean-desk policy? Is your release notes document reaching enough customers?

Using your tools' native analytical capability is a great starting point, especially if you use a unified environment for authoring, managing, and publishing your documentation. Using specialized tools for publishing, such as our Scroll Sites for Confluence from our Scroll Content Tools for Confluence , opens a whole new array of possibilities while retaining advantages of the Atlassian environment.

If your authoring environment is separate from where users access your content (for example, in a documentation website), connecting the site to tools such as Google Analytics will open a whole new array of options to get actionable analytics.

Getting Feedback

Knowing what your audience thinks about documentation is an important source of information that can improve your content.

Internally, within your company, you can easily deploy processes and tooling that will channel feedback, in any shape or form, to the right people. Intranets and their integrations with instant messaging (IM) tools are a great solution (for example, Confluence and Slack work great together) because readers can leave feedback directly in your content, as comments, inline comments, or share their thoughts via an instant messaging.

Feedback from customers

Getting feedback for your public documentation might be trickier.

You may want to protect yourself from the barrage of bots; at the same time, you don’t want to make it too difficult for your real users to share their opinions.

Connecting or integrating your documentation portal with your support service desk and issue tracking tools may be the ideal middle ground.

Such integration has several advantages:

• It gives users the tool to provide immediate feedback using the authentication tool that you provide your customers with.

• You will be able to easily manage raised issues.

• Issue tracking tools will allow you to engage with customers directly; at the same time, your users will be able to see the progress.

Feedback from within

Consider who in your company comes in closest contact with your customers. Sales, Support, Customer Success, etc. These teams can mediate the direct customer feedback both about the product and the documentation. Missing details, lack of clarity, frequently raised issues.

This type of feedback is extremely important as it is gathered in open discussions (and not as a result of an impulse) and comes filtered through knowledgeable resources, with context, and is often accompanied by specific recommendations.

Establishing channels through which those teams can provide you with immediate intelligence will lead to better documentation and, more often than not, improvements in the product itself.

Lies, Myths, and Statistics

Should you chase the view numbers in your documentation?

No. Here’s why:

• Documentation has a final (newsletters) or easily saturated audience (product documentation) level. You have a final number of employees or users (customers) at any given moment.

• Sooner or later, your product documentation site’s readership is going to reach the saturation level. You may induce peaks by SEO-optimized release notes, in-app communication, marketing activities, but the view numbers will plateau over a longer period of time.

This is our most popular content, we should promote it.

• Why and when do people read documentation? When they need help. When they can’t figure out what to do. “The most popular content” can easily signal “We need to improve our product’s feature because customers are confused.”

• Your content, typically of a more generic nature aimed to educate users about a specific subject matter, in other words, content that’s interesting outside of your product users, may be referenced on a public forum such as Atlassian Community, Stack Overflow, etc. It will drive the numbers up but most of them won’t be your customers. It may entice prospects, though 🙂

• Search engines offer accurate AI summaries.

Have Feedback, Will Travel?

Documentation is a process. A lot of things happen between hitting that Publish button. You are gathering feedback, a new release is approaching so you’re gathering information… in the next chapter, we’ll look into best practices in the sustain/maintain, the last phase of the documentation life cycle.