I just read an article about choices people are presented with in products, the article Checkboxes that kill your product by Alex Limi is remarkable in that this is something that is so obvious but has not been addressed even today.
You could ask the question “what is the problem with giving the user options?”. It sounds great, there are many ways a program could operate so we come up with a default behaviour and then, if the customer does not like that behaviour, they can change it by changing the option in a settings dialog.
Let’s break this down to the real world
- The first thing is that we (the developer/designer) cannot make up our mind how the software should operate in the first place.
- We defer the decision of the behaviour to the customer, a co-worker used the phrase “burden of interpretation”, adding an option moves the burden to the customer not the developer.
- If we can’t make the decision for the user and we know the code inside out how do we expect the customer to make the decision.
- Having an option increases the number of code paths, hence, increasing complexity.
- Increasing the number of code paths means that you have to conduct much more testing. You are spending time (and money) that could otherwise be spent on new features that your customers would prefer to have.
Most people these days have some sort of smart phone and there are a slew of options hidden in those settings pages, I know that most of them are pretty straight forward and they have those sexy toggle switches (not those ugly check-boxes you get in Windows) but the effect is the same. There are too many of them, if you don’t believe me take stock yourself, without looking at your phone try to name 5 settings, most people have trouble naming 1 or 2.
Here is a real world example, I updated my wife’s iPhone to iOS 7 (bad move, she hates it), anyway, there is a setting that determines how long the phone waits before you have to enter you pass-code in again, well Apple in its wisdom reset this value during the upgrade to immediately rather than using the value that was set before the upgrade. So, on top of her ire of being forced by her husband (me) to use the new OS she has to keep putting her pass-code in. You may ask why doesn’t she just change the setting, well she doesn’t know where the setting is, even if she found the settings icon and loaded the settings page her eyes would glaze over because it is too overwhelming for most people.
How to prevent options spiralling out control
I worked on a medium sized development team and we always had situations where we wanted to add a setting to cater for the old way of doing something or to give the customer a choice (where we couldn’t decide amongst ourselves). This was the modus-operandi for the longest time, what this gave us was a settings page that was littered over a hundred settings in various categories all controlling minute things that only a select few customers (if anyone) was interested in.
The main reason was that we were scared that we would break something and cause our customers grief that would (in turn( result in defects or rework. What was really happening was that we were being lazy or we didn’t have the confidence in our analysis or we did not think things through to their natural end or we were not prepared to put the effort into making it work 100% of the time the new way.
So, I made a decision that I would apply to the next developer who asked to created a setting. I would ask them a simple question, the same as the one above, name me 10 (or so) settings and what they do, most developers could only name a couple (if any). But 10? Isn’t that a lot? Yes it is but we have over a hundred settings in our product, surely a developer should know at least 10% of them (I would say more like 90%). The idea was to put the developer in the position of the customer, I.e.
- How would the customer find out what settings were there?
- Was the documentation adequate for the customer to fully understand what was going to be affected by the change to the setting?
- Are there settings that affect the behaviour of other settings? (really bad)
If you can, don’t …
The approach we (nearly*) ended up using was that we tried to prevent new settings going into the product. We did more analysis, thought things through more, tried to isolate changes so that the new way only affected new stuff etc, where there was a slight chance that the new way would cause problems we added a hidden (registry) setting that was turned on by default. If any customer had an issue we would instruct technical support to turn the setting off, if no one called in with a problem for a couple of releases we would remove the registry setting and remove the old code, if we got a lot of calls then we would reconsider the code. Not perfect but a necessity for a legacy product with many users.
* We started implementing this change but events overtook our best intentions and the team was (in one way or another) disbanded, however, the product does still live on. and no new settings have been introduced 🙂
Remember, software development is hard, we (developers) relish the challenge of making things work and we’ll do literally anything to get the job done. Our customers on the other hand are not so passionate about the bit and pieces, they purchased your software to get a job done, hopefully as quickly and as simply as possible. Giving them 1001 options to give them flexibility that they just don’t want or need just makes their life complication, the opposite of the reason they are using your software.
Just KISS those options goodbye and your customers will thank you.