These trade-offs are unavoidable. If you don’t make them explicitly, you make them implicitly. Can’t decide which feature get a big button? You can create ten buttons but you’re making another trade-off: each will be a little less prominent, and your product’s simplicity and elegance will suffer.

Trade-offs are necessary at every stage of the product lifecycle:

• Apple is often praised for simplicity. Less is more: remove all the physical buttons and do the rest in software. But that’s not the whole truth. The iPhone has two volume buttons, a power button, a Home button, and a ringer switch. Only the power button is necessary. Someone made a trade-off, sacrificing a certain degree of simplicity for the convenience of four more buttons. The result may, in fact, feel simpler: without taking the phone out of my pocket I can adjust the volume or set it to vibrate. What we call simplicity is, in fact, a successful trade-off.

• Facebook has repeatedly favored speed over caution, angering users by releasing features and design changes (e.g. the newsfeed) without vetting them thoroughly. Many look to the resulting uproar as a cautionary tale, but I believe this is the wrong lesson. At worst, Facebook’s tremendous growth has proceeded in spite of these choices. But I suspect Facebook has succeeded because of them: by trading speed for pre-release research and by making sure they can correct course quickly, Facebook has innovated, stayed ahead of the competition, and gotten free user research in the bargain.

Make no mistake: trade-offs are hard. They require sacrifice. They require risk. But then, it should come as no surprise that these qualities are needed for great product design as well.

Data-driven design is a vital tool for hill-climbing iteration of a site, but you should take great care not to use it as an appeals process whenever you and your designer reach an impasse. It sidelines the designer into being no more than a brainstormer, devoid of design ownership…Also please keep in mind that everyone has opinions on design, and that your UX professional has devoted years of their life to learning to separate their subjective opinions from their objective understanding about how the larger audience will interpret an interface. It’s not as demonstrable as code that passes unit-tests, but trust in it anyhow.

from Google Design: The Kids are Alright

We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to consumers because they make the products more difficult to understand and use…It turns out that designs that just work are much harder to produce than designs that assemble long lists of features.

Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. The more features there are, the more likely one will develop problems or will interact badly with another. In software systems, there is a storage cost, which was becoming negligible, but in mobile applications is becoming significant again. There are ascending performance costs because Moore’s Law doesn’t apply to batteries.

Features have a documentation cost…Features that offer value to a minority of users impose a cost on all users. So, in designing products and programming languages, we want to get the core features – the good parts – right because that is where we create most of the value.

Crockford, Douglas. JavaScript: The Good Parts, pp. 99-100

Background

Traditionally, software applications are installed via an installer: a script that copies files to your computer and performs any configuration necessary to get the app up and running. Typically (and especially on Windows), files are dumped all over your hard drive. The program itself, yes, but also various supporting files: help files, images, libraries, etc. Deleting one of these files may cripple the application. To remove the app, you need to know exactly what was installed or you need an uninstaller.

With Mac OS X, Apple introduced application bundles to improve this situation. (Actually they were introduced with NeXTSTEP several years earlier and OS X inherited them.) An application bundle is a specially structured folder that looks to the user like single file. If you’re a Mac user, you can see what I mean: open your Applications folder and Ctrl-click (right-click) on an app there such as iCal or Mail. Select Show Package Contents and you’ll see what the app is made of.

Why is this important? Because now a double-clickable app can contain all its supporting files. Installing an is as simple as dragging it to your hard drive. To uninstall, drag it to the Trash. And applications are less fragile: because they’re self-contained they’ll run from anywhere (not just Applications), and the chances of destabilizing an app by deleting a depenency are low.

Current Practice

Since apps don’t require an installer, the simplest way to distribute one is simply in a zip archive. Unzip it and you’re done. If you drag to /Applications, great; if not, it’ll still work. Many apps are indeed distributed this way.

However, the de facto standard is to put the app on a disk image, compress the disk image, and distribute that. It’s also  standard to include either an image or an alias of /Applications to indicate the need to drag the app there.

Disk image window with drag-and-drop cue

There are several advantages to this approach:

• You can distribute auxiliary files (plug-ins, extras, manuals) without dumping them all on the desktop or obscuring the app in a folder.
• When the disk image is mounted its window can open automatically, providing helpful feedback to the user.
• It enforces the idea of dragging the app to /Applications.
• It allows you to present a license agreement to the user when the DMG is mounted.
• You can include branding in the DMG’s window.

The Problem

The trouble is, this approach works too well. Because apps can run from anywhere, a user can launch the app from the mounted DMG, resulting in the following scenario:

1. A user downloads your app.
2. He double-clicks until the app appears in a window (that of the mounted disk image).
3. Accustomed to installers or just to double-clicking on things to make them go, he double-clicks. Or, he drags the app to the Dock and clicks on it there.
4. The app launches. Everything is great.
5. Later, the user restarts his computer. The Dock icon turns into a question mark and the app’s window disappears. The user is confused and sad.

In other words, if a user misses or misunderstands the drag-and-drop cue, everything works so well that he fails to install the app, causing confusion later on. And it’s not a far-fetched scenario: many apps do still use installers and double-clicking on things tends to work. People’s visual focus can be very narrow, so some users will certainly miss the drag-and-drop cue. Aliases are arguably somewhat of an advanced concept, so the idea of dragging the app from one place in the window to another may not make much sense; and users who interact with apps exclusively via the Dock may not know the location or role of /Applications.

Luckily, this problem isn’t hard to solve.

The Apple Solution

The ideal solution would probably come from Apple. With Leopard (Mac OS 10.5), apps launched from DMGs already produce a warning:

OS warning when launching from a DMG

Apple could simply replace “Open” with “Install” and copy  to /Applications before launching:

A revised launch-from-DMG dialog

A context menu item or modifier-click would allow advanced users to run directly from the DMG. References in the Dock would be updated as well.

The Developer Solution

Of course we can’t rely on Apple to implement this. Nor do we have to. In the absence of an OS-level answer, individual vendors can provide the same functionality themselves.

How aggressive should vendors be? Delicious Library – which is not distributed by DMG – prompts users when the app is anywhere outside /Applications:

Delicious Library's launch dialog

The disadvantage of this broader approach is that it must be presented as a warning or choice rather than a natural part of the install process. By only prompting for DMG-launched apps, we can make it a simple (and expected) “Proceed with installation?” confirmation rather than a more complex “Should I put this someplace else?” choice. And while Delicious Library’s prompt keeps a user’s desktop clean, it’s an extra and entirely optional step: downloaded apps scattered all over the desktop may be irritating to some, but it doesn’t prevent the user from launching them.

“After the tone, please record your message. When you have finished recording, you may hang up or press pound for more options. [inexplicably long pause] To leave a callback number, press 5.”

I have never dared to press 5.
It’s possible that someone did research and found a real need for these Instructions, but I’d be surprised. It seems more likely that someone stuck them in because she could – perhaps Shirley herself, though I suspect she’s innocent. I’m not averse to providing options, but when they serve only a fraction of telephone users (as I suspect they do) they should be provided in a manner that doesn’t get in everyone else’s way. (The need for them is what we often call an edge case. It’s easy but dangerous to get caught up in edge cases, because the last thing you want to do is design for them at the expense of the core use cases.)
Some carriers (Sprint, AT&T/Cingular, and possibly T-Mobile) allow you to bypass Shirley by pressing 1; Sprint goes so far as to tell you about it. In the past my outgoing message has begun, “Press 1 to skip to the beep.” Instructions for the Instructions.
The iPhone has already been lauded for bringing Apple simplicity to the mobile phone market, but I think of my outgoing voicemail message as AT&T’s territory. To my surprise and delight, here’s what happens after the outgoing message when you call an iPhone user:

[beep]

Thanks, Apple.

It’s counterintuitive but by offering a wider array of options, vendors seem to reduce sales. Jared Spool’s recent interview of Barry Schwartz provides a nice overview, and Mr. Schwartz’s new book The Paradox of Choice goes into further detail. When the decision is complex, the key to higher sales may be breaking the decision making process into manageable pieces.

Many e-commerce sites provide faceted navigation systems to shoppers. These systems allow users to narrow a list of products, one aspect at a time. For example, an array of 151 digital cameras on CircuitCity.com is made less bewildering by a menu of features or facets: resolution, camera style, price range, and brand.

Facets on CircuitCity.com

With these, users can reduce the list of cameras to a manageable size. Facets are flexible and robust: because the navigation is generated from the products themselves, an empty result set is impossible. And facets don’t involve a hierarchical taxonomy, so users can filter in whatever order seems natural. I have written elsewhere on the importance of good browse tools; and like any good browse tool, faceted navigation does an excellent job of shifting the responsibility for domain knowledge away from the user and onto the content producer.

However, faceted navigation doesn’t solve the problem of choice overload. Circuit City’s five digital camera facets still present a total of 22 options. And, as Jared Spool is fond of pointing out, I’m probably not looking for a camera anyway: I’m looking for a way to take pictures. So while I may know what I’ll be photographing and how I’ll be displaying the results, I may not know how that translates into optical zoom and megapixels.

Some e-commerce sites provide product selection wizards that produce a narrow result set from a series of questions, i.e. “What size prints do you want to make?” This ought to be a perfect front end for complex decisions: at any given moment, the user is faced with one simple, understandable choice. In my experience, though, these tools are frustrating. They seem to ask the wrong questions and their results aren’t what they should be. My suspicion is that these wizards are special, separate projects for vendors, dissociated from the larger process of creating and maintaining facets. I contend that with a more integrated data entry workflow, vendors can increase both the number and the quantity of such wizards, making consumers’ choices more pleasant and manageable and increasing sales as a result.

I imagine the current facet-creation process involves the following:

• Enter name of facet
• Define possible values

Why not augment it with…

• Create a user-perspective question for the facet
• Map answers onto values

More time-consuming perhaps, but if this information is present for every facet in the system then the product selection wizard becomes a guided front end for the faceted navigation system. Every product category or sub-category automatically gains a wizard. And it needn’t be a special, separate tool: users can jump fluidly between this Q&A filtering and traditional navigation.

Naturally there are pitfalls. While the employees who create facets presumably do have some domain knowledge, they may not be accustomed to creating user-oriented questions (“What size prints do you want to make?” vs. “How many megapixels do you want?”). But I imagine that with time, training, and supervision this will improve. And even questions that merely rephrase the facet should represent a marked improvement in the decision-making process itself, since the user will face only one simple choice at a time.