This is utter nonsense. Spend even a small amount of time with someone who works outside of the computer hardware/software industry and observe how and why they use a smart phone or computer. UI walkthroughs are not only necessary, but desired. They act as the equivalent of standing next to someone and "showing" them how something works. As the OP correctly notes there is a very heavy reliance on mimicry for most learning.
Visual cues are nice, and even desired, but gentle introductions outlining how to get started are as well.
One of irks I have with "slight visual cues and subtle animations" is that they assume all users will give the same amount of attention and have the same reasoning process as the designer does. They then call the design "obvious", as if that is an objective quality---but even a short conversation (or usability study) with a sample of their users will tell them it's anything but.
Nothing wrong with being bold and trying new ideas but obvious is only really qualifiable via user testing. It's simple thing to do to see if your product is actually usable.
My method is to get 3 random craigslist people and pay them $50 bucks to play with the app for an hour. Record them struggling and have them talk through their thoughts and how they use your app. You will learn more from that experience than anything else.
The 'obvious' lock screen camera thing on the iPhone is a perfect example of something that I haven't seen anyone figure out on their own. It doesn't look or behave like anything else on the iPhone, including the only other interactive element in that same lock screen. Once you DO know, the cues are nice reminders.
The Pudding Monsters example is terrible too, as it precisely a UI walkthrough. Minimal, because well, the UI in that game is minimal, but it is explicitly telling you what to do and how to do it. (BTW the game is wonderful)
Some people skip through tutorials and rely on discoverability, others are lost without a tutorial no matter how discoverable your features are. Written introductions are comforting, You need to accommodate both learning styles.
With a recent project I watched a few totally inept testers discover all the features with no problems, but after launching it became clear that most of our power users were not discovering features. A quick bit of intro text and everybody is happy.
People learn things differently. Plenty of people skip tutorials and walkthroughs, but plenty of people also study those things like you wouldn't believe. There's no one right way to do this - you just have to try and cover your bases for each type of learning style.
Most applications don't need a complex UI and shouldn't make their UI more complex or difficult to understand than it needs to be (this, I feel is the OP's real gripe). Its rare that your UI need be so complex that a UI walkthrough should actually be necessary. Most users of most applications don't want to (and won't) go through a learning process, they just want to 'do'. That said, I agree with you that sometimes it is necessary/helpful.
I disagree. UI walkthroughs are like instruction manuals. Some people read them, but most just toss them aside and learn about the product by using it. I think there definitely needs to be some sort of help section within the app that the user can refer to when needed, but for the most part UI walkthroughs are just barriers of entry. I would even argue that most UI walkthroughs are pretty overwhelming for the average user.
it all boils down to this: When you open a newly bought iPhone then you want to see the device first after unboxing and not a bunch of how to guides.
your attention is seeking the device and not how-to-make-it-work.
This is wrong. How the hell did we learn "pinch to zoom" on the iPhone/iPad was a thing? We were shown!
Lots and lots of demos to re-enforce the action and get users accustom to a thing is fine if that experience doesn't frustrate the user and they can get up to speed using the app quickly.
If you are choosing neat new ways of communicating and changing the way the user interacts with the app for the sake of being neat, that is fail. If you violate the users expectations without a damn good reason, that is fail.
>>This is wrong. How the hell did we learn "pinch to zoom" on the iPhone/iPad was a thing? We were shown!
I'm not so sure about that. My grandmother, who certainly had not seen an iPad or iPhone in action before (she's 85, doesn't speak English and doesn't watch TV), figured it out within one minute of using my iPad for the first time yesterday.
If you think about the pinching movement, the distance between your thumb and index finger correlates to the size of the object. Increase that distance and the object grows in size (i.e. you zoom in). And vice versa. This is what I'd like to call "hyper-intuitive" and is the kind of thing people can figure out without being trained on it.
To continue using the iPhone as an example, I realized that after two years, my Dad never realized that double clicking brings up the app switcher. I agree that it is better if you don't need a walkthrough, but I wouldn't say that you "blew it" if your app needs one. If a 30 second tutorial let's the user do very powerful and intuitive things, things that may save the user time over the long run, than maybe it is okay.
Not really. The app switcher is not the only way to switch apps. In fact, it is the more difficult of the two. It makes you click the home button twice, then tap the app you want once - versus click the home button once, and then the app you want once. Three clicks/taps versus two. As such, it is not a huge deal at all that it is not intuitive.
Same thing with double-tap to zoom. Not terribly intuitive, but that's not a big deal because there's a "hyper-intuitive" way to zoom. Double-tap becomes necessary only in very specific situations where only the hand holding the phone is free - which is not very common.
Anecdotal evidence: My father once saw me open the app switcher to force quit an app that was behaving badly. He thought it was easier, so he now checks it every single time he wants to switch an app. If it's not on the first row, he goes to the home screen and searches for it, which can take him up to a few minutes. He doesn't organise his apps in any way, and isn't interested in starting, even though he knows how to move them around.
He just likes the app switcher better.
But he never would have discovered it if not for him coincidentally paying attention when I pulled it up once.
Number of steps is not necessarily and indication of the speed and ease of the action. Steps != a good metric to judge a UI by. Would you really say that a double click is equivalent in cost two a single click then finding the app icon and clicking on it?
What a load of broad sweeping nonsense. UI walkthroughs are perfectly valid for many apps. A lot of interesting software these days (read: disruptive) is introducing new concepts for accomplishing old tasks. Walkthroughs accomplish a lot more than just making up for bad design.
There's a lot of posts here against this article. If you do metrics on tutorials, tons of people skip. Even if you don't allow skip, a lot of people are just going to plow through ignoring a lot. Heck, lots of people leave the app entirely and never come back. I've seen this in my own games.
Tutorials just aren't very fun. That's why games so often have to sort of build the tutorial into the gameplay somehow, make it more piecemeal and interactive. Which is what the article is getting at. So you can think of it more as "don't make crappy boring tutorials" like popups and step by step screenshots.
User studies with web sites have show users search pages/sites just enough to find something that sounds vaguely like their current goal. They don't analyze the entire thing and read every link and then make a decision. Showing a bunch of images and a next button is sort of forcing them to do that, but it won't stick and they won't like it.
Overly confident, generalizing headlines are pretty good for capturing attention. But it does poorly at making your point.
Your reader's mindset is contentious from the get-go, and they're going to want to prove you wrong if statement is controversial. It doesn't bode well for your point if you can't convincingly back it up.
The true point in this article is that visual cues within UIs are great and nice. It's a huge victory when you can educate your user naturally (see: the popular Super Mario Bros example), but it just doesn't apply to everything. Not everything is innate; some new things need to be taught. How do we learn most things? We observe someone doing the same thing.
"Just tapping on the camera icon makes the screen jump, briefly revealing the camera UI behind the lock screen. This combined with the ridges above and below the camera tells the user to slide the lock screen up."
So THAT's how you use the camera when the screen is locked! I couldn't figure out why the screen would just bounce so I always ended up unlocking the phone to get to the camera.
Extravagant headline. UI cues are the same thing as a walkthrough. They're a channel for the designer to tell the user how to interact with something--a communicative affordance. The only difference is that they're not listed as bullet points.
We have to learn how to ride a bike and type on a computer. The user doesn't know how to do everything, nor do they have the intuitive reasoning to pick up and use something completely new and alien. While we should make them feel smart, there's room to teach them and make them feel enlightened with this new system. Contextually, a UI walkthrough may or may not be a good idea.
Despite typically cavalier attitudes toward driving in this country, cars are expert systems, not unlike piloting aircraft, or using a sewing machine.
There is substantial training, even licensing surrounding cars. We put up with the steep learning curve because of the tremendous and inescapable requirement of cars in many places.
So. Is your app so important that your user will put up with a steep learning curve and reading documentation before they can use it?
The appropriateness of UI walkthroughs hinge on this point. Steep learning curves and a need for training is inescapable in many situations - it's also almost always unnecessary for consumer applications.
Just like how no one would buy a toaster that required training/documentation.
Car's share 90% of their UI (apart from that damn Fiat hire car that invented a new way to get to put itself into reverse).
The reason why UX has to be so much more discoverable on apps, websites etc. is that there is a hell of a lot more of them and they often are created by clever fucks that decide to do things in novel ways.
I mean the core UI for all cars serves the same purpose: to make the car move. The functionality of the car (lame dash apps notwithstanding) is also confined to a very simple use case.
App functionality and theoretical purpose is by contrast infinite. Therefore it's easier to pass judgement on car designers when they do crazy inscrutable interfaces because it's generally a solved problem, whereas with apps there are many more valid reasons to try something new.
You're right - people get confused between a UI's learnability vs it's usability. Just because you need to ramp up on something initially doesn't mean it's hard to use over time.
Plus a new feature can get lost or ignored by people already familiar with an existing interface, so it needs it's own little mini walkthrough just so it'll get noticed. Here's an example of Facebook's mini popups focused on a single new feature:
I've built wizards of various kinds over the years and I call them "training wheels". The trick is to make it so they can start pedaling on their own relatively quickly, rather than using it as a catch-all where you dump every possible use case.
I can see lots of other people disagree with the OP, I thought I'd chime in too:
Self-evident interfaces (i.e. lots of affordances, very little tutorial needed to get started) can be good for people who just want to pick up an app and understand it.
BUT, there are also people who want to interact with something in the fastest, most efficient way possible. If a novel new UI can shave even milliseconds off of common repeated tasks, a 60 second tutorial is definitely worth it.
The problem is not that some apps use their own UI paradigm to achieve a minimal UI. The problem is the kind of apps that do so.
If an alarm clock (second example in the OP) requires me to remember weird gestures something is wrong. An alarm clock does not lack visual screen space and the main purpose of the alarm clock is to set the time and then close it. It doesn't have to look good or save space to show something else.
For a browser or a book reader it's different, there i want to fill the whole screen with content as reading is the main purpose of using that app. If i have to tripple sweep, double tap or whatever to get to the menu i don't care.
The authors website has a rather unusual button [ Gui work | blog ]. I thought Gui was selected, but it's actually blog. If I would've used an iphone I would've seen things differently. The point is that some things are intuitive only if you're familiar with the system in the first place.
Technically the thing in the video isn't a walkthrough as much as it is a demo, but in either case they didn't use it as a substitute for proper affordance in the final product design.
Like a matryoshka doll, it's best to educate your user at every level of interaction, whether explicitly (FAQs, copy, instructions, walkthroughs, etc.) or implicitly (affordance, appropriate skeuomorphism, etc.).
Apple is generally good at both. For example, when you ask for help, an app will both show and tell. Most apps are just "tell," instructing you where to go and what to click.
Good article, though I think you should differentiate between types of 'walkthroughs.' I think the point is that you want the users to start using the application as quickly as possible without being hindered by a walkthrough. On the other hand it is important to teach users to use your application... and constraining yourself to commonly used functionality is dangerous. I find that it works very well to 'show' users by helping them do tasks right away (a walkthrough) instead of 'telling' them how to use the application and then leaving them to remember it (also a walkthrough).
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.
They make things seem more complicated than they are.
They're often skipped.
Folks think the screenshots are the app and try to interact with them (seriously!)
So basically, they're not a dependable way to teach stuff. On the other hand, they can definitely be helpful for quickly laying out an app's value proposition and, in some cases, can provide an important layer of instruction.
Apps like Clear purposely sacrifice discoverability for minimalism and fun. In some cases, progressive disclosure and visual cues might change the nature of the app and a walkthrough may be helpful. But Phill Ryu himself admitted that the walkthrough was a band-aid and I think we would all do well to think about how we can do better in the future.
The point is, I think there is a ton of room for innovation in the space of teaching UIs but we should keep all the chips on the table. Experiment, do user testing, but don't categorically exclude options from the table.
I haven't read this article but I find the title highly objectionable. There is a recent distressing trend in UI design that providing the user with options always makes the UI harder to use. This means taking control away from users and giving it to best case devs who may not have thought of everything worst case suits with corporate agendas etc. Computers are supposed to make peoples lives easier not pidgeon-hole them into cookie-cutter lives. Sure the ideal UI doesn't require instructions but UI design is hard and I'm tired of seeing shortcuts. If you need instructions once in a while that's fine. People take college courses in how to use excel. They can read a five paragraph description of your UI. And if it tells them about features that they were hoping to see that you didn't omit to dumb down your UI for them then they might even like it better.
Hmm…not really sure how I feel about this article.
It's using existing gestures and having them carry out different functions that is unique to the app.
It's like keyboard shortcuts - every program's usage will be different minus a few key ones. Or video games, some buttons do what you expect but some will depend on what the game's design is. Of course there will be some tour or tutorial - how else are we supposed to learn about them?
Double tapping the Home Button on iPhone < How did we learn about this? Double tap? There's no visual queue on the hardware that we can double tap. Did Apple fail?
I kinda get what the author is trying to say but he also kind of miss the point of walkthroughs and tour completely.
I respectfully disagree. Nothing wrong with a simple design that deviates from the "standard" behavior. Most UI metaphors including the standards require some learning. Even the desktop icons need explanation to the users initially. Most users are ok with training if the UI is simple enough to pick up.
We're literally betting our business on Max being wrong here (www.kera.io). We believe the opposite, that the best way to learn something is to sit down and have someone show you. Perhaps in the narrowly defined 'mobile app' space where your app does 1 single thing (ie: take pictures) you can have obvious design but check out something like Siebel (http://www.selectorweb.com/images/siebel1.gif) or any sufficiently complex software and you realize there are huge opportunities for UI walkthroughs.
Part of the issue is we are dealing with such a wide audience that this opinion is valid for some and not for others.
With an app like Clear, I have 0 trouble using it and love the minimalist approach and simple interactions. I have no trouble using the app or remembering which gestures do what. Some older than me, and likely most all younger than me would feel the same way (if they use or were to use the app).
When you are analyzing it, it is easy to point out things wrong with it, but when you use it, it just feels so right.
Depends heavily on what you're letting people do, and how long they're going to spend doing it. Games tend to have smaller numbers of "verbs", and longer engagement times - for a superb example of progressive teaching, play through the Portal developer explanation (available after you finish the game).
It's much, much harder to do this with an application where you can't boil the functionality down to a small set of verbs - line of business apps are the usual terrible example of this.
"Mystery Meat Navigation" is a very good description of what makes Windows 8 a frustrating first time experience, is the synopsis of all the complaints about it, and is why Windows 8 is going to be a slow sell for the first 6-12 months.
After 3-5 hours, Windows 8 is surprisingly decent, but the first hour is a super frustrating adventure of swiping and gesturing with the hope you can get back to the home screen.
They might've invented a superior interface paradigm that doesn't fit into an existing model. While it could be discovered by poking and taping, it might be faster and less frustrating to have it explained explicitly.
If you need to teach people how to use your product you failed at UX. And the time spend on walkthroughs and quick tips would have been better spend on rethinking the whole interaction model.
That being said, it doesn't mean your product is going to fail just because your UI sucks! Sometimes the problem a product is solving is so big that users don't care how clunky it is to use...great examples: Banking, Cars and most Email clients for example.
The article's right, and in fact, I thought it was common sense. Like, interface design 101. In the end, a graphical interface is just an intuitive way to use the application's functions. If using the interface is enough of a task that you need a tutorial to use that, it kind of defeats the point of intuitive access. Just let me use your application and get the interface out of the way.
Then I came to the comments and everyone was complaining. I didn't know people liked hand-holding so much.
Games that were clearly 'blown' by this standard:
Angry Birds (1, 2, 3, 2000, space, Christmas, festivus, Halloween, whatever else they make...)
I never realized how many apps on my iPhone was such shit :(. FML.