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.

This comes at a terrific time. Products like the iPhone are popularizing usable, delightful experiences, and for many the takeaway message is make it spartan. Some point to the Google home page as the perfect user experience because it contains so little. But good design isn’t about simplicity (in the English sense); it’s about context. Fogg’s simplicity framework builds a new concept of simplicity that incorporates context and perception.

Simplicity is the “minimally satisfying solution at the lowest cost.”

It is a function of the user’s scarcest resource at the moment and thus depends on the person and the context. It involves the following factors:

• Time: How long will it take?
• Money: What will it cost?
• Physical Effort: How much must I expend?
• Brain Cycles: How much must I think?
• Social Deviance: How weird will it make me look?
• Novelty: How different is it from what I’m used to?

It may not be intended as a complete design framework, but it is surprisingly comprehensive. Some of my favorite principles fit right in (consistency with expectations, the least effective difference, and a clear visual hierarchy, for instance). It does not, however, include the traditional definition of simplicity anywhere. In other words, while a spartan UI will often be the outcome of applying this framework, it won’t be when the context demands otherwise.

Fogg’s framework does omit delight as a factor. A delightful experience can predispose the user to accepting greater complexity, increasing simplicity through aesthetics. That may mean it belongs in the framework; but it may also belong outside it as a modifier.

Will this framework revolutionize user experience design? Probably not. But it can help designers explain the complexities of simplicity to others, and gives us tool for framing our own decisions and trade-offs.

UIE’s Joshua Porter has a worthwhile article on simplicity, with a discussion of its relationship to purchasing decisions and links to additional opinion.