One of the more paining decisions we are faced during development of a product is deciding on default behaviors. Whether it is specific values we need to consider or more generic logic inside our product. again and again I find that choosing defaults are always harder and more time consuming then we expected.

At least from my experience the reason for this is quite simple. Choosing a default is the type of decision that we always try (and told) to avoid:

1. You will always be wrong.

By default ;) there will always be users that will need the exact opposite . And if that’s not enough this will probably be the only feedback that will be arriving (after all only these encounter issues with the defaults)

2. Its almost never based on real knowledge.

At the time of choice we don’t really know what the users need. Gathering this kind information is very time consuming and costly, to the point that I’ve yet to see it happen. At the end we make this decision based on gut feeling or educated guesses at best.

3. Its a hard to change decision.

Changing the defaults will always affect part of the user base. More likely since the first decision was not made using a coin, it will affect a substantial part of them. At the end this means that changing the default will always be substantial.

In short we end with a decision that is always based on partial knowledge (at best) we will always make it wrong (for some users) and it will cost a lot to change it.

i.e. a decision to avoid at all cost (or at least postpone to the far future).

But the real question is how to approach these?

I’m not really sure. What I try to do is:

1) First decide. A decision must be made, and I find it easier to make it after I remind myself that it cant be avoided.

2) Stick with it -  as much as possible, to the point that it become an absurd not to change it. this is also easier done if I constantly remind myself that for every request to change ti there are ten more that will come once it is changed.

3) Be consistent – and this I think is the key point here.  Defaults are constantly challenged. if the default behavior is consistent it will be much easier to explain and defend. if however it is not consistent it will be so much harder to do so and for some reason that will be the exact path the users will go with.

and ill end up with a question:

What practical approaches do you use to decide on the default?

  • Travis Illig

    We do a few things to pick default behavior in our product.

    Our product manager is constantly surveying competition. If there is a general “trend” that can be picked out (a “de facto standard”), we’ll probably go with that. This way, people using the product will have consistency from one product to the next and it’ll make it easier to learn (or switch).

    Where there is no competition or where there is no clear trend, we’ll poll a few key customers and try to ascertain a trend there. You’re right – it can be costly to do a large poll. Sometimes it’s worth the cost. In the case of a tie, the product manager will take a best guess based on instinct and familiarity with the customer base.

    (In the case of UI default behavior, we have a user experience group who helps do user studies and define best practices/defaults.)

    Finally, where there is no way to call it and there’s an equal argument for each option, we’ll generally choose what works best for us and provide the ability to configure a different behavior in some other place. Usually it doesn’t come to this.

    If we have to change a default behavior, there’s a lot of documentation around it, a lot of publicity to alert customers to the change, but we’re not afraid of doing it. Sometimes you have to make that hard decision for a better experience long-term and for new customers.

  • Lior Friedman

    As always thank you for this great feedback.

    question: How much emphasize do you give on “surveying competition”?