You have to deliver ...
- Content-relevant help
- Work-process and context-sensitive help
- User- and role-centric help
- Understandable help
- Friendly, respectful and polite help
You know there is no rule without an exception – that’s pretty much the same with this article. You know I’m putting always the user first – but not in this case.
When you are ask to develop a help system for an application, software or other product. The product is or is more or less final. The tasks and goals are final – hopefully they are – If not (don’t laugh – it’s sad but true, but there are still agencies and companies with products without real goals and real tasks, either because it’s a “me too product” or they lost it as a consequent of too many cooks or too much “democratic”.) you have to define the goals.
Start to ask ...
- What are the overall goals and aims
- What are the sub goals and aims?
And begin by defining the purpose and intention of the product and or service. Parallel to this you should note and understand the main and holistic purpose, the purpose of the stakeholders (company, department, …), the business principles and finally the expectation and needs of your various user and their needs, tasks and work processes.
Your help concepts should be designed around use cases, with tutorials for these cases.
are you, the supplier, clients, customer and users having or you can expect with the service and or product,
and what kind or amount of ...
might be needed ?
And then you have to analyzing the use- and workflow:
... Describe users’ tasks as detailed as possible
... Create task scenarios
... Keep in mind that there are many sub tasks within the overall workflow
Do usability testings - Note the behavior and interaction of your participants - Your aim is understanding and observing how and why they act as they act – record …
... Dead ends …
but also the points where you except problems but your participants hasn’t any.
Where can help be displayed?
- At the cursor or pointer (minesweeping)
- By Balloon Help
- On the status bar
- As a panel (content container) within the application window
- In a separate, independent window
How does a user get help?
- Static, permanent display
- Display on system start up
- Tooltips and hints on feature use
- Keyboard shortcut
- Menu selection
- Tool selection
- Audible help
Avatars, balloon helps and wizards are good for rarely and seldom performed tasks, but are usually not good for teaching. Wizards are often annoying – I think we all can remember on Clippy by Microsoft Office – the annoying Clip.
Style and approach for giving help – from less recommended to much recommended:
- Present total procedure and functions for user without demonstration or explanation and no content-situative and context-sensitive relation
- Present total procedure and functions for user without demonstration or explanation, but concerning to the current sub task
- Fundamentally present, without clarification, following steps at a specific state of work
- Fundamentally present and describe successive steps at a specific state of work
- Demonstrate without description successive steps at a specific state of work
- Show and describe successive steps at a specific state of work
- Point to and suggest consecutive steps, in relation to the individual state of work (work flow)
- Point to, suggest and explain successive, following steps, in relation to the individual state of work (work flow)