Apple Maps vs Google Maps

Apple and Google have been fighting for map dominance for nearly a decade. In 2012, just months after Google Maps first hit one billion users, Apple Maps was set as the default mapping application on IOS.

I often ponder why I typically use Google Maps, given how much I love Apple, and how easy it is to access on my iPhone.

And if one small poll on Twitter is representative, you largely agree.

Breadth of data is the primary differentiator—of which Google has a significant advantage.

For example, I use Street View to quickly contextualise where a destination is, and it has huge broad value, like identifying if there's on-street parking available.

Apple's version, called 'Look Around', is still about a decade behind (in terms of miles driven, which should be positively correlated to availability of the feature).

But assuming that you live in a densely-populated city—where both Apple and Google have similar amounts of data—how do these services compare?

While the issues raised below may be relatively minor, it demonstrates that there is still room for improvement, within two world-class apps.

Let's jump in.

Both Apple and Google know that this burger restaurant is currently closed, and that it opens at 12.00 tomorrow.

But context is the foundation of great UX—not raw data—and Google contextualises this better by also showing you when it next opens.

i.e., you may not be looking for somewhere to eat right now, but instead be keen on eating at this specific location at some point in the future.

Sure, Apple will show you full opening times, but it's hidden behind a scroll and a click.

They'll even let you know if the place is currently open, but is likely to be closed by the time you arrive.

Apple don't do this, despite having the data, and it being obvious how valuable this kind of analysis could be.

The takeaway here—and the insight that Google probably discovered—is that people enjoy the comfort of context. 

i.e., most people prefer being told what the consequences of the data are, not purely the data itself.

As I tweeted in response, it's important to remove the right clicks, not just any click.

For instance, when I search for 'IKEA', I get two very distinct outcomes:

• Google shows me the nearest IKEAs, within roughly 100 miles.
• Apple takes me immediately to the nearest IKEA.

The issue is obvious with the screenshots below: the IKEA that Apple takes me to, is a permanently closed small business.

The problem is partly due to Apple sourcing a lot of data from 3rd parties, like TomTom, some of which is old and defunct. 

i.e., in the short term, they have a major data problem.

In other words: because Apple's data quality is occasionally so poor, they need to add friction back in—by showing the user many results, and letting them select the best option.

I often see start-up founders make similar errors.

e.g., assuming that because Airbnb have a 4-click booking process, they should too—ignoring the fact that Airbnb requires very little introduction or context.

Consider that there are two distinct (but often combined) use cases for mapping apps:

The nuance is that the user may care more about their journey, than the destination.

i.e., show me the fastest route, given the traffic today.

And for that second use case, the quality of the routing is important, because you may already know the area well—and so navigation errors will be noticeable.

To be clear, the issue here is not an unsuitable route, but rather that the lack of these 'obvious-to-a-human' shortcuts can reduce the motivation to use Apple Maps for local journeys.

To illustrate that point, here is the shortcut that Apple would have missed:

It wouldn't need to miss many of these, before local residents concluded that they knew their area better than Apple—or that the value Apple provides to their short trip is net negative.

Audio becomes such an important part of the experience whilst navigating, particularly during stressful situations when your visual attention is required to drive safely.

I'll assume that most of you aren't reading this article whilst merging lanes on a motorway, and so it's important to reframe your empathy for the issue that I'm about to describe. 

Remember: stressful situations usually amplify friction.

What I found was this:

As an example, here's a recording from identical journeys (same starting location, same destination, same route), with Apple Maps and Google Maps respectively:

After transcribing a bunch of identical journeys, I found that Google not only says more (on average, about 14%), but does so without many natural pauses, or human cadence.

Listen to that recording a few times, and you may (if you're like me) start to find Google's narration quite grating and irritating. This is a major dampener on the UX, given that:

It's not immediately obvious how this specific UX issue is transferable to other industries, but it is.

Often the things that go unnoticed during relaxed usage (i.e., testing), become problems in moments of high-intensity. 

From a user testing perspective, Google would likely receive richer feedback by polling users who'd just missed their turning on a motorway, and had some guy in a 1999 Honda Civic swearing at them in their rear view mirror.

Both services (although Google's is turned off by default) will automatically mark where you last parked your car.

Most of the time you won't need, or even notice it. But it's a feature that could provide enormous value in certain situations.

i.e., low frequency, high impact.

i.e., I'm parked in the same place in the screenshots below, but notice where my pin is.

Google must have known where I actually parked—see how my blue 'current location' is correct in both.

And there's something extremely damaging about confidently marking where your car is, when that isn't where your car actually is.

Imagine trying to locate your car at a music festival, following the pin on Google Maps, only to find that it's taken you to a side road near the fields. Not only have you wasted your time, but you still need to find your car.

Product teams often downplay low frequency events, because the probability of it happening is very slim. But the key is to identify which of those rare events lead to outsized horrific (or very annoying) outcomes.

(i.e., very similar to 'Black Swan' events in finance).

If you search for a specific coffee shop, you'll be shown results from all over the world.

(I've added the darker sidebar with flags, to demonstrate my point).

And although showing results in other countries first (I'm in the U.K.), can be frustrating at times, simply sorting by location wouldn't be without flaws.

There has to be some weighting for popularity. For instance, to stop the Statue of Liberty getting buried below random businesses and shops with a similar name—but that happen to be closer.

At a glance, "18 mi" and "1800 S" are very similar. 

The lack of distinction increases the 🧠 Cognitive Load to glance down the list, and digest the meta data.

There's no obvious (and flawless) solution here. In fact, it's an awkward use of components that feels messy.

But, as an example, adding a subtle background to the 'miles' helps anchor the eye—drawing your attention to regularity (and irregularity).

If you challenged yourself to look at the address of the second item in the list above, over and over, you'll probably notice that once you understand the pattern, it's far more efficient.

That doesn't automatically make it the right design choice, but it demonstrates the issue with the status quo.