DICE INVITES
UX case study for Dice FM
77% of people miss out on concerts because they don’t know who to go with. This case study examines how Dice; an innovative ticketing app could suggest friends to see a concert with by analysing their music taste and indicating which are most likely to want to see the artist.
Have I mentioned I love music?
I absolutely love music, it’s one of my greatest passions; I love curating Spotify playlists, producing tracks on my OP-1 or creating nice drum beats on my Roland TD-11KV electric drum kit, but most of all I really love watching live music performances.
One of the things that excited me most about moving to London was the vast amount of music shows I’d be able to see. No matter how big or small the artist, my chances of catching them in London were much greater than any previous cities I’d lived in. Around the time I’d moved over, I began to hear about an app called ‘Dice’, a product that in my eyes has revolutionised the concert-going experience. I shortly fell in love with it and in the last 2 years have attended 40+ gigs, not including tickets purchased via Viagogo, Ticketmaster, LiveNation etc…
My Hunch 🧐
Despite the fact I absolutely love Dice, I’ve always wondered what opportunities there might be to make it better; and for the last year and a half I’ve continuously thought about the experience of finding someone to go to a concert with and what one does if they can’t find someone to go watch a concert with?
In some cases, people including myself are perfectly fine with going alone, but I’ve met many people that find this absolutely mortifying and that’s absolutely fine but this also made me wonder, do people miss out on concerts they’d really like to go to because they don’t have anyone to go with?
To reaffirm this hunch, I used Typeform and Instagram Stories (that’s right kids, Instagram Stories is a great way to conduct surveys and get results, FAST), I created a quick survey and got a whopping 65 responses, confirming that 77% of people have missed out on a concert because they couldn’t find anyone to go with!
77% but how?!?
For a person that loves watching live music, I found the idea of missing out on a gig heartbreaking, and all because there wasn’t anyone to go with?
I wanted to know why this might be. So to get a more qualitative understanding, I reached out and asked a few of the people from the survey, why they couldn’t find anyone to go with?
The most common answer was music taste here are a few of the responses to elaborate
- “ Most of my friends don’t really share my taste in music ”
- “ Not many people had heard of the artist ”
- “ Friends have different tastes ”
In addition to taste, availability, as well as just not knowing anyone in general in their city, were two additional reasons.
How is it 2019 and this is still a problem?
How in 2019, with the abundance of data generated from listening to music, taste is still a problem? Netflix suggests films to watch based on your watch history, Spotify suggests albums/artists you might like, Hinge suggests people to date; why can’t Dice scan our friends’ music taste and match you with friends who like artists close enough to the one you’d like to see?
The thing that interested me most about the responses was that despite taste being the big problem it also seems to be asking around that seemed to be the underlying issue of taste being the problem, one response put it perfectly:
“ Im sure if I went around asking more people I would have found some… ”
This made me think of how to reframe the problem from how do you find someone to go with to how do you do the asking for the user? How do you help them find which of their social circle is most likely to see this concert with them?
To me this seemed quite obvious, sync Apple Music or Spotify to the users Dice account (something they already do), ask to sync their contacts or even Facebook (with GDPR this might not be an option) and analyse what their friends listen to, then when you are making a decision of who to ask, the app can suggest someone, simple!
Where does it go?
While the idea seems to work in theory it needs to be prototyped and tested. The first big question for me is where in the user flow might this be integrated?
I did some quick exercises with lots of post-its to figure this out. Starting with a Task Analysis to get an idea of all the individual steps a typical user might go through when looking for a concert they like, buying a ticket and finding someone to go with. These micro-steps defined the macro, high-level actions of the task analysis which broke down into 6 stages; Looking for a concert, Finding someone to go with, Second thoughts, Committing to the concert, Double-checking, and Continuing to check.
These high-level stages were then used to create an Experience Map to understand what the typical user in addition to doing, might think, feel, and experience (through the medium of emoji 💩). Touchpoints are also important to think about understanding if the user is doing these things in Dice or other apps? In my study it looked like Facebook Messenger, WhatsApp and iMessage would be additional touchpoints to Dice. On top of all this, I then moved onto identifying opportunities to integrate this feature and firing out quick ideas on how to integrate it.
This exercise definitely showed that whatever this feature was and however it looked, there were many ways to implement it in all the stages of the experience map however it seemed like the best place for it was stage 2; finding someone to go with.
Jobs to be done
I finally had an idea of where this feature might best be placed, it was now time to really frame the problem I planned to solve before jumping into sketching and ideation. Jobs to be Done seemed suitable as Dice is an app for such a wide variety of demographics but their needs are all the same. Jobs to be done is a way of framing the problem you have set out to solve in a sentence by identifying the problem, the action that will help the user overcome the problem and the success criteria. I wrote a few iterations of these but felt this summed up the Job to be Done pretty nice and concisely:
When I’m unsure about going to a concert alone, I want to see which of my friends may potentially like the artist, so I can ask them to join me.
Problem statement & Hypothesis
Next, I set out to create a Problem Statement and Hypothesis. This is helpful as it communicates a clear vision for the work and shifts the conversation from outputs to outcomes. The problem statement puts the problem into perspective by focusing on the users need along with the insight driving that need. Here’s the problem statement I came up with below
Problem Statement: Dice needs a way to help users ask their most likely friend to a concert with them because they most likely will miss out on a concert if they don’t know who to ask.
The hypothesis is about identifying what does success look like and how can we measure it both quantitatively and qualitatively:
Hypothesis: I believe that facilitating, finding a concert buddy for Dice users, will achieve a greater rate in ticket sales to concerts.
I will know this to be true when I see users successfully finding someone to attend a concert with, alongside a high percentage of conversion rates on ticket sales.
Ideation
Great, so the problem has been set along with a high-level solution and hypothesis. Time to start thinking as to how this feature might work and what it might look like!
I started off with sketching and came up with this basic layout to get me started. At the moment Dice has some nice buttons allowing their users to save the event for later or play a track from Apple Music or Spotify.
My idea explores introducing a third button, the user taps it and a pop-up appears from the bottom of the screen; showing which friends would be their best bet to go to that gig with through a percentage value.
Dice could accomplish this by making connections either through syncing phonebook contacts or Facebook and analysing music-related data either from users in the app, their Apple Music/Spotify or which musicians they like on Facebook; plenty of options!
This got me off to a good starting point so I began to flesh this into three basic flows to get the ball rolling:
Flow #1. Sending an invite
Pretty straightforward, this maps the basic experience of looking for people to go with based on their music taste and matching it to that particular gig. The user selects who they’d like to go with and sends out an invite.
Flow #2. Receiving an invite
This is a little more complex as there needs to be thought about how the user may accept or reject an invite. If they accept do they buy a ticket? What if the sender hasn’t bought their ticket yet or vice versa? The worst thing is when someone says they’re going, they don’t buy a ticket and then the event is sold out, how might we be able to get around this?
Flow #3. Receiving an accepted request
This flow is how the person who sent the invite might receive a notification that the recipient has accepted to go with them.
Prototyping & Testing
Once I’d designed the screens needed, I wired them up and prototyped them in Invision. Next, I had to “find” 5 willing participants to conduct some usability testing with.
I looked for people in their 20s, that had used Dice before and were familiar with its interface.
The sessions took about 10 minutes and results were recorded with a usability matrix along with quotes and observations.
The results were good, requiring a few tweaks to the existing screens a few of these tweaks included:
- The indication of the invite status being green once accepted wasn’t clear.
- The percentages indicating which friends were most likely to go didn’t affect the participants choice of who to invite, they prioritized looking for which of those suggested they knew first.
- When receiving an invite it would be good to see a picture of who invited them as you may have multiple friends with the same name.
- If a user had accepted the invite they wanted a reminder they were going with that person or group.
However, the biggest issue was purchasing tickets. A lot of users tried to buy two tickets either after sending an invite or receiving a notification their invite had been accepted. The trouble here is that both people could accidentally buy two tickets or one for themselves along with the other buying two. If this part of inviting someone was going to be included it needed to be crystal clear which of those had bought tickets and if they’d bought spares etc… The simplest solution would be to drop this but as I love a good design challenge it was back to sketching out some ideas as to how this could work!
I have to admit after this session it did become apparent that this is a complex design problem. The reason being I was trying to accommodate bill splitting and all the different use cases it comes with i.e. some people buy two tickets and split them with the friend coming along, some people offer to pay for those two tickets and the friend can get the next one, some people have lots of money and don’t mind chasing the friend to pay.
These use cases work with two people however if you’re going to a show with 3 or more the flow could be complex. So I decided to design a way to show how many tickets each person going has and integrate a simple way to send them a ticket.
Final Design
Based on the testing feedback the design was iterated, finalised in sketch and prototyped in Invision and got to say I’m pretty happy with the results! Let’s walk through the changes!
Suggestions
Suggestions went through quite a rehaul, eliminating the percentage values indicating which friend would be more likely to want to see the show. Each suggested friend was given an individual invite button to make this section simpler rather than selecting all the friends at once and inviting them.
Invites
Based on the testing feedback users wanted to see an image of who was inviting them before accepting or declining. Here the user can see who’s invited them and accept or decline. If they change their mind later they can accept the invite. By integrating the invites section in the same part as suggestions this also made for a cleaner, more coherent look and experience.
Going
Testers wanted a section to remind them who they were going to see a concert with. The going section provides a list of the friends coming along, it also allows the user to see how many tickets each friend has got so they can avoid accidentally buying too many spares.
If the user has a spare and would like to send that to a friend they can select them and send it over!
Conclusion
Overall I’m really happy with this design and to have created something that addresses an actual problem. This project has taken a lot of my extra time and for that, I’m pretty proud to have completed something entirely self-initiated from start to finish!
On another note, one thing I wanted to mention is that Dice actually launched a very similar feature to this Case Study half-way into me working on my own. Theirs is called “Friends”, while some would probably panic about this or feel frustrated, it was great to just know I was hitting on a significant pain-point that they had noticed too!
I Loved working on this and can’t wait for the next Case Study!
