Help – How, When and what ...


image-source: http://dilbert.com/

What is help? What do we recognize as helpful? What will user require and identify as help and as helpful – helpful in the best way of meaning – not advisable, educational in a negative way or character? In almost every case our / your help should appear like a good friend or guide not the “big teacher” – that’s the character and just one side of the dice – And there are several more.
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 have to serve the accurate information to the particular people in a suitable way! Sounds familiar? I hope so – but all too often it’s not that way. To offer a content-sensitive help you have to ask what is the individual context and what will be the potential circumstances. And if you ask why you should make all these efforts of planning, researching, developing – It’s not because “we or you are so pleasant and kind” – No – it’s all about offering the accurate and needed support and help to the your consumer and customer in the right way. It will help the company decreasing and cutting support efforts, hotline calls and improve customer service.

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.

What ...
... troubles
... efforts
... difficulties
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 ...
... support
... assistance
... information
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 …
... Problems
... Troubles
... 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
  • Avatar
  • ...

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)
Presenting more multifaceted and rich information in the context-sensitive help link will improve the utility, usability and costs of your service, product, site and application.

Comments

Popular posts from this blog

Basics for designers

..... 4 traditional design rules

Head-up displays (HUD) much more than nice features - part 3