I have a lot of trouble explaining my interest in user interaction to others.
A typical response to my reasoning goes something along the lines of: “Yeah, but with Beryl, Linux looks even better!”
The computer scientists I talk to just don’t understand that user interface is about how the program acts, not how it looks. And really, I think that’s why there’s so much terrible software out there: these are the people who are building it!
The Five Minutes Left Test
In five minutes, you’ve got to leave for a doctor’s appointment, but there’s this thing you’ve really got to get done first, and you need iFoo to do it.
You’re stressed and in a hurry. Is iFoo going to make you even more stressed, or is it going to sit you down, give you a slap, and tell you everything’s going to be okay?
The sad truth is that unless I’m very familiar with it, almost every piece of software is going to do the former. I’m in a hurry, but now I’ve got to figure out how to use this thing. More specifically, I’ve got to figure out how to express what I want to do in terms it can understand.
Doing It Right
The difference between mediocre software and superlative software is the language it speaks. Stressful software makes users express what they want to do in its terms; excellent software works on the user’s terms. It doesn’t make the user know what to ask or how to ask it, and most importantly, it doesn’t get in their way.
A number of principles are key to getting this right.
First and foremost is the principle of least astonishment. Essentially, actions shouldn’t surprise the user. They should work consistently across applications, they should be undoable, and what works elsewhere should work everywhere.
The next level is the principle of the four-star waiter (no Wikipedia article on that, I’m afraid). When you’re at the Ritz, and you’ve put all the marshmallows into your hot chocolate, you don’t have to ask for more. When you turn to grab another, the waiter has already silently refilled the bowl. Clippy and his wizard friends are an attempt to imitate this dapper young man, but they do a terrible job because they’ve forgotten about the silent part.
Your application should anticipate the user’s needs and—without confusing or obtruding—act appropriately. Things like remembering a window’s position or the previous input to a form are only the first step. iChat manages your away status for you, asking as few questions as possible. iTunes keeps your iPhone continuously in sync, and if you run out of space, it’ll leave off things like photos before more critical data like contacts or addresses. Twitterrific focuses tweets directed at you because it knows you want to read them.
The next important step is minimization of interaction. You can start by reducing the number of actions required to perform tasks, but that’s not good enough. When I want to broadcast a thought, I use Twitterrific more often than MarsEdit not so much because of number of steps but rather as a result of how many things I have to deal with. Every control, label, and window makes your application more stressful to use; every time I have to change focus (especially window focus), you’re breaking my flow a little. Safari is good because its interface is tiny. We like Twitter because it has one text field. iMovie ‘08 is a poster child for reduction to a tiny number of core actions.
Get Out of My Way!
This is really a matter of flow—flow is the most important thing. Flow is how we move, and it’s why people sometimes prefer a notepad over an electronic document. When you want to note something, you write it on the pad, and put it in your pocket. You don’t have to make up a filename or where it should go. You don’t have to worry about remembering where to find it again later. You don’t have to think about quitting the app when you’re done.
Flow happens when you perform a task, thinking only about what to do, not how to do it. This is why people like things like emacs and vi so much: after the (considerable) learning curve is over, they can move like lightning, slowed by the speed of their ideas rather than by the speed of their tool. When focus isn’t in the right place, when a modal dialog pops up, or when a button isn’t placed near the data it affects, it breaks flow. You have to stop thinking about the grand unified theory you’re writing long enough to explain to the computer what you mean.
That’s the real price of bad software.
When a personal finance program sucks, that’s annoying. But my blogging software gets in my way, so I write fewer posts. And when I can’t figure out how to change the time signature midway through my piece in a music composition tool, I stop composing. The music stops playing in my head. I look around. I get out the manual. All this because the icon for the tool in question wasn’t good enough!
As software becomes more powerful, it becomes more essential to creation—to making things. And if your software is doing anything to distract your users from their magnum opus, the world is never going to hear it. They’ll hear something just slightly inferior; you will have been responsible for confusing the creator at some pivotal moment.
If you’ve written something fantastic, though, it’ll become an extension of the artist’s hand, just like a paintbrush. It’s an extra tool that enables him to solve new problems and produce even better results. It’s something to strive for—it’s why I write software.
Learning
Fortunately, it’s not impossible to get a sense of your users’ flow.
Step One: You don’t count. You’re not confused by anything (one hopes) because you wrote the app. Your experiences will only catch blatantly obvious flaws. Use them as an initial filter.
Step Two: Your imagination, however, does. Write user stories. Write them for every conceivable use case. Throw out the ones that you don’t want to support. Declare that the ones which remain are the only cases you care about, and stick to that.
Step Three: Watch real users. Some of the most useful experiences I had during Pixen’s development were when I sat down an entirely new user in front of it and watched them go. You’ll see exactly works and exactly what’s confusing. You’ll discover new user stories or (with enough samples) gain the confidence to trash others.
Iterate, iterate, iterate, and never allow anything to grate or confuse. Never tell a user “well, I guess you can do that, but you have to go do these other two things with the whozit first, then click refresh.”
And whatever you do, don’t need a Knowledge Base.
