Recently, quite a bit of ink has been spilled in the blogosphere about UI Walkthroughs. I thought I’d do my part in trying to understand and come up with a better framework or list of heuristics to think about before deciding on whether or not to ship a walkthrough with a product:
I responded to this question on Quora, but I thought I’d include the post here because it might be helpful to more people deciding whether or not they want to include walkthroughs on their product interfaces.
John Gruber, who is a sophisticated internet user and blogger says that a “user should be able to figure out how an app works just by looking at it”: If You See a UI Walkthrough, They Blew It. To me, an overbroad statement like that is akin to saying “A user should be able to fly a plane just by looking at the controls”.. or even “A user should be able to drive a car just by looking at it”. We need to have realistic expectations of the interfaces that we use and be more precise about what we’re building if we’re ever going to evolve interaction design.
Products fall into multiple categories based on patterns of usage and intended audience.
Some products are daily/heavy use products which should optimize for the expert user. These products need to be designed such that, once the user has an understanding of how to navigate and understand the product’s functionality, they can perform regular actions with ease.
Examples: A Todo list, a weather app, or an app for sports scores and the news on a mobile phone. A POS (Point of Sale) system where the operator has some sufficient time for training [Keep in mind that POS systems are designed for fast transactions to keep lines short and moving smoothly].
Other products are used many times by different users, infrequently. These interfaces need to be designed such that they’re intuitive, require as little handholding as possible, and should offer 80% of the benefit for 20% of the effort. Additionally, that 20% of the effort should be possible by almost all of the people who enter into the experience.
Examples: a photo kiosk at the local drugstore, a fast food ordering counter with an iPad or self-checkout system at a grocery store.
What does this have to do with UI walkthroughs? Because the first class of products are not designed to be *intuitive* on first usage, they need scaffolds (extreme way of conveying this is a “crutch”) for the user to understand their operating protocol. Once the user understands how the system works, then they will be able to use the product quickly and effectively on a repeated basis.
Here are a few articles I’ve run across recently that reference the UI walkthrough debate if you’re interested in following along:
– And the corresponding discussion on HN: If you see a UI walkthrough, they blew it.
– Here’s a company, Kera, that’s focused on making UI walkthroughs weighing into the discussion: Five Principles for Effective UI Walkthroughs
There’s a few interesting discussions here: the author of the first article uses strong language, suggesting “UI walkthroughs are evil” (to be fair, a later blog update clarified that not all walkthroughs are bad). The article claims are that UI walkthroughs are confusing, presented at a time when a user lacks context or won’t remember everything about the walkthrough enough to learn its facets, and that walkthrough annoy otherwise impatient users.
Most of these issues can easily be assailed by good execution: A minimal walkthrough combined with progressive disclosure as the user experiences more and more of the app through their lifetime use is a great way for the user to learn more about the product over time.
I’ve put together a few simple diagrams that might help UXers and product builders decide whether or not they want a product walkthrough. And if you need some help building your 1UX or product walkthrough, feel free to ping us at LiziLabs.
Respond to me on Twitter: @AshBhoopathy or follow the discussion on HN.