A Better Solution to Media Access For Drivers

ATLAS APP DESIGN

Sept - Nov 2023

TIMELINE

TOOLS

Figma, FigJam, Teams

ROLE

Scrum Master, User Experience Designer & Researcher

Overview

Navigation App For Easier Media Access While Driving


Atlas is an iOS mobile prototype designed to help drivers have easier and safer access to media while ensuring uninterrupted navigation from their phones.

In my Interaction Design II class in the fall of 2023, I was chosen to be a team lead for our semester project. I led three other students through the Lean UX design approach to craft an application that seamlessly intertwines navigation and media functionalities. Through this strategic approach, our collective efforts materialized into a cohesive digital solution.

Problem

Accessing Media While Driving Poses Problems


Countless people routinely listen to music and utilize GPS navigation while driving. However, the current process of accessing media often proves inconvenient, requiring drivers to navigate through various apps on their phones. This not only poses a hassle but also introduces potential dangers as drivers may become distracted from the road. Atlas aims to change that by giving drivers and safer way to access media while driving.

Method

Prioritizing Collaboration With Lean UX


In approaching this project, we loosely followed Lean UX, a combination of Lean and Scrum methodologies created by Gothelf and Seiden. The Lean UX process breaks down projects into sprints; given our class timeframe, we navigated through two 3-week sprints. A sprint is a defined period of time for design and iteration.

Throughout, we continually validated and measured assumptions, conducted user research, and tested our prototype for optimal usability. Because this was a class project, we were only a team of designers and were not able to discuss our designs with a multi-disciplinary team, but we tried our hardest to imbody the roles of others who may potentially work on a product team.

Lean UX Canvas Outline

Sprint 1, Week 0

In the Lean UX process, the first week of the first sprint is devoted to completing the Lean UX Canvas, which is a page or spread of all the tools, methods, and processes incorporated with Lean UX. Completing this helped my group and I conduct initial problem framing, brainstorming, and sharing our assumptions about our project’s domain.

Making Initial Assumptions


During this week, I led multiple meetings with my team to collaboratively work on each section, creating business problems, business outcomes, potential users, solutions to users' problems, a hypothesis table, and finally our Sprint 1 backlog which defined the MVPs (Minimum Viable Product) we wanted to test first.

Lean UX Canvas

Filled-Out Lean UX Canvas (Week 0)

During this week, we created the first iteration of our proto-personas. Instead of creating static personas, we created dynamic proto-personas that will grow and change throughout our sprints.

Our two initial proto-personas were Ashton, an avid driver in his mid-twenties frustrated with having to switch between apps while driving to work every day, and Amanda, a college student and worried driver who wants a safer way to listen to music while she drives.

Proto-Personas

Proto-Persona Ashton (FigJam)

Proto-Persona Amanda (FigJam)

After creating our proto-personas, our next step was to come up with solutions to their problems and figure out how we could validate these solutions. We created a hypothesis table by thinking through what business outcomes we could achieve through features our proto-personas would find beneficial. We then categorized these features and created our Sprint 1 backlog based on which features we wanted to test first.

Sprint 1 Backlog

Sprint 1 Backlog (FigJam)

Sprint 1, Week 1 & 2

From FigJam to Figma: Bringing Our Assumptions To Life


Conceptual Testing

Testing Lo-Fi Wireframes

Affinity Mapping

Major Takeaways From Sprint 1 Testing

Sprint 1 Retrospective

Sprint 1, Week 1 started off with planning and scheduling three interviews with young drivers who listen to media and receive navigation simultaneously while driving. Every 2 days during a sprint (aside from Week 0’s) I led 15-minute stands-ups meetings where we, as a team, discussed where we were at in our project and tasks that needed to be done. I led these stand-ups and ensured that everyone was on the same page and understood the expectations set for our next stand-up and/or interview. I also moderated every interview for this project.

For our first two interviews in Week 1, we didn’t yet have tangible mockups. We wanted to initially focus on learning more about our participants and their driving habits, more specifically how they interacted with their phone while receiving directions and playing media. I moderated each interview and asked questions such as, “Do you listen to media while receiving directions through your phone? If so, what issues have you encountered when doing this?”

Interviews #1 & #2

Starting with our third interview of Week 1 we began testing lo-fi wireframes which we created based on ideas and patterns we saw from our first two interviews. I designed our navigational screen where users can view their active route and control their music on the same page. As this is the main idea of our app, we believed it was the most important feature to validate first.

Throughout the two weeks of interviewing, we iterated on our designs collaboratively on Figma and began bringing the rest of our Sprint 1 backlog to life. In addition to the active route screen, we also showed participants mockups of other features such as an entertainment queue, a queue-sharing feature, and an alert when switching between apps.

After each interview (12 total interviews, 12 total affinity mapping sessions for the entire project), I held affinity mapping sessions with my team on FigJam. Before beginning, I asked my team, “What are the most important things we learned from the interview?” With that question in mind, I set a timer for eight minutes, then we tried to answer the question based on our thoughts and observations we got from the interview. After the timer went off, we discussed what we wrote down, and grouped our common observations.

Interview #1 Affinity Mapping (FigJam)

By the end of Sprint 1 we saw enough patterns from our interviews which helped us better understand the frustrations and needs of drivers. Here are some of the major takeaways from this Sprint:

  • Users heavily disliked the pop-up alert for switching out of the app. They felt that the pop-up was more distracting than actually leaving the app.

  • Users expressed interest in a route progress bar, providing a visual for how far along in their drive they are. Users felt that progress bars gave them a sense of control and security.

  • We showed users multiple versions of our route/navigation screen and did not see a consistent pattern. Because of this, we decided to implement customization in our hi-fi prototype and for testing during Sprint 2.

At the end of Sprint 1, we completed a Sprint Retrospective, which is a board where my team members and I responded to the three questions I posed, “What went well? “What could have gone better? “What will we try next?” During this meeting we were able to reflect on Sprint 1 and how we were going to approach Sprint 2. We decided that we were ready to shift our testing to show high-fidelity screens as well as introduce more usability testing as the interviews went on.

Interview #4

Sprint 1 Retrospective (FigJam)

Sprint 2, Week 0


Revalidating Our Lean UX Canvas

During Sprint 2, Week 0, I led various meetings with my team to conduct revalidation of our Lean UX Canvas, a process to see if anything important changed and if there was anything we had to fix based on our findings from Sprint 1.

Revisiting Proto-Personas

Sprint 2 Backlog

First, we iterated on our proto-personas based on our interviews from Sprint 1. We decided that Amanda, our worried driver, was also frustrated with how many notifications would pop up while getting directions on her phone. Based on many of our interviewees’ need for customization, we added that Amanda wanted more personalization inside a navigational app. We also removed her need to share her media queue as none of our interviewees shared this need.

Then, we decided that a few of the features on our hypothesis table were invalidated by testing in Sprint 1, such as the switching app pop-up alert and the queue-sharing feature. We shifted gears and reordered our hypothesis table, creating a new Sprint 2 backlog.

This backlog incorporated features we thought had high value that needed testing, such as media tabs on the navigation screen and customization settings, becoming our main MVPs. During Sprint 1, a few of our interviewees wanted to be able to change the active playlist without leaving the navigation screen. This led to my team and I brainstorming a way to achieve this, and ultimately decided on testing playlist media tabs that switches the active playlist during Sprint 2.

Revisited Proto-Persona Amanda (FigJam)

Sprint 2 Backlog (FigJam)

Sprint 2, Week 1 & 2


Moving To High-Fidelity

Sprint 2 started off with my team and I testing a higher-fidelity prototype of our app. During the first couple of interviews of Sprint 2, Week 1, we showed interviewees the features of our Sprint 2 backlog. We focused on testing the playlist tabs and customization features, while also testing the specifics of the navigation screen with media control.

Sprint 2, Week 1 Testing

Invalidated Playlist Tab Feature

Usability Testing

Sprint Retrospective

Instead of focusing on questions about our interviewees’ driving habits, I leaned more towards showing our hi-fi prototype to receive feedback on various aspects of the app. We used these first few interviews of Sprint 2 to develop a basis of what specific task-flows we needed to usability test.

Interviews #7 & #8

At the end of Sprint 2, Week 1, we decided the playlist media tabs were causing too much frustration among our three interviewees. They believed the tabs were too small to click through while driving, but if made any bigger they would block the navigation. Interviewees also felt that the original media control buttons where too close together, and felt that it would be difficult to use while driving. With these two factors in mind, we decided it would be best to redesign the media bar on the navigation screen.

Media Bar Redesign

At the beginning of Sprint 2, Week 2 we began letting our interviewees interact with our prototype themselves once we had a good grasp on what we wanted to show them. We decided to bring back one of the interviewees from a previous test because he closely matched our proto-persona, Ashton. I then crafted a brief task list, detailing the most important areas we wanted feedback on:

  1. Add both the “feel good indie tunes” playlist and the song “Wandering Star” from the Spotify tab to the queue

  2. Start a drive to “Burger King”

  3. Locate the media queue while on the directions screen

  4. Locate the directions list on the directions screen

  5. Add “Burger King” to the favorites list and change its saved name to "BK"

Interview Session #11/Usability Test #2

Like Sprint 1, I held a Sprint Retrospective meeting with my team at the end of Sprint 2 to reflect on everything we had accomplished so far and what we needed to tackle during the refinement stage. Our proto-personas, Ashton and Amanda stayed relatively the same as we validated their frustrations and needs through our usability tests.

Sprint 2 Retrospective (FigJam)

Refinement


Ensuring Consistency

After Sprint 2, we had a week of refinement where we were able to implement the final changes to the prototype based on the findings from Sprint 2, Week 2. We also took this week to polish off the design. I carefully constructed a consistent style throughout the creation of Atlas. I made sure our entire app maintained visual harmony by using color and text styles and following a relative 8-point grid.

Project Canvas (Figma)

Final Product


Atlas, Intertwining Navigation And Entertainment

Media Queue

Navigation

Over the course of eight weeks, my team and I were able to produce a high-fidelity and functional prototype of Atlas, an iOS mobile app designed to help drivers have safer access to media while driving with navigation.

Drivers can build a media queue from various apps, minimizing the time spent on picking or changing a song while driving.

Streamlining the integration of media access and navigation, promoting a safer and more user-friendly driving experience.

Conclusion


Reflecting On Eight Weeks of Hard Work

Takeaways

Working on bringing my idea to life over the course of eight weeks was an extremely rewarding process. I enjoyed collaborating with my team and honing my personal and technical skills as a designer.

  • Staying organized from the beginning is incredibly important. I wish I had stayed a bit more organized at the beginning of this project, as I had to do more work towards the end to maintain consistency.

  • Interviewing the right participants made a huge difference. Interviewing people who aligned more closely with our proto-personas helped us validate or invalidate our assumptions much faster.

  • Lean UX is about making mistakes. The faster you make mistakes, the faster you can fix them. While many of our ideas proved fruitless, they were replaced by more intuitive and desirable versions.

  • Communication in a team is crucial. As a team lead, I feel as though I have improved on delegating tasks to group members. I tried to capitalize on each member’s strengths in order for us all to do our best.

~ fin ~

Like what you saw? Check out more of my work