The Law of Conservation of Complexity
The next time you are having a big argument about design with fellow team members, and decide to make it a setting so “the user can decide”, STOP!
Any interactive system has a minimum amount of complexity. Either the designer can deal with that complexity, or the user can.
If the designer passes the complexity on to the user in the form of customization and/or settings, the total amount of complexity in the system goes up.
Let’s walk through this:
Let’s say you are a designer arguing with your product manager about a background. You want a gleaming white background, like Apple would do (or Josef MÃ¼ller-Brockmann, if you went to art school) and the product guy wants the corporate blue or something that would give the page a unique look. After days of fighting you sigh, and say “let’s just let the user customize it right? Let them decide? Users love that, think of mail!” and the product manager, in a moment of weakness, agrees.
Here’s why it’s a moment of weakness
1. The PM now gets to spec out the background changer.
2. The designer now gets to design it.
3. The designer now gets to figure out what all the colors/backgrounds will be, and make them.
4. An engineer now has to code the tool. And eventually s/he goes to the PM and says “What is the default background” and the choice still has to be made.
Now you have a feature set that needs to be maintained, updated, potentially looked at by legal, explained by customer service all because you got tired of arguing. And there is a good chance only 2% of the users will actually use it, because most users don’t want to deal with unnecessary decisions, and will just hang with the default.
But if you end up removing this feature that came to life in a moment of weakness, the few that do use it will all write to customer service (and the press) to tell you that you are evil and don’t care about your most valuable customers.
When you hit a point in a conversation where you consider passing on a decision to the end user (for that is what you are really doing) STOP:
1. Is this a decision the user really wants to be making?
2. Is there a good enough default the team can agree on (I can live with?)
3. Is the value of making this a user choice worth the development and support time?
4. Can I live with myself if I make the poor, worn out user who just spend an exhausting day reading tweets and playing farmville figure something out that was my job to figure out in the first place?
Design is deciding. The complexity never goes away. It is your job to deal with it.