It’s easy add features to a design or product. It’s really really hard to do that without also making the product more complex. Typically if you plotted the amount of functionality vs interface complexity it would look something like this:
Adding functionality whilst reducing complexity is very very difficult, and often requires some very drastic changes beneath the surface.
Your job as a designer requires you to constantly be fighting a war between adding in features whilst simultaneously improving user experience (sounds like an oxymoron). But whilst we can’t all be Steve Jobs, we can definitely implement some basic design principles that will help us in our struggles between better vs simpler.
In this article we’re going to dive into one key principle that I think can have some very powerful effects on how you approach your design work, especially when you can’t easily simplify — that is the concept of: Default Valid vs Default Invalid.
So what is Default Valid vs Default Invalid? Rather than explaining it, the best way to articulate this concept is to show you an example. Look at these two forms:
These two forms are gathering the same information. They’re both asking you how many pets you have, and what your favourite pet shop is. The difference is that a user filling out the form on the left can essentially continue through the form without changing anything, whilst the form on the right forces the user to enter something in to progress. The one on the left is by default, ‘valid’ while the one of the right is by default ‘invalid’.
“Uhh… okay..? What’s your point?” I hear you saying. Well here’s the key — by making a form default valid, a user is much much more likely to complete it. Even though a user might need to enter in the same amount of content or take the same number of actions, making the form default valid reduces what I like to call ‘mental friction’.
You will notice a big difference in conversion rate by sheer virtue of the fact that the form on the left allows you to progress if you wanted to.
“Wait wait wait..” I now hear you thinking, “doesn’t that mean you’re going to get people entering in the wrong information just so they can skip through it??”. And the answer is:
It probably varies case by case and while I can’t sit here and rightly say that you won’t experience some false positive results, you need to weigh up whether or not you’re willing to deal with a few incorrect ones but have an overall better total completion rate.
But the form above was just meant to help explain the concept - let’s zoom out for a second and think more broadly about default valid vs default invalid. Think about the most successful products on the market and how they implement this type of thinking into their product design.
Take Uber vs taxi companies for example. People like using the Uber app because it’s “simple” or “slick”. Even though at a really basic level, using the Uber app to book a ride is essentially achieving the same result as calling up the taxi company and booking in a taxi. What’s the real reason people like the booking experience of using the Uber app? Why do people feel like ‘it’s just so much better?’.
Are you ready?
I think it’s because the Uber app employs the concept of default valid. By default when you call a taxi company, and ask for a taxi to take you downtown, your request is invalid. It’s invalid because they don’t know where you are. Compare that to the Uber app. When you open the Uber app and put in ‘downtown’ as your destination, your request is default valid. Because the app knows where you are. It’s not forcing you to enter that in before you can proceed with your request. Even if your GPS is tripping balls and thinks your a block over from where you actually are, and you have to move the pin back to where you actually are, it still feels like less work than entering in your current location.
And while that seems kind of obvious from a design and functionality standpoint, I’d wager a guess that you’re looking at some very non-linear impact on user experience.
Let’s take a look at another example:
Here’s the Expedia.com.au flights homepage.
Hmm okay. Looks like there’s some blank fields we need to fill out. What happens if we don’t fill them out and just click ‘Search’?
We can’t proceed. I need to provide at least 4 fields of basic information.
Where we’re flying from Where we’re flying to When we’re leaving When we’re coming back By default, our search request is invalid.
But now let’s have a look at Google Flights:
Interesting. Straight away we notice that it’s detected the current city (Brisbane) and pre-filled the form with that. It’s also pre filled some dates (April 21 to April 25). We haven’t done anything on this page. What happens if we just click ‘Search’ without doing anything else?
Woah. Cool! It let us search even though we hadn’t entered in a destination. Now it’s showing us a map of some possible destinations with prices.
On Expedia, our search was by default invalid. On Google Flights, our search was by default valid. Even though we hadn’t even put in a destination or set any dates yet. By pre-filling as much as they could and allowing my search even though we hadn’t provided all the necessary information yet, our product experience using Google Flights just felt smoother. It felt like there was less of a mental barrier when it came to just getting started.
This is very, very powerful.
When your product or interface is default invalid, subconsciously what you’re saying to your user is “you need to do X amount of work before you can even start using this service”. Compare that to when you take the default valid approach, you’re saying to your user “you don’t need to do anything, you can get started right away! But feel free to customise it to better suit your needs once you’re in.”
Those are two very, very different messages.
Heres one last example.
Have a look at this Kickstarter page.
You can see that we’re not currently signed in. Kickstarter doesn’t know who we are. What happens when we click on ‘Back this project?’
Hmmm okay it didn’t ask us to log in. It took us straight to the pledges page. Let’s click the ‘Make a pledge without a reward’ option.
Huh. Interesting, it’s pre-filled $10 into the field (we didn’t type that in) and set focus to the field in case we want to edit that amount. Let’s hit Continue.
It’s finally asking us to create an account. We’ve been able to get this far without having to enter in anything. And even at this step, it’s allowing us to create a guest account with just an email address and says ‘You can always create an account later if you want.’
When you hear people say stuff like “I don’t know it’s just easier to use”, this is the kind of stuff they’re talking about. Even if they can’t articulate it.
Wait how is “default valid” any different to designing for low barrier to entry? In some ways the two are very similar. There are some nuanced but significant differences however.
We’d consider in the Kickstarter example above, the ability to sign up as a guest as low barrier to entry. You’re designing and creating ways to allow a user to sign up to your product and add the critical information later.
Whereas we’d consider the ability to click through to all the pledge pages and pre-filling the donation amount to be default valid design. You’re still asking for the information (you haven’t removed fields) but you’ve taken a stab at what their answer is or would be. In Google Flight’s case, you let them proceed with the information being actually blank even though it’s a critical piece of information.
So whilst lowering the barrier for entry is removing steps, default valid is leaving the steps there, but creating them in a way that let’s the user through without having to fill in the blanks.
Making your user’s journey through your product as default valid as possible you are removing negative friction, and doing so can have some seriously powerful effects.