After being a musician for the majority of my life, finding gigs has always been tedious, emailing back and forth and scouring the internet. After speaking to venues looking to put on live music it was clear they had the same problem. Being able to book gigs through one dedicated platform would massively reduce the time and friction around booking a gig.
Users & Audience
The key audience is younger musicians looking to build up a presence through playing more gigs and venues looking to keep a constant stream of fresh artists playing on their live music nights.The musician side will likely be more tech savvy and more aware of building up a presence and an image online which they may have already done so on places like Instagram and Facebook.
Given that the initial conception of this product came through wanting to scratch my own itch as a performing musician I still wanted to ensure many people had the same itch and get ideas of how we could solve it together.The first step was to speak to a group of target users. This part was quite easy due to the fact many of my friends are also musicians and even a few venue owners I knew. After listening to each persons pain points I pulled out a couple of common themes that kept coming up. These were problems around it being time consuming, lack of transparency, unsure of how to best approach.
At this stage I started drawing up concepts for how a product might look that could solve these three pain points. I also started to think about how to bring this age old process up to speed with the times and how to build it around what it’s target users will already be familiar with.I would often take these initial rough prototypes and show people to get their unbiased input on them. It started to become clear that they would use the app as a central place where they could link to the channels they have already invested time in building up (namely Instagram, Facebook, and YouTube) so that venues could hear their music and see the numbers of their fan base through things like Facebook followers, increasing the chances of them getting booked.This then pushed me to think more about how to get more visibility for artists and venues on the platform and what that would look like. There would be no point in artists or venues investing time in building up their profile on the app if they never got seen. This led to the idea of “Artist” and “Venue” feeds that were sorted by location to the user. For example, a user who opens the app in Manchester will see all the musicians and venues in Manchester that are nearest to them. If the same user was to open the app in Leeds they would see all the musicians and venues from Leeds that are closest to them. However, I also realised that people may not want to only appear to the people in the same location so I created the option of specifying a location when applying a filter to either the artist or the venue feed.
Another important factor that came up was to offer more transparency around the actual booking from both sides. With this I decided to make the prices artists charge visible and at prices they set to avoid the “email us for a quote” type of booking agencies we are trying to get away from in the first place. This means that venues can quickly see which artists are in their price range and which are not. Now that the prices charged were set within the app we could open it up to allow actual monetary transactions to take place. This meant that when a venue found an artist they wanted to book they could pay for the service then and there. This would mean that the artist has peace of mind that they will actually get paid and not get short changed after a gig which many have previously been stung by. A booking cannot go through without the venue paying the money into an escrow service that will hold the money until the day of the gig. Unless an issue is raised the money will be released a couple of hours after the booked start time.
After gaining initial feedback and iterating to ensure I was on the right path through using proof of concept sketches and involving both parties in the discussion in the early stages I could then confidently move on to adding the polish to the user interface.The aim was to keep the interface as clean as possible and reduce the number of steps between discovering an artist/venue and making a booking. A little personality was added to reduce the feeling of just paying for a service like any other commodity and instead inject a bit of fun as music is a creative field after all.
After finishing up most of the user interface designs I went ahead and created a prototype in Flinto so I could go out and put it in the hands of real people. I wanted to ensure the user flow was intuitive and that the user instinctively knew what each element on the screen would do.I took this prototype and put it in the hands of a number of people. Here is an example of one testing session (I have removed the name of venue for privacy reasons):
Working on this project was extremely rewarding as the more I showed people the designs and the prototype the more positive feedback I got that this would be really helpful for them.I went ahead and actually built out the iOS Application in Swift that included all the features I had designed minus the calendar and booking features for an MVP release. A problem I have stumbled upon since releasing is that most people who have been eager to sign up can’t get the app because they’re android users! I’ve brought onboard another iOS Developer friend of mine who is now helping to rewrite the app in React Native with me so we can make the product available on iOS, Android, and eventually Web.