iHeartRadio is an Internet platform which allows users to listen to live AM & FM radio, artist radio, and podcasts.
In this project, we were tasked with integrating a mini player into the iHeartRadio app, due to growing user needs for multitasking while browsing for relevant and meaningful content.
Project Role
• Lead UX Designer
• Design Researcher
• UI Designer
Tools I Used
• Omnigraffle
• Photoshop
• Google Spreadsheets
Skills I Used
• User Type Research
• Experience Mapping
• Competitive Research
• Wireframing
• UI Design
• User Testing: Survey, 1-on-1 usability testing, moderator, notetaker, writing test scripts
• User Testing Analysis: Affinity diagramming, observational spreadsheets, sorting painpoints, documentation
The Problem
Between the browsing and listening points in the experience is a gap we noticed can be minimized. Every time the user is browsing for alternative content to listen to, they are removed from the current experience to find what they are looking for (Figure 1).
Figure 1. Current user paths between browsing and playback/listening experience.
Business Goal
While the bulk of the user’s interaction with the iHeartRadio app revolves around the browsing and listening experience, the business goal provided here is also to increase total listening hours.
The Process
Experience Mapping with Guiding Principles
This exercise provided the team a shared understanding of how iHeartRadio is integrated into the current user’s daily and weekly routine (Figure 2). Through various user tests, we learned why users chose iHeartRadio, and areas of the application which grow in value over time. These guiding principles helped define the four main stages, exemplified here throughout the user’s journey - from being introduced to the product, to post-product experience.
Figure 2. The three user types identified for iHeartRadio's mobile app.
Highlighted below (Figure 3) is the area of journey relevant to the project we were currently working on. All three types of listeners will be affected.
Figure 3. One of three experience maps compiled. This one is for the Live Station user, with the "Listen" stage highlighted.
See the experience maps for each type of user here (in higher resolution).
Competitive Research
Before exploring any concepts or solutions, we researched what currently exists among competitors (Figure 4). We reviewed the interaction of users listening to audio while browsing various content, use cases where users are unsatisfied and wanted to find something different to listen to, and the transition from one player type to another (if applicable). Pros and cons were analyzed for each competitor.
Figure 4. Competitive Research
Proposed Solution
To eliminate removing the user from their current activity, and based on research findings, we proposed to implement a mini player that would be available universally throughout the app (Figure 5). This lightweight control of their listening experience allows the user to multitask, or view other relevant content without having to lose their place in the current UI.
Figure 5. Proposed outcome.
Challenges and Limitations
• We were required to keep the footer ad banner, as instructed by upper management. This was not negotiable at the time. As a result, all conceptual wireframe included the footer ad placement.
• Tapping on the mini player leads to the full-screen player, which had a dark theme. Transition between the two points needed to feel seamless, while keeping all UI elements clearly legible and followed iHeartRadio's branding.
Conceptualization
These sample wireframes below illustrated various concepts that were explored during the process.
What we learned
• Constant animations (i.e. equalizer) causes battery drain through high CPU usage.
Prototyping
After many revisions, discussions, and receiving a lot of feedback from developers, management, and preliminary surveys sent out to a number of users, the team settled on a few concepts they felt most strongly about. The design team put together a few prototypes and several multiple rounds of user testing to help determine answers to many questions we had, in regards to things like size, interaction, behavior, position on the screen, adverse effects that detracted from the ideal listening experience, and what features should the user have access to from this mini player.
Figure 6. Prototype A, Half-width mini player.
Figure 7. Prototype B, Full-width mini player.
Figure 8. Other designs that were considered for prototyping.
User Testing
User testing was conducted on 20 users online (per platform) and 10 users in-house, following a script which covered common use cases. The users selected were based on demographics that resonated with our target audience. These tests were conducted on iOS and Android users.
Questions We Had On Usability / Interaction
• Upon launching the mini player, what are the user’s initial feelings/reactions?
• Do the users understand the purpose of the mini player, or what it can offer to their experience?
• Do the users find the mini player useful?
• Does the mini player hinder or facilitate in their listening experience?
• Will they figure out the gesture-based actions?
• Will the addition of the mini player to our app increase, decrease, or not affect the TLH (total listening hours)?
• Will the mini player change the how users use the thumbs, favorite, skip buttons? (ie. frequency, any new negative outcomes, etc.)
• Was the size of the buttons and mini player comfortable to use?
• How did the users feel about the placement of the mini player? Was is convenient, intuitive, not obstructing their interaction with surrounding content?
• How did the users feel about the mini player sliding off (for floating mini player version)?
• How did the user feel about the header animation (for docked mini player versions)?
Questions We Had On Visual design
• Which design did the users gravitate toward?
• Based on the visual design, did the user know how to interact with the mini player?
• Was the tooltip successful in conveying the information? Did the user read the tooltip and absorb the information?
• Was the text large enough to read?
• Were there any misconceptions with the visual affordance?
Results
After multiple rounds of user testing with working prototypes, we were able to conclude the general direction for the mini player. Above are sample documentation from the user testing analysis. Exercises included affinity diagramming, observation sheets, sorting painpoints, and other documentations.
See full documentation of the results here.
What we learned
• Although the half-width mini player obstructed the browsable content underneath the least, the small size caused limitations on how many UI controls can be surfaced on the mini player.
• Mini players being near the top of the screen made it difficult to reach when using the mobile device, especially for the one-handed users.
• The pros and cons for the full-width mini player - floating vs. docked - was about equal.
• While the docked version of the mini player was familiar, easy to comprehend, had larger tappable area, the swipe-to-skip gesture was not apparent to many users. Those who did discover the swipe capability actually expected other actions to reveal underneath.
• While the floating version of the mini player slides off the screen when scrolling (to allow for larger browsable browsable space), the mini player floating back up when the user scrolled up made the browsing experience less fluid, which made some users frustrated.
• While the floating mini player's visual affordance makes the swipe gesture very clear, it actually made users feel that they could accidentally "swipe away" the mini player and not know how to retrieve it again.
• In both versions that were tested in the final round of testing, users generally expected to be able to thumb up and thumb down, and have an actual skip button (instead of the swipe gesture).
• Users gravitated towards the darker theme, reasoning that, overall, it helped the screen feel less visually cluttered, and helped the ad appear less jarring.
Outcome
The final design of the mini player was implemented across all iOS and Android mobile/tablet platforms in 2016. While we met our goal of increasing TLH (total listening hours) overall, we continued to collect feedback from our users, and utilized this feedback during a redesign project in 2017.
