Skip to main content

The Fault in Defaults

Defaults should work for a broad category of customers and ensure their privacy and security. Customers trust your judgment, make your product worthy of that trust.


Defaults should work for a broad category of customers and ensure their privacy and security. Customers trust your judgment, make your product worthy of that trust.


We have all been burned with bad defaults at some point while using software. Malicious defaults deserve a separate post, this post assumes good intent.

After learning programming as a kid, my first customers were my parents who needed a program to help them manage and run a print magazine with < 5000 subscribers. It was a Visual Basic 6 application that automated most of the manual paperwork that my mother had volunteered to do.

Working on that project as a hobby, rewriting it from scratch more than 20 times over a period of five years to reduce human decisions taught me a valuable lesson that I carry with me:

Your customers trust your judgment when they see example values for a field.


Imagine buying a lopsided hammer that randomly aims for your thumb, unless you add a counterweight. Sounds absurd, right? And yet many software tools provide contrived examples in their documentation and confusing defaults in apps.

I find it useful to pause and ask myself, "Why are you building what you are building?" at the end of every milestone. If I can answer it honestly and feel content, I continue. In the broadest sense, I am okay with building tools that help people do their thing with less energy, time or money, even if only a handful folks use it.

You may want to separate defaults based on cost, performance or any other parameters that are relevant to your product. Help users express their intents and budgets, tune accordingly.

A tool must do what most people expect it to do, without surprises.

Security & Privacy

Making web-applications on and off over the past two decades has made the importance of securing my servers and machines that access them quite clear. I have learned to treat claims of "100% secure" with a bowl of salt.

Security is not a set-and-forget switch, it is a constant arms-race against human and automated threats. Privacy is not merely a token phrase, lives are disrupted by private data inadvertently landing in malicious hands.

Protection through multiple layers of isolation, and privacy through not storing data that is not required for providing services expected by customers makes most sense for the long run.

Just as one protects their own business against irrelevancy and direct threats, I see no reason to skimp on providing the same protection to customers and their data.

Building a moat around your business is good, also building moats to secure your customers's interests is better.

Good defaults make it easier and less stressful for your customers to use your tools, get their work done and move on to other matters.

Talk to potential customers, understand where your tools fit in with their workflows, then design to accommodate at least three workflows.

Do not be tempted to gamify a tool without purpose, beware of incentives that you choose to put in. With something as simple as default values in fields, you have the power of suggestion, use it to help customers make decisions beneficial to them.

Empathy goes a long way; tools that earn a customer's trust tend to remain in the toolbox longer.