How to add product features without making it more complex
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.
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.
Default valid vs default invalid
In this article I’m 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? I think 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:
Maybe.
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 I need to fill out. What happens if I don’t fill them out and just click ‘Search’?
I can’t proceed. I need to provide at least 4 fields of basic information.
- Where I’m flying from
- Where I’m flying to
- When I’m leaving
- When I’m coming back
By default, my search request is invalid. Okay makes sense I suppose.
But now let’s have a look at Google Flights:
Interesting. Straight away I notice that it’s detected my current city (Brisbane) and pre-filled the form with that. It’s also pre filled some dates (April 21 to April 25). I haven’t done anything on this page. What happens if I just click ‘Search’ without doing anything else?
Woah. Cool! It let me search even though I hadn’t entered in a destination. Now it’s showing me a map of some possible destinations with prices.
On Expedia, my search was by default invalid. On Google Flights, my search was by default valid. Even though I 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 I hadn’t provided all the necessary information yet, my 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 I’m not currently signed in. Kickstarter doesn’t know who I am. What happens when I click on ‘Back this project?’
Hmmm okay it didn’t ask me to log in. It took me 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 (I didn’t type that in) and set focus to the field in case I want to edit that amount. Let’s hit Continue.
It’s finally asking me to create an account. I’ve been able to get this far without having to enter in anything. And even at this step, it’s allowing me 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.
I’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 I’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.
Okay but does it actually deliver better results?
Here’s an example with some numbers for comparison from our own product, Askable, which is a platform that lets UX designers recruit people for in-person ux testing.
Originally when we launched the product every user had to enter in a booking name. That was mandatory field and they weren’t able to proceed with their booking until they entered in that info.
We noticed a ton of drop off at that first step, where users would sign up but bail out before going on to audience and demographics selection. We ran this version all throughout February. In the end it converted at 1.7% (unique users to the product to users who completed and paid for a booking).
We decided to add a default booking title to our March release, which you could edit if you wanted to.
That was the only change we made on this part of the product (most of the other changes were back-end stuff). The conversion rate for this version ended up being 13.3%. That’s nearly an 8x better result, just by changing one thing. By making as much of the booking default valid as possible, we were able to get a much much better result.
Thinking about ‘default valid’ in your own projects
- What other products can you think of that implement this kind of design logic? How do you think it impacts it’s users?
- Are there opportunities for you to implement this in your own projects?
- Is absolute accuracy and up-front user information more important for you or is higher conversion rates / product adoption?
- If you’re lacking user-supplied information, what ways can you infer that through other means (device metrics, estimates from existing data, machine learning predictive algorithms)?
- What’s the quickest and simplest way to A/B test this against the current version?
