Software should be so well designed that it needs no explanation! If it’s well made then you don’t have to explain it! These are the goals of a software designer, but they are often unrealistic ones. With a wide array of poeple using something comes a wide set of needs. Inevitably you will need to provide some sort of education or help.
Providing help and documentation is one of the The Neilson Norman Group’s 10 usability heuristics.
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
I wanted to explore some patterns for how help and educational material are delivered to people. The delivery is interesting because it’s a bit of a balancing act. You never want to see it, but you always want it to be there when you need it. The Neilson Norman group puts it this way: Good help should be “available without interfereing, succinct yet descriptive, and unintrusive.”
All these examples fall somewhere along a spectrum of being system-initiated to user-initiated. Ideally, the system can infer when to provide help based on it’s understanding of the user. Although this is the ideal, you will inevitably find yourself where you have to provide feedback non-conditionally.
🚚 Delivering help
These are quick prototypes used to illustrate common patterns. They are displayed in the context of a mobile web form, but a lot of these patterns can be applied in a variety of contexts.
System Initiated: Inline
User-Initiated: On Select
Conditional: On Error
Mixed: Expandable Overlay