Giving users what they need, not what they want.
The 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.
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. ...on February 19th, 2007 at 5:20 pm
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. ...on February 19th, 2007 at 10:54 pm
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/
...on February 20th, 2007 at 12:26 pm