We tout decicions and not options. We laud people who make it work, simply and efficiently. So how do we decide what the default decisions should be?
I was looking at a new plugin for an affiliate program, and it set up the links based on region. The way this plugin worked, if you don’t have an account specifically for that country, the plugin author had it set to use his ID if the user didn’t enter one. This is a small issue, in that the user may, unwittingly, be letting the dev earn money of their site. It’s also just not permitted. You don’t put up links or ads on someone else’s site without them checking a box to allow it, it’s gauche and against the .ORG guidelines.
Without knowing the issues of the affiliate app, I pushed back, and was surprised that the plugin dev was doing this because if he didn’t, the code would break. The affiliate program didn’t have a fallback to show a default location if you didn’t have an ID for that area, it just errored out. Thankfully, this developer and I worked out a solution. If there was no ID for the region, the plugin wouldn’t display the affiliate links. There was also a checkbox “Use the developer’s affiliate code in regions where you don’t have one!” that explained this would help feed and clothe the dev.
Another example. A plugin made a shortcode to play MP3s, and by default if you don’t have an MP3, it played one of him from his domain. Besides the fact that you’ll crash your server if you get popular enough, the fallback for that should be for the shortcode to output “Oh noes! No MP3 picked!”
This got me thinking about how we determine the defaults for anything. We pick what we want to support most, we guess at what people will use most, and we test what we can think of. But that isn’t easy at all. Start factoring in upgrades. You add a new feature and you want people to use it, so you turn it on to aid discovery (Jetpack does this). Not everyone likes that and gets mad that the first thing they have to do is disable it! So you think about alert boxes “Hey, you upgraded and there’s a new thing!” but then people hate dismissing those alerts.
Picking the right defaults for your intended audience matters. The affiliate code guy knew about an error if he didn’t do that, and compensated in a way that would be seamless for the users, but a little unethical (I felt) because it took advantage of their ignorance to make money for him. I’m kind of hip on educating the masses. The shortcode guy just didn’t think about the long-term ramifications. Neither actually meant to be harmful, but both were thinking about their users and their familiarity with things. Both were cognizant of the fact that a product not working because of incomplete settings should not break.
Determining your default settings is a race between education and simplification. It should be as simple and straightforward as possible to make things easier for the new users. At the same time, it should be made totally obvious in straightforward ways what the defaults can be changed to. This can be done with help screens in your plugins, but also in the welcome pages and the in-line explanations of setup. You can hide aspects of the code from users until they’ve finished pre-requisites.
Defaults are the one place where you have to actually try to know what the users will be thinking, so don’t worry if you get it wrong. You can always iterate.
People judge by how things look. If someone only wears a black turtleneck and jeans (Steve Jobs), we create a specific mindview of them and it rarely changes. Someone who always wears avant-garde clothes that are nearly unwearable (Katy Perry), we create another. If that person always wears a suit jacket (Tim Gunn), we have yet another view. Neither is right or wrong, of course, and they all have their places.
Most of the time, the conversations are mild, a reminder that you actually have to pay, here’s how you pay, off you go. But once in a while you get to hear the tale of someone who wants to cancel an account. This is only interesting because we don’t cancel your account for you. You have to log in and cancel the charges and billing. About once a day, someone asks why we can’t just accept they are who they say they are and close the account, and I hear my coworker explain over and over that it’s not secure. We can’t verify you over the phone, we called you, and… well there’s a reason you have to call your bank and not the other way around.
We can blame GoDaddy and Paypal all we want for this. Should they accept the last four digits of my credit card as identification? Should they accept my social security number? What about my password (which means they can read it, by the way), or what about a special password used only for verification? Now I have to remember more, carry more, and know more all the time. It’s information overload. And because of that, because we’ve complained, they do less.
WordPress doesn’t want to get in the way of your content. It would rather make decisions, not options, to keep it simple. We constantly argue about better ways to simplify, how we can remove options to improve usability, how we can make things easier and faster.
Many of you use smartphones. Many of you buy in-app purchases. Many of you, like me, think that in-app purchases are kind of a terrible thing. Thomas Baekdal goes a step further and argues they 
Therein lies the bane of most development setups. We don’t know what questions to ask much of the time, because we can’t know. We ask everything we can think up, and suffer from the 
There are a lot of smart, complex, questions. You know the ones where it’s “How do I thread my new sewing machine?” Sounds relatively simple and easy, but it’s deceptive. I say this having had to read poor documentation, from 1920, on how you thread a sewing machine. I realized I was smart, but I was inexperienced, so I googled how to thread that specific machine. It was a smart question, but it wasn’t simple. In fact, it was insanely complex, and at a certain point someone in the house wailed “I just want to sew!”