General strategy on help

Question

I have a fairly complex desktop application.
It uses some advanced search techniques and some statistics for analysis and prediction.

The help is separated with one section of no UI.
These are "Features", explanation on how they fit together, and the actual calculations behind the analysis.

Inline training has context sensitive help with like "button does X - syntax is Y".

One of my re-sellers has taken the time to create tutorials with step by step instructions. I am surprised it is needed but they would not have taken the time if they did not think they needed it.

What is a good strategy for help and inline training?

The app is complex and it is not expected that they would just logon and figure it out by themselves.
Like SSMS (SQL Server Management Studio) requires you to know T-SQL.

The app has a single manual that is the "what" not the "how".
It has inline help on specific features so the explanation of a button close to the button.

For some basic tasks we would like to have a tutorial to get them going.
Users will skip training and not read the manual.

The idea is a tutorial on some basic tasks to get them going.
But no way we can write tutorials for advanced stuff and all the possible paths. Technically we could but we just don't have the resources - a good tutorial takes time.

How to present to the user this tutorial is to get you going but don't expect you are going to learn the entire product?
My biggest fear is that the tutorial will be judged for what it does not do.

We have the same issue with features. If the feature lacks something they might expect we are careful to tell them what it does and does not do. Before you say give them what they expect. Users can have unrealistic expectations. It is about managing expectations.

Answer 1

Since there's no images or mockups I'm not 100% sure what you are asking, but I'll try to answer.

Is it too complex?

For starters, if the application is so complex that users need to have multiple inline helpers, it could be a major turn-off for them. Imagine entering an elevator and being handed a book on how to control the speed and acceleration by hand... you'd back off and take the stairs instead.

Do you think there is some room for improvement? Some ideas:

• Only show the required fields/options, and keep the rest at default values. Maybe provide an option to change the defaults, but don't clutter the UI if the user doesn't need to change them.
• Provide examples as placeholder text. No need for any more complicated inline help if the syntax can be explained in a dozen characters.
• Error check on losing focus, or even during input. Check whether the user properly entered a value (e.g. letters instead of digits, or two decimal points in a number), and change the color of the input field if something's wrong. A tooltip with quick error explanation might be useful, but it should only be shown if it's really needed.

^{download bmml source – Wireframes created with Balsamiq Mockups}

Lengthy help section

This should only be needed if the user wants to learn about the way your application works under the hood. If it's the go-to way of learning how to use your app, the UX may need major changes. In the above mockup I added (Click here to learn more) link, which would point to a help page dedicated to input field syntax.

Step by step instructions

If your appplication needs these, it means you should consider changing the flow of your app to a wizard. It's perfect for lengthy step-by-step operations, and divides user's attention into small, digestible chunks, instead of overwhelming them with one large page cluttered with options and input fields.

Answer 2

Here is a brief of the help strategy that we implemented, and it significantly improved the measured System Usability Score.

1. Help should be about the domain. If help veers into "how do I use the system" it is doing the wrong thing. This is just an indicator that there is a UX problem that needs to be fixed. Removed 30% of help and 50+ screenshots that were hard to maintain.
2. The domain has high level concepts - covered by a "Tell me more" link on the screen they are using. And specific domain "info" on fields relating more complex concepts. (While e.g. 'tell me about TSQL query language' may sound heavy handed, users actually love things spelled out at the moment they get stuck)
3. All processes are built into the UI. Not just dumb "Wizard" style step-by-step UI, but date, progress and status sensitive guidance.
4. One system had one high-level process that was critical, but very occasional. We didn't have resources to implement workflow in that app's legacy UI. Produced a physical guide to take them through the process. (Some times have to be pragmatic and just do the best within constraints)

Notes in this

• no assumption made that users are expert in domain. Made sure that guidance was on hand - even if referring to external websites.
• We didn't explain how features "worked" ('click here', etc). The right UI and an understanding of domain makes right action 'evident'
• Yes, we have survey data that a high proportion users skip training, introductions and don't read manuals like a book. The more systems with a strong UX users experience the more this will be an expectation.

Now with that strategy background, to your specific questions

• our "Big picture tutorial" was simplified from a 16 page booklet down to a 2 sides of a B5 card with 14 headline points. High-level, but complete enough - because the other UI and help was improved. We consistently reduced volume of help but improved it's access route and timeliness.

• if any constraints on functionality is explained in terms of the domain knowledge, then expressing what a specific system is, or is not, capable of should be succinct and clear for a user that understands the domain.

  It is much more complex if you ask the user to mentally map from 'System Functionality Description' (i.e. How the Screens, UI controls, sequence of activities are used) versus 'Domain Capabilities' (i.e. what the system is able to achieve in a given Problem Domain)

  By way of example compare 'You cannot select Option-Y and Option-Q simultaneously' to 'System does not support aggregation for external datasources"

Answer 3

Accepting the question as stated I came up with the following design for the three types of help

• Manual - not UI
• Inline UI specific help
• One tutorial

The manual stands on it's own and has chapters.

Inline the instructions just describe the the button like IncFam means Include Family. For when users enter syntax we also describe the syntax inline. We keep these close to the user control. Always use an expandar with a standard look.

We place links to the specific chapter both in the instructions and UI with just a simple ? link. Like a pull down with a certain type of data we don't need to instructions tell the use what a pull down is - the ? link just describes the data.

For the tutorial we also use ? links to the manual. And it is split screen with tutorial on the top and manual chapter on the bottom. The idea is to teach them to fish.