ATLAS // MOBILE APP // SEPT - NOV 2023 (2 MONTHS)
Combining GPS navigation with media platforms for a safer driving experience
TEAM // 4 DESIGNERS
TOOLS // FIGMA & FIGJAM
01 // OVERVIEW
Enhancing the driving experience
Atlas is a mobile app that provides users with a safer driving experience by seamlessly integrating media entertainment with GPS navigation. This project was created for my Interaction Design II course, where we learned about the Lean UX methodology and tailored the process for a classroom setting.
02 // PROBLEM
For drivers of vehicles lacking an infotainment system, accessing their media while driving increases risks for distractions.
Many people rely on either Google or Apple Maps to reach their desired destinations. Several of these drivers also utilize the Apple CarPlay infotainment system, allowing them to simultaneously view their GPS, control their media, and several other functionalities.
For the drivers of vehicles without this comprehensive system, they are forced to constantly switch between their GPS and entertainment of choice while driving, imposing a greater risk for accidents.
How might we bridge the gap between using GPS and accessing media for drivers without an infotainment system?
03 // SOLUTION PREVIEW
Minimalizing driving risks by streamlining the usage of GPS and media entertainment apps.
Atlas bridges the gap between using GPS and accessing media for drivers without an infotainment system by providing users with a way to queue up their favorite songs, podcasts, and audiobooks before their drive, decreasing the risks that come with relying on a phone while driving.
04 // METHODOLOGY
Laying the groundwork
To carry out this project effectively, our team utilized Lean UX, a design methodology that focuses on quicker, more iterative building and testing to create products that are in alignment with users’ needs.
Starting off, our team made assumptions by answering questions derived from the Lean UX Canvas, a tool used to facilitate user-centric conversations on how to frame our work. We followed up on our assumptions by testing them over the course of two 3-week sprints.
05 // SPRINT 1, WEEK 0
Making an educated guess
Since this was a class project with a team of only designers, we had to take on the role as hypothetical stakeholders and brainstorm the business context for our product. With our generated insights, we were then able to formulate our problem statement.
PROBLEM STATEMENT
The current state of navigation apps has focused primarily on giving directions and suggesting locations. What existing products fail to address is the driver’s control over their media. Our product will address this gap by allowing drivers to access media safely while driving.
Our "ideal" users
We assumed our user base would be drivers—particularly younger—who lacked infotainment systems in their vehicles and wanted a way to view directions on their phones without the need to switch out of the GPS app to access and control their media. From this assumption we developed our proto-personas Ashton and Amanda.
What do we need to learn first?
With our Lean UX Canvas now completed, we then created our Sprint 1 backlog. We asked ourselves, “what are the most important things we need to learn first?” Our answer to that was to prioritize the hypotheses that we deemed the riskiest and test them first, in order to mitigate the effects of these possible risks later on.
06 // SPRINT 1, WEEKS 1 & 2
The start of the cycle
With our first sprint in motion, we began to interview participants who we believed aligned with the characteristics of our proto-personas. We conducted three interviews, with the first two solely focusing on the participants’ lifestyles and driving habits. Every two days we participated in stand-up meetings to see where we were at, what needed to be done, and ensure we were all on the same page moving forward.
Testing the first draft
For the 3rd interview, we tested the low-fi wireframes we designed based on patterns we recognized from interviews 1 and 2. We specifically tested the main navigation screen as it would be the app’s core feature. After that, we spent the rest of the two weeks interviewing participants with our iterated designs.
Observing patterns
Alongside every interview, we completed affinity maps with the following question in mind: “What are the most important things we learned from the interview?” With that we produced our findings and uncovered any substantial patterns that would guide us in our design process.
What Sprint 1 showed us
THE GOOD
Progress bar
Many users were in favor of a progress bar for their route, as the visual stimulus added a sense of measurement for the distance of their trip.
THE BAD
Pop-up alert
Users disliked the pop-up alert when trying to leave the app, as it felt even more distracting than leaving the app in the first place.
WHAT TO ADD
Customization
Since there were different versions of the navigation screen with varying arrangements of key UI elements, we chose to implement a screen customization feature that would be tested in Sprint 2.
In retrospect…
To conclude Sprint 1, we held a sprint retrospective, which is a comprehensive meeting used to reflect on how the sprint went. While we wanted to focus on users’ personal experiences with our initial interviews, our main takeaway from the retrospective was that it would have been beneficial to test hi-fi prototypes earlier on to receive more in-depth feedback.
With that in mind, we embarked on our second sprint cycle where we began to flesh out a hi-fi prototype.
07 // SPRINT 2, WEEK 0
Double checking what we thought was true
To kick off this second sprint cycle, we looked back to our Lean UX Canvas to discover any important changes.
Polishing personas
We first reiterated our proto-persona Amanda based on our insights from Sprint 1. Since Amanda is a worried driver, we made the assumption that she would also find frustration in excessive notifications that pop up on her phone while looking at directions.
Using our feedback from our interviewees, we made the decision to add Amanda’s interest for more customization within a navigation app, as well as removed her need to share her media queue.
What did we learn, and what now?
We created another backlog for Sprint 2, as some features from the Sprint 1 backlog— sharing media queue and switching app alert—were invalidated during our previous interviews. This backlog also had new high value features that became the main hypotheses we would need to test, the most important being playlist media tabs that would allow users to switch between playlists on the navigation screen.
08 // SPRINT 2, WEEKS 1 & 2
Upgrading to hi-fi
In preparation for our next round of interviews, we all began to bring the prototype to a hi-fi level. I was tasked with designing the media screens, where users would be able to search through their connected media app libraries and build their queue all within the app.
My main goals when designing the media screens were:
Provide a clear visual distinction between the length of drive versus queue length
Create a swift way to switch between searching media and viewing the queue
Organize the UI elements in a way that clearly distinguishes between media sources, the user’s library, and recommended content.
Testing, testing…
In the next two weeks of Sprint 2, we conducted more interviews to test the hi-fi designs of our prototype that included the features from the Sprint 2 backlog. We also took advantage of these interviews to work out which specific task-flows we wanted to use for usability tests.
Feeling invalidated :/
After a few interviews, we noticed the playlist tabs were causing our participants too much frustration, as they were too small to tap while driving, however if scaled up in size would have obstructed the view of the navigation. The media control buttons were also closely placed together, which interviewees voiced as another concern if they were to use the app while driving. Thus, we redesigned the media bar to improve its ease of use.
Coming full circle
For our next interview, we decided to bring back one of our initial participants as he was similarly aligned with our proto-persona Ashton. We had him go through the prototype by following a series of tasks, which were the most important areas we sought feedback on.
In retrospect (again)…
Similar to Sprint 1, at the end of Sprint 2 we held another sprint retrospective meeting to look back on all we did thus far, as well as what final touches we need to keep in mind for refinement. Our proto-personas also stayed the same as we validated their needs and frustrations during our usability tests.
09 // REFINEMENT
Driving it all home
Once we were finally through with both of our sprint cycles, we had a week to refine our designs using our new findings and overall bring the app to life. To ensure a sleek and harmonious design, we implemented color and text styles, as well as adhered to a relative 8-point grid.
10 // FINAL PRODUCT
Media and maps, all in one.
Driving just isn't the same without music.
Onboarding
Route actions
Settings
11 // CONCLUSION
Lessons I picked up along the way…
Interviewing the right people
Being able to interview people that aligned closely to our proto-personas made validating our assumptions a much more rewarding process.
It’s okay not to be okay, thanks to Lean UX
As someone who has perfectionistic tendencies, engaging in a process as reiterative as Lean UX really opened my eyes to what it means to always be evolving, and not being fixated on getting it all right on the first try.
Putting our heads together
Consistent check-ins with my teammates allowed us to flow seamlessly between tasks, as we were always on the same page regarding the trajectory of our design process.