Apple Maps vs Google Maps

  • 7 Jul 22
  • 9 mins read
Apple Maps vs Google MapsApple 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.

As a result, it's estimated that Google lost 300 million IOS users.

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).

Source: justinobeirne.com
Source: justinobeirne.com

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.

5 examples of clever UX

1. Contextualising data

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.

Apple

Article Image

Google

Article Image

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

More impressively, if you then navigate to this destination, Google will proactively notify you that it's closed, before you set off.

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.

Note: it's obviously advantageous to consider this when building dashboards and specific data tools, but it has a broad use for most data points. For instance, Uber showing the driver on a real-time map adds context to their arrival time.

2. More clicks, please

"Taking friction out of processes has been the playbook of Silicon Valley for the last decade or two”

Jason Calacanis

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.

Apple

Article Image

Google

Article Image

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.

But, the avoidable UX mistake was to optimise for simplicity, without the data to operate at that calibre.

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.

    3. Human alternative

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

    • 🚘

      Navigation

      i.e., how to get somewhere.

    • 🚦

      En-route context

      i.e., the fastest way of getting somewhere.

    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.

    Google demonstrates a willingness to use pedestrian paths and shortcuts—ideal for city walkers. By default Apple sticks to the main roads.

    Apple

    Article Image

    Google

    Article Image

    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.

    4. Audio

    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:

    Apple's narration felt considerably better; calming and very human. Google's often felt sporadic and robotic.

    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:

    • ⏱

      1. Journeys may be long

      i.e., you may be listening to this voice for hours.

    • 🤬

      2. It's valuable during intensity

      i.e., you need to listen carefully during the most stressful scenarios.

    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.

    5. Parking

    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.

    But, for some reason, Google can't handle car parks. Instead, it just says I parked on the nearest public road.

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

    Apple

    Article Image

    Google

    Article Image

    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.

    That's the risk of low frequency and high impact moments—when they do occur, things deteriorate quickly.

    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).

    🔥 The biggest UX takeaway from this study:

    Contextualising data is important. Remember that although Apple knew a restaurant was closed, they'd still navigate me there, without warning. Data often requires interpretation, which requires attention and effort, which your user may not have.