How title and navigation in documentation help minimize user stress

9 min

Sooner or later we all find ourselves face to face with a complex information system, and not every interface allows us to quickly find and perform the required procedure. In such a situation, events can develop according to one of two scenarios:

The first. In front of you is the system and 5 minutes to complete the necessary procedure in it. First of all, you are looking for the right button or menu item, do not find it and start to get nervous, because time passes, and you want to be effective in any of your activities. Tension makes you defocused, in this state you continue to search and at some point you realize that you cannot figure it out on your own. Contact technical support: dial the number, pleasant music plays and a detached voice informs you that you are the fifteenth in line, the tension grows. After some time, a technical support employee answers, he explains to you what to do. You calm down and complete your task.

Second. Here is the same system and the same 5 minutes. You open the user manual, find the section you want, read it and do everything as it says. Several minutes passed, you calmly figured it out and completed your task.

As a user, I would be more satisfied with the second scenario, in which the user manual plays a very important role. But not every guide will help you quickly figure out something; there are a number of requirements that it must meet.

In this article, we will analyze the requirements that relate to the titles of sections in the manual or the titles of instructions. We will also discuss how navigation should be in user documentation.

Do you want no one to find, name without thinking

The title of the instruction is not the title of an article on the Internet. He does not need to attract attention and evoke any emotions. The user should understand by name what procedure is described in the instructions. The instruction should be named so that it is easy to find it on the Internet. Let’s take a closer look at this.

The title of the instruction should not evoke emotion

I use two kinds of names:

  • title-problem;
  • process name.

Each species has its own purpose, and when choosing a name, one important point should be taken into account – the psychological state of the user, namely, the state in which he is at the moment when he starts looking for this instruction.

What is “name-process”

The purpose of an instruction with this name is to explain a process.

An example of a situation: the user needs to understand something, he has a sufficient amount of time and a more or less calm state. In fact, his job is to understand how something works. For the instruction that will solve such a problem, I use the name-process.

If this is a user manual, then there may be many such processes in it. In this case, we are not talking about the title of the instruction, but about the title of the section of the manual.

Your search query can begin with the words “how does it work” or “how to do it”. These are obviously requests for a description of the process; the user will ask differently about errors and problems.

An example of a process-name: “Working with the Rutoken Disk program”

The situation when they will look for this instruction: the user bought a Rutoken device with the Rutoken Disk program and wants to figure out how to save a file in a protected flash memory.

His search query: “How to save a file in a protected section” or “how to work with Rutoken Disk”.

He opens the instruction, selects his operating system and a section titled “Working with a protected section”. Such a search will take him a few seconds. Then he will perform all the steps of this procedure and understand the process.

Another example of a process-name: “Working with Rutoken through CryptoPro CSP in macOS”

The situation when they will look for this instruction: the user bought a Rutoken with a CryptoPro certificate and he needs it to work on a MacBook.

His search query: “Rutoken CryptoPro macOS”.

He opens the instruction and performs all the steps from it in sequence.

An example of a bad instruction name: “Instructions for formatting Rutoken and setting a new PIN-code for clients migrating from the RB System”

The situation when they will look for this instruction: the user needs to format the token before using it in another system, or he just needs to change the PIN.

I don’t like this name for three reasons:

  • It’s too long.
  • It contains two procedures: formatting the token and changing the PIN.
  • The name is not worded the way the user will look for it.

And it turns out that it can be found not only by the user who wants to format the token, but also by the one who wants to change the PIN. The user will open this instruction, start formatting the token, and this will lead to the fact that all certificates that cost money are deleted. He just wanted to change the PIN, but it had to be done differently. Also, the user could have an initially empty token, then there is no need to format it. In this example, we see that a bad instruction name can even lead to financial losses. This instruction would be suitable only if the user needed to format the Rutoken.

Bad name can lead to financial losses

Now on request “how to change Rutoken PIN-code” the user will find our instructions.

What is “name-problem”

The purpose of an instruction with this name is to help solve a problem.

The user was working in the system and something happened in it. For example, a message was displayed with some kind of warning or error, and he does not know what to do correctly. He finds himself in a stressful situation, the result depends on what he will do next. To describe such cases, I use the name-problem.

Your search query may start with the words “what to do if” or “an error was displayed”. Here the user needs to get an answer as quickly as possible.

Also, in such a situation, its search query may duplicate the name of the error or the text of the warning.

An example of such a name: Rutoken smart card unavailable

The situation when they will look for this instruction: the user connects a Rutoken smart card, but it does not work in the system, and he wants to figure out why it does not work and what to do to make it work.

His search query: “Tokens or smart cards are not available”. He describes the problem as it appears in the error window.

He finds this instruction and performs the necessary actions on the system.

The second example of a title, but now a section: What to do if the User’s PIN is blocked.

The situation when they will look for this instruction: the user entered the wrong PIN code several times, a message was displayed on the screen stating that it was blocked.

The most emotional reaction can occur when this is first encountered. Most often, it seems to the user that everything, access to Rutoken cannot be returned, but this is not so.

His search query would be like this: “What to do if the User’s PIN is blocked”.

He will open this instruction, find the desired section and unlock the PIN.

An example of a bad instruction name: Rutoken is inserted, but the red diode is off. What to do?

What I don’t like about this title:

  • It is too long, it contains unnecessary details, namely that Rutoken is inserted. Due to this, the name could be shortened.
  • I would replace the word “diode”, not every user knows it.

Let’s draw general conclusions:

  1. Before coming up with a name for an instruction, you need to understand who this instruction is for and in what situation the user will look for it.
  2. When composing titles, use words from the user’s world.
  3. Think about what query the user will enter when they look for an instruction.
  4. Before publishing the instructions, read the title again and think if you have indicated some unnecessary details.

If you want no one to find it, forget about navigation

After the user reads the title of the instruction, understands how suitable it is for his task, he will be taken to the page with the content. So it should also be composed in a certain way. True, there is a case when it should not be. Let’s figure it out, I hope you’re not tired yet.

Content as a map

The main requirement for the content of the instruction is that it must be logical.
The purpose of the content, like any map, is to speed up the search process. Help the user quickly find the desired section. Yes, someone will say that you can always use the internal search in the instructions by pressing Ctrl + F, but this is not always convenient. If there are many pages in the manual, then the internal search can only confuse the user.

Content should be logical

Here, too, we cannot do without examples. Let’s take a look at navigation in one of my instructions.

The simplest case is when a program is described that runs in one operating system. In our case, this is the program Rutoken Logon… Let’s take a look at how navigation works in instructions for her.

As you can see, this is just a sequence of procedures. They are built according to a certain logic that reflects how the user will interact with this program. It turns out that before posting the content of the instruction, it is necessary to understand what the user will do in this program, to understand its logic.

A simple sequence of presentation might look like this:

Installation -> Start -> Settings -> Workflow -> Uninstall

In such content, the user simply finds the desired section and follows the procedure described in it.

The second case is when there is a program that runs on multiple operating systems.

We have previously considered instruction about Rutoken Disc, it just was with such content. In it, the user finds a section with his operating system and a subsection with the necessary procedure.

This sequence of presentation looks like this:

Selecting an operating system -> Start -> Settings -> Workflow -> Uninstall

The name of the operating system was simply added here, there can be many of them in one instruction.

The user must find the name of the desired section in less than half a minute, otherwise it can be concluded that the content does not work and can be safely removed.

The user has half a minute to find the desired section

I also really like to do navigation within sections, this is for those users who automatically skip the content.

Here’s an example like this instructions… It is written for users Rutoken U2F

Here, if the user skips the content, he will see the name of the required service in the section heading and already inside this section will find the required subsection, while the names of these subsections also remain in the content, for those who still read it.

Content can ruin everything

There is a case where content can really ruin everything. The easiest way to describe it is that if the user skips any step, nothing will work. A roadmap is needed if there are many roads. But when there is only one road and you need to move along it without missing a single point, the map is not needed. The user simply follows all the steps one by one. Yes, I have a lot of such instructions, and they are most often about setting up something. To minimize the user’s stress, at the beginning of such an instruction, I explain to him that it is necessary to consistently follow all the steps of this instruction, then he will form a certain mood.

The last example in this article will be about that. Instructions on how to remove the certificate. At the very beginning of it, I explain to the user that before deleting the certificate, you need to define the encryption provider or the certificate format and write down the container name. This is important, because you can delete the wrong certificate, and it will be impossible to return it.

Therefore, at the beginning of the instruction, the user does not have the opportunity to go directly to a section. He opens the instruction and on the first page reads the warning and the sequence of actions. Here my role is to warn him of the possible risks. Then, of course, he chooses for himself how to act.

Let’s draw general conclusions:

  1. When composing your content, consider the logic of user interaction with what you are describing.
  2. If the user missed the content, then navigation in the section can help him.
  3. If you cannot skip steps in the instructions, then navigation is not needed.

It would seem that all these conclusions are simple and logical, but I often see that they forget about it. Let’s all the same be aware of everything that is written in this article and start writing in such a way as to minimize user stress. After all, then we can change its state, as well as improve the global relationship to user documentation.


Leave a Reply