small refactr logo
At refactr we believe in the value of connection, the utility of agile processes, and the power of great ideas. We are creating the next generation of software for people who expect more from their web applications.
refactr
« Java is not slow! | MNteractive Podcast Profile: Refactr »


Giving users what they need, not what they want.


graphsThe Creating Passionate Users blog is quickly becoming one of my favorite sites. It is posts like this one called How much control should users have? that keep me coming back.

These graphs from the post succinctly illustrate a point that is often difficult to convey to people: user happiness dos not increase as their control over an application increases. It’s the paradox of choice as mentioned in an earlier Refactr post and also The Paradox of Choice by Barry Schwartz “looks at how the overabundance of products today makes buying even toilet paper stressful. We shut down when we’re faced with too many choices, even when those choices are about relatively simple things.

The post touches on a key idea behind configuration options and preference settings in software, Of which I am generally not a fan:

“As user capability (knowledge, skill, expertise) increases, so should control — at least for a lot of things we make, especially software, and especially when we’re aiming not just for satisfied users but potentially passionate users. The big problem is that we make our beginning users suffer just so our advanced users can tweak and tune their configurations, workflow, and output.”

The ideal would be to have a piece of software understand where a user is at in their comfort-level with it and and suggest ways they can improve their experience. However, we have all seen how this has not worked with Microsoft’s annoying paper clip in Word.

Until we get to a point where this is a reality, we should strive to match the amount of pain a user has to endure with payoff a user gets from the feature or feature’s being presented.

As Kathy Sierra puts it: “Putting users first does not necessarily mean putting users in charge.” I would argue that in many cases, giving users preference settings and various customization options is just a lazy way to put the decisions onto the users rather than making it yourself as the software designer/developer. As 37signals would say “make opinionated software“. Your software doesn’t have to be all things to all people, especially when it is better to be a great thing for a few people.

The post is worth checking out for many reasons, not the least of which is the comparison of Apple’s iMovie and Final Cut products and the corresponding graphic depiction of the “canyon of pain” that is gulf between them, in terms of their respective learning curves.

This entry was posted by Ben Edwards on Monday, February 19th, 2007 at 12:51 pm and is filed under Agile Processes, Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Further Discussion (3 Responses so far. Add yours)

  1. Ed Kohler said...
    Great explanation. I think an ideal solution allows programs to open up more features as user’s experience increases. Microsoft Office programs actually do a decent job with this by auto-hiding menus people haven’t used or don’t regularly use. The additional features are there where they’re ready for them.

  2. aaron said...
    Maybe we should all take a queue from guitar hero and add levels of difficulty. “Experts” pull off better tricks, but anyone can rawk, regardless of skill.

  3. Jaan said...
    Good post! You mentioned 37Signals, and I’d like to recommend their excellent book “Getting Real”.

    It’s about saying “goodbye to bloat” and building “simple, focused software that does just what you need and nothing you don’t.”

    http://gettingreal.37signals.com/

Join the Discussion