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.
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…
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:
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.
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.
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).
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’.
- Customers (and volunteers) are motivated by the sense of community at gigs and the opportunity to meet new people.
- Customers are motivated by ‘pay what you want’ ticket pricing, as gigs are perceived as a cheap night out (common in tier 2/3 cities).
- Customers are motivated by the mystery only, some never come back to the platform once they’ve seen behind the curtain (they assume higher profile artists will be at every gig).
I further validated these hypotheses by sending a representative survey out to existing/lapsed customers to discover their motivation for buying a ticket.
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.
- Customers are motivated by the ‘bring your own beer’ aspect (as gigs are perceived as a cheap night out). Akin to our ‘pay what you want’ finding.
- A few customers are motivated by exploring new parts of their city, they attend a gig to see what the audience/venues are like in a new area.
- Regular customers want to connect with the artists they’ve seen post-gig: listening to music, watching videos, buying merchandise, etc.
I used our insights to suggest some user personae as follows:
- Primary: Artist discoverer
- Secondary: Community lover
- Secondary: Curtain peaker (to explore ways of reducing high churn)
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.
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…
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.)
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.’
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.
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:
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:
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.
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.
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.
- Getting invites to gigs with your friends by comparing your availability.
- Improving subsequent gig invites/experiences based on user feedback.
- Gig recommendations from friends/artists/users with similar taste.
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).
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.
- Choose the date flow: to enable gig planning further in-advance (usually for special occasions).
- My artists area: so you can connect to (and celebrate) artists post-gig.
- Sneak a peak at last night’s gig: to provide a preview of what a gig’s actually like (for new users) and dynamic content (for frequent users).
- Artist of the day: to discover the popular (international) Sofar artists.
- Listen to a Sofar playlist (Spotify) and listen to Sofar radio (SoundCloud).
- Advocacy rewards: a premium experience as you attend more gigs.
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.