Thinking In Defaults

As a Product Manager at Postlight, I get to help all kinds of partners build amazing digital products. One of the most difficult things I do is help people understand that building great software means starting with defaults and building on top of them.

Everyone from your local Starbucks to Ford Motor Company would have you believe that offering customization is what makes a product successful. Offering a thing is great, but give a user the ability to make it their own and they’ll truly love it.

The Trap

Even for product people, it is easy to deceive ourselves. We love the nooks and crannies of our products, and it’s hard for us to step out of our deep knowledge of the products we build and think of them like the average user does. We gloss over the default views to get into the fun stuff — the enhancements, power features, and settings. And when we do this, we’re doing a disservice to our users.

At Postlight we are often asked to build incredibly complex products and platforms. We may have domain experience, but sometimes we come in fresh faced and ask a ton of questions. We learn the playing field, and in doing so, learn all of the preferences that everyone involved in the product has. John wants users to be able to change the color patterns in case people are color blind. Nancy knows that no two users are going to need the same kind of reporting, so wants to make it as easy as possible to switch reporting structures and layouts. What we quickly realize, in almost all instances, is that nobody is paying attention to defaults.

You see this in the work that appears on places like Dribbble and Behance, and in the product recommendations that proliferate this platform (which, to its credit, has excellent defaults). People love to propose new, edgy ideas that stretch a product to do amazing things. What you never see in these flashy posts are suggestions for better initial table columns, x and y axis, or profile layouts.

How We Think

The approach we take at Postlight is to start at the beginning and work our way outwards. Whether we’re building an entire platform from scratch or simply some new features on top of an existing product, we take in all the thoughts and feature requests and ideas from the Johns and the Nancys and we write them down, often in an area we call the “icebox”. It is certainly tempting to start by sketching out the most complex interaction, thinking that if we can solve the most complex, the less complex items should obviously and easily fall into place. But have you ever tried starting a puzzle from the inside out? Or built a house by crafting your moldings before you’ve even put up drywall? It is, amazingly, easiest to start at the beginning.

We focus narrowly on the one use case that will be most valuable to most users. Understanding that there will be ways for users to adjust, and documenting what those ways are, allows for everyone involved to know that their preferred view will be possible, without requiring us to mock up or build out each unique variation. And most importantly, we draw lines in the sand when customization starts to go wild — not everything should user adjustable, and it is important to recognize that. Users may want to use your app in 26 point font comic sans, but does it truly improve their experience? If you’re familiar with the Jobs-To-Be-Done way of thinking, each customization should allow a user to complete some specific job that they couldn’t do with the default setup.

A Not-So-Far-From-Real-World Scenario

You are building a product to help organize your building/community/neighborhood. You know the general scope of the product — it will enable users to communicate with each other and better know what is happening in the neighborhood.

Thinking about defaults would be figuring out which groups and settings a user should have when they first log in, how a neighborhood message board should function, and how direct messaging should work. User profiles — not the customized version, but the core fields that every user has to fill out — are great defaults to think about.

Avoiding defaults is when you propose a tool for users to add package tracking numbers and alert their neighbors that a package is going to be delivered. Or thinking about how users set up sub-communities. Or creating customized types of messages for the message board: one for announcements, one for birthdays, one for parties, one for sad news, one for introductions, etc.

This may sound like edge cases (and to a certain extent, some of these are), but the difference is important. These aren’t scenarios a user could conceivably do in the product as you’ve made it — these are entirely new actions you’re creating for your users, before you’ve even finished the defaults!

To return to our friends Starbucks and Ford, think again about how they approach customization. A salesperson at both might encourage you to add whip or heated seats, but in neither case has the company ignored the defaults. In fact the opposite is true — both companies spend much time and effort researching, designing, and building their non-customized products. The baseline of any Starbucks drink or Ford car is something that the company is proud of, and that they think will sufficiently meet your needs. Every addition, customization, improvement, or adjustment, is something that will make your life better — but is not fundamentally required.

The next time someone tries to tell you that their customization idea is required to make the product successful, ask them why it isn’t the default state. And if they can’t explain why it isn’t, then it is probably not truly required.

Cody Cowan is a lead product manager and the director of growth and partnerships at Postlight.