They drove all day. They drove all night. They stopped at a Denny’s in St. Louis. As they dug into their Moons Over My Hammy the Bunny said, “Tomorrow we’ll make for Denver. It’s a flat, boring ride but then we’ll have the plains behind us and see some mountains!”

Just then a long, furry head emerged from the booth behind them. “I couldn’t help overhearing,” said the Ferret. “I’m headed to San Francisco too. May I join you?” The Bunny looked worried but the Frog said, “Sure! I can see from your trucker cap that you’ll add value to our little adventure.”

The Ferret slipped into their booth, grabbing a mouthful of Bunny’s dinner. “All this speculation about routes is silly,” he said. “Look out that window! Hundreds, thousands of cars headed off on their own adventures. Surely our best route will be the one with the most cars. Let’s count how many go each way and follow the biggest crowd.”

“That’s a great idea,” said the Frog. And they headed south.

They drove all day. They drove all night. They stopped at an Applebee’s in San Antonio. As the Ferret shoveled overcooked peas into his mouth the Bunny said, “I don’t understand. We’re following the traffic and I get that. But how do we know we’ll reach San Francisco?”

The Ferret smiled. “It’s not important! What do we gain by setting some arbitrary destination? How do we know we’ll even like San Francisco when we get there? Let’s focus on the here and now, use the information around us to guide our decisions.”

Bunny thought about this. “But if we don’t have any greater destination, what’s to stop us from wander–”

“While we’re at it,” interjected the Ferret, “what are you contributing to this trip? I’m watching the cars, Frog is driving, all you’re doing is looking at the map and suggesting routes that don’t match the traffic.”

The Bunny sat silently, grateful that an angry rabbit is visually indistinguishable from a calm one.

They drove all day. They drove all night. Bunny looked out the window as they passed cities, towns, mountains, strip malls, and deserts. Also more strip malls. They stopped at Burger King in Cheyenne, Cracker Barrel in Nashua, Waffle House in Austin, Chick-fil-a in Atlanta. The Bunny did crosswords.

One morning, as they rocketed east out of Mexico City with the windows down and the Ferret singing along to the radio, the Frog glanced at the back seat and found it empty. “Where’s Bunny?” he asked.

“Gone,” said the Ferret. “Left this morning. He looked angry. Or calm. Said something about San Francisco.”

“What an asshole,” said the Frog.

It’s the myth of the Average User. At Yahoo! we called them Chief Household Officers (an unfortunate warping of a legitimately identified market segment). Maybe you call them Stay-at-Home Moms or Women 30-45 — somehow they’re always female. They’re a catch-all excuse for dumbing down products. We try to get them in the lab but they end up being smarter and more interesting than we wanted. In fact, we’ve never met an Average User.

Perhaps the stereotype is born of helping friends and family with technology problems; or waiting in line behind someone at the ATM; or watching the antics of a fellow cafe customer with fascinated horror. A lot of people are really bad at basic computer tasks. Many don’t fully understand their filesystems, or the difference between an OS and a Web browser.

But that doesn’t mean they’re dumb, or inept. It means they’ve figured technology out on their own, skipping over many of the underpinnings because they weren’t relevant. They’ve spent hours on Facebook and Google and know their way around, but haven’t had to interact directly with their home directories.

The result is a specific, somewhat predictable set of expectations. Show a user something that acts like Facebook or Google and she’s likely to figure it out. Show her something that looks like Facebook but acts some other way and she’ll struggle. Talk to her about friends or newsfeeds or Googling and she’ll get it. Talk about RAM and browser windows and WebKit and not only won’t she get it, she may not care.

Why bother pointing this out? Because it affects the success of your product. Design for the mythical Average User and you’ll have something that’s neither compelling nor efficient to use. At worst it’ll be insulting. At best it’ll limit your chances of success: not only are you designing for people who don’t exist, you’re also creating an environment where it’s easy to justify uninteresting functionality and bland visual design.

Instead, design for real people. Even if your product is meant for everyone, find a more interesting subset with clearly identified needs. Understand their expectations for how a digital product works and capitalize on them. Keep it focused. And respect your users enough to differentiate between experience and intelligence.

I often use Dropbox as an example here. Everyone I work with uses it (technical and non-technical alike). It’s simple to understand and easy to get started. It just works. It explains itself in layman’s terms, but isn’t insulting. Its feature set is small and focused, but it functions flexibly enough for power users to work around its apparent limitations (e.g. using symlinks to work outside the Dropbox folder). It solves one problem and solves it well.

Remember that novice users, once hooked, become power users and need efficiency. Conversely, novices aren’t necessarily your first customer. If your target user isn’t technologically adventurous, the way to his heart is through those who influence him. For example, Gmail’s global rise was fueled in part by tech geeks who eventually convinced friends and family to switch. Facebook started on college campuses and expanded from there.

The next time an absent relative is invoked to justify a decision, challenge it. Get the relative on the line, find a real person to serve as a replacement, turn to the data…whatever it takes to make sure you’re designing for real people. Because mythical users can only generate mythical revenue.

Let’s get one thing out of the way: creating a great standard experience is a hell of a lot easier than creating a great custom one. Even some of the best custom apps (e.g. Twitter for Mac) fail to handle some key interactions (e.g. distinguishing between an active and an inactive window). Your mockup may look splendid in Photoshop but in sidestepping your platform’s own UI toolkit you’ve assumed the responsibility for all sorts of details (e.g. accessibility). In other words, don’t go down the custom route unless you’re willing to put a lot of effort into making design a differentiator for your product (as Twitter has clearly done).

Anyone who’s worked with me knows I enjoy designing custom controls — widgets tailored to the task at hand. Generally these tasks could be accomplished via some combination of standard UI elements, and the argument against them is often about consistency. In “User Interface Conservatism versus Liberalism,” Adam Engst writes,

…the real problem with UI liberalism is that it reduces the usability of the platform as a whole…The more you use applications in concert—and many of us spend our entire days at our Macs—the more you benefit from the consistent user interfaces designed by UI conservatives. And when applications rely on consistent user interfaces, they become easier to learn as well, which translates directly to the bottom line when we’re talking about productivity applications.

Much of his argument is good. But ultimately I disagree: consistency doesn’t matter. In 2005 Jared Spool wrote, “Consistency in Design is the Wrong Approach“:

The problem with thinking in terms of consistency is that those thoughts focus purely on the design and the user can get lost. “Is what I’m designing consistent with other things we’ve designed (or others have designed)?” is the wrong question to ask.

Instead, the right question is, “Will the user’s current knowledge help them understand how to use what I’m designing?” Current knowledge is the knowledge the user has when they approach the design. It’s the sum of all their previous experiences with relevant products and designs.

As an example, consider Apple scrollbars:

Apple scrollbars on the Mac

iTunes and iPhoto’s custom scrollbars are visually inconsistent with the standard Mac one. Yet I doubt this creates any usability problems because they retain the same layout and a set of core visual cues. They all rely on the same current knowledge.

Easy example, you say: that’s just visual design. What about differing interactions? Encountering a Mac scrollbar for the first time, a Windows user might be confused because the up arrow is at the bottom. Here, the visual design serves as as guide: that up arrow is nearly identical to the one found on Windows. So the user’s current knowledge of Windows allows her to find it after a moment’s hesitation.

But that’s where things get nuanced. That hesitation is fine if she uses a Mac occasionally. But if she’s constantly switching back and forth she’s also repeatedly re-training herself, constantly incurring that cognitive load. And however inconvenient that might be, at least she can recognize two different contexts; it would be far worse for a Windows app to use Mac-like scrollbars. Here, consistent placement matters because it’s how we achieve consistent expectations.

It gets worse: suppose your app uses custom code to generate a snazzy scrollbar. You put both arrows at the end since that’s the Mac standard. That Windows user changes her Mac’s system preference so the scroll arrow is at the top. Every scrollbar except your app’s changes to obey the new setting. Yet another example of why custom UI is difficult.

Today, nearly every mouse has a scroll wheel, and many trackpads support a two-finger scroll gesture. I question whether most people use the scroll arrows at all. Twitter agrees:

Twitter for Mac's scrollbar

So that’s bad, right? Well, not necessarily. If most people don’t use scroll arrows few will miss them (or even notice they’re gone); and given Twitter’s more tech-savvy audience that number is even smaller. For those who do, a complete lack of arrows is probably better than non-standard ones since it’s a clearer difference. The visual design helps too: the scroll thumb retains is distinctive shape to prompt user expectations, but its appearance is notably different from any of Apple’s, providing a cue that this is a different sort of scrollbar as the user switches between apps. The lack of scroll track enhances that further. It’s a risk, but one with justification.

Design is hard. The more of it you take on, the harder it becomes. There’s nothing wrong with custom UI when it’s done well — that is, when you design for current knowledge — but that takes time, effort, and probably testing. Apple, Microsoft, and a number of excellent Web UI frameworks have done that work for us, allowing us to create superb experiences without worrying about the details of how a dropdown works. For many developers that will be good enough; better to focus on solving new problems, perhaps with the occasional custom control when a novel task demands it. If you do create a fully custom UI, go in with your eyes open: get a phenomenal, detail-oriented designer; accept that the UI will require significant effort; and leave time for usability testing. Recognize the trade-off: you’ll get a distinctive brand and carefully-crafted emotional impact, but you’ll invest a lot of resources to get there.

After I left Syncplicity, I ran into the CEO of Dropbox and asked him my burning question: “Why don’t you support multi-folder synchronization?” His answer was classic Dropbox. They built multi-folder support early on and did limited beta testing with it, but they couldn’t get the UI right. It confused people and created too many questions. It was too hard for the average consumer to setup. So it got shelved.

Some tasks have an inherent complexity that even the best design can’t fix. At times they can be implemented as “power user” features, buried enough to stay out of novice users’ way. But when such a feature is in high demand users will find it and their product experiences will suffer.

Multi-folder synchronization is a useful feature. There are workarounds, but by omitting it Dropbox is forcing users to do things the Dropbox way instead of their own. They made an explicit and difficult trade-off: frustrate users a little by making them change their workflows, instead of frustrating them a lot by giving them a confusing experience they’d be guaranteed to use. And it worked out for them.

We often design by identifying user needs, prioritizing them, and then building the best product we can to meet them. This is a great reminder that it’s not that simple.

I have a former colleague who’s infamous for his hatred of every product ever. It’s been known to drive me nuts: he looks at a promising, innovative, life-changing product and trashes it for some random detail.

But maybe…maybe I’m frustrated because I agree with him. He’s the little voice in the back of my head, the sinking feeling in my gut when a detail is out of place. That quiet, agonizing shattering of disbelief when the illusion of a perfect product comes apart.

Friends are often surprised at the anger I direct at Apple, coming as it does from someone in possession of his tenth Mac, third iPhone, and an iPad. Apple comes closer to pixel perfection than most, and that makes the moments when they don’t especially painful…especially when their track record is worsening and no one else has stepped up. I want the perfect product, and I think we can do better than anyone is today.

Pixel perfection is an asymptote. It’s the unattainable dream of a product whose every detail—pixel or otherwise—is flawless in the service of a clear, focused goal. We will never achieve pixel perfection. But we have to try, because the quest is what allows us to innovate, delight, and amaze.

The Good

One of the most powerful advantages of the iPad is its simplicity. Some of that simplicity comes via the App Store: every app is located, installed/uninstalled, and updated via the same route. There’s no need to manage multiple install processes or installations in a filesystem. Apps are vetted by Apple, which (censorship concerns aside) ensures a certain level of quality, stability, and safety. One has to be that much less of a power user to take advantage of the system. That’s great for users who don’t want to become computer geeks, in the same way that one no longer has to be an auto mechanic to own and operate a car.

The Mac App Store brings that to the Mac. Many users will probably get all their software via the App Store, and it’ll make their lives simpler and easier, giving them more power to customize their computers and less frustration managing them. That’s terrific, and probably where computing needs to go in order to maintain its place in people’s lives while reducing frustration and overhead.

The Bad

The App Store will work best when as many vendors as possible use it. A few things may deter them and/or create headaches for consumers:

• Are major vendors like Adobe and Microsoft really going to be comfortable giving Apple 30% of their Mac revenue?
• There is no way to return software to the iOS App store. That’s frustrating but not terrible when you’ve only paid $2.99…but what about when you’ve paid $299? I suppose there’s no reason the app vendor couldn’t process returns, but will Apple give them their $100 back?
• The Mac has a flourishing community of developers and users, and I believe in part that’s driven by communication between them…in turn fueled by pre-release programs. Passionate users beta-test, report bugs, provide feedback, and serve as advocates. The App Store doesn’t permit this.
• The App Store also forbids demo software, so farewell to the 30-day free trial. Combined with Apple’s return policy it’s a perfect storm of “buyer beware.”
• The App Store forbids apps that look similar to existing Apple products. (Technically doesn’t this exclude Firefox, Chrome, Thunderbird, Word, PowerPoint, Excel, AIM, Yahoo! Messenger, most IDEs and text editors, Outlook, and non-QuickTime movie players?)
• The App store forbids apps that modify existing functionality. To quote TUAW, “Well, that just wiped out 90% of the best Mac apps in a single, flaming fist punch.”

Clearly there are some barriers to adoption. Which will make it tempting for Apple to lock down the platform the way it has with iOS and force developers to distribute through the App Store. I don’t think they will: not only might it alienate developers to lose control over their machines, but I’m not even sure one could develop and debug effectively on a locked-down machine. Maybe I’m wrong there…but it feels like developers might be less effective without full access to their machines. (I suppose Apple could sell a special developer Mac, or provide a sanctioned jailbreak.)

My last concern is somewhat nostalgic. As a kid, I sort of fell into computing. (OK, my Dad teaching me BASIC probably helped.) The transition from user to power user to hacker was an easy one because it was all there for me to mess around with. As we get better at hiding the innards of our computers, we also put up barriers to learning the joy of scripting, coding, and hacking at them. Maybe that’s inevitable. Maybe I feel the way my grandfather does about my generation’s general inability to repair their own cars. Or maybe we just need a new HyperCard.

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.

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.

• View and enter tasks quickly and easily, from anywhere.
• Put everything on your mind in your Braindump list. Put near-term tasks in your Now list.
• Set due dates and priorities. Categorize with tags.
• Overdue tasks move automatically to your Now list.
• Work with your tasks in an informative task cloud, color-coded by tag and sized by priority. Sort alphabetically, by date, or by priority.

Try it yourself! Sign up for a free account at http://zirr.us.