Say you are developing a desktop application, and you want the user to be able to customize menus, buttons, keymapping, and other commands and components. How much customization should be allowed?

I like my environments to be pretty much infinately customizable. I also want the environment to have a good set of defaults so I can just tweak the settings I need rather than having to set up the whole thing. Does anyone have any user experience to point to to support or contradict my preference?

  • 2
    Not this warrants being a full answer, so it's a comment: if your configuration dialog requires a search box, it's too customizable. For example, Toad, by Quest Software. Oy. – Mark Freedman Jan 24 '11 at 17:15
  • I hope you’re not a Google Chrome developer because if you are, this question deserves to be kicked in the nts (context for the non-initiated: Chrome believes in the philosophy of zero configuraton. I can’t even configure my preferred language. And Chrome infers the *wrong language.) – Konrad Rudolph Jan 24 '11 at 17:52
  • Nope, I'm not. Purely for my own benefit. :) – Michael K Jan 24 '11 at 18:03
  • This question seems better for the User Interfaces SE. – mummey Jan 24 '11 at 18:56

12 Answers 12


keep in mind that every option / customization you add is going to make for a more complex program, which will be both harder to use and to maintain. If it's something only a small percentage of people would use, I would ask if it is worth it.

  • Exactly. Is it worth it to spend 25% of your development time on a feature maybe 5% of your customers will use? Probably not. Is having this extra customizability going to net you any more customers? Again, probably not. – Andrew Arnold Jan 24 '11 at 16:12
  • @GSto, absolutely correct! It is the complexity that kills, and every condition multiplies the possibilities! In other words - 16 independent booleans gives 2^16 different configurations which all needs testing. – user1249 Jan 24 '11 at 16:46
  • 1
    This is what Apple excels in - make decisions and hide the complexity. – user1249 Jan 24 '11 at 16:46
  • @Thorbjorn - absolutely. I can configure way more stuff in Windows but on OS X I generally don't need to because the defaults are all really well thought out. – Jon Hopkins Jan 24 '11 at 16:56
  • @Jeff O - That's a good point. it's not a strictly black and white issue, and it's a hard balance to strike. – GSto Jan 24 '11 at 18:41

When it will make a significant positive difference to the users to allow customisation.

Essentially it's like any other requirement - it needs to justify the cost / effort to implement it. That may be increased productivity or usability, or it may be some level of increased user satisfaction, but there should be some reason for doing it which justifies the effort involved.

As someone who likes customisation, the questions you should ask yourself are:

  • If I were paying, what would I pay for this level of customisation? How many people like me are there? And would that cover the cost of developing it?

  • What do my competitors do? What is the expectation for products in this area?

  • If instead of spending the effort making it customisable I were to expend that effort on other features, which would I prefer? Is this true for typical users?

Remember, everything you choose to implement is really something else you're choosing not to do (at least for now) so everything needs to justify the effort needed.

  • great answer - I was going to put something to this effect in my answer, but then it would start to approach book length and ignored. :) – Wonko the Sane Jan 24 '11 at 16:09

Ask yourself why you want to let the user customise each little thing. Is it to avoid making design decisions yourself, forcing them on the user instead?

Here's a good post by Jeff on the subject: http://www.codinghorror.com/blog/2005/09/the-problem-with-configurability.html

  • 1
    +1 That's why a good set of defaults is important. I would never design something that required the user to configure it; I'm more concerned with how many options should be given. – Michael K Jan 24 '11 at 16:27
  • +1 on referencing Jeff's article. This covers everything I wanted to say about the topic, and also relates well to his point on convention over configuration. – Mark Freedman Jan 24 '11 at 17:11

Users, in general, hate applications that are so poorly thought out that they have to customize to get their needs met. In my experience, most users are not as comfortable using a computer as an IT person and will not customize even when given the option.

If you are customizing in order to avoid doing a proper job of designing, you are customizing too much. If you are customizing because you like customization and not because it is a requirement, you are customizing too much. If you have a genuine requirement to customize, you should still question if it is a good idea and find out the underlying reason why they think they need customization. Often you will find a new requirement they hadn't mentioned if you use a requirement for customization as a place to start a dialogn with the person doing the requirements.


It Depends on the Application

This may sound like a cop-out, but it really isn't (or, at least, isn't meant to be).

The amount of customization should be, in part, dependent on the sophistication of the expected end user. Engineer types are much more likely to get in and tinker with the user settings than, say, my Grandma playing solitaire on a Win98 machine.

It also depends on what the application itself is. If the point of the application is ease-of-use, you don't want to muddy that with a bunch of user-configurable options.

Too many configurable options makes an application seem overly complex. If you create an application that has a lot of these options, I'd at least "hide" them in an "Advanced..." configuration screen or dialog, and only put a subset of things that the average user of that application will want to change on the "regular" options screen.

Another alternative is "skinning" something. That may mean the traditional "skinning" stuff (for example, the "Appearance" tab on Windows Display Properties), or it might mean a set of options that are set all at once (for example, the "Themes" tab on the same dialog).

  • What do you think of an incremental search box and preferences dialog similiar to Eclipse? – Michael K Jan 24 '11 at 16:00
  • @Michael - It may be ok, if your application approaches the complexity and/or audience of Eclipse. Again, Eclipse is primarily an engineering application, and those users expect a more complex and broader range of options. On the other hand, if I was using something like Notepad, I wouldn't want to be bothered with all that. – Wonko the Sane Jan 24 '11 at 16:07
  • @Michael, actually the Eclipse preference dialog HAS an incremental search box! – user1249 Jan 24 '11 at 16:47
  • @Thorbjørn Ravn Andersen: That's why I was using it as an example :) – Michael K Jan 24 '11 at 17:08

I generally don't bother. I've had to work on a lot of different machines, and keeping them all customized would be more of a bother than it appears to be worth. If I do customization on one machine, I'll be annoyed when another machine doesn't have it. Making it easier to move customizations around would help somewhat (consider emacs users and their site-lisp files), but often I'd find that too much bother anyway.

If your app won't work well out of the box, but needs to be customized, you've failed.

I do want my favorite software on a machine, but I don't think that's what you mean by customization.

One issue with customizability is that it's a promise to each and every customer that you have to respect. You send out version A, and your customers customize. All well and good. Now, what do you do with version B? If you break your customers' customizations, they'll be upset, and if you do it more than once, they'll be very reluctant to customize, so you'll be left with customization functionality that very few people use, along with annoyed customers.

This means that you have to pay attention to what customization you've involved with each upgrade. This may give you headaches, when you want to restructure something that should be easy to do, except that it would mess up customizations. You have to pay attention to possible combinations of customizations that could interact badly.


A program is too customizable when any of the following is true:

  1. There are no reasonable out-of-the-box defaults for things. Customizability is a lot more palatable if stuff works reasonably well even if you don't customize it. For example, I hate vi because its out-of-the-box behavior in terms of what the backspace and arrow keys do is so different from the convention on the rest of the machine. I know this can be customized away, but when I walk up to a stock machine it's basically unusable until I waste a bunch of time fiddling.

  2. You've made your program so customizable that its look and feel is effectively different on every machine, Linux distro, etc. and you effectively can't "learn once, use everywhere". Again, see vi.

  3. You've built an inner platform such that the user would be better off just using the outer platform to accomplish what he/she wants. For example, once a text editor or command line text processing tool gets too powerful, it's probably easier to just write a quick-and-dirty, ad-hoc Python script to do the more complex text manipulations than to learn how to do them using the inner platform. Similarly, once a plotting library becomes too powerful, it's probably better to just let the user directly interact with the GUI library it's built on top of to customize the finer details of the plot.

  • 1
    +1 #3 is one I had not considered. – Michael K Jan 24 '11 at 17:26
  • I'm not sure why you use vi as an example. While it works a lot differently from native MS Windows or Mac OSX conventions, it's internally consistent. I've had no problems working on a raw install anywhere. Learn vi as it is, don't customize it, and it'll be usable everywhere, although it sounds like you wouldn't like it anywhere. – David Thornley Jan 24 '11 at 17:52
  • 1
    @David: Ok, but IMHO software that so severely violates such important conventions is basically broken. Also, vi violates the conventions of "modern" Linux software, such as anything written for KDE or Gnome, so it's not just a problem on "non-native" platforms. – dsimcha Jan 24 '11 at 18:10
  • vi is, very definitely, its own thing. The closest thing it has to a native platform thrived a long time ago. It seems to me that either it doesn't need customization or it isn't worth customizing, depending on your point of view. – David Thornley Jan 24 '11 at 20:20
  • 1
    @David: To me, the reasonable thing to do would be to simply make the defaults reasonable in newer versions. If you need backwards compatibility with the vi worked on PDP-11s, then you can configure that yourself. – dsimcha Jan 24 '11 at 21:10

TL;DR: When your application becomes an intimidating framework.

From the application developer's point of view, that's when customization would allow the application to break in such ways that support becomes impossible, either because the user is unable to report how he set up the application or because various settings interactions become too tortuous to make heads or tails. Think the customization system thoroughly and allow for information to get back to you in a meaningful way.

From the application user's point of view, that's when the user feels like setting up the application is daunting, often because it's akin to programming, for a loose definition of "programming" (This includes GUI-oriented programming or Blinkenswitches).

Yes the line is a blur.

Yes sometimes a good code or GUI (re)design can make the application switch board even with the same customizable feature set.

Create a learning curve between "casual", "advanced" and "expert" settings. It could go all the way to providing an API and/or scripting. All users are not starting on an equal foot: a tiered system will make each one feel at home. It can also create a sense of progress and achievement when a beginner switches from "curated" to "advanced".

Good examples in various areas include Firefox (preferences, about:config, userchrome.css&al.), Chrome (basic settings vs "Under the hood"), Mac OS X (pref panes, "defaults(1)", applescript/automator), or even Vim's vimrc. Bad examples include any application whose settings pane feels like a maze. I'm sure you could name half a dozen from the top of your head (unless they traumatized you into forgetting them).


Firefox might be a good example - the user has the ability to customize the UI, and add on different extensions as needed. The core program is not customizable, but the rest is fair game.


When your application breaks too often for your customer's sake or your developer's sanity, you probably have too many.

I'm working with a .NET, SQL Server desktop client server app that allows:

    Custom Tables
    Custom Stored Procs & Views (These can have data modification capabilities as well)
    Creation of custom data sources in the application (Inside or outside the 'live' database)
    Creation of custom grid forms based on custom data source or combining of custom data sources
    Creation of custom reports based on custom data sources
    Creation of custom logic script on data entry fields 
    Customizable data import functionality
    Customizable workflow process data entry and notifications
    Customizable selection and placement of data entry fields/controls on standard forms
    Detailed user security settings to all forms, data CRUD, app functionality and reports

Seriously, this company created a customizable beast. It's designed for a vertical market, but the other implementations could be limitless.

  • I use a project mamangement tool like that and every person who uses it, hates it with a passion. We shouldn't have to customize to add a clientname for instance. Who buys an expensive project managment tool unless they have so many projects that they want to sort of by client? Letting customization dictate database design is a major flaw and will create a poorly performing, hard to use application that users will despise. Anytime someone tries to sell a COTS product with "it is infinitly customizable", I run away as fast as I can because that means the product is ultimately unuseable. – HLGEM Oct 5 '11 at 18:36

I like to design for customisability, but before I get around to implementing it, I would prefer to get everything else really solid. In fact I would probably like to get version 1.0 out the door where it can be handled by users before I started to think about adding user-customisable features.

Before that I just don't know what customisations are going to be useful to my real world users. It may be they're happy with how the interface works and would rather have more features available rather than having enough customisability that they can change the position of buttons or menu items.

I would rather have a really great interface that forces the user's hand a little, than have a lot of customisation going on, but wait an extra six months or year until my application can be released. Shipping is a feature!

The only definite exception to this is that if I am requiring keystroke combinations I would, in most cases, want to make those customisable, because you never know what else a user has running and it would be very irritating to collide with another application in a way that the user could not easily work around.


You could add the most basic and common sense configurations to a menu, so they can be directly tweaked from the user interface. Everything else, that is more complicated you can put into some configuration file or some other means that is accessible from a configuration tool or something.

That way, your most common, unspecialized users have access to the basic configurations they need to use the app, while your more specialized, expert or otherwise more interested users, can use the extra configurations to suit their highly specialized needs.

I think this is the best trade-off between having a user-friendly and highly customizable app. The success of this, though, is how you split the configurations. Which are the important ones, which are just for fancy tweaks? That's the hard part I think. And don't forget to add a reset to defaults button, in case someone messes something up.

Not the answer you're looking for? Browse other questions tagged or ask your own question.