Several years ago, I started seeing troubling pieces come out suggesting that we Move Beyond Jakob Nielsen (I’m paraphrasing here). The implication: that we’d allowed designing for usability to create a failure of imagination. We’d impoverished web design and mobile in the service of a geeky goal we could now forget about now because, after all, this is the future, and we have phones, and hey, <APPLE!>, right? You know?!??
A couple choice rants that single Jakob Nielsen out for particular scorn are: Windows 8: Why Jakob Nielsen Gets It Mostly Wrong, (DC: I’m stifling a laugh here), and Tim Richards’: Putting Jakob Back On The Shelf (p. 37) from Razorfish’s FEED 08.
The general thrust of these and other articles is: ‘Hey, a serious focus on usability inhibits us from designing and charging for…well…whatever the hell we want to!‘
And in the years since, that’s just what people have done. In an ever more multi-platform world, we’re now struggling not just with different conventions for interaction on different platforms, but with varying interaction patterns – I’d say variously-broken patterns – on any given device.
Even Apple’s MacOS, once a bastion of “It Just Works” clarity and ease, has shown staggering drift away from the usability design principles that once made Apple the most highly-valued company in the world. Drift, in the service of inadvisadly making its PC operating system look and act like its cash-cow smartphone operating system. (For anyone confused about this: A PC doesn’t work well with the conventions of a phone, just as a phone doesn’t work well with the conventions of a PC. Doesn’t take an expert to realize this).
Forgetting Baseline Usability
You’d think that any practicing UX designer would’ve known how to provide baseline usability since UX 101, but, to quote Jason Isbell, “In case you don’t, or maybe you forgot, I’ll lay it out real nice and slow”:
- Show no insert cursor, or a single insert cursor on a screen. That cursor should be in the field that is in focus for accepting typed input, if any field is. Show no insert cursor if no field will accept typed input.
- Don’t show two or more cursors.
- Don’t show an insert cursor in a field that will not accept input.
- Don’t show an insert cursor in a field that will accept input “in a second”. If the field is not ready for input, do not show an insert cursor in it.
- Treat “focus” indication for non-text gadgets (drop-downs, checkboxes, radio buttons, etc.) in the same way as cursors: show only the one in focus on the page.
- Respond to a tap or a click instantly (in less than 20ms, let’s say). Show some feedback instantly that the user has tapped or clicked, so that the user may know the tap or click has been received.
- Lock out multiple taps or clicks, unless multiple taps or clicks are an intended interaction pattern for this case. Don’t allow the user to tap-tap-tap-tap on your gadget that didn’t respond quickly and accidentally perform an action like opening a document 4 times.
- Double-click on a selectable word should select it. Double-tap on a word in an editable field should do so on mobile (though double-tap is reused on mobile sometimes to zoom. Doing anything sometimes is a minefield. Who thought that was a good idea?).
- Don’t grab the arrow keys in text fields on Mac. On Mac OS, pressing the up arrow in a single-line text field places the cursor at the beginning of the line. Pressing the down arrow in a single-line text field places the cursor at the end of the line. Grabbing the arrow keys and replacing their function (with, for example, scrolling through suggested search terms or alternate search engines) confounds the user’s ability to edit a field without leaving the keyboard.
- A button needs to look clickable/tappable.
- Things that are not clickable/tappable should not look like buttons.
- All the important parts of the UI (and honestly, why do you build unimportant parts?) should be visible, and it should be obvious how to work them.
- Gestures…*sigh*…too much bad here for a single blog post. The tl;dr: gestures are invisible. People can’t know they’re there. They’ll only discover and use the obvious ones. Don’t hide important functionality in invisible gestures.
- Don’t disable zoom on your mobile site. Seriously. Especially you, Flickr: it’s a photo. Do you REALLY think I don’t want to zoom?
- Don’t LIE to the user: that dumb spinning GIF doesn’t indicate that anything’s “still working…” anyplace, except the GIF animation library. Show real feedback if you have it, but don’t show fake feedback.
That’s just a short sample of the thousands of usability rules and heuristics we’ve turned away from in the last few years, in the up-in-blinking-lights name of “Innovation!”
Finally, one rule to rule them all:
- Don’t innovate the UI. I’m serious. The system already has a UI that everyone who uses the phone, tablet, PC – whatever – already knows how to use. When you innovate UI, you’re already wrong. You’ve introduced functionality that people don’t know how to use, and may not ever be able to discover. You make people learn to use their own device all over again, increasing cognitive load, and incenting the user to choose something easier to use.
What would be innovative today? Interfaces so normal that they are a cinch to use. That use the system UI – along with excellent information design and IA – to deliver what the user wants, with zero learning-curve.
UX Designers, once your research is done, most of your IxD and UI work should probably be an easy walk through doing standard stuff the same way every time, if you’re doing it right.
Managers, you shouldn’t incent and promote on whether designs are beautiful or flashy, but instead on how well they satisfy users and work the same way everything else on the target device does, as long as you’re delivering the new and innovative functionality that’s to make the next million.
That’s probably going to break the heart of any visually-strong designer reading this. I feel for you. I know what it’s like. You want new, fresh looks, you want animation, and POW. But if the system doesn’t go POW, you’re not supposed to put a POW there, and you’re being a better designer by not going POW where no POW should be.
You can make a difference by….not making a difference from standard OS and usability conventions. Please do. Or don’t, as the case may be.