I am developing a system for publishing instructions for my company. And in the process I noticed a very interesting feature concerning not only filling out instructions, but also setting tasks in corporate information systems (CIS), building hierarchical structures with descriptions, etc. This semantic feature is connected with the choice of field names.
Suppose we have an instruction. The instruction, besides other fields, contains the following:
- name (required, unique within the container)
- short description (optional)
- detailed description (mandatory, formatted text)
')
A brief description is needed in two contexts:
1) introduction to the course when reading the instructions themselves
2) an explanation of the name, when the instructions are displayed in a list or table
As a rule, if the field with a brief description is called
“short description” , the user falls into a stupor when filling out the form. He needs to either comprehend the whole instruction and write a squeeze out of it, or quote some important, in his opinion, fragment. The “short description” field becomes rather an announcement, a preview, and it is almost meaningless to show it when you view the instructions in detail, along with a detailed description. Those. it becomes useful only in the second context.
At the same time, the “short description” becomes strictly dependent on the “detailed description” field. If the process described by the instruction changes, you will have to rewrite both fields.
I renamed the field, called it
“goal,” and it immediately got rid of all the flaws. First, when writing instructions, the user remembers what the final results it should lead to, as a result it is easier for him to fill in the remaining fields. Secondly, when reading instructions, it is easier to understand its essence, when you know why the actions described in it are performed. Thirdly, the field “goal” perfectly complements the name as a brief description (usually it is one or two sentences meaningful). Fourthly, the goals of processes change less often the ways of their implementation, thus, this field needs to be changed only when the very essence of the instruction changes.