There’s a really interesting conversation happening right now about UI walkthroughs in mobile applications that has caught the attention of the community at large. Max Rudberg kicked off the conversation arguing that walkthroughs are frustrating, ineffective, and an indicator of serious design flaws. The Hacker News comments are worth a read as well.
Rudberg effectively criticizes a specific way of implementing a walkthrough, but misses a more interesting conversation. I think it would be useful, though, to define exactly what a walkthrough is first.
At Kera, we define a UI Walkthrough as the process of intentionally revealing functionality to a user. This is a broad definition, but that is intentional. Because there are many ways to walk a user through a piece of software. Rudberg takes a stab at one approach - the “slideshow,” where an end-user is presented with a series of panes showing the application in various states before they get started.
A UI Walkthrough as the process of intentionally revealing functionality to a user.
But we believe that UI walkthroughs have the opportunity to be incredibly effective when designed with care. When a walkthrough is well-designed, it doesn’t feel like UI Walkthroughs at all - it becomes invisible, and part of the core user experience.
So far we’ve identified five principles of walkthrough design:
The spectrum runs from completely separated from the UX (slideshow, youtube video, document, etc) to completely integrated into the UX (hint, reveal, in-app message, etc). Our position is that UI walkthroughs should be as integrated as possible into the application.
The spectrum ranges from ever-present (help menu or a visual hint that never disappears) to just-in-time (revealing functionality only when needed). We believe that walkthroughs should be presented to a user at precisely the time they need it. Either by exposing them intelligently, or by allowing them to be searched.
The spectrum ranges from completely optional (would you like help now?) to completely mandatory (complete this walkthrough to unlock level 2). Studies from the video game industry show that mandatory walkthroughs are much more effective than their optional counterparts.
The spectrum ranges from revealing the location of buttons or sections (a “tour” for the lack of a better term), to exposing a specific workflow. When I sign up for a new service, I don’t want “this is where your settings button is” as much as I want “let’s update your profile photo.”
The spectrum ranges from completely synchronous (our friends at GoInstant have written a great piece about this), all the way to highly scalable asynchronous solutions like Kera. Our position is that synchronous solutions are fine while discovering the best way to onboard, which can then be replaced by a more scalable solution.
We think if you take the time to design a UI walkthrough that takes advantages of these principles, they’ll be more successful, and they won’t offend people who take design seriously.
Going back to the Rudberg article - I don’t think he has a problem with intentionally revealing functionality to the user. In fact he endorses a more sophisticated style of walkthrough (the hint). He simply (and correctly) critiques lazy walkthroughs that are tacked on as an afterthought, as opposed to becoming part of the core UX.
Ultimately, I’m happy he and others like him have brought this conversation into the forefront. Now it’s up to the rest of us to push it forward.
You can find me on twitter @maxcameron