Create Stunning User Documentation Using Online Documentation Tool

A user manual is a great tool for any product.

It answers simple questions about usage, helps guide new users for their first steps – and it’s obsolete as soon as it’s left the printing press.

There’s always something more to add.

Maybe it’s a hack a user thought of, maybe it’s a bug found a week after release.

Do you really want to go through the hassle of updating your user manual again?

Especially in the world of software, and especially in software as a service.

But even though it’s troublesome, you still need to write strong and readable documentation for your users to rely upon. A product without documentation is already essentially dead in the water.

How many times have you started a new program and never needed to look up how to do something with it?

Fortunately there are already excellent online documentation tools for getting robust and flexible user documentation out there. In this article, you’ll see what makes Document360 the clear leader in this space.

What Makes Good Documentation?

One of the first key elements in writing good documentation is clarity. If you start out writing with clarity in mind, you’ll always end up writing something that’s useful to the end user.

That means two things when broken down.

First, your writing should be concise and accessible. Never use a sentence where a phrase would do (tech writers are notorious for doing this). Short writing makes it easy for readers to grasp the most important concepts.

Part of this is also assuming limited tech knowledge on the part of your users, or at least only as much knowledge as is actually required to perform each task. Even very technical people have slow days where they’d rather just read a quick explanation instead of having to remember each code library name.

Second, it should have a unified style. On big projects, it’s inevitable that multiple developers or other team members will get involved. It’s very important to have an editor involved so that the writing style remains consistent throughout the whole manual.

If it doesn’t, it’s practically inevitable that different terms will be used for the same concepts and the same process will be described with different steps. That’s a great recipe for confusion!

Another mark of good documentation is usefulness.

Plenty of developers have their own “favorite feature” that ends up taking the lion’s share of their development time. They’re proud of it, and justifiably so.

But if you ask them to write about how to use the product as a whole, they may not be able to escape the blinders of their own effort.

The documentation needs to be built for the users. That means you need to both have a great idea of what they’re going to need, as well as have a way to analyze which articles are actually being read.

That kind of analysis, incidentally, is built right into Document360. It’s easy to perform an internal audit and see which articles aren’t getting the attention they deserve.

Lastly, good documentation keeps up with the times.

The ideal user manual is immediately updated as soon as the product is updated. Any new feature, any change in a menu, any change in functionality – that’s an update to the documentation.

It only makes sense, right? You can’t point users to something you know is out of date. The last thing you want is a frustrating tech support ticket to be reopened again because the manual itself was wrong.

Old-style manuals and static webpages rarely stood a chance of being updated more than once or twice, but with a knowledge base as your source of support, you’ll be able to quickly and easily keep users updated and happy.

Yes, happy – even when they have issues.

Users Love Helping Themselves

That’s because users are most satisfied when they can solve their own problems.

Everybody likes feeling competent and knowledgeable, and even people that don’t mind getting their support questions answered by others still save time if they can find the answers by themselves.

After all, a lot of support questions are “how do I use this feature” or “does this feature exist?” This kind of thing takes time to answer, but once a user learns it, they’re not going to forget. It becomes a part of their skill set.

That’s not to say that a high-quality manual is enough to totally replace your support people, though.

But it can cut you down from, say, paying for live phone support to paying for live text chat support, or from chat support to email support.

On top of that, you build a sense of authority and expertise with your product.

You definitely want that, and you’d assume it would be the default case. However, plenty of people are used to heading straight to Quora or StackExchange with their product questions, and there they could be led astray by people promoting their own competing solutions.

Why not get them to go to your site? Your official site is already going to rank highly for searches about your product, so it stands to reason that your online support pages should as well.

Don’t let your current or future customers get led astray by third-party sites, no matter how well-meaning. Get your users comfortable with finding their answers on your site, and you’ll be amazed at how many more stay with your product.

A Knowledge Base – The Best Option for User Documentation

There are a couple of good reasons why a knowledge base checks all the options mentioned so far for user documentation needs.

First, it’s really easy to update and rework a knowledge base. We’ll go into detail a little bit later on about just how simple it can be to manage different versions and approve different levels of access.

All the concerns about keeping your documentation updated get totally addressed by the forward-thinking metrics and analytics available to you with a platform like Document360.

You get to see what type of problems people are searching for solutions to, where they come from, and which articles are the most helpful. That “helpfulness” rating is itself broken down into both actual ratings of “good, medium, bad” and view counts.

Your team can cross-reference all of these data points to build a complex and nuanced image of the success of your user documentation, and then make targeted adjustments where necessary to improve.

Second, the fundamental format of a knowledge base keeps people moving through the articles exactly where they need to go, solving their own problems on the way.

It’s an expertly designed system for cross-linked answers and quick knowledge dumps.

For example, a typical article appears large and clear on the screen with photos, videos, and more helping the user understand exactly what they need to do to solve their problems.

Next to the central article is a logically-flowing table of contents that lets users quickly jump to whatever catches their eye.

And of course, there’s the search bar – the killer feature of every good knowledge base.

The Search Bar

This is not your ordinary search bar.

It immediately searches the titles, tags, and full text of all articles in the knowledge base, as well as performing fuzzy matching and statistical analysis to guess which article is the most relevant at any given time.

You can see here in this example that searching for “pictures” brought up results about “images,” including the most relevant article based on statistics “adding images to articles.” Even though several articles include the search key “pictures,” the algorithm knew the top result was the most fitting answer.

The fuzzy matching shows up here as well: the search term was “pictures” with an S, but the results include “picture” with no S as well.

As you can immediately tell, the search bar works best when you have well-organized content to choose from.

Suppose you make billing software, and your users are looking for the way to produce a rolling total.

If they search for ‘rolling total’ in the search bar, they’ll ideally see an article titled exactly that, short and to the point.

But they’ll also see where the rolling total was mentioned in other articles, such as in an article about the types of calculations that can be done with the software. This is great because it might get the user to explore around the documentation and end up teaching themselves more than they expected to learn.

Even better, it works the other way too.

You can and should hotlink articles to other articles, so that as you read about one available functionality, your attention is automatically linked to the other things that are possible with your software.

In this example, “Custom HTML Section” and “Custom Footer” both link to the appropriate articles. It’s easy to track which users come from outside searches, which users come from the search bar results, and which users come from hyperlinks inside the articles themselves.

Speaking of tracking, search metrics are indispensable when writing user documentation on an online knowledge base.

You should be able to see information on three key data points: number of searches, number of users searching, and number of searches that came up with zero results.

The number of searches in general gives you a broad sense of the utilization of your documentation tool. After setting up a knowledge base, you should expect to see people using it – so if they aren’t, you need to get the word out to your customer base about this nifty new feature. The number of users searching is also helpful because if that number is very different from the total number of searches, it means that some of the population is searching multiple times before they get their question resolved.

You can track that by seeing a list of the search terms that come up with no results. Often, these will be typos that the fuzzy matching wasn’t quite able to handle. But if you see useful search terms in that list, it’s a good idea to whip up some articles on that subject that could be served next time.

As a final touch, it’s simple and painless to exclude an article from search if you so choose. You might do this if you’re working on different iterations of an article, for instance, or if a new feature has come out and you haven’t yet gotten around to writing the necessary documentation.

As you can see, a search tool is only as good as how it works for the users and the customer service team.

Getting Started with Document360

So just how easy is it to start using Document360 to build your knowledge base, get access to those search metrics and revolutionize your user documentation strategy?

Very, very easy.

As soon as you sign up, if you already have another knowledge base from another company, the staff at Document360 will help you migrate all your articles over with an automated system. You’ll be able to preserve all the images, videos, files, and formatting in your old one too.

And if Document360 is your first online knowledge base platform, you’ll feel right at home. Everything’s been designed to be as intuitive as possible for first-time users. That’s evident from the first look at the page editor.

The Document360 Editor

The page editor for Document360 should be super familiar if you’ve ever written a post on an online forum or blog.

It’s called a “what you see is what you get” editor, or WYSIWYG for short.

That means the formatting tools such as font size, bold/italic, and spacing are all usable as if they were a word processor.

This is a standard feature, but imagine going back and trying to build a website just a decade ago – messing around with HTML and CSS to get each section absolutely perfect.

Document360 also supports Markdown.

Markdown is a concept little seen outside the blogging world, but it has some great advantages over just using the GUI buttons to format your text. For one, you never need to take your hands off the keyboard.

For another, you can focus on the content of your post without getting distracted by formatting until the very end. For example, you just need to add asterisks to bold your text or underscores to italicize. This lets you rapidly use the most common formatting styles without needing to interrupt your flow and change from “writing mode” into “how do I make this look good” mode.

As you can see in the above screenshot, the editor includes a separate pane for live viewing of what your published post will look like.

At the upper right of the screenshot, you can also see a button for comments. The comments feature in the Document360 editor lets you add comments to articles for other people on your team to see your thought process – and maybe suggest some changes of their own.

Think of the alternative for a moment: if you wanted comments on a particular article before you launched it, you’d have to send it around via Slack or email in order to solicit comments from everyone individually.

Now people can see your draft with the attached comments and quickly let you know what they think.

That review process is absolutely imperative for writing clear online documentation helpful for users from all backgrounds. The more eyes you have on your articles, the more helpful they’ll be.

Managing Categories

Document360 is built on a category model. This helps you organize your documentation into sections, much like chapters or parts in a traditional user handbook. You could have sections for “Working With Accounts,” for instance, and that section might include “Adding accounts” and “Removing accounts” as articles.

The sections are all viewable at all times on the left-hand side of the screen for quick navigation.

You’re allowed to create up to six levels of nested categories for a clear and orderly documentation presentation.

This fits really well with the principle of online documentation design that your users should be able to navigate the website without having to solve any problems stemming from poor layout.

As you can see in the example, each nested level is clearly one layer of abstraction more specific for the exact topic users might be searching for. This helps you cover your bases if you haven’t yet fleshed out your full documentation outline.

A user might be directed to the “Custom CSS” page when they really wanted more information or an overview of appearance settings in general. By having the categories nested in this way, it’s totally intuitive to move up one level and see all the articles that have to do with appearance customization.

By the way, you don’t have to have the same folder icon for every level.

You can also add emojis into the names themselves! Simply clicking on the folder icon brings up an entire emoji gallery. Be warned, though, that different browsers display emojis in subtly different ways. A viewer using an iPhone and a viewer on Chrome on their Windows desktop are going to see slightly different images – and every designer has their own emoji preferences.

Note also that the category manager supports bulk operations.

From the editor, you can publish, hide, show, and delete multiple selected articles or categories at once. You can also move articles to a different category.

Let’s stick to that example about editing CSS. If your developers started out with only a couple of different ways to customize the appearance of your software, and one of them was based on CSS, it might not make sense at first to have an entire Appearance category. Later on, if a dedicated Appearance Editor comes out, you might find that an entire category is justified.

Finally, different categories might be applicable to some users but not all. It’s easy to assign levels of access across your whole knowledge base, so that, for example, subscribers to the “Free” tier don’t get swamped by articles about all the features in the “Executive” tier.

Versioning Your Documentation

As has hopefully been clear throughout this article, when you write user documentation it needs to be updated frequently to match the development of your product.

This can be tough when dealing with several human editors and no centralized place to manage different versions of the documentation. Inevitably, someone is going to create their own version with their own changes. A couple of cycles of that, and it’s a nightmare trying to get it back together in one piece. This can happen with just one article!

Document360’s draft editor allows for easy “forking” of articles.

Forking a draft just means that a new copy is created and kept unpublished for you to edit as you like. You can choose to publish or unpublish any of the drafts in the edit history at any time – or delete them if they’re no longer necessary.

And what about the case where multiple people are working on their own forks? As much as we’d like to think our teams communicate perfectly, it happens plenty often that two people have their own visions for one document and haven’t gotten together to collaborate.

Since you can easily see which version is the “latest” and which version is published, this confusion should be cut down by a lot.

And when it isn’t, you can click “View Differences” between two article versions and compare them with highlighted changes.

This can be a good auditing tool to see how much actually gets changed over time as your team is improving the articles. Are they mostly making minor cosmetic changes, or are there big overhauls happening all the time?

Conclusion

Whether or not you use Document360 for your user documentation management, you should be able to see the benefits of industry-standard features like search metrics, versioning, an easy-to-use editor, and so on.

Believe it or not, companies that actually pay close attention to their user documentation are in the minority – and they suffer because of it.

Why not take the opportunity now to level up your customer service knowledge base with a robust user documentation tool?

Using the right tools for technical writing makes the life of a technical writer easy. Read on most popular tools for technical writing