Getting Real: The problem with preferences, interface design, and the customer experience

Getting Real: The problem with preferences, interface design, and the customer experience 09 Aug 2005

55 comments Latest by J Miller

At 37signals we’re pretty anti-preference/setting. When we Get Real we try to make informed decisions for the people who use our products so they don’t have to think about preferences or settings or adjustments — they can just use the product and know that the people who built it already thought about the best ways to design it, use it, and view it.

Of course we can’t and don’t want to make every decision, and we do have some preferences here and there, but we really try to avoid them. We see preferences as procrastination — “eh, let the customers worry about it later.” And, yes, from time to time some people complain that the product doesn’t do exactly what they want exactly when they want and exactly how they want, but we can live with a little dissent so long as the vast majority can get down to business without having to tinker.

Building in user-definable preferences and settings also means more software, and we’re all about less software. For every setting you have at least 2 conditions (and often times many more than that). And for every condition you have to present a different interface. Some preferences are small and don’t change the UI much, but when you start combining this preference with that preference your customers will quickly end up seeing a screen you’ve probably never seen. Are you comfortable, as a product developer, delivering a screen you’ve never seen?

And that’s the point I want to make. One of the hidden dangers of highly customized software, and products flush with preferences, is that it becomes very difficult to craft an ideal customer experience. If you have 10-20 preferences, each with a few different options, you can pretty quickly build up hundreds of different display scenarios. And while you can test the software side, it’s exceedingly difficult to test the experience and interface side. Have you ever seen choice 3 of preference 7 combined with choice 1 of preference 12 along with choice 5 of preference 4 and choice 2 of preference 9?

So, be careful when you add preferences. Preferences aren’t free. Each one adds a little more uncertainty to the customer experience you are selling. The goal is to find the balance that best suits you and your customers, but don’t always assume more customer control is the better choice.

55 comments so far (Jump to latest)

Chris 09 Aug 05

I think it depends on the software.

A CMS for example would need lots of options because of the many things it needs to do.

However Basecamp does not because it is designed to do one thing.

JF 09 Aug 05

People use Basecamp to manage client projects, book writing, publications, term papers, classrooms, weddings, home improvement projects, internal brainstorms, and travel. That’s a big one thing. ;)

Paul 09 Aug 05

JF, you must love Windows dialog boxes with multiple rows of tabs.

I also think it depends on the software, but a lot of preference pages/properties pages have a ton of options that are making the entire process way, way more confusing than it has to be. A pretty easy example is Mozilla versus Firefox; the latter has rather simple (or at least, visually simple) prefs versus Mozilla’s.

I think a similar issue is just naming the darn things. In Outlook, for instance, I’ve got Customize, Preferences, and Options (in Preferences!) and I still can’t remember where to set my signature.

you know what I mean.

don’t be a smart arse.

Pisser 09 Aug 05

I could not perform my daily functions in my workhorse applications (Photoshop, Illustrator, Dreamweaver) without preferences.

My devil’s advocate position is that if you can cover all of the functionality of your application without preferences, perhaps it doesn’t do enough.

I’m all for simple but I don’t want 1000 highly focused web based products even if they are well designed and don’t need preferences. It just seems like cluttering my kitchen with single purpose gadgets.

Your software claims to be simple and easy to use but the cognitive load of having to remember each and every one of these small apps (where they live, what they can do, what you have entered into them, have they been paid up etc) is steep and far from simple.

Pisser, what you are talking about aren’t preferences, they are features. Your claim that you have to remember multiple products and what they do isn’t about preferences within the applications, it’s about your preference to have mega apps that solve every problem in one place.

I am talking about features but they relate quite directly to preferences. If your application only has 5 things it can do (features) you don’t need many preferences. I’m not sure you can have a feature rich application without preferences.

Cade Roux 09 Aug 05

A lot of the time JUST having a setting or preference is a feature. Feature meaning a functionality which the user wants, behaving in the way the user wants. If one person wants it one way and another wants it another way, how exactly do you do it without some selection criteria.

Preferences should be limited as much as necessary, but ultimately they cannot be eliminated as they are a product of meeting varying consumer demand (although what they want isn’t always what they need).

A lot of the time JUST having a setting or preference is a feature. Feature meaning a functionality which the user wants, behaving in the way the user wants.

Exactly!

Here is the list of items from the Flickr account page:
Photo Settings
Uploading Tools
Uploading photos by email
Default Photo Privacy
Allowing Downloads
Photo Licensing
Blogging
Uploading photos to your blog by email
Third-party applications
Authentication list
Privacy Settings
Notifications from Flickr
Your privacy
Personal Information
Edit your profile
Tell people a little (or a lot) about yourself.
Create/Change your buddy icon
Change your screen name
Edit your email address
Change your password
Your own Flickr web page

Which are features and which are preferences? Either way they sure do have a lot of them and I think it’s this customization that makes the application successful.

Nick Ragaz 09 Aug 05

The number of features isn’t really the issue.

Features are essentially tasks that you want to perform, and any single task probably has an optimal interface that an attentive developer could deduce for the user without requiring the user explicitly to model her own behaviour. I’d be hard-pressed to think of a task/feature (especially a web-based one) so complex that it would require preferences.

Looking at it this way, there’s no inherent reason why enabling more tasks in an application should necessarily lead to adding preference settings.

With regard to Flickr, I never use any of the preferences— but actually, I’m not aware of any Flickr application customizations. But I do know that Flickr provides lots of ways to enter metadata about myself (or my Flickr persona) and my photo collection, which makes a lot of sense for a site that’s about creating community by sharing photos. Everything listed above — as far as I can see — is directly involved in performing those two tasks, rather than a “preference” for how I use Flickr.

Just but (as I said) only if it needs it.

“One of the hidden dangers of highly customized software, and products flush with preferences, is that it becomes very difficult to craft an ideal customer experience.”

I think it is the opposite. Giving people options is always left out of software and makes it impossible to do what you want it to do so most people go about making there own.

pwb 09 Aug 05

Yes, you could.

The point isn’t to have zero preferences, it’s to create preferences judiciously, understanding that they can add complexity.

Everything listed above � as far as I can see � is directly involved in performing those two tasks, rather than a �preference� for how I use Flickr.

I don’t really want to have a semantic software terminology discussion but this is how I see the difference:

Function:
Restricting view access for uploaded photos

Preference:
Allowing users to define default access for all of their uploaded photos

Brady Joslin 09 Aug 05

@Chris

Interesting part of your point is that 37signals offer an API for Backpack (not sure about the rest). In effect, if you don’t like the interface options, use the API and build your own. Of course, that is considering there is enough value added through the API to warrant the customer sticking around.

Giving people options is always left out of software and makes it impossible to do what you want it to do so most people go about making there own.

Look outside of your world. Most people DO NOT write their own software.

Dan Boland 09 Aug 05

I think my concept of preferences may be different from that of others.

To me a preference is something trivial, like setting a color scheme in Backpack. A preference shouldn’t break the application it’s in, even in conjunction with an infinite number of other preferences, because it’s not something that has the potential to break anything. It’s just plugging in “green” instead of “blue,” for instance. Does that make sense?

What you’re describing, Jason, sounds more like an option to me. I think of options when I think of something that can unlock different possibilities that could very well break in conjunction with other options.

I don’t mean to get caught up in semantics, but that’s just my take. If that doesn’t make sense, sorry, that’s the best I can do to articulate it.

The point isn�t to have zero preferences, it�s to create preferences judiciously, understanding that they can add complexity.

Preferences can add complexity for development team but can also greatly reduce complexity for user.

For example:
Photoshop > Preferences > Units and Rulers allows me to set my default units to pixels. Now every time I create a new document I can immediately start working in my preferred unit

If Photoshop allowed users to switch unit types but did not allow for setting a specific unit as default then my work would be harder and more complex (extra steps to switch units all the time etc)

The worst case is that the developers decide that there is a single best unit for all workers and completely leave out the unit switch function in the name of simplicity and ease of use.

Joe Clark 09 Aug 05

A lot of users with disabilities are simply not going to be able to use your product with the default interface you’ve decided, in your ignorance of their specific needs, is all or most of what they should actually need.

kelly ross 09 Aug 05

Seems like the semantics bit is just avoiding the meat of the post. Anything user defined, features, options, behaviors, tasks, preferences, all add the same complexity in the user outcome (which was the impact of the post). As someone above mentioned, in many cases this is a good thing, despite the likely post deployment hazards.

Generalizations about functionality are fine in a blog post but in applying them requires grounding them in a unique context. The hypothesis assumes infinite time, dollars, and wisdom to craft the perfect, all inclusive interface. But no one can actually do that. Its more powerful a design goal that you could aspire too (and the power of it is the aspiration) but is never practially realized. In the end its about resource constraints and known user needs, and as long as you aren’t being lazy but judiciously using resources to get the best practical benefit, then aren’t you doing a great job?

The lesson I took away from the entry is that if you are going to allow for user or some subset of users configuration options, ascertain whether that is actually a user need. Will the option help the user more than hurt them? Many times its a huge help. There are entire categories of software sold on the concept that is being critiqued (like portals), which seems to emprically invalidate the hypothesis.

Nice blog entry, got me thinking.

Seems like the semantics bit is just avoiding the meat of the post.

Shocking! ;)

Thanks. That’s the point.

Brian Sweeting 09 Aug 05

I think the best thing about your products is that I can start using them with very little setup. I signed up for a new basecamp account today, added some people, added a project, and added the first milestone in under 5 minutes. I also took the time to switch to a different theme and add our company logo, but only because the option was there. If those preferences weren’t there I wouldn’t really have missed them much.

I like that I can use your products for a number of different purposes without the need for setting preferences or configuring the environment. I can use my backpack account for keeping my work-related info organized, but my wife can use it for a shopping list or as a way to organize a family reunion.

I think preferences are things that should come after the product is launched, and only added based on customer feedback.

There are entire categories of software sold on the concept that is being critiqued (like portals), which seems to emprically invalidate the hypothesis.

Shocking! :-|

Do we all get writing (or editorial) credit when this “Getting Real” book hits the shelves?

kingbenny 09 Aug 05

Good discussion. My view is that sometimes a few preferences, like the ones Dan Boland describes, can make an application more personal and more likeable - but when preferences are used to affect fundamental functionality of the software, that quickly becomes a mess.

Wesley Walser 09 Aug 05

I think Pisser is on to something… when is the book coming out?

I’m not sure I follow this. Can you provide an example?

Pisser, if you had to change units in a menu item or some selector would that prevent you from doing your work? Would it slow you down by more than a second or 3 per newly created document?

Randy Peterman 09 Aug 05

A piece of software may or may not be bloatware depending on what preferences are in it and its purpose.

Jason, thanks for stating a principle that is important. Pisser (and others), Jason was not stating a law, making a rule for all developers everywhere, but simply presenting an idea that can help in design to KISS.

I think a preference/setting is a feature.

If Product A lets me change the background colour to “cornflower blue” or “spring green,” that is a feature. That feature is a potential selling point.

If Product B enforces that “battleship grey” is the best background colour for all users, then it lacks a feature that Product A has.

The argument for Product A is that it has more features. The argument for Product B is that is it easier to use, and ease of use is a feature.

The interesting part of this is that the choice (A or B) is, itself, a user preference, there is a market for both. The market for A is developers and power users. The market for B is casual users.

I contend that the key is recognizing your audience. If you�re developing the next Visual Studio or Photoshop, it better have lots of preferences. Something like Basecamp should fall in between, being as it�s for power and casual users alike.

There has been a lot of debate here about the difference between feature, option, preference, setting or configuration.

In any non-trivial piece of software used by a large number of users, you will have people that want to achieve different goals. In some cases, you tune it so that there are actually different features for different goals, and thus there is no set of options which have to be chosen except which feature to use.

In other cases, for a single feature which is USED IN DIFFERENT WAYS like reports or wizards, there are options which will need to be configured by the users on different timescales - once, regularly, every task etc. We have a configurable medical exam in our software. Are all exams the same, no. So the user has to configure the exam. It’s basically a form designer - they design an entire questionnaire right within the software. The time they invest in setting it up directly results in savings as the exam is tuned to the doctor workflow. So it’s one MASSIVE setting.

This, of course, comes from requirements from users.

I believe in asking the user as few questions as possible and achieving their goal with as little effort as possible - letting the computer do what the computer is good at and letting the person do what the person is good at.

Useless settings certainly exist in some software, but software gets big and complex BECAUSE the job it does is sometimes big and complex and dependent on user preferences (on different scales). Settings NEED to be questioned, and their existence SHOULD be justified, but they WILL still proliferate.

Jeremy Curry 09 Aug 05

—Just a note, havent read all the comments, too many!—

I think thats a brilliant observation Jason. The less preferences, the less likely things might break down, and the faster your user get start experiencing your product.

Chuck Norris 09 Aug 05

It is easy to dazzle the world with catchy cliches such as “Getting Real” and whatnot, but come on…

“The goal is to find the balance that best suits you and your customers, but don�t always assume more customer control is the better choice.”

Is this not common sense? I am sure Adobe, Microsoft, and Macromedia have entire teams devoted to finding this “balance”. Of course, you may counter that with another catchy cliche - “thinking small” or whatever it was. It seems you are recycling what is already out there, rewording it, and adding a bunch of links to Basecamp and Backpack.

I am not trying to be harsh or insulting, but this blog has taken on a infomercial/sales pitch atmosphere that was not noticeable a year ago. Do you think we subscribe to this blog because we want to know how Scoble thinks 37signal is the shiznit? Chances are, we already know of Backpack, and Basecamp, and that is why we are here.

I agree with the book comment. You are obviously marketing something.

We’re voicing our opinions and sharing our experience. We also have a business to run. We think we balance it pretty well. And, yes, Getting Real is going to be a book — we say so at the bottom of the Getting Real page. No secrets there.

As far as links to Basecamp and Backpack, there were no such links in this post.

Chuck Norris 10 Aug 05

I reread my post. I sound like a cock faced yuppie, and for that I apologize. By the way, the Basecamp link comment was general, not based on this specific post.

I think Dave Shea acheived the perfect balance between blog and business before his book came out. He made a few posts about the book, his co-author, the process, etc - but was not actively marketing it on his blog (aside from a small pre-order link on the side-navbar, out of the way).

He started and ran a huge resource for the web community. He devoted his own time and money to helping out the industry. His site is largely responsible for getting CSS into the mainstream. I bought his book as a way of saying thanks, as I am sure many other web designers did. If he would of shoved it in my face, I would of been turned off - which is what is happening here.

For some reason, I feel a blog mixed with marketing/advertising is a bad combination. Maybe I am the only one. Anyways, I will stop with my off-topic posts. Good luck with your book.

Paul Thrasher 10 Aug 05

For those that are into adding preferences, what preferences would you like to see added to basecamp?

Carl 10 Aug 05

Come on Paul. 37s has been giving away a ton of really useful information on this blog. Plus they’ve also developed Ruby on Rails and *give it away for free* so other people can leverage 37s’ blood sweat and tears in their own apps.

I for one want to continue to hear from 37s on their real experiences building and servicing the products. This post was 98% about preferences and tough decisions, and 2% about their stuff. I think that’s an acceptable balance.

Mathew Patterson 10 Aug 05

Some good points on both sides (particularly Joe Clark’s mention of disables users - sometimes preferences will be vital to usability). Generally though, surely anybody who has been involved in software design ever will have heard ‘Just add it as a preference!’ about 50,000 times.

Each individual item might be simple to code, but you end up with so many preferences you can’t find the one you need. The point of the post, for me, is to err on the side of restraint and simplicity. Better for most users, better for support.

Michiel 10 Aug 05

While I agree with the complexity issues raised with more preferences; I also wish developers would add an ‘advanced user’ option to unlock all things that you can customize.

I switched away from the Gnome desktop for precisely those reasons: I could not customize the desktop in the fashion that works best for me; instead I was forced into a desktop model that did not work for me.

Ian 10 Aug 05

I think the heart of the matter is this:

Tons of preferences are an indication the developer has lost sight of how the software is actually being used.

In essence, throwing in the towel and ignoring what it is the user is *trying to do*. MDI in Win32 is probably the worst offender. You want to view two documents at the same time? Be prepared for 5 seconds of precise mouse clicking and it’ll still be off by a few pixels. Oh, and you may accidentally lose or close your child window…

Web apps are great because a) my hard drive can crash and I still have my data, and b) the designer isn’t allowed to use MDI.

Louis 10 Aug 05

If you were redesigning the UI for something like Webmin, an app with a zillion prefs that is targeted at a highly technical audience, how would you do it? Does the fact that webmin’s audience is highly technical warrant its design?

Scrivs 10 Aug 05

What makes MovableType and WordPress such a joy to use is that you can customize the living hell out of those applications, but if you wanted to just post a blog entry you can do that quickly and easily.

I’m sure I am talking out of my ass here, but isn’t it easier to add features/preferences to a web-based application when it is run off a database than it would be to do with a desktop application? I kind of assumed the basics of web apps was pulling info from a database and sticking it on a page. If a preference/feature is selected thats just another field in the database you have to query.

This is why Flickr, Yahoo, MT, WordPress and many other applications can add new features without making it harder on the user or developers.

However, while saying this I feel I am missing something. Please correct me if I am wrong here.

Derek Ashauer 10 Aug 05

Do people want preferences? Of course they do. Google, for years, simply had a single search box. However, now you can customize your Google home page to include news, weather, traffic, movies, quote of the day, and bookmarks. A company that is supposed to be dedicated to simply providing the most relevant search results is now looking like Yahoo! Google has the resources to do research and find what the most common features people would use are just offer those features (ala JF ideas). However, they have decided to let the people customize everything. I think the key to their customization is the incredible ease of it all such ass drag ‘n drop placement.

Google has the biggest audience in to code for, however, so they need to be flexible. Does Basecamp need to be as flexible as something Google puts out? No. But as JF pointed out, they do have a wide range of users they need to accomodate. For example, many people are dying for an invoicing feature for Basecamp (myself included), but when you think about their entire userbase it doesn’t make much sense (although, web designers/developers could be the vast majority of their userbase and in that case it may make sense)

I think the 37Signal products have (almost) the right balance of settings/preferences. When I say “settings/preferences”, I mean modifying the application to look/function how I want it to which is not the default way. For example, I can customize the look of my Basecamp to match my company color identity so it integrates that much more.

Settings/preferences should be created based on the userbase. For example, I am currently working on a web-based app where very untechnical people will be using it. My main focus is making the settings as minimal as possible and as easy as possible to manipulate because I won’t have time to field all the ridiculous questions I would see with an app which had a zillion preferences.

Being a tech savvy person, I want the ability to subscribe to an RSS feed, place it under another feed, which is to the right of my movies, which is to the left of the local traffic, etc etc (in reference to Google home page customization). However, if my mom tried to use Google’s customization, it would take her an hour to figure out how to subscribe to an RSS feed in the first place after spending a week trying to figure out what an RSS feed was in the first place.

Moral: you have to develop for your audience, that will dictate what the app needs to do.

Mark Kawano 10 Aug 05

I have to agree with Chuck Norris. I believe the balance between a design/usability blog and a marketing tool is being tipped in the wrong direction. This is certainly the fastest path to alienating your readers

If you’re going to make a bold “heuristic” principle about software design (as some have suggested this is), please add products other than yours in to the equation. Without considering more complex software (designed for multiple users in different countries) your principle is just a basic requirement for specific products.

Instead of stating the already known factor that adding preferences adds complexity, I suggest you say something new. What are your ideas around how to reduce preferences for software other than basecamp? That would make for a useful post and a better way to sell a book.

Anonymous Coward 10 Aug 05

Then leave, Mark. I like it here. I’ve been learning a lot. It’s not 37signals responsibility to enlighten us about everything and every product, they are simply sharing their experiences building what they’ve built. They’re sharing what they know. Right or wrong, that’s for your to decide, but to ask them to provide analysis of other products is putting the burden in the wrong place. 37 doesn’t advertise this site as a public research blog, it’s simply a place to talk about what they know, the things they’ve learned, their mistakes, and their ideas. Nothing more and nothing less.

Gordon Robertson 10 Aug 05

You don’t always have to present preferences to users as preferences. Take for example those dialogs you get which have a checkbox on them labelled “don’t bug me about this again”. That’s a preference, although it doesn’t appear in any prefences form.

Another type of preference is the simple persistence of selections. The point made earlier about using the preferences dialog in PS to change the default units. Another way of approaching that would be to remember the user’s previous selection and use that as a default the next time. I’d say this was still a preference in that it’s user specific, but it doesn’t cause the same combinatorial problems mentioned in the original post. And it provides a more helpfull / responsive UI.

Pete 10 Aug 05

Couldn’t some preferences be just that: user preferences for how the software works?

Like I may not agree with you on how this one aspect of the software works (say… showing aggregated to-dos from Backpack pages), but I would prefer for it to work that way.

Loading software with options can be a slippery slope, but I’d hardly use that as a barometer for how successful the software is to it’s audience.

anon, after re-reading my post. i do sound way too harsh. I too learn from this site. Otherwise I wouldn’t browse it and spend my time giving feedback. i think i just got thrown off by the title “Getting Real: The problem with preferences, interface design, and the customer experience”. I guess I was expecting other insights because of the that.

Dave Davis 12 Aug 05

Many times we are blinded by the status quo. We are used to how things work for us now, and imagine all change as disruptive. In the specific context of web apps, I tend to agree that preferences can be more trouble than they’re worth. There are critical differences between preferences in applications for the web delivery and local apps that make preferences problematic; most obvious is the extra steps and communication involved in setting, then accessing preferences in an environment where one may address the application on any number of machines, at different places and times. There are other, possibly BETTER, ways to handle variables than preferences, especially on the web.

All information has value, yet we often don’t recognize it until after that data is discarded. How a user interacts with a site generates data, and that pattern or approach often implies that users preferences. Respecting, and putting that information to use can go a long way towards eliminating the need for preferences in many cases.

Pisser’s example of photoshop ruler units preference is a good case in point, even though that application is not web based. I’m also a heavy user of this app, and can attest to the benefit of having the feature as a preference. Yet rather than being the best possible solution, this reflects the status quo.

Thinking outside the box, I can see other paradigms that would work better for me personally, and possibly Pisser too. I find that units preferences can change based on the task though. I design CDs, so if I’m working on packaging I prefer picas, while I need pixels for Enhanced content (movies, pictures, etc on a second session). I tend to work on things in batches, so I need one for a long time, then another for awhile, and so on. Today I go to prefs, dig through to set the rule, then work until the next batch and reset. No big deal, but still this is neither intuitive nor optimal.

In my audio DAW many programs change time rules (minutes:seconds, bars:beats, feet:frames etc) with a simple click, or a flick of a pop up. Like Photoshop, you set preferences for the default for what you use most of the time. It doesn’t take much imagination to envision a better system: What if my last-selected option automatically became the default?
The obvious problem with this is that sometimes we choose wierd options we never want to see again. This isn’t hard to get around: a single “save as default” (if you use Digital Performer, this is a very familiar approach) ensures you don’t destroy a key configuration. Many remaining issues can be put to bed by saving previous configurations in a list, wiki style. I’m not suggesting that this is a universal solution to every preference, or even this particular issue. Just that there are other ways to handle things that can be quite elegant, more powerful, and critically, more intuitive for non-coders.

Making the application aware and responsive to HOW users interact, then adjusting the interface accordingly is a more intuitive and natural solution. When I leave my car, the buttons are where I last set them. When I turn on my TV its set to the last channel I watched. This is the pattern with EVERYTHING in our lives other than computers.

Again, I don’t want computers to be exactly like the rest of the world. Things can always be improved. Still I do want them to pay attention, be aware of and responsive to my actions. Greater user-awareness, on the part of any application, leads to better interfaces and less need for many preferences.

-d-

Mark O'Sullivan 16 Aug 05

I recently completed work on my first big open source product, and preferences are one of the big features available to extension authors. I can vouch for the fact that too many settings can be a scary thing. Particularly when trying to track down bugs. I’ve had times when the *only* way to figure out what is wrong is to get a user to take a screenshot so I can see what the user has enabled & disabled.

I have been a fan of the work of 37signals for a number of years, and I certainly appreciate JF’s point of view. I am a paying customer for Basecamp, and I can see how you guys have made decisions for me with regard to preferences. I do, however, find that for me personally there aren’t enough preferences in Basecamp. I find myself often hitting brick walls and getting frustrated, especially as I become more and more accustomed to the application. Which brings me to my point:

I believe that you can never strike the perfect balance for your users. Every user is going to want something different: That is a fact. With my software, I release a base version that has very few bells and whistles. What other developers come up with for it after that is up to them. I’m happy to be putting out a product that is simple to get started with, but I’m even happier that once a user gets used to my application, he/she can then extend it to do whatever he/she wants.

I often find myself wanting this kind of ability in Basecamp, and I secretly hope that you guys will eventually allow those more advanced users to add on extra features and preferences as they want them.

Adrian 17 Aug 05

I should declare a prejudice to start with: I’m an ex-paying Basecamp customer. I left because it didn’t have the (modest) features I needed and didn’t allow me to make minor, but necessary, customisations. OTOH, I own Defensive Design and AWDR and I write Rails. They rule. So I’m not anti-37sigs entirely or even mostly.

The very general point that every preference adds complexity, both to the innards of the software and the user experience, is somewhat stating the obvious. As the original post states, you can (unit) test the software in any number of permutations, but it’s harder or impossible to do that with the UI/UE.

A blanket “just make it an option” approach to design is lazy and harmful. You need to be extremely judicious about:

1. What’s an option to start with, and if so:
2. What the choices are, and:
3. What the default is.

But that doesn’t mean that a system with more preferences is worse than one with fewer. It depends whether the preferences are necessary, well constructed and well defaulted. If they are, they add value for power users without detracting from the UE for average users. If they’re not, everyone suffers.

While remembering the “flashing 12:00” syndrome that most users don’t change settings from the defaults, we should also remember that users that do change settings do so for a reason. Remove their freedom to do this and your software becomes useless to them.

No-one has mentioned that preferences can be grouped together. While in one sense you could argue that this adds another layer of complexity, in practice it really doesn’t. Ship your software with a reasonable number of preset configurations with meaningful names and you give massive flexibility to a wide range of users without making any of them think beyond a single choice. Make those configurations savable/loadable and users can distribute their favourite configurations to others. Popular third-party configs can be distributed with future releases. Wonderful.

JF writes: “Are you comfortable, as a product developer, delivering a screen you�ve never seen?”

Frankly, very comfortable. I would rather agonise over getting the defaults right than lose sleep over the fact that someone’s going to use my software in a way that I haven’t planned for, tested and approved. The entire business of IT is based on serendipity, customisation, hacking, tweaking and beating the hell out of any piece of software or hardware you can lay your hands on. I’ll pay ten times the price for a product that’s well-designed over one that isn’t, but I don’t assume that any designer is or should be omniscient. I do expect them to listen to their users, be responsive, fix bugs and constantly improve their overall designs.

“Well designed”, in my book, means the wise counsel of good defaults combined with the freedom for users to do anything that isn’t obviously, inherently harmful. Designers aren’t relinquishing responsibility by acknowleging that users need freedom and therefore have responsibilities too. If every time Joe User hits his head on the wall it hurts him, it doesn’t mean that there’s a problem with the wall. But if the wall doesn’t need to be there at all, I’d be the first to take it down.

I get a lot of pleasure from shipping systems that “just work” with the default configuration for the majority of users. But I also love it when the power users push the envelope and do bizarre things that I’d never have thought about. You can do both.

Most average users don’t become power users, but all power users start off as average users. I want to keep these people on board. They are the best advocates for the system and usually the unpaid tutors and support staff for most of the average user base. Systems without power users are basically doomed unless you believe that your company can provide 100% of the marketing and support for the whole user base. No company ever can.

You can block specific harmful combinations of preferences without removing the preferences themselves. In some contexts, allowing users to choose foreground and background colours might be necessary. It doesn’t mean you should allow them to set foreground and background to the same colour - or at the very least, without giving them a warning and allowing an easy rollback.

I’ll think long and hard before adding a user option to one of my systems. But when I do add one, I’ll spend the time to get it right. This is how software is improved, not harmed. If the latest release has twenty new options, it may well mean that there are 20% more people who weren’t users that can now use it, or 20% of the current user base that won’t defect once they get to the stage where they ask “but can I do _this_?”

As Joel Spolsky has pointed out, it may well be true that 80% of the users only use 20% of the features. But they all use a _different_ 20%, so you can’t remove 80% of your features and expect many people to be able to use your “lite” system. It just doesn’t work like that. People will either not buy to start with, or defect, from a system as soon as they realise that it doesn’t do a single thing that they need it to. Which is why good software needs to do a whole lot of things that any individual user will never need.

There’s a reason why you can skin Windows Media Player but not Microsoft Word. It’s not because the WMP team are better designers, or worse ones, than the Word team. (Which isn’t to say that either of those products are particularly wonderful.)

More well-designed and necessary preferences (and features) always add value, always, even if you’ve got a million of them. We don’t need less software, we need more software. But as software grows, the design needs to be exponentially better. The spoils will go to the people that can meet that challenge and do it intelligently, rather than do it stupidly, or try to avoid the question entirely by insisting in the face of all experience, that “less is more”.

I’ll get my coat.

Phil 22 Aug 05

I totally agree. Try configuring Opera version 8! Under ‘Tools’ menu it offers ‘Preferences’, ‘Quick Preferences’, ‘Advanced’ and ‘Apperance’ - it’s almost impossible to obtain the same configuration twice.

J Miller 23 Sep 05

The flip-side to preferences giving users configurations that your QA folks couldn’t have foreseen is when the preferences betray a hole in your feature set.

Consider Visual Studio 2005 Team System. Start a new project in C#. Hammer in a method then right-click on it and “Create Unit Tests…” — by default, Visual Studio will offer to create the unit tests in Visual Basic, not C#.

Now, Visual Studio could’ve looked at what it was working on and said “Hey, it’s C# — I bet the tests will be in C#, too!” but it didn’t. Visual Studio could’ve paid attention to when I changed the option presented and said “Hey, the user selected C# tests — I bet this user will usually want tests in C#!” but it didn’t. No. It paid attention to the static “Use VB” option tucked away in its preference file that was oblivious to my actual needs, desires, and usage model.

Overall: Don’t put in a preference where more research into your target markets’ usage model would help you build a better product without it.