Offending Experts and Pleasing Everybody

An audio recording of my talk at Carson Systems’s Future of Web Apps conference has been posted online, so those interested in what I had to say but who couldn’t make it to the conference can now have a listen.

For myself, I’m pretty sure I’ll never plop it onto my iPod, as I hate hearing recordings of my voice. This probably runs counter to my interest in continually improving as a public speaker; it would do me some good to sit down and hear all my gaffes, my stuttering and my aimless diction. But I already subject myself to plenty of discomforts in the name of self-improvement, so this is one I’m just going to forgo for the time being.

I don’t mean to discourage you from listening to it, though. Several people told me my performance was ‘not all that bad’ and ‘definitely less painful than watching the slaughter of kittens.’ Go hear for yourself!

On a less disingenuously self-deprecating note, I wanted to share here a visual illustration of one of the things I mentioned in my talk. The idea is that, as interaction designers, we of course don’t want to offend any segment of the user base. But if you’re going to offend anyone, it should be experts and not beginners or intermediates.

Features, Usage and Users

When discussing features on design and development teams, I have occasionally heard the sentiment that, “We don’t want to remove that feature, because power users really need that.”

My take is often that, no they actually don’t, and the reason is that a product that’s been designed to beautifully map to the needs of a beginner or intermediate is very likely to delight an expert, too.

It’s become a cliché to cite the iPod for this, but it’s true that that device is a beginner- and intermediate-focused product that experts nevertheless find completely engaging. I would also cite Nintendo’s Wii gaming system, which is so well geared towards those with negligible gaming skills that even I bought one. And outside of the hardware world, there’s the case of Google’s minimalistic home page, 37signals’ Basecamp, and more recently, Twitter, which has virtually no affordances aimed at experts.

On the other hand, products designed to map closely to the needs of experts are often turn-offs to beginners and intermediates. Users who come across features that reveal not just the complexity but also the specificity that experts need often quickly decide, “This isn’t for me.” Rarely will a beginner find herself delighted as to how well a product has been designed to map to a skillset she doesn’t yet have.

It’s not just this emotional reaction that leads me to favor those with less experience over those with more. It’s this chart, taken from Alan Cooper’s immensely helpful book, “About Face 2.0,” which shows the distribution of users across expertise levels — as in, where are the most users?

Distribution of Users Across Levels of Expertise

When I saw this, it inspire me to doodle a similar visualization that shows how feature usage is distributed across the spectrum of users’ expertise levels. That is, who uses the most features in a given product? By and large, beginners and intermediates use relatively few, and experts often come close to using the full complement of a product’s features.

Distribution of Features Usage Across Levels of Expertise

If you lay the two graphs on top of one another, you get a not particularly scientific but fairly instructive idea of where the sweet spot lies.

Sweet Spot for Feature Design and Development

That purple overlap area is where I’d say that the majority of design and development effort should be focused: on features that will be used primarily by beginners and intermediates, and not so much on experts. You’ll notice that as a distribution of features, this visualization still tends to skew to the right edge of the expertise axis; a greater number of features will always benefit those with more experience, it’s true, but the fall-off point is key. In my experience, it’s not necessary to continue to climb that curve of feature quantity all the way to the far top, right. Just design and build the features that most people need.

+
  1. Your explanations reflect my daily work experience in developing web platforms. The question for me is more, how can a client be convinced that this is the best way to go. This is a constant struggle in my 10 years of work experience.

    Best wishes from Austria

    P.s.: First post here. I attended your workshop at the FOWA and was very inspired by your presentation.

  2. Your presentation at FOWA is really interesting. I don’t know if you can tell me this but I would like to know what programming language is used in the (custom I suppose) web framework developed at NYT. Moreover I wonder if this language is embedded in the html templates or you use a different template language (more simple to understand for design guys). Thanks.

  3. “My take is often that, no they actually don’t, and the reason is that a product that’s been designed to beautifully map to the needs of a beginner or intermediate is very likely to delight an expert, too.”

    True. But why should you choose to have things one way or the other – can’t you have both, with advanced features available to the advanced users while still maintaining a simple front that pleases the novices?

  4. Interesting talk, and enjoyable to listen to.

    To bad the slides could not be shown along with the audio. But it is good enough.

  5. You could of course also add the whole approach of Apple to technology and interface design.

    I see the way technology systems need to go as akin to how you experience playing say a RPG game on your Console – you start with clothes and a basic woodern stick and work your way up to aquiring more and more skills and armour and weaponry that builds up around you as your experience grows.

    Just look at the way Adobe overloads all their CS software with millions of palettes, doo-dads and effects, Totally overwheling to any student or newbie. And also dangerous in many cases. At the very leasy you should be able to strip these features away, or add them in stages as you require them.

    An ‘experience timeline’ needs to be incorporated into software and interface design.

  6. I also rather enjoyed your talk at FOWA. It was, in fact, how I managed to swing the entrance from my boss.

    This is a very good premise to work on when designing something in the public domain, but how about something where all your users very rapidly become experts? Call centre software, say, where they get an initial training period and then use it intensely, 8 hours a day? The premise of simplicity clearly still stands, but offending the experts would not be such a good plan!

  7. Khoi,

    I’ve been desperately trying to take this approach in the Computer Art lab I manage. I’m doing my best to actually limit the features of our lab, which in my case means taking some stuff away, as I’m in the somewhat tricky position of reverse designing our lab. Bernd’s comment reflects my problem as well: How do I convince the users and my bosses that just because they can have something, does not necessarily mean that they should? It’s a tough sell. People do better with limited options, but they tend to think they want endless ones.

    -systemsboy

  8. An interesting aspect of many applications is the use of an API to allow more features or functionality, this may appease the desires of ‘power users’ to get more out of it!

    Twitter is a good example of this, it’s easy to use for it’s normal function but if you want you can get your hands dirty with the API and start to integrate it into other applications. But that functionality doesn’t come at any cost to the beginner or intermediate user.

    I guess the same could be said of the iPod by installing iPodLinux on it I suppose too!

Thank you! Your remarks have been sent to Khoi.