I bet if you take a moment right now and think about it, you can imagine someone who’s over-customizing everything. That person will have a custom layout, custom plugins, and custom features only they know about in what feels like everything they touch. I started on that side because those peoples are often easier to spot in the wild than the opposite. The counterpart of that person would be someone who doesn’t change any settings in anything they touch. Those people use all their apps and devices “as-is” without any form of customization, sometimes not even the password (please do not use default password for anything). Looking into it, it turns out they’re more nuances to this than it seems and both have different hidden cost and commitment you took when you decided to go on that path.
Customization commitment and cost
What exactly could you be committing when you decide to customize something? Time and possibly lots of it, over long periods. The reason for this is relatively simple once you realize it, but because it’s implicit, it’s not always obvious. If you change things to make them your own and build a workflow or habit around it, you implicitly commit to keeping up with the software updates forever to make sure that changes keep working. That commitment will stay until you stop using the software or remove the customization and change your habit or workflow.
That is why the main thing you end up committing this way is your time. You will have to invest time and energy to fulfill that promise you probably didn’t even realize you took when you started to customize things. That investment becomes a lot more apparent and demanding, with software and other devices that often get updated. The more updates and change there is to something, the higher the chance it will break what you changed and require time to repair it.
A good example of that is what I lived through with NixOS; you can read my experience more in-depth here My Experience with NixOS - Part 1: Holy Grail?. NixOS offers a broad and robust set of customization and options to play with. You can create a Linux molded to your needs and requirements, but it’s a lot more work than using a system where most of those decisions are made for you like Ubuntu. It took me a full weekend and close to 2 weeks off and on to get a fully working NixOS as I wanted, whereas it would be a weekend at most for Ubuntu. So why did I decide to go with NixOS? Because customization doesn’t just have cost but some significant upside too.
Customization power
Customizing things can be a very powerful boost for items you use daily or that have high friction. For devices and software you use daily, friction will accumulate surprisingly fast. For example, just 1m of friction four times a day for a year is 24h of lost time. That’s a full day you could have been spending having fun or sleeping or working on something you love instead. That’s a basic example, but if you stop and think about it, I’m sure you can find many things that you do more than four times a day, which has a lot more than 1m of overhead. That formula also scales with the number of times you do something, not just the time it takes. Something you do 30 times a day with only 10 seconds overhead ends up being 30 hours.
You cannot remove that overhead entirely in many cases, but what if you could cut it in half or reduce by a third or more. That is where customization shines most, to cut down friction and make things fit better in your workflow and how you work. In those cases, the time investment upfront for customizing and maintaining the custom parts is below the time you end up saving over time from the reduced friction. That’s where it makes more sense to customize and make something your own when it can reduce or eliminate friction for a reasonable time investment.
Some things also require customization to work at all. Things like note-taking system, productivity system, exercises, health-related systems cannot be just plain default. Items that are very close to you, your body, and your way of thinking require customization to work. In those cases, the best way is to customize it to your default needs, make it work, and then look at the overhead to go from that point into the very optimized territory.
Tyranny of defaults
The other side of this coin is the “tyranny of defaults” where people don’t ever change defaults unless forced to and so end up using whatever the company/developer chose. Contrary to customization, this doesn’t require any time investment, and there’s no commitment to keeping up with updates. That’s because if you don’t change anything, the job of making things continue to work is on the provider, not you. That doesn’t mean there’s no commitment on your part, though, even if you don’t have to commit time.
The commitment instead is that you trust the company behind the product to do what’s best for you by default, and they will keep making right decisions on what’s best for their users. You invest trust in them because if you don’t customize or change anything, you will be using whatever is the defaults, even when it changes.
That also includes changes in the default behavior and settings you might not be aware of since you never changed them. Just as with customization, you could end up with a broken workflow after an update, but you might not realize it until it’s too late. That trust also gives the company behind the product a lot of power over your workflow and user experience. The default user experience needs to be good enough for your use-case and what you want to do with the product. That trust also includes things like security settings, export settings, and interface settings, all of those things can impact when they suddenly change on you. That’s not to say that it is bad or wrong to do so, as there are many times where using plain default is the best way.
Beauty of defaults
There’s some interesting upside to keeping things by default, especially for shared products. If you share something with others, keeping the default will be better since you don’t impose your way of working on others. That is especially true in teams product where everyone needs to use the same workflow and product together. In those cases, if someone customizes the app for themselves, then everyone else needs to do so too and end up committing to work the same way, or they’ll end up with frictions on their side. For that reason, it’s best to keep it default for everyone and keep the time investment and friction equal across the board for everyone.
Using default is also often a good thing for products you don’t use often or that have a long time between uses. If you use some software once every other month, it doesn’t make sense to invest time in customizing it; you will probably forget how you did it and why anyway, making the whole point moot. It’s a lot easier to keep it default in those cases and let the company handle the migration and make sure thing works the same every time you use it.
Another great thing about defaults is in security, where a strong default is often the best design. Most people don’t take time to fiddle with security settings for fear of breaking things or just not knowing; having reasonable defaults here is a powerful thing. That means that if you put the right security settings by default, most users will, in turn, end up with the proper security settings. By the same token, if there’s a problem with the settings, there could be an update to change the default, and most peoples instantly benefit from it. Changing defaults to a higher setting is often the easiest way to increase security across the board for that reason. The reminder of people will often be people who know what they are doing and are probably OK.
