Over the years, I’ve discovered that every time I decide to redesign my website, it quickly becomes an obsession—one of those things ends up consuming weeks or even months of time until, finally, I give up in exhaustion.

Possibly it’s because I consider a website to be like an interactive book that you explore in real time, and like every other book I’ve ever written, it’s never been finished, only abandoned. (Some of my critics think I should abandon my books before I write them, but that’s a different conversation.)

I used to be that way with software I wrote too, whether it was for myself or anyone else. It not only had to be idiot-proof, it had to be genius-proof as well—just in case I made a genius-level mistake.

But as time-consuming as obsession is, it also produces experience and expertise. You learn things. You come back from the adventure with new insights. And the next time you have to tackle a project, you don’t make the same mistakes; you get to make new mistakes.

Last month, I talked about the history of how the software interface evolved from the command line to the menu. Most programs today have a menu bar across the top, usually with File, Edit, View, Tools and Help options, or some variation specific to the needs of the program.

The Microsoft Ribbon is an evolutionary step, and the jury is still deliberating as to whether or not it’s a good one. Microsoft loves the ribbon, and it is the new standard for all Microsoft products. Some users hate the ribbon, others shrug and say they can use it. I haven’t heard anyone say they love it, so I have my doubts about any other software publisher adopting the ribbon idea.

The issue is not the ribbon, nor is it even the menu bar. The issue is the whole idea of how an interface should work. The user wants to be able to get from here to there in as few clicks as possible. The ideal program would have only one button: “Do What I Want.” But software doesn’t work that way, and neither do husbands. This is why both programmers and divorce lawyers can afford to send their children to good schools.

#!
In Web design, the rule is “three clicks or less.” The user came to the website for content. The more important the content, the faster he should be able to get to it, but no content should be more than three clicks away from the home page.

In software design, the rule is “two clicks or less.” Okay, there are exceptions to that. Adobe Photoshop has so much functionality that sometimes you’re spelunking three or even four clicks deep, and sometimes that just takes you to another window with its own unique set of options. The alternative would be to have menus so cluttered that they’re impossible to navigate.

And this is where usability testing comes in.

As near as I can figure out, usability testing is one of the most overlooked aspects of design, both in hardware and software. A few examples:

Samsung’s Galaxy S II is one of the best smartphones ever, but the on/off button is awkwardly placed. It’s just a little too high on the side to be easily pressed. I’m not the only user to notice this.

Amazon’s Kindle Fire is a great tablet/e-book reader, but the on/off button is in an even worse place (on the bottom), and you can accidentally turn the device off just by holding it wrong. Didn’t anybody walk around with a prototype for a few days?

Microsoft’s Zune was a marvelous media player—in my opinion, vastly superior to the iPod. But while the touch-screen interface was very usable, I could never quite figure out why the device needed three different hardware buttons, or which one to click for which function. Again, I’m not the only user confused by this.

StarCraft II is a marvelous game; I play a couple rounds almost every night. But why is there an “Enter” screen after I sign in? Why can’t I just go directly from signing in to the main menu?

Why did Amazon change their start page? Yes, it was inconvenient before to scroll through the categories to tell the search bar that I wanted to search only in a specific department, but now it’s two or more clicks away, and that’s even more inconvenient.

In hardware or software, it’s about “clickability.” How fast can I get from here to there? Is the device or the software going to be transparent to the experience, or will I be reminded each time that it isn’t as convenient as I’d like? Who’s going to spend the most time waiting: me or the device? I vote for the device.

#!
Thinking as a programmer or even as a designer is not the same as thinking like a customer. The programmer sees the structure of the software as a set of functions and the interface as access to those functions. A designer sees the interface as an artistic goal. So menus often end up as a reflection of the programmer/designer’s opinion about how the program will be used, or should be used.

But the user comes to the program from a whole other direction. He’s impatiently looking for the “Do It Now” button. He doesn’t want to sort through a host of recording options in Exact Audio Copy, he just wants to rip an accurate track off a CD. He doesn’t need to see all the filtering plug-ins for Audacity, he just wants to edit the unnecessary pieces out of the recording of his three-year-old’s rendition of “Born This Way.” And most of the time, the user doesn’t care about all the renaming and filtering options in IrfanView, he just wants to batch-resize a folder of photos before uploading them to Facebook.

The common user usually has a specific task in mind, and he wants to get in and out as smoothly as possible. He wants the program to have a menu of one-button presets to choose from—from ”quick and dirty” all the way up to “painfully precise.” And if necessary, a “custom” option so the user can create presets of his own, like “quick and painful” or “good and dirty.” The point is that interface design is often the biggest single obstacle to software usability, and ultimately, its success.

I don’t fault programmers for this. From the programmer’s side, it makes sense to design the software this way. And I don’t fault the users either for being impatient or frustrated. “Read The Frustrating Manual” is no longer part of the process—in fact, it never was.

(Okay, in the interests of full disclosure, I read a manual once. It was Jeff Duntemann’s excellent little book that came out with Turbo Pascal 5.5 explaining how Object Oriented Programming worked. But other than that, let’s face it, the manual is pretty much the last thing anyone looks at when installing new hardware or software. Most manufacturers know this and do their best to make the process plug-and-play instead of plug-and-pray.)

This is what every software developer needs to understand. You are not in the business of writing code. You are in the business of providing a service to the user. Writing code is simply the way you deliver the service. Finding out what service the customer wants from you and how best to deliver it is the key to your own success. To be blunt, your job is to serve the customer’s needs, not your own. The customer is usually pretty good at telling the difference.

Successful software gets used, it gets recommended, it gets popular, and eventually it even becomes a standard by which all competitors are measured. You create success by approaching the problem from the user’s side. What does he want and what experience are you creating for him? How many clicks?

As important as the underlying code will be, it’s the interface that the user sees. And that determines the user experience. Developers need to invest some serious thought and energy into usability testing. Failure to road test the user experience is product suicide. Why invest months or even years of your energy building a Ferrari engine only to put it in a Yugo body?

What do you think?

David Gerrold is the author of over 50 books, several hundred articles and columns, and over a dozen television episodes, including the famous “Star Trek” episode, “The Trouble with Tribbles.” He is also an authority on computer software and programming, and takes a broad view of the evolution of advanced technologies. Readers may remember Gerrold from the Computer Language Magazine forum on CompuServe, where he was a frequent and prolific contributor in the 1990s.