Apple Maps: nearby, but not near you — a UX case study
By: Sarah A. K.
Tags: Design, Maps, Case Study, Apple, User Experience

Design Strategy

Before starting, one word about user research

To understand how the users approach the application, I opted for observing them in context. Some contextual questions:

· What are you doing?

· Why do you use Apple Maps?

· What are you trying to do?

· How do you search for restaurants?

· What have you just done? Why?

I adopted a strategy that consists in first, observing how they use Apple Maps in general and then, asking them questions about a specific feature, Nearby in this case.

This allowed me to put myself in their shoes, see the application through their eyes and gain some insights into their behaviour and spontaneous reactions to the system’s response.

Let’s lay the foundation for this concept of Nearby

As a user of Apple Maps myself, one of the things that surprised me is how numerous the actions required to use Nearby based on a location other than mine are. I thought it would be interesting to observe how people handles this feature in context to comfort me in my assumptions.

Even if, generally, such a use of Nearby is quite situational, it is not pleasant to go through such an experience when exposed to. The users need to perform intermediate actions like centering the map on a specific location, adapting the zoom, and so on. Some actions can be repetitive or require them to restart the process from scratch.

A flow representing the actions performed

On top of that, intermediate actions involve high cognitive load and don’t give direct access to any information. Instead, they lead to other actions, which are in fact, the ones to do so.

One thing they have in common is that these actions are all performed directly on the map.

“Is the source of the problem on the map or in the menus?” — I thought

To be sure, I classified the way the users interact with Apple Maps into three approaches, that I called: Confident, Explorer, Old-school.

The three approaches: it was easier to find the pictures than their names

When put into the context of using Nearby with the actions performed, feelings and thoughts expressed, it seems that the old-school approach is the more source of negativity and unnecessary efforts:

I named this: the “Approaches” map

Most of the intermediate actions belong to “old-school”. The feelings become more negative and the thoughts tend to be more question-oriented. I assumed that at this stage, something might be doubtful or not clear to some users, which leads them to think more than necessary.

The source of the problem seems to be more related to the lack of context and explicitness: to address this, the users cope on their own and rely on the actions they are familiar with, based on what is displayed (combination between explorer and confident approach).

To provide a potential solution that improves the Nearby experience without disrupting Apple Maps’ way of working, I set the following objectives as guiding lines:

Minimizing the number of actions in the use of Nearby

Reducing the cognitive load

Giving more context to the actions performed

Let the creativity express itself

For my concept to reach these objectives, I followed my intuition, explored Apple Maps features, checked the Human Interface Guidelines from Apple, asked user feedbacks and of course, sketched, threw away, sketched again… while pursuing further research.

Before searching for places…

Before diving into sketching and wireframing, I thought about how I should proceed to simplify the access to Nearby.

I noticed in Apple Maps that the features are not easily accessible from one to another. Not that it is not a good thing but, in some cases, it can be tedious. For example, reaching Nearby from the menu of a place previously searched requires going back to the search bar and closing at least one menu along the way.

A potential way to overcome this would be to create an access to the Nearby menu from the currently selected place’s one.

A button would be an interesting way to represent this and only requires a simple gesture: Tap.

By adding such a component, the complexity behind the access to Nearby could be reduced.

Only one action to perform from the place’s menu

No need to open a menu, close it and reopen another one.

“Let’s start with a simple button”

Like I said above, Nearby should be reachable directly from the menu of the place on which the search has been performed, be it an address, a restaurant, a hotel, etc.

What if I put this button near the “directions” one?

Seems interesting… but not everywhere. In the case of food places for example, there can be two buttons: one for “reservations” and one for “directions”. So, if “Search Nearby” put there, it would require organizing the buttons in two levels:

The menu would seem crowded and you would likely need to slide down more if you want to consult further information about the place, which causes additional efforts. This would not be better in horizontal mode: in this case, the three buttons would be superposed on each other.

Also, in malls and airports places, since Indoor Maps icons are already placed under the buttons, it would not be relevant to add more components.

Indoor Maps

By the way, I found the way this feature is organized very interesting. Let’s say the menu is the place and the icons are the ones inside. Even in the interface, the concept of places inside another one is respected.

I thought I should do something like that with Nearby. The button should be positioned somewhere near the menu. This leads to…

“A better simple button”

What if I put this button at the top of the menu?

Since the right side is occupied by the weather tag, only the left and the middle ones should be considered.

While searching for solutions, I came across a very interesting post about thumb reachability on iPhone screens and its impact on the mobile experience.

This made me think that the best choice would be the one that allows the users to reach the button the most natural way as possible without nailing the UI. So, I checked with a heatmap how reachability looks like on Apple Maps.

This heatmap version is an adaptation from Thuy Gia Nguyen of the templates created by Scott Hurff

Both sides work well in terms of reachability.

However, if set at the center of the screen, the way the buttons are organized on the map would not look well-balanced. On the right side of the map, you can see they occupy both the top and the bottom extremity. So, it would make sense to set the same organization horizontally to keep a certain visual balance.

I chose to put “Search nearby” on the left, at the opposite of the weather tag.

Concerning left-handed users, even if they do not represent the majority of smartphone users (about 33% according to this post from Steven Hoober), I wanted to take them in account as well to be sure that I made the good decision.

Thumb reachability for left-handed users

You can see that the button is still reachable. One third is still in the safe zone and another third is in the stretch one. This means that it requires slightly more efforts but not at a level that completely nails usability. This did not question my choice to put it on the left. Sometimes, compromises need to be made.

Now about the dimensions of the button, I adapted them so that they fit all the languages of the countries in which Nearby is available.

Time for a small language lesson

I did not want the label to be cut due to the probability for its size to be changed depending on the language set by some users: for example, in French, the label “Rechercher à proximité” (Search nearby) cut to “Rechercher…” (Search) would be misinterpreted.

The button is now placed in a way that respects the concept of nearness in the interface itself: it is accessible at your fingertips and it is “near” the place’s menu.

The button disappears when the map is used

For an optimal visibility when the users interact with the map, the button disappears… and reappears once they have removed their finger from the screen.

“So, let’s tap this button. What happens then?”

Seems familiar…

We arrive on a menu. The title explicitly informs about according to which place the search is performed. I changed the text in the search bar into “Search for places” to give more precision about what can be typed inside.

The line under the search bar has been removed to reduce the frontier between “Nearby” and “Search”, which belong to the same goal, searching. This assumption has been confirmed by the way these two features are presented on the Apple Maps website: they are stated in the same section, unlike Indoor Maps, which has its own. So, I thought it would be relevant to make them more visually related to each other. Moreover, with the title at the top, the interface would have been overloaded.

Also, in the sub-categories (for example, food), I made some small changes on the label specifying in which area the popular places listed are located.

“Popular Near San Francisco” has been replaced by “Popular Near Palace Hotel”

Let’s recap. We have a button, it leads us to a menu to search for nearby places. How about doing so?

Let’s search for places!

When the results are displayed, they are organized both on the map and in the list. It’s also at this moment that the actions causing high cognitive load are likely to be performed.

Basically, they mostly require the users to handle the map. The goal is to better visualize where the place initially selected is located among the results.

An interesting option would be to make more explicit the way they are presented.

Let’s start with the map.

On the map: the badges

The search results and the place initially selected

I thought about making the selected place’s badge still highlighted in the middle of the search results. With this, the users should not have to re-center the map or select places randomly to find the one according to which the search has been performed.

“What if the spots displayed on the map belong to the same category as the place selected before?” — an interested feedback from an insightful user

A simple idea came in my mind: making the icon of the spot initially selected bigger than the others, to make it stand out.

Case in which the search results and the place belong to the same category

To reinforce the contrast and the difference between the spots, I proposed to circle it by a band; I inspired myself from the “My Location” mark:

Screenshot taken from my iPhone

Before you see how this idea fits into the application, let’s have a look at the list.

In the list: staying coherent with the context of the search

Again, I made sure that the menu explicitly shows that the results are located according to a certain place.

I hesitated between:

keeping the search bar then adding a title that specifies the context of the search

and removing it

Should I keep the search bar or remove it for the sake of visibility?

At this stage, the focus is on the results of the search. Their visibility should be optimal for the users to consult them without feeling submerged by too much information.

Moreover, I received a feedback about the search bar which was something like:

“It’s not like I could resume the typing anyway. The suggestions disappear and there are only the results of the list instead.”

So, I came up with removing the search bar and putting the title stating from where the search has been performed instead.

Let’s have a look at the list and how spots from the same category as the place from which the search was performed are represented.

Search of food spots

I chose to reproduce the Indoor Maps feature style: I put the icon of the category to which the places belong before the title to stay true to Apple Maps visual identity. I also wanted to reduce the austerity of the pile of text at the top, for the menu to be more pleasant to see.

Search of Starbucks Coffee shops

In case some users type, for example, the name of a brand in the search bar, the icon becomes the search one instead. The title of the list is surrounded with some quotation marks to present it as a citation, showing that the result comes from something specifically stated by them, and not a category selected among Nearby icons.

Now, to come back to the feedback about the search bar, if some users want to return to the latter, they only need to close the menu. The keyboard automatically deploys itself and allows them to resume their typing. With this, no additional actions are required, and the suggestions that appeared when typing are still visible, unlike the original version.

Before…

Now…

All that being said, let’s have a look at the flow:

A more simplified task flow

It seems less complex than before. No need to guess or estimate the position of the selected place anymore. In comparison with the original flow, this one has less steps, no more decision phases and cognitive load. Also, there are no loops anymore and the actions follow a more precise order.

But it’s too “early” to end this case study now. How about checking search results?

After searching for places, let’s consult them!

Considering criteria selection (popularity, distance, price)

Generally, the users choose the places based on different criteria. Let’s say these places are restaurants. The users can consider the price level ($, $$, $$$), the popularity or the distance to reach them.

“If I plan to eat elsewhere than the restaurant at the university for lunch, I consider the nearest spots to not be late to classes” — a student

The problem is that if they want to choose restaurants based on these criteria, they will likely browse the whole list: even a restaurant at the bottom of the list can fit them. However, Apple made a good job with making it not so long and only focusing on the most relevant spots in the area.

But I was tempted to explore how this can be even more simplified. Here is: “Sort”.

Sort by popularity, distance and price

By default, I made the results sorted by proximity to fit with “Nearby”. With “Sort”, the users can also sort them by popularity and price. If some places have not any price indications or reviews, they are put at the end of the list. In this way, Sort stays available even when some results lack such information.

I assumed it would be more relevant to make it accessible only when the list is fully deployed: to me, there was no point in doing so when only two places of the list are visible. Space is precious and must be saved at all cost.

A problem of address

Another thing is that sometimes, some places are located at the same address.

So, what happens if one of them is the place on which the search results are based?

Places located at the same address

Since the initial place must stay visible whatever happens (the search is based on it), I decided to set it as the “master” of the group. This means that its label is displayed on the map in priority over the other places in the cluster.

The place searched remains the master

Besides this, it works the same as a standard cluster of places: after tapping it, a list is deployed, and the users can select one of them.

Facilitating the visualization of the proximity between two places

The last thing is, usually, when the users consult each result on the map, they tap on each place’s badge. But when they need to know more about how far a search result is situated from the initially selected place (this supposes that they want to know more than the distance between them), they will be confronted to a tough process:

Setting directions between a search result and the place initially searched

It can be even more frustrating knowing that the two places are both visible on the screen.

You will likely say “it’s not common to do so” but let’s say it happens. Can you imagine what the users will go through?

Why not giving them the possibility to visualize it in a simpler way?

A potential solution would be to make the map zoom in and show the route between the current place and the one formerly selected.

But initially, the users could select any places on the map without having to zoom or pan. With this proposal, he would need to accustom to the automatic changes of zoom level when selecting a place, closing the menu, selecting a place, closing the menu, etc. and this can be tiresome when done repetitively.

So, it would be more relevant to give more control to the users for them to adapt the map whenever they need.

Here comes “View”: a mode that allows the users to toggle the view of the route without quitting the menu of the place.

“View” mode activated

At first, I wanted to use a logo to represent the “View” mode.

But after asking feedbacks and researching about this possibility, I came to understand that users are more at ease when confronted to a label that precisely explains the goal of the mode than a logo. So, I came up with the label “View Route” instead.

Activating the mode zooms in the map for the view of the route to be detailed enough. Deactivating it resets the zoom and the view to their initial state.

“View” mode in action

The zoom is set at a level that allows the consultation of other search results, especially the ones located near the currently selected place. When tapping one of them, the map centers automatically to its position and allows the users to consult it without adding much efforts. Also, they can consult the route to places that are not in the results as well.

A good shortcut to check directions

The label of the “directions” button has been changed to a more explicit one for some users to not think that tapping the button leads to the menu of the route highlighted. For this, they can directly tap the route on the screen. Of course, it required me to sacrifice the route duration information under the label.

With such a process, the users do not need to change the starting point which, by default, is their own location, and thus, save them a lot of efforts.

A simplified “directions setting” process

Adapting the whole Nearby feature to these proposals

For consistency purposes, I made the whole feature look the same throughout Apple Maps.

Few visual changes made to Nearby

However, I chose to make “View” exclusive to the consultation of places based on a location other than the users’ one.

Why? Because when based on the users’ position, consulting the route is easy and only requires tapping “directions”. With “View”, the users would get the route displayed, then would tap it to see the details whereas it is already possible to do so in one tap via the classic “directions” button.

Let’s not forget regions in which Nearby is not available

Since the feature is not available everywhere in the world yet, the search bar is the only way to search for nearby places in this case.

Also, I did not verify this, but I assumed that the approach when using the search bar is based on its familiarity to the users and learnability (Confident). Thus, it can be a welcome shortcut to this Nearby concept.

Typing “Starbucks near Palace Hotel” or “Starbucks Palace Hotel” for example would be a quick way to reach the list of Starbucks spots according to the Palace Hotel’s location. For more intuitiveness, I made sure that a suggestion appears under the search bar once the users have typed a word. For example, once they have typed “Starbucks”, a suggestion proposing “Starbucks near ‘name of place in the map’ ” appears. This could be a hint for them to know that such a search can be performed as well.