“A guy walks into a bar.” Most of us read that sentence and immediately expect a joke to follow. But since 2011, every user story written for the AMI Music app has begun with those 6 words.
A guy walks into a bar and his favorite band plays, or he learns about a new album they just released, or he’s entered into a free drawing to win an autographed guitar from them.
Why? Because his phone and the jukebox talk to one another.
These stories and more were captured on countless sticky notes, whiteboards, and internal wiki pages — waiting for technology to catch up and for someone to define how they would all seamlessly come together.
Initially released as a hybrid application in 2012, the AMI Music app provided users with the ability to find participating jukebox venues, purchase credits, and spend them to play music. Phone sizes were of course much smaller then, so less thought was given to future expandability within the UX and visual design. It was more about getting it out there.
Version 2.0 was a technology switch. The hybrid design was dropped in favor of going native on both Android and iOS. The switch allowed for much faster download times in bars and restaurants where 3G or 4G coverage was often spotty. But more importantly, because the mobile team lacked a full-time visual designer, this switch allowed AMI’s engineers to produce screens on their own with native material design.
The app thereafter continued to grow in popularity and use.
VERSION 3.0
My personal daily involvement with the app began in 2017, following a decision by management to invest additional resources in mobile.
By far, mobile was the company’s best growth story, but the app lagged behind in many desired characteristics or features possessed by a competing product. Tasked with helping to close the gap, I met with product management to be debriefed on short- and long-term goals. Additionally, I requested reports showing the common journeys of actual users and assessed the app myself.
Based on my research, I arrived at the following conclusions:
The company’s decision to build most 2.0 screens with no visual blueprints (provided by a visual designer) created a situation in which there was no source of truth for the app. There was no reference, besides the actual app itself, to determine the accurate appearance of screens.
The absence of a visual reference guide resulted in inconsistencies. Components like navigation bars, buttons, icons, font sizes, and spacing were not consistent from screen to screen.
While meant to appear native, the app was out-of-date with current iOS and Google design guidelines. In fact, occasionally the two would blend. A very “iOS thing” would appear on Android or vice versa.
The app’s visual design had a lot of wasted space and didn’t have the look & feel of a modern-day music app.
User journey mapping showed that many users had to dive deep to reach their preferred method of music selection, requiring up to 7-8 touches to complete a transaction.
I concluded that reinventing the user experience and visual design made more sense than building a new suite of features on top of the existing 2.0 framework. I shared my findings with product management, the team agreed, and project 3.0 was born.
UX RESEARCH & GOALS
Whenever possible, I try to be very data-driven in my approach to design. Again, knowing there was a wealth of information on existing users, I made sure to study how the app was being used. However, because data alone is easy to misinterpret, user surveys were also arranged to collect information on what features they currently found most useful, least useful, and what new features they wanted to see most.
Customer Support was consulted to gather information on commonly reported confusion or user errors, and lastly my own instincts came into play.
Instincts are clearly shaped by experience. And in my case, my early career sets me apart from other designers in a unique way.
If you’re unfamiliar with the name, during the 90s and 2000s, Megatouch was the world’s premiere manufacturer of coin-operated touchscreen games for bars and taverns. From cards to trivia to photo-hunting, these coin-operated machines provided endless hours of entertainment to casual players and high-score chasers alike. But what made them particularly unique was their bite-sized length. Each game was designed to last 3 minutes, at the end of which, a final score and rank were delivered in hopes of baiting players into dropping another quarter in to try again. And boy was it successful – to the tune of billions of annual paid plays!
Megatouch was a unique place to earn your stripes as a user experience designer because every application you created had to “earn its keep” within 3 minutes. Every project forced you to ask:
How can I create a learning curve that flattens within seconds?
What’s the least number of touches needed to deliver the first moment of joy to a user?
What needs to be accomplished within the user’s first 180 seconds to make them a repeat customer?
So, onto my whiteboard went several goals for the 3.0 application.
Make signing up faster. An account was required to play music and I wanted to minimize the number of steps needed.
Make it possible for an existing user to play a song within 3 touches. Not just any song – a song they would likely want to play. Data showed users having to dive deep to reach their preferred method of music browsing and I wanted to bring those methods to surface level instead.
Make it possible to jump between core features. For example, if a user was deep into a music search, I wanted to ensure they could stop to add funds, change a setting, or add a song to a playlist without losing their place in that search.
Make it much faster to purchase funds. I wanted to remove as much friction from that experience as possible.
Give the app a clearly defined style guide and a source of truth, a place where designs for all screens could be stored and reviewed. This later became Zeplin.
VISUAL DESIGN
For a period of 8 weeks, I worked independently on the app’s design.
Within UIUX circles, it’s often debated whether prototype mockups should “look” more finished or whether they should simply be comprised of grayscale shapes. In my opinion, it depends on the audience.
While engineers can clearly start with basic shapes, full-color mockups are far more effective inside the boardrooms that actually dictate the projects given to those engineers. As such, I tend to work in full color, leaning on my experience, as well as the speed at which tools like Sketch allow me to work.
I divided the app into 4 sections or tasks:
the act of playing music
the act of creating playlists
the act of purchasing funds (to play)
the act of managing settings
Because I felt users would value the ability to jump between the 4, my first major decision was to incorporate a bottom navigation into the design. Tabs for Play Music, My Music, Add Funds, and Account would serve as the app’s primary navigation and organization.
PLAY MUSIC TAB
“Play Music” would enable users, whether signed in or not, to browse nearby jukebox locations using location services. For convenience, signed-in users would be given shortcuts to recently visited venues and favorites (a list that could be managed).
The app itself was meant to be used in-venue, which meant 90% of the time, users were already standing or seated inside the venue of the jukebox they intended to play. In fact, the jukebox was used as the primary form of promotion for the app.
After selecting a venue, users would arrive at the venue’s main page. Here the experience would differ depending on whether the user was a known customer or not. The goal, as previously mentioned, was to allow users to play a song within 3 touches. To accomplish this, features like “My Recent Plays” and “Songs Trending Here” would now provide instant access to playable content.
Additional selection methods that our research showed as popular would also be given faster access. These included direct music searches, browsing popular artists, browsing discounted music, and curated playlists.
MY MUSIC TAB
With millions of songs available in the catalog, “My Music” would enable users to quickly access and play their favorites. This would be done via two methods.
First, I wanted to provide users with a simple means to say, “I love this song. Add it to my favorites.” This would provide a shortcut around the typical steps required to create a playlist. Instead, a favorites list would always be accessible – all a user had to do was add music to it.
Second, the app would clearly need to support the creation of custom playlists and eventually “multi-song selection” for quicker play of them.
ADD FUNDS TAB
“Add Funds” was incredibly important to get right. In any app, it’s the non-fun part of the user experience where you’re asked to spend money. I wanted to get all users in & out of that experience as fast as possible.
To achieve this goal, I proposed:
Incorporating alternative methods of payment (Apple Pay, PayPal, etc.) to alleviate any hesitation a new user might feel about providing their credit card information to an unfamiliar app.
Allowing the app to recall the amount of funds previously purchased, as well as the method of payment, so next time, the user could repeat that same transaction with no friction.
Giving users the option to have funds automatically added to their account anytime their balance dropped below a specified threshold.
ACCOUNT TAB
“Account” would store all setup and configuration options. But work to be done would also include a simplification of the account creation process. In 2.0, new users were asked to complete 7 different input fields. My goal was to cut that down to 2, dramatically easing the onboarding process.
Once all mock-ups were completed, department leaders including engineering, QA, sales, marketing, and customer service were gathered for an in-person summit where the design was presented, debated, and thereafter green-lighted for software development.
BETA PROCESS
Eight months after development began, a beta candidate was ready for distribution to iOS users. Invites were sent to over 5,500 people in hopes of acquiring at least 1,000 beta testers. Targeted groups included friends and family, high and low volume users, users known to be price conscious, and customers recently acquired from a competitor, among others.
In addition to a 10-question survey, users were provided a means to send direct feedback. Results were as follows.
85% reported an overall positive beta experience with many providing valuable insights that were used to further improve the app prior its general release.
99% claimed onboarding to be very simple.
75% stated that having one-touch access to playable content such as “My Recent Plays” and “Songs Trending Here” was incredibly useful.
74% expressed appreciation for their favorite browsing options now being easier to access and explore.
55% claimed adding funds was now faster, with 24% planning to enroll in our new Auto-Reload program.
Overall, testers were very pleased with the beta experience, and for the few that were not, follow-up communication plans were immediately executed to learn more.
RELEASE & RESULTS
On November 5, 2018, nearly one year after designs had been presented for discussion, 3.0 was released to the iOS App Store, with Android following soon thereafter.
Four months later, the app hit a significant milestone, reaching a weekly transaction rate of $1M per week. Monthly plays via mobile reached 6M. And unique purchasers, including those users purchasing at least one song per month via mobile, increased by 33%.