520 or 90 is an app that helps Seattle drivers decide whether to take the 520 or 90 bridge by calculating time and cost. The first screen you see is simple. When we tested it, people knew how to use it. Looking at it, it seems pretty obvious that it should be designed this way, right?
Well, it definitely wasn’t at first. Simple solutions are almost always obvious once you see them. That’s why it’s so easy to take them for granted. But take a look at some of our earlier design concepts – some of which, frankly, I’m a little embarrassed about.
When we first thought about 520 or 90, we had this grand map idea in our head. That’s how existing solutions work, after all.
The Map Design
Okay, where do I start with the usability problems we found with this. For most people that we first tested this on, it actually went OK. But if you look deeper, the design had a bunch of holes:
- What if someone makes their start and end taps on the same side of the water? Then they wouldn’t be crossing the bridge, which is the whole point of the app. We’d have to throw up some rude error message, or figure out how to disable half the map when it came time to make the second tap.
- Some people tapped on the 520 and 90 blue circles, expecting us to give a recommendation about the bridge.
- Some people wondered why the map wasn’t showing the current traffic on the roads.
- Then there’s the fat finger problem – users are not going to be completely accurate with their taps, and you shouldn’t expect them to. So, we’d have to provide some way to start over if people screwed up their tap. Meh.
The Quadrant Map Design
So we came up with an idea to solve the fat finger problem: divide the map into quadrants! Then the user just has to hit a region. You think this would test well?
It didn’t. It was horribly confusing. Once we finally abandoned our grand map vision, we tried a list.
The List Design
This one tested decently. People understood how to use it. But, look at it. It’s so cluttered. In good design, what isn’t there is just as important as what is.
Okay, so how about a less cluttered design? We wondered whether people would get the “enter a zip code” method:
The Zip Code Design
They didn’t. Not only is it a bunch of extra annoying taps to enter in a number, people don’t always know the zip code of where they’re coming from or going to, and it’s a rude design to expect them to.
The Final Design
In the end, we combined the best parts of the list view with the best parts of the zip code method.
Here’s the super rough mockup:
With some photoshopping, you get what’s in the app today:
The asked-for feature that we cut
There’s another feature we were considering for this screen. One that is frequently suggested to us by people we show the app to: location awareness.
Unfortunately, location detection is not instantaneous. It takes the phone a couple seconds. What if the user had selected one thing, and the GPS detected another? Would we just replace their selection without asking? Or pop up an error message asking which one they wanted to use? Yuck.
You know what’s not obvious? Cutting a feature because you just couldn’t get the UI right. But it’s exactly what we did. (It’s also what Dropbox did, and that’s why there’s only one dropbox folder.)
It wasn’t easy to make this call. As engineers, we’re naturally inclined to want to come up with smart solutions that take advantage of the latest technology. It kind of bruised our egos a bit, as if we were somehow now technically inferior for not using location awareness. But, our number one goal was to create a simple design. So, at least for this release, we cut it.
Related post: How we picked the logo for 520 or 90