Mixlr is a social live audio app that allows anyone to broadcast simply using their mobile or desktop device. The client wanted us to re-design the user flow for broadcasters, and there were several criteria including:
- Incorporating features from the desktop app, now made possible on mobile with the upcoming iOS 13 update.
- Convincing broadcasters of the value of the mobile app experience and converting them from free, to paid subscribers. (Mixlr will start charging mobile broadcasters by the end of 2019).
We utilised various UX methods throughout the project and took an agile approach, iterating on our processes throughout the sprint. Below are some examples of our process that got us to our final product:
Design Studio with our client at the Mixlr offices
- Analysis of Mixlr & its direct & indirect Competitors
- User Interviews with 5 existing & 4 new Mixlr users
- Experience Maps
- New persona developed to capture a large & previously un-represented part of the Mixlr user-base
- Problem Statement & How Might We statements
- Multiple Design Studios including one involving the client
- Card-sorting exercise to determine names & methods for broadcast categories, plus terminology exercise to determine best name for new audio files feature.
- 4 prototypes from paper through to high-fidelity, all iterated through user testing
- User testing throughout the sprint with new & existing users (30+ in total)
- Affinity Mapping throughout the sprint after each set of interviews & user tests
- Accessibility contrast tests & simplified re-design of Mixlr Style Guide
This project was a very rewarding and successful one but as always there were some great lessons to be learned:
- The importance of Agile: As a UX team we worked agile, constantly iterating on our designs, however the nature of the sprint (huge time constraints and working externally from the client) meant we made lots of changes to the product and handed over to the client at the end in more of a waterfall methodology. I believe that if we'd had more time, working more closely with the developers in an agile approach with incremental changes would have been much more effective.
- The importance of collaboration with developers in terms of knowing what is technically possible in a complex product.
- That showing evidence of research & insights (either through facts & figures or direct quotes from users) is extremely important for client buy-in.
Understanding the Users & Defining the Problem
Through our user interviews, testing & experience mapping we identified that the main part of the broadcast flow causing issues was the moment of going live. Users found it jarring to have to go live before entering their broadcast title & category. An existing user we spoke to had even created a how-to guide for fellow broadcasters due to the app not being intuitive.
A lot of the existing users we spoke to were not music professionals but were passionate about broadcasting as a hobby, so we wanted the Mixlr app to make their hobby easy rather than over-complicating it. After creating a new persona Mike to encapsulate the wants and needs of our users, we defined the following problem & hypothesis:
When Mike is broadcasting, he wants an easy and effective way to set up his live broadcast so that he can focus on creating content and interacting with listeners.
We believe that by simplifying the user flow and enhancing features we can allow Mike to focus on doing what he loves most.
After defining the main problem and listening to our users, we aimed to solve all issues through ideation in Design Studios, focusing on 3 main areas:
- Clarity - making the user flow and user interface as clear as possible for the user
- Personalisation - allowing users to easily personalise their broadcasts & channels
- New & Enhanced Features - a combination of new features requested by the client and their user-base, plus enhancement of important existing features based on user interviews.
We addressed lots of things within each of the three areas; I have gone into more detail on my Medium case study
for this project but I will take you through our most significant changes here.
The most significant change we introduced was allowing users to set up their broadcast before going live, to minimise error and allow them to get the most out of their broadcast. Various users we spoke to had several regular broadcasts - we created the concept of 'Saved Templates' which users can use for regular slots to reduce repetitive admin.
Above: The 'Go Live' flow in the existing app vs our re-design with 'Saved Templates' feature
For the sake of clarity and accessibility we also simplified the iconography within the user interface as several users had problems with this. For example we replaced the stop button, previously the mixlr logo, with a universal stop button to avoid any confusion, particularly for new users:
Progress of the Channel/Profile page, from the existing app through to our hi-fi design
Users commented that they used Mixlr to broadcast live, but relied on competitor apps to publish and promote their work, due to Mixlr's channel page being fairly greyed out and therefore "not very public facing".
We wanted to make sure our product tackled this issue, so we made sure to remove any 'greyed out' elememts from the UI, and added more opportunity for artwork to make the channel page look as public-facing as possible.
We also made some changes to the 'Showreel' where broadcasters store & display previous broadcasts. Through one of our team design studios we add the concept of 'Collections' allowing broadcasters to organise their content into groups, and at the same time making it easier for listeners to find relevant content. This feature in particular was well-received when we tested our prototype with the existing userbase.
3. New & Enhanced Features
After adding the new playlist/audio files feature requested by the client, we turned our attention to enhancing another feature of the app: the chat. Through our interviews we discovered that the social aspect of Mixlr was a huge for a number of its existing users, who were dismayed when Mixlr had recently disabled the chat due to issues with spamming.
"The engagements I've had on the social aspect of Mixlr are really incredible."
Ian - Mixlr user
As Mixlr's tagline is 'Social Live Audio', and since the chat was so important to its users we set about trying to enhance this feature and solve the issue of spamming. Our solution was twofold:
- Moving the chat from the channel page where it currently sits, and attaching the chat to individual broadcasts. Making sure the chat is only live for the duration of a broadcast, and not evergreen on a person's channel, would help limit the opportunity for spamming.
- Introduction of Direct Messaging feature. This was requested by one user we spoke to as he didn't want to share his personal details on a public chat each time someone reached out to him personally. To restrict spamming, any direct messages received by people outside a user's contact list would have to be approved.
Progress of the Live page a user would see when broadcasting. The leftmost screen is the existing app which doesn't have a dedicated live screen and instead shows a user's channel page. The rightmost screen is our final hi-fi design showing the chat which belongs to that specific broadcast.
The most rewarding part of this project was being able to work with the dedicated existing user-base of Mixlr, and helping to improve their experience. We received really positive feedback from them during tests of our final prototype. We also received positive feedback from the client who are currently working on a beta-release on iOS due in early 2020.
Please see below for a video of the final prototype, or if you want to explore it yourself click here