I could probably turn this into a blog post (and will later), but there are a lot of microoptimizations of default settings for B2C apps that make huge differences in conversion:
- Defaults should be almost sufficient to use the app. (i.e. if it has some workflow, you should be able to pretty much hit "Next next next" and get it to work. Bonus points for making the number of nexts as low as possible.)
- Pick something that results in visually impressive output rather than a blank page. See Balsamiq for inspiration here -- they start you with a mockup in progress that demonstrates most of the highlights of the software.
- Ever seen Firefly? I really like how they use the word "shiny". Ideally, your defaults should show the shiny in your app. In Hollywood they have a saying: make sure your budget makes it onto the screen. In B2C apps, make sure the stuff you did all the work on makes it into the user experience most of your users will see.
- Assume your user is a novice at both your software and the problem domain until you have evidence otherwise. A lot of people ask the user "Hey, are you a novice?" That is one way to do things, but it makes your core workflow one stage longer and every stage costs you conversion. I prefer "Assume they are and give them a discrete 'skip ahead' button" or "Assume they are and watch them for evidence that they are not".
- If your app is supposed to make the user feel like they just killed an effing lion, then your default settings better have a lion bound and gagged sitting under a forty-ton weight suspended by a weak string which passes through an open pair of scissors next to a sign saying "Snip this."
- (Do this if nothing else.) Track actual usage of the app and modify your defaults based on actual usage. Bonus points if you can do it dynamically, if that makes sense for your app. For example, if you pick A as the default and 25% of your users go out of their way to change it to B, then that probably should have been B. (You can split test and see how many people would have changed it to A if it had defaulted to B.)
While all of these are true, I find that they usually derive from a simpler rule: Have a laser focus on the users you're trying to reach, and everything you do should make their lives easier in some way.
When I find people breaking these sorts of rules, it's usually because they're thinking of themselves or some non-customer stakeholder.
edited to add a corollary: until you've done the sort of testing patio11 advocates, you don't know who that customer is.
I think what you are saying is good advice, but don't think it is necessarily co-extensive with what I'm suggesting.
For example, say you're targeting teachers. Keeping a laser focus on what teachers want is important. However, I think you need to put extra focus on making their first five minutes absolutely amazing. (And their first 30 seconds. And their first 5 seconds.) My reason for this is simple: almost all apps are going to leak an amazing number of their customers between first and second use. I don't have my report in front of me at the moment, but I think something like 40% of BCC users never complete their first bingo card and never log in again. Essentially none of these people buy the software. On the other hand, roughly 2.4% of trialers convert, or roughly 4% of users who succeed in their first interaction with the app. Increasing my bottom line by 5% requires converting 5% more of that second group -- which, let me tell you, is hard freaking work -- or, in the alternative, improving the first run experience of three out of every 40 users who fail to complete Task #1.
It is really hard to optimize your entire application, user experience, value proposition, etc to get +5% conversion. However, polishing your first five minutes until it freaking shines is not nearly as difficult. Do you present people with a blank page currently? Spend an hour and put something on it. I will put money on that helping. Does it take a critical mass of friends/input/lions slain to get fun? Do the work for them. Fake it if necessary.
And, yeah, instrument everything. Can I plug Mixpanel here? plug Every time I think "You know I should really build more instrumentation into my app..." I remember "Oh, wait, it takes a twentieth of the time to just throw it on Mixpanel -- no visualization code or complicated controls to refine the data range required, praise be."