In my post yesterday about instructional screens, those meta-states that apps sometimes use to literally explain how their functionality works, I said that if an interface has to be explained, then it’s probably broken.
Of course, there are no absolutes in interface design, so a declaration like that should be taken with a grain of salt. The concept of coach marks can work, and quite well, but usually not in the static, superficial manner of the examples I cited in that post.
Interface Plus Time
Usually what makes instructional text work is some sophisticated acknowledgment of context; instructions are most useful when the user is directly engaged with the interface or asking for help. Animation, particularly, can make them more valuable, so long as the animation is quick and to the point.
Here’s another way of tackling instructional text that I found recently and that I thought was quite clever: to introduce some recently released features, MeetUp uses a single notation at a time, placed directly on top of its interface.
The text is very short and just as importantly it comports with my assertion that you can really only get users to read or focus on one thing at a time by offering just one point at a time. Any more than that, and the user is liable to skip reading everything altogether.
The designers are having their cake and eating it too by including a very simple navigation (previous, next) within the notation bubbles, letting users advance to more text if they feel so compelled.
This is a clever method of breaking down into bite-sized bits what could easily have been a much more cluttered — and much more easily ignored — instructional screen. But what’s really great about this approach is that the navigation has a certain irresistibility to it. Having viewed the first notation, and having seen how painless it was to consume, how could you not want to click on the second one? And then the third?
Even better, there are only three of these notations. Just three. So not only is each one mercifully brief, but the whole course of them is wonderfully judicious. It’s not only that the designers here have found a sly way of getting users to consume lots of instructional text, but they’ve also developed an interface where not a lot of instructional text is needed. If you start with a good design, you don’t need to do a lot of explaining.
An ancestor of this feature is the common “tips dialog” that appears at the launch of many desktop applications, informing the user of features both simple and advanced. Such tips dialogs often have previous and next buttons too; the main innovation here is treating the tips dialog as a call-out that points to the feature in question, as well as integrating itself into the workflow so that the call-out addresses the single feature that is most likely to require attention from the user.
Thank you! Your remarks have been sent to Khoi.