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 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.
Join 24,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
I’m a tech writer & editor, working on both online help and (gasp! still!) written documentation.
Very interesting comparison – thanks a lot!
Glad you liked it.
Take a look at how we have solved the problem of help in our Content Management system – http://mini.squiz.net/features/help
We have added a help button that lists all of the articles for the screen that you are viewing. If you are not sure what a field does or a new field has been added in an upgrade, you can use the picker tool within help. You click the picker icon, click the element on the screen and a description of the field along with all of the articles it is used in appears in help. You can watch the video (see link above) to see this feature in action.
Great idea for connecting the help text with the actual interface. If we ever do a follow-up post on inline help I will consider it as an example.
The simple and non-technical way to achieve some of the same effect is of course to add help text in the image title tag on all icon and images in the UI of the application.
The picker tool seems like a very neat feature. How do you achieve this effect? What authoring tool are you using to create this kind of help?
Thanks for this!
We’re currently designing a complicated medical system and we need to add inline help so that the users find the product easier to work with and more intuitive. These are excellent examples.
Glad you can use it.
Would love to see your end-result. E-mail me at firstname.lastname@example.org if you want to.
Can you weigh in on the use of the question mark icon or i icon? I am still trying to figure out the consistent uses of these- as they aren’t implemented so across many platforms- but the i icon as I see it can be a good way to give quick help and keep the interface cleaner.
In my instance, this application has a defined user group, and they are advanced, but this would be a new element. Once they are use to it, then they should be able to ignore the i, but anyone new(er) to the interface would have access to it.
We have tried links in places, but they create quite a bit of visual noise.
Would love to have some additional insight.
One of the best written article on embedded help…
© 2021 Baymard Institute US: +1 (315) 216-7151 EU: +45 3696 9567 email@example.com