Amazon Music Mobile Navigation Redesign
As of October 2016, Amazon Music launched an entirely new, full-catalog service. At this launch our team had the opportunity to completely rebrand the entire product suite. Even more important was the opportunity to fundamentally update the interaction paradigm of the app across all devices.
Where we started
Hamburger menu: Poor discoverability and slow navigation. Usability and ergonomic concerns, especially on larger devices.
Where we ended
Bottom navigation: Enhanced discoverability, usability, ergonomics, and integration.
The Who and the Why
In the case of the redesign, the 'who' and the 'why' go hand and hand. Previous to this product launch, our target customer was a very casual music listener- someone who didn't listen to a ton of music, had relatively mainstream tastes, and didn't want to pay extra for their music. With the release of a full-catalog service, this product was now going after a much more hardcore music fan; users who not only listen to a lot of music, but curate and collect music in a much more intimate way than our previous customers. So who were these new users and was our current product supporting their needs and use cases?
Before I ever put pencil to paper, I like to talk to users to determine their pain points and anecdotal use cases.
As I mentioned above, our team was targeting a more "hardcore" user with this product - but figuring out who they were and why they were going to use our product was harder. I started our process with ethnographic and generative research to find out how people were using streaming in their life. To properly understand the use cases I needed to not only see people in our usability lab, but in their car, home office, living room, and on the run. I found that people use music drastically different in different scenarios, and that location dictates more than time. For instance, a person may listen to familiar albums at home, but the second they leave the door they listen to explorative playlists.
So what problem does that present us? With the hamburger menu, users are fully submerged into one section. Going between their saved music and browsing new music could not only take multiple interactions, but is hidden behind a drawer so may not even be obvious. The real problem I am trying to solve here is to allow users to get between browsing streaming music, to their favorite music, to the recent history as quickly and effortlessly as possible.
Death to the hamburger menu
It's really crucial to design with the appropriate context. In the case of the hamburger, the industry has been waiting for the ice to break for a couple years. A few macro trends happened that allowed us to push past it this year- Luke Wroblewski and Google pushing bottom nav into android and supporting it through external SDK's, and the increased size of phones. While hamburgers don't work on small phones particularly well, hamburger nav performs even more poorly on larger phones where it is out of reach of a natural thumb tap area. I didn't go straight to the bottom nav as it launched, I went through many stages of iteration to get it right.
The line from start to finish is rarely a straight line in product design. This project was no different - I tried out different ideas. Just because Google Material had set precedence for bottom nav didn't mean it was the best for our users. Above a few of my sketches in our initial exploration sprint. Ranging from just making the hamburger better, to a full planetary, gestural fly-out.
Some ideas have more obvious merit than others. I took 4-6 of these ideas and pushed them to wireframes with the intent of getting them in front of my colleagues (designers, PMs, devs, lawyers, anyone)
Again, design is rarely a straight line and the above image is absolutely not an exhaustive display of all the iterations. The general upshot of bottom nav in our music app was the ability to quickly change between streaming, saved music, and recent history - but within that users tend to choose specifically between albums, playlist, stations, etc. So I had to build out a dual-navigation strategy. One interaction for moving between streaming & saved, and another interaction between playlists, stations, etc. After I got that feedback, I had my general structure to work with and I could start optimizing!
Delivering and Building
The most crucial step in the design process is building the actual product. A paradigmatic shift like hamburger -> bottom navigation requires and enormous amount of trust and communication between design, dev, and product. The design went through countless iterations, tests, and revisions. I used quite a few tools; InVision, Zeplin, JIRA, etc. but the most important handoff tool in this project was face to face communication. It was sitting in the room with the tech team to build the UI and required backend. It was discussing user findings with the product to help shape our goals and how our team was going to measure success of the project. There were problem hundreds of considerations, but below is a consolidated list of the most important decision points.
Both for testing and exploration purposes, prototyping was crucial in this project. We ran the gamut of prototyping tools; AfterEffects, Pixate, Principle, and InVision. Since this was fundamentally an interaction problem, I saw that we got drastically different results from static mock tests and interactive prototypes- what looks good doesn't always act well! Having the full app prototype built out also improved communication with the development team. Experiencing the entire interaction model allowed all our teams to buy into the larger picture rather than building individual pieces that may not make sense in isolation.
The number 1 thing I tested through development was users' understanding of the UI without touching it. Were they able to correctly identify the "state of the system"? How much could they tell us about the app from a single, static screen? This was one of the most crucial tests we completed. This informed elements that I would generally consider "polish". It informed the active states, indicator bars, interaction affordances, and what navigation "meta-data" I showed.
android vs. iOS
Bottom navigation is a strategy that is fundamentally addressing ergonomics. Conceptually, this should apply to all platform and be agnostic of operating system. What I found when I did an audit of popular apps (music and not) was that apps generally "respected" the platform paradigms and located at the top of android, and the bottom of iOS. I pushed very hard on this and firmly believed that this improvement should exist on all mobile platforms. I did extensive testing across iOS/android/Kindle and compared findings. Overwhelming I found that the benefits were cross platform, and the problems that did exist were not specific to android vs. iOS. Therefore our team ended up rolling the changes across all of our mobile platforms.
Our product should work for everyone that uses it, but I also built in advanced features for the most hardcore users. The tenant I pushed hard was "the pro features should not make casual users' life harder". The app previously had play controls available on a minimized state, but I found that most users didn't use them there (but rather on a full screen or lock screen). I knew some users want that functionality so I built it in as a more advanced feature and gave a lightweight FTU to introduce it. The product still functions perfectly if you never discover these interactions, but offer a next level optimization for the most arduous users.
tablet vs. phone
Again, bottom navigation is generally though of as a ergonomic driven interaction paradigm- so does it make sense of a 2-handed device like tablets? Our team admittedly went into this sprint with a bias (which I preferably would never do) but due to tech limitations and branding goals, I knew our team was going to use bottom nav on tablet, but the question was how to make it fit the best possible. I tested things such as: control locations, left/right structure (or the option to user-define), and alignment.
The (most) final design
This design will hopefully evolve over time. Even at the time of launch our team has updates queued up to improve the design, but at some point I had to go pencils-down for launch. I primarily followed the best practices laid out in Google Material's definition of bottom nav (which I generally find to be grounded in strong usability practices). There is one main and noticeable upgrade - the "circle transport". This was initially a controversial decision as it went against what we had previously; album art has to be square & we have to offer users the ability to shuffle, randomize, etc. at all time. I found through research that people are overwhelming losing their connection of album art (especially millennials and younger who grew up in a post digital music world). I also found that most people are only playing/pausing from this screen. It was a ton of testing and iteration to get the play button obvious enough and still show the album art. A lot of users search a lot. This lead me to push search to a very very prominent location.
What I learned
Through dedication, some chaos, and hard work from many people our product launched this product in October 2016. I am not shy to say this is the biggest and most influential project I worked on. At times I felt in over my head, and other times I felt like we were thinking too small and moving too slow. I learned an incredible amount, and pushed my hard skills in the process. I think more importantly I learned quite a few soft lessons that will help me in my future.
the devil is in the details
I sometimes thought of this project as building a new house, but keeping the foundation and interior walls the same. It took an incredible amount of care to make sure we reconnected all the important parts and kept it a consistent and effective experience. It was the little things that made the biggest difference in the end - matching up the gesture interactions so that our new circle transport could shine, but the rest of our app could function smoothly. This really pushed me to understand the code better, and most importantly develop closer relationships with the engineers.
engage the right partners, at the right time
This project had an enormous "footprint". Not only was I working across (3) platforms, but also up and down the tech stack on each of those teams. It would have never worked to design on one platform, and then push to others. The nuance of each platform colored the overall output continuously- rather than trying to fit an iOS shaped square in a round android hole. It was also important to make sure I supported the unique business needs of each platform without letting those decisions affect downstream development. I realized that to build a successful project product-wide, I needed a product-wide team.
the user is the most correct
"The customer is always right" is a slippery slope - but not wrong. In this case the user always had the power to trump product, tech, or design. Its an incredible feeling to not argue over differences, but rather put the idea to test in front of users. I don't agree with the 40-shades of blue approach, but I did learn how "polish" items can have an enormous impact on the end user. The PM and I had a disagreement on what type of indication we needed for the active state - after 10 user tests it turned we were both right and a delicate combination both approaches worked best.