When Better Design Means Embracing A Worse User Experience

Not long after the iPhone launched 10 years ago, we software makers became convinced that mobile apps, unlike their desktop counterparts, should be inexpensive and single-purpose. This was our chance to make software unburdened by the traditions of the past, which favored shipping new features every year or so to justify the cost of paid upgrades.

The App Store quickly bloomed with gorgeous products that did one thing well, like Twitterrific, Things, and anything from Tapbots — and that’s just starting with the letter T.

But as mobile platforms matured, the most successful apps went the way of their desktop predecessors and developed into large multi-purpose products. Now, apps like Snapchat, Evernote, and WhatsApp are approaching the ranks of Facebook and Salesforce in terms of the functionality they pack. They do this to capture more of their users’ attention, which they can monetize.

Adding more and more features to software can indeed make it more valuable to users, but there are risks. For one, large apps can collapse under their own weight, bloated by features customers don’t use anymore (iTunes, I’m looking at you). Worse, they can become Frankenstein monsters of assembled parts. Both of these lead to user confusion, frustration, and — unless you have an ironclad lock-in strategy — user drop off.

The key to successfully designing large software products is making difficult tradeoffs between the UX of individual features and the product as a whole. Sometimes it even requires embracing a worse UX for a feature so that the product is more consistent overall. I know how this sounds, but stay with me!

At Automatic, we faced this challenge in the development of our new app, which was designed to bring together all the things a driver needs to manage their car — from live vehicle location tracking to good driver insurance discounts.

The new Automatic app launched last summer with over 200 screens and dozens of features, yet customers tell us how much they like its “simplicity”. What’s more, Automatic is at the top of the smart devices heap with a 4.5 star rating on the App Store.

There’s a lot I could share about the design of this app, but the single most useful insight is the power of economical design: expressing the app’s content and functions with as few unique layouts, interface components, and navigation rules as possible.

This might sound like an uncontroversial principle of good design. For most products, economy usually lands somewhere in the middle of the priority stack, but it is rule number one for large apps. This is because a human’s cognitive bandwidth is limited, and with so much content variety in a large app, they can’t afford to squander it parsing unfamiliar interface components.

As an example, here are two versions of the parked and fill ups screens from the development of the Automatic app. Version A uses unique layouts for each feature, while version B uses a common layout.

Screens that share a common layout are understood faster, especially in large apps with many screens.

The screens in version B are clearer because what the user learned looking at one screen is immediately familiar in the other. The effect is compounded the more screens there are in an app.

Designers are usually trained to use or create whatever interface elements they need to best achieve a user goal; they aren’t used to being constrained this way. At Automatic, we helped ourselves resist the temptation to add complexity with this sign posted on the wall.

“A design system only works if its rules are followed. Avoid making exceptions (really!) even if it would improve the user experience. Instead, consider making improvements to the design system itself so the whole app benefits.”

Wait, what?

Am I actually encouraging you to ship a feature with an interface you know could be better for the sake of consistency? Yes.

But before you do, step back and ask yourself three questions:

1. What am I trying to accomplish with this interface?
2. Is something similar being accomplished some other way already?
3. Can I use this approach there instead?

When designing a new feature, consider how it could apply to existing features and visa versa.

Through careful iteration, you’ll likely find a solution that works well in multiple places. It probably won’t be the design you started with, and it probably will never be as good as an interface designed from scratch for a single purpose.

If this process sounds tedious, that’s because it is. Working this way requires painstaking attention to detail. It takes at least three times the effort because you’re reconsidering the design of the app as a whole every time you change or add a feature.

But the effort is worth it because, despite the business need for ever larger apps, we should strive for them to feel as simple as the gems that launched the modern mobile era.