Guides to software manuals To create the perfect software … – Channel Partners

Unfortunately, few projects have an emphasis on the documentation that you provide. But consider this task as a necessary evil.
In the applications that support business processes, only parts of the purchased or leased software are mostly used. What processes, when and in what manner are mapped is different from company to company, from one area to another.

Some software documentation leaves among users more question mark as a relief
Photo:. Syda Productions-shutterstock.com

We all know that a software project usually competes with big goals, then step step to reduce its scope (Scope). What is still displayed initially logical and structured, loses with increasing complexity and number of process variants of logic. Suddenly there shall be an option to be activated, which does not fit to the process; da dip content equal fields with different wording on or field names are named so that the user needs to think twice about the corner.

If the user 2 x around the corner thinking must

Since This happens in pretty much every software implementation, we need a solution that helps the user in everyday life, to find your way. We should not rely solely on its intuition, because that would all too often provide the wrong answer. Therefore, it needs process-oriented manuals that describe step by step what to do

Here you will find six tips you should heed when creating user oriented documentation:.

“11.5”>
• Talk. the language of the user
  grid, grids, multi-value, etc. are terms that come from the IT The user thinks and speaks of windows, boxes, lines, and selection lists. If this IT-heavy concepts but want to use, you should have good and understandable reasons for this decision. Then you should use these terms consistently and systematically. Without exception. We write for our users, not for ourselves. So we have to make use of their language. To want to find the right words, listen to the users. Which applications are otherwise still used and which concepts are already being used there? You do not have to invent from scratch but, use, whenever possible, already something present the wheel. Ask their documentation a chapter disambiguation forward to explain this.
  

• Create Confidence
  Just imagine, you have bought a new TV. A great device with many features that you are very curious. The device is attached multi-lingual guide. You can find your preferred language and follow the operating instructions carefully. Unfortunately, without coming to the desired destination. The device is not working as it is described. You are wasting valuable time, get angry, lose the desire and ask whether the unit is just as bad as the instructions to do so.

A prospectus for your solution.

Do you have a guide that describes each step and understand the application works in the specified manner, then creates confidence and saves you trouble, questions and erroneous data. Give yourself quiet a bit of effort to make the documentation in response. This increases the chance that users will take this fact into their own hands. Then the documentation is a prospectus for your solution.

• Use the documentation during training
  > Creating a good user documentation means effort. Therefore, use this documentation as often as possible. Additional training materials that are used in the training, do not make sense. Let the users already use in the training documentation. Refer again it

  A logical sequence of the content may be 1:. 1 be the sequence in which the content is taught. Use the documentation, so that the participants work during the training content itself. This creates confidence in the documentation but also in the ego of the participant:
  

• <"but it is not so difficult is indeed all in here.." p> precision, truth and clarity
  Sometimes it is not as optimal as the software reacts in everyday life or what she wants to be fed. Some operations or functions are just the beginning, maybe very slowly.
  Enter the users to clear and precise instructions. You should know exactly which option you need to select when. . You do not want to interpret

  Could, should, would, perhaps, probably – you can remove it from the vocabulary

  What counts is precision, structure and. whole truth, even if they are not beautiful sounds. We do not write the novel Gone with the Wind but an instruction manual, which leaves no room for interpretation. And if it is indeed the case, then we also write five times in a row: Click

Besipiel for a step by step instructions (Microsoft AX)
Photo: Christa Weidner

The benefit must also for the users outweigh

“5”

• Keep it Short
  Each word we write must be read by the user. It also prolongs the proofreading and revising. Check every syllable and word on whether it is necessary and contains additional information. If not, get rid of it. Write short sentences. Remember, though, that must prevail even for the user of the benefits.
  

• Make the dummy test
  Make the dummy test: A documentary is good, if any user without any previous knowledge and training, based on the documented instructions to operate the software and implement the processes can. If your documentation can do that, then it is really good.

Please use the format that prefer your users

If the authors Editors and follow your software documentation these tips consistently and meet, then you’ve probably already an exceptionally good documentation that is available for your project of great benefit. With such documentation can the training time will be shorter, there are fewer support calls and also the process and data quality will surprise positively. BTW, when we speak of documentation, then this can also be online, wiki-based zumBeispiel are provided on your intranet. Use the format that prefer their users. (BW)

Newsletter ‘products’ order!