Tools

Namespaces

Variants

Views

Actions

Search

Contents

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.

# Use fonts in line with the intent of the product, for instance a game/fun application could use fonts like Comic Sans, Monotype Corsiva etc, where-as an application targetted for enterprises should typically use Times New Roman, Arial etc as fonts.

# Use fonts in line with the intent of the product, for instance a game/fun application could use fonts like Comic Sans, Monotype Corsiva etc, where-as an application targetted for enterprises should typically use Times New Roman, Arial etc as fonts.

# Ensure that the layout fits well into the limited visible space available on the mobile devices.

# Ensure that the layout fits well into the limited visible space available on the mobile devices.

−

4. <b>Writing the actual content of the help manual</b>

4. <b>Writing the actual content of the help manual</b>

Line 47:

Line 46:

# Do not use slangs or wordings with religious/racial/sexual/ethnic connotations. Remember the intent is to help and not to hurt/peeve the end user.

# Do not use slangs or wordings with religious/racial/sexual/ethnic connotations. Remember the intent is to help and not to hurt/peeve the end user.

# Share the support center contact details in case the user is not able to make headaway even after using the help.

# Share the support center contact details in case the user is not able to make headaway even after using the help.

−

+

#The application should works as specified in the documentation and the Help screen.

−

+

#User guide/feature list must be up to date and consistent with application.

+

#Do not use overall terminology in technical word, use terminology which is familiar to target users.

+

<br>

5. <b>Review, both peer and end-user</b>

5. <b>Review, both peer and end-user</b>

Revision as of 06:06, 30 June 2009

Help manuals are written keeping in mind the end user, who mostly likely would not be that conversant with the technical complexities of the implementation. Which brings us to the first golden rule of writing help manuals “Do not use technical jargons or overwhelm the user with details of underlying technicalities of the functionalities”.

The user is not bothered about the nitty-gritties; rather s/he wants to use the application without too much fiddling around, which brings us to the second golden rule. “The steps, process, ways to use the application or its functionalities should be written/documented in simple, easy to understand language”.

Lesser the maintenance/after sales support a product requires, better are the Return On Investment for the parent company, in which lies the third golden rule. “A well written help manual could very easily from an end user perspective be the best/worst part of the product/service offering.”

There is no substitute for a specialist, which means if the product being developed has lot of functionalities and you want the end user to actually make use of those offerings, you should always consider hiring/taking the services of a technical writer. The technical writer comes with an end user perspective, as ideally speaking s/he hasn’t been associated with the code/design of the product. So when they see the product they think of it from the eyes of a user, his/her comfort level and familiarity with the product offerings. This understanding helps them formulate the help manual in a manner which is easy to follow and use.

Some of the phases of writing a help manual should be:-

1. Understanding the target user profile

Before even beginning to look at the product offering or writing a single word in the help manual, the writer should understand who the end users of the product are. They should delve into the likely skill-sets, comfort level, expectations, usage patterns, linguistic/cultural profile of the target user.

The first two would help in deciding how much information needs to be provided. The next two would help in formulating the help in a way where the most common used functionalities/expected behaviors to be documented more clearly and in greater details. While the last two would decide the languages that the help manual needs to be written in, also to use words/expressions/grammar and other linguistic things in accordance with the user, because some words/sentences might make complete sense to someone in say the US while it could end up offending someone in India.

2. Analyzing the working of the product in detail

Typically the individual writing the help manual should understand all the functionalities/offerings/any known issues/limitations of the product as this would help them articulate the same properly so that the user doesn’t have to spend sleepless nights making repeated calls to after sales/support groups. The writer should sync up with the architect/product manager of the application to understand the application in detail. One to one sessions/walk throughs could be a good way of doing this activity.

3. Creation of a user friendly layout/format for the help manual

The layout/stylesheet of the help manual should be user friendly and easy on the eyes. It should be formal yet attractive enough for someone willing to look through them. A typical end user is very irritable when it comes to spending too much effort to get something working, hence the importance of using the right layout/fonts/colors to give the user a sense of purpose and helpfulness.

Some generic guidelines to follow are:-

Generally a pictoral representation of the features/settings is more informative and easy to follow then words.

Maintain consistency of fonts and layout throughout the help manual

Use colors sensibly ensuring that you don’t use too loud colors, or any colors that could possibly offend/irritate the reader’s sensibilities.

Use fonts in line with the intent of the product, for instance a game/fun application could use fonts like Comic Sans, Monotype Corsiva etc, where-as an application targetted for enterprises should typically use Times New Roman, Arial etc as fonts.

Ensure that the layout fits well into the limited visible space available on the mobile devices.

4. Writing the actual content of the help manual

Having finalized the layout/format of the manual, you get down to the actual wording of the help manual. Make sure that you don’t overwhelm the user with too much content or give too less information thinking the user would be smart enough to read between the lines.

Some generic guidelines to follow during this activity are:-

Clearly detail the settings/expected values on the settings/administrator pages if the application has any.

Document the maximum/minimum values for the input fields so that the user is aware of them before-hand.

Clearly mention the known issues if any before hand so that the user doesn’t expect something to work when it is not going to in any case.

Link the logical entities of the help together for instance in a multi view application it is always a good idea to write the help for all the functions/commands available on a particular view.

In case the help for a particular view also completes a feature on another view, give links to that instead of re-writing the entire thing again.

Use the right wordings, carefully detailing the steps and expected behavior, sometimes an example setting and the expected results would help the user to understand better.

Do not use slangs or wordings with religious/racial/sexual/ethnic connotations. Remember the intent is to help and not to hurt/peeve the end user.

Share the support center contact details in case the user is not able to make headaway even after using the help.

The application should works as specified in the documentation and the Help screen.

User guide/feature list must be up to date and consistent with application.

Do not use overall terminology in technical word, use terminology which is familiar to target users.

5. Review, both peer and end-user

Get the contents reviewed by your peer in case you have one, otherwise the product manager/architect could also be a good choice for the reviewer. It would also be advisable to ask an end user/someone not involved in the product development/help content writing process to review the artefacts. The latter would bring in fresh ideas and end user perspectives thereby helping finetune/improve the document even better.

6. Final delivery along with the product

Once you have done all this, you are ready to deliver the help manual along with the product, either as an online help tool, end user documentation/manual or a context sensitive help.