10: Mobile
The author muses about the history of the phone - specifically, until the modern smartphone, there wasn't much point: they had primitive capabilities and delivering a usable, or even remotely useful, service to a sufficient number of users was nearly impossible.
The present-day smartphone, modeled on Apple's iPhone, is actually a usable device though still quite primitive and limited in its capabilities. And given the popularity of that model, and that other models attempt to mimic its functionality, it is now worthwhile to consider the mobile audience.
The Mobile Difference
Insofar as designing for mobile is concerned, Krug suggests the differences are "not much." The basic principles are the same, but the device is different.
Mobile capabilities, however, are significantly different: you simply can't do as much with a mobile device and have to design to some rather severe constraints to be usable on the small screen. The viewing area is very small, the capabilities limited, and interaction with fingers on a screen is rather clumsy.
He mentions the "mobile first" fad, which was proposed by smartphone enthusiasts (and companies that developed applications for the platform). The one good thing to come out of that fad was a focus on simplicity and singularity of purpose. But unfortunately, designing for the phone and porting it to the web is as ill advised as designing for the web and porting it to the phone. They are two different things, and each should be designed for its own strengths and weaknesses.
Another bad assumption was that the mobile device was something that would be used while sitting on the couch at home and want to do everything that is possible in the online channel. Actual user behavior suggests otherwise: people want to do some things on mobile, but not everything.
The Problem of Scalable Design
Programmers and developers are notoriously lazy, or "efficient" in their own language, and relished the idea of a solution that would be coded once and could run anywhere, pushing the need to adapt to the small screen to the front-end designers.
This gave rise to the notion of scalable design - which has been rebranded as dynamic layout, fluid design, adaptive design, responsive design, and likely a few other names as they try to make a bad idea stick. The main problem is that web and mobile are different, and simply changing the size and layout of elements does not make what "works" on one device useful on the other.
It's still getting sorted out, and the argument is far from over. If you're in the position to have to cram a website onto a phone or stretch a phone onto a website, the least you can do is ...
- Don't prevent zooming. The web browser on a phone is designed to zoom in because it's well known web site type is too small to be read on the small screen. It's a built-in function; so just don't interfere with it.
- Consider email links. Site operators attempt to get smart by switching mobile devices automatically to a mobile version of their site - but this breaks links because the things that are available on the regular web site are in different places (or not at all) on mobile. It's something to consider before sending promotional emails assuming they will be received on a desktop computer.
- Link to the full site. No matter how bad your website performs on mobile, some users will not be satisfied with your mobile offering and are willing to suffer the inconvenience of the full site. The current convention is to place a toggle at the bottom of every page.
Hidden Affordances
The author suggests that "affordances" are visual clues in a design that suggest how something can be used. (EN: The word is mangled a lot - others would call visual cues "signifiers" and state that an affordance doesn't always have a signifier. But what the author is basically getting at is that the things that communicate that something can be touched or interacted with is often invisible on mobile.)
In many ways, its' going back to 1994-style web design, with designs that look like device interfaces and have no character of their own: buttons, text boxes, radio buttons, checkboxes, and the like look like those that appear in the system settings screens.
You also have to recall that a mobile device doesn't have a mouse, or a cursor. So unlike the web, users can't see where their "pointer" is - they just use their finger to touch things. And most users don't drag their finger around the screen, but tap. This means things like displaying something or changing its color when the cursor hovers over it simply do not work in mobile. Every interaction is a click.
Slow Responsiveness
The connection speed on mobile is not quite as horrible as using a modem, though sometimes it can be. Depending on the quality of the user's connection to the mobile network, it can be awful at times.
Fro this reason, mobile design must be trimmed down: large photos and multimedia elements may take a while to load, and the page must make sense without them.
Given the choice between having a visually impressive site and one that works fast but is stripped down, go for the latter. People are too spoiled by high-bandwidth connections on their home and office computers to tolerate a service that they have to wait to load.
Flat Design
Another fad in the mobile design world is "flat" design - making everything look two-dimensional by avoiding all shadows, bevels, and gradients. It was very much in fashion for a little while.
While 2D designs are more clean and readable, it provides little affordance. There is no way to identify at a glance whether text on a color box is a button or a heading or just being highlighted.
If you jump on the "flat" bandwagon, then you should consider that you are losing the ability to indicate interactivity by standard conventions, and will need to be far more attentive to creating a distinctive look for interactive elements and teaching the user the design conventions of your mobile site.
Usability Attributes of Mobile
Krug's definition of usability can be applied to mobile without any changes:
A person of average ability and experience can figure out how to use the thing (learnable) to accomplish something (effective) without being more trouble than it's worth (efficient).
(EN: I'm not sure if it's a change, but I would suggest one additional concern for mobile ... the addition of "in the environments in which it will normally be used" because this is often ignored. Mobile apps are tested in usability labs, a quiet and still environment, rather than being tested by a person walking around in a noisy environment in which they are doing other things at the same time. Hence I think a lot of mobile efforts get a green light when they really do need serious reconsideration given the way in which they will really be used.)
The Need to be Delightful
Mobile technology does suffer from the desire to be cool, nifty, and delightful. Because it is a gadget and a novelty, it's imagined that it is a "fun" device rather than a practical one, and that applications have to compete to be visually impressive and fun to use.
Krug does not deny the competitiveness of the market for mobile applications and users' fascination with "cool" - and it's even conceivable that users will be more playful and experimental with mobile applications than they are with the web interfaces that do the same tasks.
But consider the "fun" factor to be an extra-credit assignment. If it gets in the way of being learnable, effective, and efficient, the gimmicks and eye candy will not save the app, and may harm it.
(EN: What's being recognized is that mobile users split their time between work and play. They like games and cool apps that don't really do anything useful - but there are other apps that they expect to enable them to do something quickly and efficiently and are exasperated when they cannot do what they want. Take the common example of checking your bank balance while walking to the checkout - they need to get in, get the information, and get back within thirty seconds, and their attention will be split between their device and their environment, let they crash into someone while walking. This is not "fun" time, and "cool" means usable rather than gimmicky.)
The Need to be Learnable
Because real estate is limited on mobile devices, applications that provide a lot of features and functions often need to cram a lot of things into the small space and come up with various ways to activate features.
There isn't space for a button for everything, and some features have to be a few clicks or swipes away from the launch screen. And to make matters worse, there isn't space to give instructions to the user as to how to interact with the screen.
The author mentions testing one mobile application that led a participant to say "It feels like I'm playing a pinball machine." But in a good way, as if to express pleasure in the strange array of taps, drags, and other gestures he needed to use to access the various functions.
The author mentions an application that, the first time it is launched, puts the user through a ten-screen slideshow that demonstrates the ways to access the various features. He remarks that they "have actually done a very good job with training," but then observes that usability testing "hasn't fared so well" and in fact "no one has succeeded" in doing the task for which the application was designed.
People who are interested in getting something done don't give much attention to tutorials. Even when they seem to pay attention, they don't remember what they need to do when the time comes.
Instructions and pop-ups that coach the user are a hack. The better approach is to enable the user to learn as he goes - but the appearance of the elements on the screen, the user has a sense of what to do each step of the way.
(EN: Once exception I have noticed is the "power user" who is going to be using an application frequently. They are very interested in learning the tips and shortcuts for doing things more efficiently. But that's a little bit different to accessing the core functions at all. The primary way of doing things should be learnable, but shortcuts that provide an alternative faster way can be provided.)
The Need to be Memorable
One attribute Krug feels is important is the need to be memorable - specifically, in that a person who uses it one time can rely on his memory of how it worked to sue it a second time.
He notes that he doesn't often mention this because if an application can be figured out the first time, it will be just as easy to figure out the second time. But he's had personal experiences with applications that he forgot how to use - creating a new document, accessing the controls, and other functions were a mystery to him the second time, even though he had figured it out before.
(EN: This is another issue with applications that need to be explained - typically, an instruction screen and call-outs appear the first time the user interacts with it, but never again. The developers assumed it would be something they remembered, and perhaps assumed they would use the application often enough that it would become ingrained in memory - but many apps are used infrequently with long gaps in between sessions.)
He asserts that memory is a major factor in whether people will adopt an application for regular use. There is the novelty factor the first time an app is used, but when the novelty wears off, it has to be useful for something as well as being usable in order to be adopted.
Usability Testing on Mobile Devices
Usability testing involves making up tasks for people to do and watching them try to do them using a method you designed. That remains entirely true for usability testing on mobile devices, but there is a difference in logistics.
Testing websites involves bringing people into a laboratory environment that largely matches the environment in which they will be using the website: it is a quiet space like an office (or home office) in which there is a computer that is equipped with the typical browser application and supporting plug-ins and helper applications.
These labs are ill-equipped for mobile testing. The device may not be the same as the one that the participant normally uses and the participant is seated at a table, and prompted not to move the device out of a certain area (because it is being recorded by a camera).
That is nothing like the way a mobile device is used in the real world. In reality, people use different devices (with significant differences), are in a multitude of environments that are often noisy and full of distractions, are using the device while doing something else, are often standing and holding the device in one hand, and other significant differences.
As such, bringing a mobile device into such a test is to run a bad test, as the situation is atypical and the results are almost wholly invalid given that it fails to model the actual behavior of the user in the wild.
These factors make it difficult to do usability testing in a traditional lab, and researchers haven't quite figured out a good way to do a valid mobile test.
Some Recommendations
Krug offers a smattering of advice ...
First, you should not rely on screen mirroring. Because there is not a cursor to show what the user is doing, mirroring the screen provides little useful information. You have to point a camera at the screen so you can see the user's hand as well, to know what he is doing. Mirroring also requires there to be a cord attached to the phone, tethering the user to a recording device (generally another computer), which is unnatural.
Allow the user to hold the device naturally. That is to say that if they want to use it standing up and holding it in one hand, making them sit in a chair and hold it with both hands so the camera can see it is causing them to behave in abnormal ways. His suggestion is to attach a camera to the device.
He alter promotes his own design of a "Brundleyfly" camera, which clips to the top and back of a mobile device, much like a book-light can be clipped onto a book. IT turns into a bit of an in-book commercial as he discusses the way in which it overcomes common problems (with larger cameras) and brags about its ease of use. I'd drop this entirely, but it does serve to explain why he has no other suggestions for ways to record mobile sessions.
(EN: another idea - place a camera on the user's head to record this. That seems unwieldy, but Google glass makes it less so and there are smaller cameras that might work. The drawback is that if the user isn't looking at the device, you won't see what he is doing - but my sense is that it is rare a person is doing something blindly, and is usually looking at the screen while interacting with the device - though there may be intermittent attention as the user glances up from the device to make sure he's not going to bump into something, he generally ceases activity with the device until he looks back at it.)
Krug suggests that you shouldn't "bother with" a camera pointed at the participant because you can get all the important information from what is happening on the screen. He does conceded that some observers "like" seeing the participant's face, but he thinks that is unnecessary and not worth the complexity of adding a second camera to the mix.
(EN: Here, I disagree, and sense that Krug is not very adept at reading nonverbal communication. A person's expression and posture tell me a lot about how they feel, particularly during a pause, and this is critical information to doing design well. Granted, it is not germane to the yes/no question of "could they use it" but if that is all you care about then why observe a test at all - just get the results. It is important, and should not be dispensed with.)