

Navigation Deficiencies
in Apple Maps


OVERVIEW
Zoomed Out View
Apple created Maps in 2012 in an attempt compete with Google. Unfortunately it fell short in major ways leading to multitudes of updates to even being considered an alternate.
As a former courier and iPhone user, I used it for work as it is the default navigation app. I experienced many frustrations with the tools, and some leading to near wrecks and loss of money due to it’s poor routing. A lack of route control was a focal point of frustration.
I chose this project to solve some of the glaring problems that Maps has. I decided to dive deep into the deficiencies turning my focus on two major flaws: multiple stop route creation and custom add a stop feature.
FIRST IMPRESSIONS
Creating the Route
With two focus points, I wanted to see if maps users felt the same. I looked through 100’s of user reviews, and found merit in my problems, including issues related to driving for work



Maps users expressed lots of frustrations, many involving navigation deficiencies and the inability to fully customize their driving experiences. This quote encompassed the sentiments of my own and many user's frustrations.
"The 'Add a Stop' feature is basically useless. It greatly limits the type of locations you can add, and even for the categories it does give you, it misses TONS of options. If I'm needing to stop at multiple places, it would be nice to add all the locations I want and be shown the most efficient circuit." -AE
LOOKING DEEPER
Navigating the Competition
Obviously Google is the main rival to Apple in the navigation arena, but I felt it was important to search other competitor's features to see how Apple compared. I looked at many mapping applications, and found that all of them had custom route building features. Keeping this scope in mind, I narrowed it down to 3 competitor mapping apps.

Google Maps

Map Quest

Waze

PROBLEM FOCUS
Next Stop Heuristics
To look deeper into the problem, I conducted a heuristic evaluation. During this process I found other issues with Maps that I had roadraged about while narrowly avoiding wrecks. I left them out of my extended research and ultimate problem, but appended them to this completed evaluation to emphasize the lack of care I believe Apple put into this product.

FINDING THE QUESTION
Mapping out the Directions
With my problems starting to come into a justified and clearer view, I began mapping out the framework of my problem. I thought deeply how the user (frustrated courier among others) would benefit from an updated version of the faulty application. Using my own driving experience (now backed with research methodologies) as well as user frustrations, I found a how might we question that I believed encompassed the issues I could solve within the given scope. It started off wordy so I iterated before I found a statement that really resonated with me.
How might I navigate to multiple places without being overcome with roadrage?
....Ok, so that wasn’t it, but I considered it. 😆
How might we allow users to plan their directions more efficiently before going on a trip and
while driving?
To reflect on the initial issue that bogged myself and many other users down, there is an inability to create custom multi stop routes, and specifically while driving. That root frustration is what guided this research and lead me to the framing of my problem.
To help narrow down my problem scope, I created a problem summary to reveal issues to research.

Problem Summary
USER INTERVIEWS
Navigation Thoughts
To gauge the validity of the problem, I interviewed 5 Apple Maps users. My goal was to find out whether users felt in control of custom navigation and the current options provided by Apple. In particular if they felt the add a stop feature and route building options offered enough.
Here are the key insights from the interviews:
1. Users want the ability to add a custom stop that’s not curated for them, which is what Apple currently offers.
While navigating, user expectations are that they have the ability to create their own routes without choice linitations.
“It just feels like I’m only being fed, marketing stuff rather than it’s actually about my route planning.” - NR
2. Users dislike that you can’t build a dynamic route with multiple stops.
The expectations about multi-stop routing mirrored that of add a stop routing.
“There’s no way to add multiple stops.” - NR
“There is no way to add a stop, unless you just cancel the route and redo it again.” - JE
The main message that I took from the user interview and subsequent affinity map was that users felt a limited control of their navigation experience. This strongly resonated with my purpose in this case study to fix Apple Maps. There were multiple complaints about lack of control that I was able to back with user pains and interviews. My case study could not encompass all those issues due to time and scope restraints. Nonetheless, I was building a strong case for fixing a glaring issue and large oversight with this application.

STORY MAP & SKETCHING
Designing a Visual Map
Story Map
In order to better visualize the user flow, I created a Story Map. This enabled me to begin the visual process.

Sketching
When I started sketching, I wasn’t visualizing my solution at the necessary level. I initially tried to redesign the whole process to get to custom route building. After sketching out of scope, I realized that a redesign of the current add a stop process wasn’t necessary. Apple already had that feature, it was just lacking customization. All I needed to do was improve the add a stop feature already in existence.

*I used this to get my ideas flowing




Just to get some flow, I sketched a general route with a new call to action to help me visualize a solution. (*see first image) I used that flow to begin focusing on a more micro level. Using competitor features as influence, I narrowed it down to the image above. I felt it solved the problem with minimal UI additions.
WIREFRAMING & LO-FIDELITY
Finding the Way
I decided to build two sets of screens to use for my prototype. Following my how might we question, the first was for planning a trip before driving, and the second for while driving. I wanted to show the ability to build a multiple stop route before driving, and then show a custom stop added while driving. I felt it was important to show both processes separately in order to isolate the two changes.
Here's a walkthrough of my low-fidelity prototype scenario 1
Here's a walkthrough of my low-fidelity prototype scenario 2
Here were the key test insights:
Tests 1-3 had the majority of questions.
Button placement, hierarchy and purpose confused interviewees, prompting them to ask for scenario and task clarification. Questions about the tasks arose which coincided with button usage and purpose.


Slight Detour
In the excitement of implementing my solution digitally, I lost the scope of my sketched solution and tried to redesign the process for add a stop and custom route building. I added features that I felt were cool and streamlined the process instead of what needed fixing. Fortunately, usability testing evoked questions about call to action purpose and hierarchy of the secondary and tertiary features. Due to time constraints, I was unable to implement those changes in the lo-fi prototype.
So it’s just not the right button. All the functionality is right, and it’s very intuitive, but when you hit that you have multiple options. It should be a different icon that indicates that you’re about to get a few different options. One of them is add a stop. -NR
I talk more about this in the What I Learned section of this case study.
Improving CTAs using Apple standards
100% of users found the call to action buttons to be a little unintuitive. As mentioned in the detour, the placement and usage weren’t consistent with what Apple already had and made the task process somewhat tedious. This was a major point of focus for me moving forward. Though the fix I was making was visually small, it’s effectiveness is highly dependent upon strong call to action features.
Streamlining the navigation experience
100% of testers understood all the scenarios and tasks and felt they were clear enough to emphasize the updated features and CTAs. Users felt the solution solved the problem by adding the functionality that was needed. Some scenario verbiage was too revealing of the necessary clicks needed to move forward. That caused tasks to be easier where they should have been more thought provoking.
I think it's good. I think it's pretty seamless. It feels better than Google in that there isn't a bog in menu options. -EG
Thoughts moving forward
Overall aside from CTA feature adjustments and hierarchy of elements, the solution went over well and solved the problem. 80% of users seamlessly went through the test, with one technical difficulty unrelated to the test script (see Technical Difficulty in the What I Learned section). Time constraints and scope diversion led to UI mistakes and screen inconsistencies. Fortunately there were no major visual issues that caused the scenarios and tasks to not be completed.
HI-FIDELITY
Final Destination
With the usability tests overall garnering good results, I moved into Hi-Fidelity. This process is where I rectified my lo-fi CTA decisions and made the UI feel like an Apple product. Seeing my solution come to life in color brought about some excitement.
Here's a walkthrough of my high-fidelity prototype scenario 1
Here's a walkthrough of my high-fidelity prototype scenario 2
Due to time constraints, I was unable to run hi-fi usability tests. I did however, feel confident in the solution and believed in the UI elemental and functional changes that I made.
WHAT I LEARNED
Parking Lot
If I had more time
With more time I would’ve devoted it more into sketching ideas. I feel I was a bit hasty in my decision making and solution. My desire to come up with a good solution took over the rationale of iteration. I also feel that I could have simplified my sketching process.
I believe I could have done a better job with my prototype. My wireframes fall into that category as well in that they didn't reflect my sketched solution. I did a little too much trial and error with buttons and features during wireframing instead of iterating during sketching. I wish I had solved most of my visual solution via sketching as opposed to wireframing. I believe that my ultimate solution was strong, however my method to get there is not a process I want to normalize.
I wish I had spent more time building more dynamic tasks and scenarios for usability testing. I feel that I could have been a bit more innovative. That being said, the problem I solved and subsequent solution I came up with was well received by my testers. I am proud of the thought process I put into this case study, as it is something that resonated with me strongly.
Technical Difficulties
A technical difficulty came up during my first lo-fi prototype test, requiring me to improvise. My tester was unable open the prototype themselves. Instead of wasting a bunch of time trying to troubleshoot, I opened the prototype and shared my screen. I then controlled the mouse and clicked where my usability tester told me to based on my scenario and tasks. Funny way to run my first ever prototype test, but in the end I was proud of my ability to think quickly and still complete the test on time.
UX Lessons
I rushed into digital screens, and didn’t spend time thinking about the best way forward. I didn’t look at the micro level of the fixes that I was making to Maps. I overthought the solution and caused more work for myself. I am happy that I came to that understanding though, because it really opened my eyes to better practices and being more efficient on the front end. Having to make button changes seems really silly now when an intuitive solution for those functions already existed. The visual needs were micro not macro, and I lost sight of that. In Figma, I didn’t initially use components and that caused some work later down the road when I was touching up the prototype. My Hi-fi screens and prototype strongly called for that work and I learned lots during the rebuilding of those UI elements.
During this case study I learned that not all methodologies need to be applied to the research process. Doing a methodology just to check it off a list is not UX. It doesn't make you look better in your research, it ultimately just wastes time and adds unnecessary fluff too your studies. That time could be utilized on more effective methodologies to prove and back your problem. Fortunately I didn't go down this path very far, I only utilized a couple extra processes that didn't factor into my ultimate solution. That was a good lesson, as it emphasizes a quote my teacher told me. “Work smarter not harder.” That hasn't always been my MO, but it is something I deeply respect and intend to make my method during my future In UX.
Overall takeaways
This case study was fulfilling because it resonates with my daily use of this application. Apple clearly did not care about their user base upon creation of this product. It got a little bit cute with its features, and tried to make things too simple and clean. In the process of doing that, they omitted key and powerful features that ultimately led people away from their product to their largest rival. As of this writing, Apple has made updates to Maps and added custom route building and custom add a stop features. I look forward to seeing their solution as compared to mine, and hope that it fulfills the needs of the frustrated courier/delivery worker or any other user that just wants to go where they desire.