Sofar Sounds — a UX case study

Introduction

Sofar Sounds are a start-up that organise secret gigs in intimate venues (typically a private home). Their competitive advantage is a three-way sharing economy between curated artists, unique venues/hosts and the wonderful Sofar community.

I was hired as a freelance UX lead in late 2016 to research and design a React-native ticketing app. The first thing I did was organise a hack day to map the existing inventory/ticketing process and to brainstorm some alternatives.

Image for post
Image for post

Hack day

The hack day suggested a core opportunity in being service-led instead of product-led. This was due to the top-tier cities scaling to ~20 gigs each week which resulted in an ever-expanding inventory of ‘identical gigs’.

Although each gig is unique, the secrecy of the artists combined with the shear number of gigs made the selection process quite overwhelming…

Image for post
Image for post

We planned to remove this analysis-paralysis by asking for a user’s availability and preferred locations and filtering the gigs accordingly.

Gigs are usually over-subscribed, but the hack day also suggested that we look into the need to ‘apply’ to each gig. Applying to gigs was resulting in an overly complicated ticketing flow which would involve designing, developing and maintaining many different touchpoints in-app. We pondered making an amend to the flow as follows:

Image for post
Image for post

I validated our ‘analysis paralysis’ hypothesis by A/B testing the effects of surfacing fewer gigs on identical gig selection pages. The results showed 3-5 gigs was ideal and any more resulted in increased abandonment.

Image for post
Image for post

I also checked that the application process did seem overly-complicated by assessing the select/confirm/pay flows in MixPanel (over 50% of selected customers didn’t confirm). By comparison customers that could buy tickets directly (by being given a promo code to skip the ‘apply/select’ step) had twice the conversion rate.

Customer analysis

The next step I took was to try and understand the Sofar Sounds community/customers in more detail. I was most interested in their motivation for attending a Sofar gig (but also their demographics, needs, expectation and mood).

Image for post
Image for post

I explored the Sofar Sounds social media pages and I conducted interviews at gigs across London. Finally, I spoke with top-tier city managers which led to the following hypotheses:

  • Customers (and volunteers) are motivated by discovering new music (emerging talent) and finding ‘their new favourite band’.

I further validated these hypotheses by sending a representative survey out to existing/lapsed customers to discover their motivation for buying a ticket.

Image for post
Image for post

All of our existing hypotheses were further validated by the survey, but we also discovered some additional insights:

  • Customers are motivated by ‘sharing Sofar with someone new’, they want to show the alternative side to their city to friends/family and they’re also keen on using gigs as first dates.

I used our insights to suggest some user personae as follows:

  • Primary: Artist discoverer
Image for post
Image for post
Image for post
Image for post

Feature prioritisation

Although the brief was to create a ticketing app, we also needed to consider the wider motivations behind downloading (and keeping) the app. I decided to conduct (and maintain) a Kano survey to both understand the key features we had to include in the app, but also to assess what simple features might lead to a truly hedonistic experience.

Image for post
Image for post

During this process, I discovered that there was some risk around removing the ‘apply’ functionality (and product inventory more generally). I decided to look into this in more detail by assessing the ‘number of applies per session’ in the back-end. It transpired that quite a few customers were applying to more than 12 gigs at once…

Image for post
Image for post

After reaching out to the ‘apply to 12+ gigs’ customers for more information, they described that they found joy in the lottery of seeing what they were selected for each week (and then confirming one gig from the reduced options available). This correlated with the negative sentiment around removing ‘applies’ within the Kano survey and helped to explain some of the friction when looking at the average conversion rate from ‘selected’ to ‘confirmed’.

We decided that the positives of getting rid of the ‘apply’ process outweighed the negatives. (Although we did note the potential delight in a ‘surprise me’ gig-matching feature in the future.)

Image for post
Image for post

Designing for delight

I also wanted to design for delight (in an efficient manner) by considering the worst-case-scenarios in-app and how they might be flipped into unexpected moments of joy/advocacy.

We designed for delight by suggesting that ‘Sofar not yet in your city’ users could raise the profile of their city to get Sofar there sooner. We also used delightful animations and copy to ‘fix’ any dead-ends in-app, such as: ‘Sorry, no gigs are a good match for you right now.’

Image for post
Image for post

Customer co-creation

Because we still had a few alternative ways of matching gigs to customers I decided to create paper prototype components to enable co-creation with real customers. Each component was on an individual piece of paper and could be re-arranged/re-drawn as customers saw fit.

Image for post
Image for post

These sessions were really fun! They allowed us to ask contextual questions to make design decisions quickly. We could draw new components as-needed and the format forced us to design for simplicity.

After discussing the feasibility of the wires/components with the tech team (and stakeholders), we settled on the following core wireframes:

Image for post
Image for post

Moving to high fidelity

In moving to higher-fidelity designs, I started to organise usability sessions and ensured we only focussed on one flow at a time (first open, sign-up, set your preferences, match a gig, pay for tickets, etc). This meant I could make further adjustments to ensure higher fidelity designs were optimised for both pragmatic utility and emotional delight.

Crucially we moved away from conversational UI (which was well-loved during the co-creation paper prototyping sessions) towards simple, sequential decision-making which greatly improved usability:

Image for post
Image for post

Prototyping and testing

I used Marvel for international prototyping and testing as I could manage remote testing insights via their Lookback integration. I also created a fully-fledged version of the prototype in Principle to explore transitions that might enable us to move away from traditional ‘pages’ (and increase engagement).

For testing: I recruited a database of existing Sofar customers via an online survey as normal. But I also reached out to the top-tier city managers to help me recruit remote UX researchers as it was crucial that the app be relevant/successful in all top-tier cities (most of which were in NA).

I top-and-tailed our Marvel prototype with a basic script and ran UX training sessions over Skype with the nine UX researchers to ensure we all had the same approach to user testing: wait, listen, no transference, echo, boomerang, columbo, etc.

We managed to get into a fortnightly sprint rhythm where I would publish the latest prototype (building on each dev release in an agile fashion) and the UX researchers would then test with five participants (usually customers that turned up early to gigs). I would then action the majority-case feedback and test the revised version locally before passing to dev.

Sentiment checking

Because we had a wealth of user testing/feedback videos in Lookback, I also collated unprompted positive/negative feedback towards the prototypes more generally to stay aware of risk/reward for our planned features.

Image for post
Image for post

App launch

We launched in both app stores simultaneously and obtained/sustained a 4.9 star rating by championing bug-squashing using InstaBug ‘shake to submit’ functionality (with promo code rewards for submissions). We also refined our core flow by experimenting with notifications, notification timing and the gig matching algorithm to increase ticket sales via the app (all managed via MixPanel).

Using a service-led offering was very successful as Sofar Sounds could now provide gig recommendations (furthering their competitive advantage). We discussed how the new algorithm could be further developed to enable:

  • Finding your new favourite live band/artist via Spotify integration.

The gig matching algorithm was the responsibility of a particularly gifted back-end developer (thanks Graham) and it effectively auto-applied/confirmed customers to the perfect gig on demand. This meant you could now find the ideal Sofar gig and purchase your ticket in six quick steps (improving conversion and ticket sales).

Image for post
Image for post

App iterations

Post-launch, I was asked to design additional functionality to the core flow using insights from our Kano survey and ongoing feedback loops. The priorisitised features were:

  • My invites/tickets area: for reminder notifications and avoiding emails.
Image for post
Image for post

Summary

This was a six month contract. The research and initial design of the app ran for 4 months, resulting in our initial AppStore release. I then worked in fortnightly sprints to design/test subsequent features for a further 2 months. I worked alongside Sofar’s CTO, with 5 devs and a project manager. I also managed a team of 9 UX research volunteers.

Image for post
Image for post

Written by

London-based UX expert: I enjoy solving problems with insightful research, intuitive flows and elegant interfaces. https://jonmarshall.co.uk/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store