Live non-music content in a music app

It's not everyday that we get to design in a blue sky, new app type of world. We constantly are inheriting tech, executing existing product strategy, and working on iterative design. This project was an opportunity to work outside the box, inside the box. In the summer of 2017 we launched live streaming (audio & data) of International Soccer coverage within the Amazon Music ecosystem.



Though this was an opportunity to design effectively an entirely new app, it came through a pretty strict requirements process. This project was really important for two different reasons - sports at Amazon, and live content in our music app. As much as possible, we approached this project agnostic to the content being provide - from the very beginning we had a design tenant that 'we should build features that work if/when we expand past European football content.' Because of this, it was really important to think of the customer's total journey, not just at a single screen.

Customer Journey

This project touched a lot of parts of Amazon, and a lot of different design points. From the very beginning we started from an entire journey life. Starting from "This is an entirely new service for Amazon customers, what is the marketing message that gets them to the right experience."

Platform selection

Using the customer journey work, it started to grant clarity as to what platforms would be the most important and when. We did competitive analysis on many different sports & live apps to determine what the standard was. In addition we used ethnographic research to determine how customers went between devices. This also gave us direction as to how we direct customers from device to device, and when/how to upsell.

m[2] IX flow.png

App Map

One of the most important considerations we had to think about was how does this fit into an existing app. One of the most difficult aspect of this project was being relatively far away from the target customers (German football fans) and the culture of sports and music is very different in Germany than it is in America. We made a decision that was most correct for Germany (still works for the US, but maybe not as optimized). This allowed us to sandbox this experience while still feeling like an integrated part of the app. We did this same exercise for all the platforms. 

Even more than visual or interactions decisions, I find these IA-type decisions to be the toughest to determine what is the right design alternative and which option is the strongest.  In this case, we dig through user data (research, usage, etc.) and map those use cases to UI destinations.

Navigation Options

Once we landed on how we integrated this new experience into our app, we had to determine how to get to it. This problem was particularly difficult in our org because it was such a moving target. At the same time we are designing this project, there are 2-5 other projects that would potentially be pushed to a global navigation level in our app so our solution needed to work anywhere along that spectrum. I will discuss more shortly, but ultimately this decision was based on user research and discussions with individual platforms. One of the most interesting aspects of this design problem was the ability to work with other teams within Amazon. Other teams (such as NFL on Amazon Video) were having this exact same discussion at the same time so we were able to collaborate and share learnings/process.

Screen Shot 2017-07-21 at 9.38.48 AM.png

Iterate from sketches

This image shows a single screen (the live game view on mobile) and the iteration cycle we went through. Each stage of this had many many revisions and were shaped by internal review, guerilla testing, and tech development.

In this particular screen, we prototyped a lot to determined what the correct interactions were and user tested to validate that as well as get more resolution on what info is most important to customers. As you can see, the length of this screen varied quite a bit. Our mentality was "take everything away and see what people ask for" which sometimes ended in a 'kitchen sink'. We then tested taking sections away one by one to determine what was necessary, per platform.


This project involved a lot of prototyping, using many different tools and levels of fidelity. Below are 3 examples show a range of what, when, and how I prototyped throughout this project.

Wireframe prototyping (in Pixate RIP)

This prototype was primarily for internal teams to work through the interaction of the live game experience. I intentionally kept the content at a block wire level so that we could discuss the feasibilty/efficiency of the interactions without getting tripped up on visual design and content ordering. 

Small feature iteration (in Framer)

There were times that I prototyped small feature sets a relatively high level of fidelity. Generally this was less about user testing, and more about dev handoff/discussion as well as design critique to determine the fine points of interactions.

Full functioning prototype in Framer

We ran a full user test (in Germany) in which I put together a full app prototype to test not only getting into the new experience, but also the usability inside that experience.

Using the right tool for the right platform

Again, this was all happening across many different platforms. So this prototype was done in Keynote to work with FireTV team to test the "channel change" option. Because I was working across so many platforms, it was crucial to build with the right tool, level of fidelity, and have a strong sense of why I was building the prototype.

User Testing

There were numerous reason we aggressively tested throughout the course of this project (not least being good design hygiene). The largest of these studies was an in-person usability test in Amazon's Munich office. The intent was to usability test the mobile Framer prototype I had built, test a WoZ Alexa design, and validate the feature-set we had determined to be P0. Far and away the most valuable learning and takeaway I gained was the importance (and difficulty) of testing in an environment entirely different than your own. It's unlikely to understate how important the nuanced difference of German's culture around sports and music changed the design compared to the American users we had tested with. This session, more than anything else in the project, shaped our roadmap and informed the design.


Specs & Handoffs

On Day 1, we launched on (8) platforms, (7) form factors, (6) languages, and numerous screen sizes. This (sometimes overwhelming) complexity really forced me to approach hand-off based on a system.  No matter how well thought out the system is, there is always, and should always be certain bespoke elements on platforms. I built my specs so that if I was not around, it should be able to be built, but I relied heavily on personal communication and face-to-face work. 

The coolest example of this is how we decided to handle artwork for an individual game. We are support over 1600 games, and therefore need an approach that can be completed without any manual labor, while still having a high beauty bar. I worked with a systems engineer to build a ImageMagick script to ingest stadium and logo images, manipulate them and create artwork automatically. Again, we tested this across sports and came up with a solution that should work no matter the teams or sports that are playing. These images were utilized across all the clients and delivered a consistent and reliable experience. 


Launch and learnings

The most fun part of this project was the excitement we saw on launch. Its always gratifying to see screenshots of an experience you design and a news site! We are still early in the season, so we are iterating through future features and cleaning up issues we pushed for launch, but overwhelming, the response has been positive. I cannot speak to much of it here, but we have begun using this project as tip of spear, and moving further in the direction of non-music content and live across Amazon.


Like I mentioned above, the most poignant takeaway for me was just how different customers are in different locales and how important it is to engage those users. From Day 1 we got the question "why are you putting soccer in a music app"  which was a fundamental blocker in many of our discussions. Once we got to Germany and spoke to customers, the question never came up and it was apparent that cultural it just made sense. If we had not spent as much time in Germany as we did, the app would have launched in a very different state and likely not performed as well.

The other big learning for me was how to frame a project differently and bringing along requirements at a parallel rate. In this case we constantly were meeting in regards to live content, sports content, combing unique content types. It was easy to get lost in a rabbit hole of solving a problem specific to Bundesliga, but I was always challenged to think more agnostically and how we could solve this problem in a way that would support other content, other platforms, etc.