Predictability

Home » Thoughts and Musings » Thomas M. Tuerke on Design »

design: /di·'zin/

n a deliberate plan for the creation or development of an object. vt: to create something according to plan.
good design: /'gud —/ the product of deliberate forethought and careful understanding of the purpose of a subject, resulting in a subject which significantly improves its utility, allowing it to integrate seamlessly and naturally into the role for which it is intended.
false synonyms: fashion, decor.

Table of Contents [show/hide]

Predictability

Mon Dec 19, 2005 Link to this entry

You hear the term intuitive frequently when it comes to interface design. Unfortunately, intuitive means different things to different people. Like the saying goes, "Common sense often isn't."

Really, what people are looking for is predictability. A user, particularly a first-time user, should have a reasonably high degree of certainty what the outcome of an action will be, before they undertake that action. Designers have tried to leverage that by couching computer operations in familiar terms ("using everyday metaphors", to sling some lingo.) When you're using an unfamiliar email program and you see a paper-clip icon, you're fairly certain it means "attachment" because, hey, in the real world, you use a paper clip to attach something to your messages and memos.

Interestingly, over time, some computer metaphors have become incorporated into the canon, even though their original meaning may have become lost as technology changes. For example, many applications use an image of the 3.5" floppy to mean "save", even though floppies are no longer in common use. It won't be long before there are computer users who have never used a floppy, and won't have any first-hand experience with it. Whether the floppy icon will still have currency then remains to be seen. But then again, the same can be said about paper clips for attachments: are paper memos being passed around anymore?

Now, there's inherent predictability, in that the predictability is formed by experience well before the user's first experience with some circumstance, and there's acquired predictability. This latter case comes from having gotten used to the way things are, but you have to "burn your fingers" once or twice before that lesson sinks in..

Some designers rely on acquired predictability to use an application. But it still involves a learning curve, because of the "burn your fingers" lessons, and usually requires Drinking the Kool-aid—accepting a foreign mind set complete with very localized terms and metaphors—in order to use the system. This is usually inferior, because the user is forced to adapt to the application, instead of the other way around. Better usability leverages inherent predictability, by allowing people to carry forward metaphors from experiences prior to their use of a particular thing (and will likely have use in other parts of their life, too.)

Apple's whole idea on the early MacIntosh computer was that you shouldn't need a user manual. If a thing's purpose wasn't immediately obvious just by looking at it, the designers reasoned that they hadn't done their homework, and tried to find a better way to express it. A lofty concept, and it's responsible for the radical weight loss in many users manuals, even for software unrelated to the Mac. It was no longer acceptable to require the user to be intimately familiar with a thick manual just to use a product.

Whether or not the goal is attainable, though, it is a goal to strive for. The easier you make something to use, the more ready somebody will be to actually use it.

Sections: 2

Predicting Consequence—Reading Order

Fri Jan 13, 2006 Link to this entry

— Thomas M. Tuerke
It's often useful to design a dialog (or a web form) such that if one control (sometimes also called a widget) has influence on other parts of the dialog, the consequences should only happen below and/or to the right of that control—essentially "reading" order. (Yes, this assumes a western script bias.)
For example, a "Load" control shouldn't appear at the bottom of a dialog if it loads values into things above it.
Why? A good dialog is one that's easy to fill in, and the mind is predisposed to traversing over a surface in reading order, so the good dialog will cater to this predisposition, rather than having the user jump around from one area to another to get a task done. By having a consequence appear out of order, the user's thought process is interrupted, and they're forced to rescan what they've already "approved" (if they even notice it at all.)
There are minor exceptions to this. If a bunch of items are part of a visually related group, there can be some interplay in that group—even "out of order"—if the user's mind is willing to accept the whole group as some single unit.
This is something the developer must also learn to do: to think like a user. A developer is often familiar with the intricacies of the software, realizing that each radio button, for example, is a separate control... but the casual user may not be. Stop Thinking Like A Developer is useful here. Think Like a User should be the mantra. Without being condescending to users, they really don't care about the finer points of programming. They don't think about interacting with individual controls. They usually have a task, an operation, in mind and they want to finish that task.
Another quasi-"exception" is the OK button, if that's appropriate. Usually, this is the indication that the user is ready to commit to the intent expressed by the dialog. There might, however, be some need to validate the state. (Ideally, this should happen as soon as possible, but the OK button is sort of the last chance for the application to verify that everything makes sense.) In this case, parts of the dialog might need to be revisited, but I don't really consider it a true exception, because by the time the user has reached the OK button, they've gone over the entire dialog anyway.

Leveraging Common Metaphors

Tue May 16, 2006 Link to this entry

— Thomas M. Tuerke
On the matter of predictability, I remember working on a product called SigmaPlot. In a nutshell, it was a scientific charting product with a worksheet to contain data, and an exceedingly complex "menu" structure of options to design the very esoteric charts needed by researchers and scientists. As a product, it is still going strong, but with a lot of design improvements over the original version.
The problem was that unless you were a constant user of the product, you forgot how to do things, so making charts was an exercise in frustration for the infrequent or "some-time" user. The product was immensely popular for the charting that you could do with it, but our users had a love-hate relationship with it. In fact, what often happened was that a single researcher at a facility became the SigmaPlot Guru, and others would go to him or her for their charts. Good for stoking up the ego of that researcher, but bad for everyone else, including Jandel—the company that made SigmaPlot—since we could only sell one unit to the guru, instead of units to all of the researchers who had charting needs.
The barrier to use was the immense learning curve needed to use the product, and it did require you to drink the kool-aid to use. When I was first hired, I lobbied for the then-novel "Macintosh" (and up-and-coming "Windows operating environment") interface, sensing that this was the way things were headed. It wasn't a hard pitch, as I think almost everybody there was already game to the idea. There were other advantages, too: the only-when-needed popup menus were much more economical on the limited screen real estate than a large "choices 1 through 10" double-spaced menu permanently down the left side of the screen, but the big win was that Macs were seen as far easier to use than their IBM-PC counterparts, and were making in-roads in the still-new personal computer industry. Interface metaphors—like a top-of-screen menu bar, copy and paste, and object-verb commands (select something, then issue the command against it)—were increasingly what many users had come to expect from computers, so these ways of relating to computers carried forward to their use of SigmaPlot as well.
It was a radical change, but one that paid dividends. The previous version of SigmaPlot had a userbase of around eight thousand users... the new version tripled the userbase to almost twent-five thousand in a few short months. Clearly, people found it much easier to use, as our sales figures showed. All because we didn't require customers to drink the kool-aid of yet another arcane command and interface structure. Looking at the product, they could predict with reasonable certainty what effects their actions would have in the product. And that's what usability all about.
That said, SigmaPlot wasn't universally loved. We did get hate mail, mostly from those disenfranchised gurus who were finding their colleagues happily producing very good charts without them, but also from ideologs who proclaimed "if I wanted a Macintosh, I would have bought a Macintosh!"