Help text: either it’s there when you don’t need it, or you can’t find it when you do need it. Let’s take a look at 3 different ways Google, Amazon and 37signals solve this problem.
A big inline dialog with an arrow pointing right at the feature. Google uses this in a lot of their products when introducing new features and it provides an amazingly clear context for the description.
The dialog is obtrusive and requires you to take one of three actions: “Close”, “Remind me later” or “Learn more”. The last option is interesting – by having a “Learn more” link in this dialog, Google can keep the description brief and explain it in further detail to those interested.
Obviously this is not suited for general help that you always want to show the user, but if you’re introducing a new feature and want to promote it and help your existing user get started, this approach is a good candidate.
A link, posing a simple question: “What’s this?”
This link is typically placed next to the header of a feature, and clicking it will open up a help text that explains the section or feature.
Because a link is small and unobtrusive, existing customers who already know about the feature won’t be distracted, yet anyone curious to learn more can go straight to the relevant help page. And because the help is in a separate area, you can write a more in-depth description if needed.
Brief help text permanently embedded in the interface. Writing full sentences explaining a feature or the outcome of actions your user is about to take can be a powerful concept. It will help new users understand things better and reassure existing users in what they’re about to do.
Surprisingly many websites and web applications nowadays have extremely short labels with no explanations next to their form fields. Unless you intrinsically understand the feature, you’re lost. With embedded instructions you replace the “Name” label of your form with “Name the project”, and perhaps you even add an example or two as well (see above screenshot). This guides the user through the screen.
This is of course a UX writing balancing act. When dealing with simple screens and features that are used frequently (e.g. adding a to-do item to a task manager), embedded help may be overkill. However, for screens that aren’t used frequently and features that aren’t necessarily intuitive, embedded help can be a great choice.
Think about the scenario your users are in: what’s the best way for them to learn the feature? Is it important for them to know about the feature before using it or can they safely play around without destroying anything? Is it okay to distract users a little bit in this screen or should you get out of their way?
If you have any ideas or other examples, then post a comment.
Authored by Christian Holst on September 24, 2010
Join 30,000+ UX professionals and get a new UX article every second week.