Amazon Music 'Home' feature

The problem

Increasingly, we care less and less about the container our music comes in. The average listener couldn't tell you the difference between playlists and stations, and overwhelmingly young people don't think of albums as a relevant concept. All we know is that we want to listen to music we like. The one thing we generally are pretty confident in is whether we want to listen to something we've never heard before, or something familiar. Before this project users were landed in a location that would have two layers of specificity- a content type and a content description (e.g. recommended albums or my saved artists).  That means not only am I making an assumption of whether you want to explore or return to a favorite, but you are stuck with arbitrary containers to choose from. 'Home' is a place where music should be customized entirely to you and your context; what you listen to, what device you're on, and when it is. 

the solution: a homepage for music. What would a newsfeed of your personal DJ look like?

The who & why

The why is relatively simple - users need a central place to go for all their favorite music. Our aim was to reduce the number of decisions and gates a user must go through to find relevant content. Rather than specifically doing ethnographic or usability testing, this use case came from repeated findings from previous user tests.  The product team previously had to make an assumption of where to drop users into the app, which could effectively be wrong or right. The goal was to generate a neutral environment that minimized assumptions we had to make about deeply personal habits and tastes.

The who is even simpler -  almost everyone. (I say "almost" because of 1 user test I did over a year ago where the customer had a single playlist that they listened to exclusively). Recommending music content for customers is relatively easy. People tend to stick within genres or themes. Regardless of genre preference, recommending content containers (playlist, albums, etc.) and whether the user is in an exploration or familiar mood is nearly impossible.  This problem extends beyond personas and target demographics, virtually all our users face this same dilemma.  

Service and UI Design

There were two very different parts of the design process: designing the UI for web, iOS, and android; and designing the system that would determine what to show users. 

System design

If any given user can listen to multiple types of music containers, I have to design a system that will support that. The crux of the problem really came down to "how do you design a UI when you don't know what's going into it"? Because of the highly customized nature, users' interface will look drastically different depending on their listening habits and preferences. My solution was to design a system that identified elements and groups and defined the UI in agnostic terms. This not only allows the service to deliver the most relevant content regardless of container type, but also allows clients to render that content in the UI form that is most appropriate for its form factor. This system was loosely based on existing UI components and set rules for what/where/how to display content.

Service design

We, as an industry, have gotten pretty good at generating recommendations for songs you'll like. How, when, and where you deliver them are quite a bit harder. I had the opportunity to work with a long chain of partners to design a system that would try to optimize on the how/when/where. Unfortunately I did not curate music myself, but worked with data scientist and service engineers to help define machine learning algorithms that will optimize your home page. Once that optimized list is generated, that list is sent to a device where it uses the design system I defined to render that piece of content in the most appropriate way. Defining the criteria for ML algorithms was an interesting exercise in translating user studies to programmatic rules.

Delivering, building, and shipping

Delivering this project was an entire project in itself. Since there was no single "mock-up" that could be us, I created a pattern library to help the design team communicate with developers and business stakeholders. The design tenant that reinforced this can be simplified down to "a song should look the same whether its in your library or streaming, on iOS or android (and pretty similar on web too)". This forced me to be more diligent with my design - any slight change or customization in one place meant a change everywhere else. Below are a few parts of the most crucial aspects of the design.

Scalability and grids

While ideally assets and UI elements are bespoke to each screen, in such a large system it is define and provide every single scenario. Using usage data and best practices, I defined rules for grids and UI components - most delicately for image assets. I was able to reduce down to (2) aspect ratios for all hand curated assets that scaled across  all of iOS, android, and web.

Content agnostic

Since it was impossible for me to know every combination of content that would exist, I approached all the UI elements agnostic of content. Therefore a list was a list, regardless of whether it was a list of songs or a list of albums. While this may oversimplify use cases, this approach freed clients to build a generic list and populate with the content that is best for the user.  

Rule based design

Since the UI layout would be dictated by a single service for all platforms, every additional layer of complexity was multiplied.  "Lists of songs should always look like X on a phone, except for when Y happens"  is a programmers worst nightmare. This forced me to look closely at the patterns I use, and talk with our users about how format works best on a given platform. 

What I learned

This project was an incredibly unique opportunity to work across system/service/UI design. By creating a design system and using it to programmatically render a U, I learned how to better communicate my designs into words. When I was forced to translate my designs into rules, I quickly found that I needed to explain it to another human before I could explain in logic. Designing to a system forced me to be thorough with my design since outliers and edge cases could easily cancel out the efficiency gained. I gained a much stronger awareness of the overall system and how a small decision can affect multiple platforms and environments.

The biggest takeaway for me was how many people have valuable insight that doesn't typically make it to UI. Designers often pat themselves on the back for talking with front-end developers and PM's, but never consider the API engineers that actually create the service that delivers our experiences. By better understanding the backend systems I could make much more efficient and confident designs for what is easily show on the front-end. By better understanding the content curators expectations and intentions, we were able to better map content to users. I learned that the job of a designer is often times to translate all of that internal knowledge into a user's experience (and sometimes vice versa).