Make stuff that just works, or go home.

“This is what customers pay us for–to sweat all these details so it’s easy and pleasant for them to use our computers. We’re supposed to be really good at this. That doesn’t mean we don’t listen to customers, but it’s hard for them to tell you what they want when they’ve never seen anything remotely like it.” – Steve Jobs

The job of the the software developer and the hardware engineer is to make experiences. They deliver these experiences for users by building things. Software, devices, and the marriage of the two. Sounds easy enough. The detail is in making things into experiences that “just work”.

Long ago, I started a blog post about my (now returned) Leap Motion controller, and stalled out on it. Listen – I don’t want to pile on a small company trying to make their own way. I think that Leap Motion has done some things very well. They made a good looking device, with nice packaging and even a pretty darn good (low friction) application store. But when the rubber meets the road, the device… just didn’t work how I expected it to. I’ve got a general post I’m mulling over the next few weeks where I’ll talk about that, as well as Kinect for Windows/Kinect in general.

Where the Leap Motion controller falls down, though, is actually in use. There are promises that their marketing materials make that simply don’t work in real life.

A few years ago, my youngest daughter asked for a toy (for either Christmas or her birthday) that she had seen during the little bit of TV she watches that had ads. Upon opening it, she seemed underwhelmed. When I asked her what was wrong, she noted, “It’s smaller than I thought it would be, and this thing doesn’t really work.” She was pointing at a pretend water faucet, if I recall correctly.

There are few things that are more disappointing – for a grownup or a child – when something we spend our money on or get as a gift doesn’t work the way we’re led to believe it should work – or even worse, the way we’ve been told it will work.

As I was boxing up my Leap Motion, a colleague came by and asked me to take a quick look at their computer. Unfortunately whether it’s a colleague, a parent, or a friend, that’s rarely something fun. Indeed, something had happened when they had rebooted their computer, and it had now somehow lost the trust relationship with the domain (and as a result, my colleague couldn’t log on). If that sounds gross and confusing to you, it should. It’s Windows showing you how the sausage is made. There’s an easy fix. Unplug it from the network, and Windows logs on using cached credentials. From there, you can do a bunch of things (including jamming the metaphoric sausage back into the casing) – but it will almost always let you fix the problem at hand. This hack is how Windows has worked for years when this scenario happens. My question? Why doesn’t Windows just say, “You may be able to log on to your computer and fix the problem if you unplug the network connection.”

Shame on me for not thinking of that solution 15 years ago and submitting a bug on it – and driving it to a fix.

I’ve been looking at a new book from Addison-Wesley called Learning iOS Design. The timing of the book may not be great, given the iOS 7 design refresh, but a lot of the principles still apply. It’s a good read so far, and most importantly, is really thoughtful in terms of sincerity of design. As I first thumbed through the book, I happened to land almost immediately on page 146. On that page is a section entitled:

The Moment of Uncertainty

It reads: “A crucial instant occurs every time a user provides a bit of input to a piece of technology … if the designers have done their part to create a graceful experience, then the instant will pass without notice by the user. The technology responds, the user’s expectation is met, and he continues getting done whatever it is he’s using the app to get done.”

This text, and much of this book, resonates with me. Over the last few years, I’ve begun looking around at the technology in my house, my workplace, and my life as a whole. Hardware, software, apps, appliances, everything. If something makes my life easier, I keep it. If it makes my life more tedious than if the item wasn’t there, it gets tossed. (I’m looking at you, Sony alarm clock on my nightstand.)

Imagine a device or an application. As it is designed, we can consider the potential discomfort (let’s just call it pain) of using this thing. The goal of a good designer is to eat the pain for the user. Imagine the below as a horizontal slider where the pain of a good interface can be alternately felt by the user or the designer. Iterations, refinement, tossed prototypes, all go in to building an end result that pulls the slider below away from the user and toward the designer. The work the designer performs upfront leads to a more efficient, predictable, and enjoyable experience for the end user.Painpoints

Arthur C. Clarke said, “Any sufficiently advanced technology is indistinguishable from magic.” The trick is to make magic where people can’t see the strings, and can’t see the cards up your sleeve.

I’ve mentioned this video before, but I think two of Jonathan Ives’ quotes in it are really relevant here:

“A lot of what we seem to be doing in a product like that (the iPhone) is getting design out of the way.”

and secondarily:

“It’s really important in a product to have a sense of the hierarchy of what’s important and what’s not important by removing those things that are all vying for your attention.”

I’ve said on Twitter before that it’s wrong that we’ve let people tell themselves that they’re stupid when the computer doesn’t work the way they expect it to. When you turn on the hot water and it comes out cold, does that make you stupid? No. So why do we put up with this from computers, devices, and software/apps?

I believe in the end, the technologies that win will be those that just work for users. Those that are predictable, easy, and enjoyable to use will win with consumers. Devices and software that are not focused innately on the needs of the end user will not survive. They will be discarded for solutions that do.

Comments are closed.