Unnecessary Explanations is Khoi Vinh’s critique of the methods and materials used to explain user interfaces. An attractive proposition, he notes, because it’s easier to explain away the interface deficiencies rather than fix them. He highlights a lot of bad examples and ends with a very pointed observation:
If it needs to be explained, then it’s probably broken.
We have started to explore this issue with Potluck. We know how to use the application, obviously, but there have been a few cases when the person using the application wasn’t sure what to do next. It wasn’t the elements with which they were supposed to interact that was the problem. The input, buttons, links, etc. were all fine. It was when they landed on a page after completing an action and weren’t sure what to do next. (This was in the beginning steps of using the app by the way.)
Armed with this data we began to look at different ways of guiding the user through the first stages of the application. I kept a few points in mind as I explored solutions.
- What are our technological capabilities?
- Am I bringing any unnecessary real-world metaphors to the problem that obscure more than help? (i.e. let’s put all our help tips on post-it note graphics)
- What about the current design necessitates an extra help piece? Or, why can’t the user figure this out on their own?
- Am I handicapping the learning experience by preventing exploring or experimenting?
Fast-forward the thinking process and we come to the two ideas that anchor the first solution we are going to try.
Create helpful leads for initial tasks that match the interface and therefore feel like part of the app. They will be written in the same style as the rest of the copy on the site, but more verbose.
The help tips will be in place of what is normally there in the application. When the task related to the help tip is completed the help text disappears. The idea is that once they have completed the task they now have internalized the knowledge needed to do it and therefore the tip is now clutter in the interface so it is removed.
For initial users this will work great: the help text explains how to accomplish an action and once the action has been accomplished the published result now sits in the place where the help text was previously. But what about when the application is well-established within an organization and someone needs help? And what if a user wants to see the help tip again? I’m still thinking through this one, but in a follow-up post to the original article Khoi highlights a great method to make help text work:
[I]nstructions are most useful when the user is directly engaged with the interface or asking for help.
With that in mind I think we are going to implement some sort of help mode that you can enable in the app. When that mode is “on” the help tips will reappear (similar to how they were before) as will any additional interface items that serve to explain the application’s use.
How that will appear and function is yet to be determined. Our main focus will continue to be on creating the app in a way that ensures the least-used feature is the help mode.