Interaction Design: What Is It, and What Is It Good For?

A good design is characterized by what it does not attempt to accomplish. In this spirit, this post is not a manual explaining how to do interaction design. It is not ground breaking research in the field. However, it seems many people are ignorant of this field, or confuse it with related fields. This post is meant to explain what it is, and what problem it solves.

Interaction design inspiration for this was taken from many sources, chief among them are Alan Cooper who wrote two wonderful books, _The_Inmates_Are_Running_the_Asylum_ and _About_Face_, and Bruce Togazzini who maintains the website “Ask Tog”.

Interaction design is the design of machines with complex behavior. It is similar, but not identical, to the design of form, industrial design, and the design of visual media, graphical design. It became important when computers, machines with potentially extremely complex behavior, became popular — often in non-traditional form such as cell phones, DVD playes or microwave ovens.

One of the most basic needs for people is to feel good about themselves, and especially about their intelligence. People like to feel smart. Intelligence is the ability to predict from patterns, and to act correctly on the prediction. This need is evolutionary: being able to read patterns better, and make choices on that prediction, is important to survival.

People hate when programs make them feel dumb. They emotionally suffer. This suffering should be predicted, and avoided. The goal of interaction design is to avoid the suffering. When the user suffers such an insult, design has failed her.

A typical real-life object will have a small number of states. A collapsible table, a standard industrial design example, can be in “fully collapsed”, “one side collapsed” or “fully expanded”. A complicated real-life object, such as an oven, can have a few hundred states. A small, short, program, will have thousands possible states (for example, if the UI contains just 10 check boxes).

The consequence is simple: unless carefully designed, a program will make any user feel stupid. The effort that is needed to allow predictability, even of a small program, is commensruate with the effort to make a complicated device understandable.  A useful piece of software is already at the ultra-light plane level of complication.

Our minds, evolved to tools no more complicated than a rudimentary spring, are not up to the challenge. We use Occam’s Razor in understanding the universe, and in particular software. We imagine “the simplest thing”. Unfortunately, it is seldom accurate…and when it falls out of sync with the implementation –we feel dumb (it does THAT! of course!) Therefore, programs should be designed to prefer a simplified “user model”: a user must be able to believe (erroneously!) she understands how the software “thinks”.

Worse, our minds do have a way to understand complicated behavior: assume a human-like mind. Studies have shown that software triggers the part in our brain designed for interpersonal interactions. Software written without this in mind, like people who do not keep this in mind, will appear rude.

Humans learn to be polite during years of development from parents and from surroundings. These do not come by themselves! People in jobs where they are supposed to provide a service, such as waiters or secrataries, develop this politeness further into professional skill –being aware of people, anticipating needs and doing what is desired is what they do for a living, and what they depend on for survival.

Programs, serving a human, must be carefully designed to be as polite. Otherwise, basic switches in the brain trigger “I hate him!” Nobody deserves that as a customer.

Cooking pots are an example of industrial design. People hold the pot in certain ways, people use the pots in certain ways. But the pot be surprising. It has to look nice, be easy to use and not hurt the user.

A poster is an example of graphic design. We need to relay a message. It has to look nice, be understandable, and not offend the viewer.

Apartments are an example of interior design and architecture. It has to look nice, be easy to live in, not be dangerous.

After these things are designed, someone needs to make them. Cooking pot require material engineers, construction engineers, perhaps robotics programmers all collaborate to make the cooking. Perhaps the pot is impossible — it is useful to consult with them earlier, and design around the limitations (add plastic handles even though they destroy the harmony).

The poster needs colorists, inkers and so on. They will create the poster as directed. Perhaps the poster is impossible: with the given materials, it’s impossible to get that resolution or shading — it is useful to consult with them earlier, and design around the limitations (use slightly different colors even though they destroy the harmony).

The apartment: plumbers, brick layers, etc. all collaborate to give the apartment you want. Perhaps what you want is impossible: we need a support column in the middle: consult with them earlier and design around the limitations (even though the column destroys the harmony).

This is not the way things are done in the new world: programmers are given a bunch of features. We will use the example of an e-mail client.

A typical e-mail client feature list might look like:

• Support embedded images
• Support address lists and extraction of addresses
• Support multiple folders, message management

Sometimes the list will contain items like “feature parity with GMail”. Always, always, the most important feature: “easy to use”.

Programmers go off and design the thing to support all the features. Of course, they all make sure it is easy to use: they eat their dogfood, and in week 1 into programming, they use it for all their mailing needs. The mail clients ends up supporting 10 ways to copy a message (so it can be easy to use by 10 people). It also supports 1000 configuration options (to work around bugs during the development period, but never taken out because “the user might need to configure it to never notify for new mail except for mailing list mails which are not classified to folders”). It’s extremely easy to delete all your e-mails at the press of a button. “Alt-A F M” marks all mails in all folders, and “D” deletes all marked mails. It does, however, first ask you “Do you want to delete all marked e-mails?”.

Nobody can use it without spending half an hour configuring it, because none of the developers ever use it in the default configuration. Before any key bindings are defined, one-by-one, in a text configuration file, the only way to reply to mail is to: Alt-M go into the menu mode, then pick “C”, inside the new mail type CTRL-I (for import), then ALT-M for the currently marked mail. Of course, all developers bound “M ALT-M C ALT-M ” to various keys in their keyboards. It also supports doing it completely via the mouse: click the “Actions” button and out pops the action dialog. You click “Compose” and you’re launched into the message composer. There you click the “Import” button, and out pops the “import dialog”. You choose “Reply to marked mail” and voila, you have the marked mail.

The client follows the organizational hierarchy. The “action” team is responsible for all that can be done with a mail. They programmed the dialog box themselves, and were happy enough to provide a “CallActionDialog()” function. The “import” team whined and bitched, but they got the “Forward” and “Reply” functionality. They just stuck it in their dialog, next to “Image”, “Table”, “SVG graph” (because the user might need to send graphs.) The marketing guys’ job is cut out for them. They check off every feature against the list of features, and put out brochures with all the features listed, with screenshots of a mail reply with SVG and PDF imported. The programmers are happy: after some days of debugging, the product is relatively bug free. QA is happy: the crashes are gone, and mostly the product works according to the design spec. Even the user testing people are happy: after just 3 minutes with the product, the user immediately found how to compose mails, how to reply to mails…but for some reason, nobody uses it as an e-mail client.

What if we designed cooking pots like that?

Feature list:

• Support >150C
• Must be easy to handle after having heated up
• Must support >4KG.

The engineers would construct a metal bucket, durable and weighing 0.5Kg. It supports 200C and 8Kg. It has a plastic “clip” to latch onto specific holes. “It’s easier to manufacture this way!” The clip can’t stay on for more than 15 minutes. “Nobody needs to move a pot for 15 minutes straight”. But it’s easy to use: the handle latches into the hole very easily. Marketing is happy. QA is happy. User testing is happy…and nobody uses it.

What went wrong? Design is more than a feature list. Design is even more than a feature list that contains “usability”. Design is thinking about people. The “user” is an amorphous blob, who can be all that we want her to be. Design thinks about what specific  people do with stuff. The designers should decide what they want from the engineers, not necessarily be engineers.

User interface is an “old computer world” notion. The implementation already exists. It has already been coded up. Perhaps these are standard command line utilities from the old era. Maybe it’s a complicated mainframe program. The user is new. She’s behind the screen. We need some way for the user to interface with the program. Like all good interfaces, it should express with minimality the existing functionality.

This technique is known alternatively as “putting lipstick on the pig” and “hitting the product with the pretty stick”. In the e-mail client example, the user interface designers added about twenty buttons for the “common actions”. However, the complicated model is still exposed by the fact that after pressing a button, the client is in a different modality.

In our new-age cooking pot, the designer made sure that it is obvious which side of the handle to hold, and which side of the handle to latch into the hole, as well as have nice arrows easily pointing the way of what should go where.

The bizarro-mail-client and the cooking pot from hell examples are up made — but we all use computers, and things which have computers in them — and things which have computers in them, but you don’t know about…

There are still many in the software industry who underestimate the importance of interaction design. The typical replacement touted is is usability testing. However, usability testing suffers from several problems. For usability testing, scenarios must be invented. These scenarios are almost, but not quite, like the scenarios that are the basis for interaction design. They correspond to features, not to user stories. In addition, testing happens late in the process — after all the choices were made. Therefore, it is impossible for usability testing to influence any of the choices which are hard to change.

Doing usability testing in liu of design leads to problematic products. More features will be added, genetically sorted into different menus by a kind of simulated annealing process. This is also one of the classic ways to get into a “lipstick on a pig” scenario. In essence, usability testing works like evolution. Evolution, compared to design, is a slow wasteful process, leading to extinction of most players.

While this is not intended to be a manual for interaction design, some principles should be introduced. Affordance: “When designing a monument, one has to consider a monument. If you’re designing a chair, however, you should be thinking about butts. All day.” Since people interact with the computer with their hands in fingers, designers should think about hands and fingers. It is often a good idea to steal from industrial design: an old methodology with more success, and user familiarity. Mice “feel”, after a while, a certain way. We should support visual cues to those feelings, such as rough ridges where we expect the mouse to grab. Other examples of affordance include 3D buttons the user is expected to push, 3D buttons with state (pushed or unpushed) or boxes to be written it that look like an empty piece of paper. Similarily, decoration should look 2D and with low-contrast colours — it should be seem to afford interaction.

Experimentability: Undo is not always spelled “undo” –various idioms fit various situations, like “revert to saved version”. Dangerous features should be eliminated. If it is all at possible, make each feature “undoable” in some obvious way. Allow a feature to be “experimentally applied” (for example, trying out a new design for a blog.) Make it obvious dangerous things are dangerous — “don’t put the ejector lever near the volume control.” My IM client puts the “Block user” button right beneath the box where I should type. When I click to focus, I have an equal chance of seeing “are you sure you want to block this user” as much as actually succeeding.

Predictability: Just because MS does it (or Apple…) does mean it’s a good idea. Perhaps not the best idea, but only depart from the way other programs work when it is significantly important to do so. When a program behaves like all other programs, a user will feel smart because she will know how to use the program. If it looks like a duck, it should be a duck. Conversely, if it’s not a duck, make sure that it doesn’t even resemble a duck. If you have a button, don’t make it look like a label. If you have a label, don’t make it look like a button.

Principle of least surprise: do whatever would surprise the user least. Note that because of the current state, the user will frequently be surprised by the program not making him feel like an idiot. This principle can be violated in these cases.

This post concludes with several case studies of interaction design.

Dilbert blog comment meltdown (thanks to AskTog): the blog allowed writing “draft”. Drafts were only available to select readers. You could “publish” the draft. After Scott Adams “published” the draft, he didn’t need the draft, so he deleted it. However, there was no difference between the draft and the published version in the software. Scott Adams deleted his own work…and 500 comments from users on it.

Why did it happen? Feature-oriented design. “Allow drafts”, “allow commenting on drafts” and “allow deletion” features all existed. The programmer put in a dialog “are you sure you want to delete?” Scott Adams was damn sure he wanted to delete the draft. Scott Adams worked in the newspaper business, as a comics creator, for many years: he would work on drafts, eventually photocopying or faxing a final version to the paper, and throwing away all his drafts. User model: when a draft is published, the published version is a copy of the draft as it was when it was published. Nothing I do to a draft can change the published copy. Implementation model: a document can be in “draft” mode or “published” mode. Switching between the two is easy, and it functions as an access control. There’s no concept of “working on the draft”: you work on the document, be it in either mode. This could have been fixed with better “features” or even a better “pretty stick”: add the feature “allow undo” or add better wording — naming the modes differently (public vs. private, for example) This would have been better fixed with interaction design. Scott Adams is a typical high-profile blog user: many of the people who were famous before the internet/web exploded, have followers who want to read what they have to say. These people worked with newspapers, and were used to writing drafts. If the product was designed with people like that in mind, we could have allowed a real “draft” which is “published”, making a permanent copy. This being a computer, we could still allow “Edit to published version”. We could have allowed “propagate changes from a draft to published”. We would have “revert to previous published version” (which would be different than a step-by-step undo, although they could have shared implementation).

The unusable alarm clock (thanks Alan Cooper): an alarm/radio/CD player combination. Arming is done by pressing “alarm” exactly five times: once turns “show time” to”on”. Twice turns “show time” to “off”. Three times shows CD/Radio. Four times shows volume. Six times disarms the alarm. In a dark room, sleepy, you need to press it five times. * “5 shall be the number you shall press, and the number you shall press shall be 5. Not 6, for that disarms it. Nor 4, except on your way to 5, for that is not enough.” If you fail? You get fired, I guess…or maybe dumped…or worse?

Most users need to wake up at the same time every day. Have 3 buttons: “arm”, “disarm” and “change settings”. Don’t allow the off setting at all: it is stupid, just play it until the user clicks the “I’m awake” button.

Sending SMS on my cellphone: after I send an SMS, the text remains there. Sometimes I remember: I have to press “Clear” on repeat for 30 seconds to delete it all, then go back to where I was. Sometimes I forget: I see the text, and think “OMG, did I send it?” I quickly send it again. This costs time, money and embarassment. Sometimes I sit on it: since writing an SMS prevents it from autolocking, after some creative sitting, it can be sent anyway. Who needs to send the same SMS twice? We have address lists, and if resend is a useful feature, a “forward” feature on sent SMSs would be more useful.

Google: people go to google to search. There’s “text to search”, and then there’s “Search” button. One extra “I’m feeling lucky” button for these “I already searched it on google, and I want the first hit” situations. Rich visual modeless feedback: looking at the google interface, you immediately know what you are searching. On top, what you’re searching for, as well as your options, is bold. Clicking on anything on top searches for the same terms as you were just searching: no need to cut and paste.

OLPC Journal –a filesystem alternative (thanks random reddit guy named serhei): filesystems are a hierarchical way of saving files. It is related to how computers think, not normal humans. Categorization fails anyway — “everything fits under Misc” — so users learned to put all files in the same folder, and give good names. Sometimes they separate files according to types, which is really silly, because computers are better at that. OLPC journal allows programs to “save” objects to it. A user can explicitly choose to do so, but programs will also do it automatically: periodically or after the user does a big action. The clip board is part of the journal. Any “clip” is added to the journal. The journal can be filtered and sorted in various ways. Any object can be tagged, and the journal automatically tags any object with generated metadata. Old revisions can be compressed, if space is at a premium and things can just let fall off the end –unless the user tags them specifically. “Backup” is easy: just a store of the old items into a big offline storage.