Much more than a sleek facelift, my redesign of the live music platorm, Songkick, drives home a user-centric experience backed by data, interviews, and user testing.
Following my passion for live music, I set out to better the user experience of an app central to that domain – Songkick. I began this project on a hunch – having used the Songkick website previously, I knew the UI was extremely inconsistent, and that there were features that seemed poorly thought out. Moreover, because Songkick is a much smaller company than many of the music industry tech giants, I wondered if there were underlying UX problems resulting from this lack of infrastructure and investment in design best practices.
I knew that to uncover whether or not this hunch was valid, the beginning portion of this project would be very research-heavy.
Know the company and their product
Analyze the user context and overall user experience
Consolidate insights, iterate towards a solution via prototyping
Performing organization research, constructing initial assumptions based on app usage, conducting qualitative user interviews to understand user context.
Songkick provides it's users with "personalized concert alerts". Users rely on Songkick to stay in the know about when and where their favorite artists are performing live near them.
Users must track both artists and locations, allowing Songkick's UI to display primarily concerts from the user's tracked artists within their tracked locations.
One popular way that users can track their favorite artists: by scanning their music library, like Spotify. Each time they scan, Songkick automatically tracks each artist in that user's library.
Push notifications are a big part of the experience, where users mostly recieve alerts about newly announced concerts that they are tracking.
Songkick provides quick access to popular ticket-purchasing platforms and occasionally allows users to purchase concert tickets from them directly.
I knew that, because this was a redesign of a company's flagship product, the goal of this project would be to advance the mission of the company through the new design.
What is that mission? After reading up on Songkick's About page among other resources, it became clear that their number one priority was putting the fan first.
Here's what the current version of Songkick looks like.
As you can see in the above video, there we some perceptible UI shortcomings of the design, and as I walked through the app (I'm fairly familiar with the Songkick website), I began to piece together micro and macro problems.
There are way too many tracked artists ("tracked" means I'll be updated if they're performing near me) generated from my Spotify account – did you see how long I had to scroll??
The Concerts view is confusing – I can filter, but I can only sort by genres, and not my tracked artists? The horizontal carousels also create a very overwhelming UI of seemingly randomly-generated content.
Marking a concert as "Interested" or "Going" provides the user with no obvious value. This should either be fleshed out or done away with.
My user interviews allowed me to build a mental model of which touchpoints Songkick fits in to the current user journey.
Often times, interviewees described finding out about concerts when one person in their friend group posted something in a group chat or shared the news about a concert in person. There was also surprising overlap between friend groups and live music tastes!
I thought it interesting how no one really "goes out to find a concert", they kind of happen across them via word-of-mouth or during social media sessions.
– Interviewee 5
While most users confirmed the Spotify was an accurate representation of their live music tastes, it raised eyebrows with regards to how "scanning your Spotify library" actually manifests in the app.
Information Architecture testing, user testing with various flows, user feedback + app store feedback, consolidating insights, revisiting hypotheses, collecting quantitative survey data.
First, I explained Songkick's mission and the base functionality of each category (each category being a feature/tab from the Songkick app) to users.
Then, I tasked users to, in short, redesign Songkick. This is what they came up with, and I made sure that they explained their thinking every step of the way.
Users viewed Profile as "the place where [they] would mess with preferences"
Concerts being "that initial feed that you see, the results based on your preferences."
Notifications is a very essential feature, but users weren't sure if it deserved its own tab or not. Many claimed that push notifications was its most effective implementation.
To users, Search = used when looking for something that’s not permanent, not a persisting preference/setting.
For in-app user testing, I ran my users (who had never seen the app before) through 3 primary flows and observed their thought process at every step of the flow.
Scan your artists from Spotify.
Find a concert that you'll want to see this summer.
Start tracking a new location.
Users walked me through what they were thinking during each task, what they liked, what they didn't, and what confused them.
– one particularly frustrated user
To bolster the robustness of my in-app feedback, I read through Songkick reviews on the Apple app store and Google Play store.
The scanning process is extremely sub-optimal (note the quote that I bolded). After scanning, users get inundated with concert UI about artists that they wouldn't care to see live.
The content strategy and overall design of the main view, Concerts, is incredibly flawed and confusing for users.
To do away with the Interested/Going feature, or to build it out?
Currently, the app allows users to mark concerts as Interested or Going, yet there is no apparent benefit, save for viewing your upcoming plans, to doing so in-app.
While on the website, the value attained is being able to view friends' upcoming plans, which lacks discoverability altogether (it's at the very bottom of the long-scrolling main page).
To further dive into this hypothesis, I reached out to my Stanford classmates to learn about how important word-of-mouth transmission and peer influence are in concert conversion, or one's likelihood to go to a concert.
Because of the contextual insights I had gained in my interviews (i.e., users would see themselves using this app every week or month), I did not want to replicate social network or messaging functionality established in widely and frequently-used social media.
Creating dedicated user personas, 3 core design goals, brainstorming solutions/features, testing screen prototypes, consolidating feedback, iterating core solutions.
Roddy loves to go to EDM raves during free weekends, but he generally listens to hip-hop when he's not catching live music, regardless of if he is studying or working out.
Decides he wants to go to more raves with his friends.
Downloads Songkick hoping it can help.
Scans his Spotify playlist and gets 300+ hip-hop artists.
Creates new account, manually searches every EDM artist.
Realizes this is way too tedious and time consuming.
Matt is a busy college student always making plans to see concerts. This coming summer, he'll be moving to New York City to pursue a banking internship.
Excited to make plans to see concerts in NYC.
Downloads Songkick in hopes that he can find shows.
Becomes super confused by the Concerts view.
Can’t find a chronological list of his recommended concerts.
Gets alerts for artists that he doesn’t like.
Sally, a social butterfly, has a super diverse music taste. She loves to go to all kinds of live events as long as she has at least one friend to go with.
Finds Songkick isolating, yearns for a social aspect.
Instead, asks around about concerts people are seeing.
Realizes some people share an interest in a smaller artist, Yung Pinch.
Goes and has a great time with them!
Wishes there was a magical orb telling her who everyone was seeing.
While there are an incredible amount of UI tweaks to be made to Songkick based on the in-app feedback that I had gathered, creating the above user personas based on my UX research allowed me to focus on a subset of persisting problems that, if solved well, would contribute to 80% of usability improvement (look up the Pareto principle, or the 80/20 rule).
Refine Scan/building up tracked artists in a flexible, effective manner to align with users’ true live music preferences.
Streamline and align Concerts and Search view/functionality with expectations and needs of users.
Leverage social networks and Interested/Going feature to facilitate more discovery and engagement without attempting to replace current established lines of communication.
How might we refine the scanning/tracking process?
After scanning, Songkick automatically tracks the user's top 25 artists. The user can continue to curate (add or delete) tracked artists at their will.
During on-boarding, after initial scan, user goes through "cards" of concerts that they might be interested in, likeing or dislikeing them as Songkick refines their tracked artist list.
Intermittently during app-use, the UI pops up concert recommendations that the user might be interested in, and the user confirms or rejects that recommendation, updating their tracked artist list.
I decided to also focus on streamlining the Search view because most users, during my Card Sorting testing, viewed the Concerts and Search view as having intertwined functionality, and thus were confused by the Search view's seemingly limited scope.
How might we improve the Concerts (and Search) view to fit the users' needs and expectations?
Divide the Concerts view into two tabs (like the Spotify Library view), Explore (the user's tracked preferences) and For You (the app's recommendations).
For the Explore tab, vertical shows the chronological ordering, while horizontal carousels maximize real estate (and sacrifice discoverability) to show user concerts they may like.
Expand search to provide for locations. One potential user flow: Search => Boulder => View concerts in Boulder => Explore tab in Concerts view with that filter applied.
How might we leverage social networks for concert discovery?
Like in Venmo, automatically track friends based on contacts and Facebook. Also allow user to gauge a "pulse" on who is seeing who performing live, similar to the home view on Venmo.
Allow users to join groups to help mobilize concert conversion within friend groups - entire group recieves notifications together as well as pre-sale codes.
The Groups idea arose from a combination of research findings: users admitting that they've missed out on several concerts before, friend groups often sharing live music tastes, peer influence being very important in concert decision-making, etc.
This is what we want: "Ryan is interested in concert X"... "Hey Ryan, I saw you were going to X"... "yea man, didn't know anyone else wanted to see them too, but wanna go together actually??"... "I'm in!"
What did I sketch out?
No major changes here – simplying making the UI minimalist.
Two variations of an on-boarding screen to display all artists that were scanned, with the top 25 having already been tracked.
A 2 tab view in the Profile tab where users can see their tracked artists as well as their scanned artists.
What did users think?
My users rated this approach as much more effective than blindly tracking all of the artists on their libraries.
One user voiced her concern: "what if I start listening to new artists: I doubt that they would bubble up to my top 25 artists! That list wouldn't help me then."
What did I sketch out?
The main Concerts view has 3 tabs. Tracked = concerts based on who/where they're tracking, Recommended = app's recommended concerts, Saved = manually saved concerts).
I created 3 ways to render Concert content in square, rectangle, or 3/4 rectangle shape.
Initial search state with "Recent Searches" suggestive UI, variations regarding search results to account for addition of location searchability.
What did users think?
Users unanimously preferred the overall Concerts view structure compared to the original horizontal carousel UI.
Users appreciated the Recent Searches feature of the Search view and preferred the tabbed search results UI. As one user pointed out, "I hate how Spotify doesn't separate albums from songs from artists when I search things".
Half of my users preferred the square (2 column) card layout, while the other half preferred the wide rectangular card layout.
Since the Interested/Going feature isn't exactly a screen itself, and because it is intrinsically part of "socializing" the Songkick app, I decided to focus on the Profile view, where users already expected friends preferences and Interested/Going to reside.
What did I sketch out?
Different experimentations on organizing preferences for the user (tracked artists/locations) and embedding Friends and Groups features within as well.
A tabbed view to toggle between a user's friends and the groups that they belong to.
What did users think?
Users saw potential in the groups feature and confirmed that they did not want for this feature to allow for messaging because they already have group-chats established!
Users were weary of making this a fully fleshed out friends feature, wherein users make accounts and explicitly add/request friends.
They also voiced concern about receiving notifications about "friends" that they didn't care about.
Devising a design system, studying Songkick UX copy, designing high-resolution mockups and final prototype in Adobe Xd, future improvements and next steps.
Songkick's dark theme already served as a very robust visual approach because it met the users' mental model of concerts and live music.
I made sure to read up on and follow the dark theme best practices widely agreed upon, specifically referenced in Google's Material Design documentation.
Songkick did not seem to use color intentionally within their UI. I decided to use their accent color to indicate important UI, like newly announced concerts, tracked artists, etc.
A ubiquitous design transition from the current app, I decided to rely consistently on rounded edges for card components as they are widey regarded as being "back in style" in the UX world for many valid reasons.
Since I was using red to indicate important UI, I needed a distinct color to show error states. I chose an orange hue to do so!
Without furtho ado...
Sensibly, I decided to align my copy in the redesigned Songkick app with Songkick's tone itself. Their tone?
"We think of the most straightforward way to say something, then don’t say it that way."
"We don’t refer to ourselves in the third person."
"Sentences should feel tidy and functional, and paragraphs should look and feel snappy."
This tone comes out most in the onboarding flow!
For a user to build their list of tracked artists, this is a persisting process that begins in the onboarding phase and continues via app recommendations and manual additions in the Profile tab.
Users receive notifications from their "Close Friends" while being able to keep a pulse on who is going to see who in their Notifications tab.
Users can join groups with shared live music tastes to be notified together and recieve Songkick promotions.
The bread and butter of Songkick, the Concerts view allows users to browse chronologically through concerts from artists and in locations that they are tracking. They can also check out location music that the app thinks they will enjoy.
After getting a pulse on their surrounding community in the Notifications tab, users can view more information on specific artists or concerts.
Here's what the final redesign looks like in the hands of a user!
To test how successful my redesign was, I know I have to get my final prototypes back in the hands of users. As I am still testing users, I am still waiting to post the final redesign feedback here!
As of now, Songkick has no idea that I redesigned their app. But I intend to change that (via many cold emails) and at the very least, to hear their initial thoughts!
The social side of Songkick is the most volatile, for me, as many users claimed they would only see themselves using Songkick around once a month. Would only a few users add their friends?
Throughout this whole redesign, I was weary to focus on push notifications because I worried it took away from the app design itself. But, as I learned with user interviews, push notifications could make or break their UX. Songkick could be improved via intense quantitative research on which push notifications are effective (enhance concert discovery and conversion) versus disruptive.