Currently, the search experience on Sofar Sounds is very limited, with only a single drop-down menu available to users for searching concerts. Additionally, from a business perspective, Sofar Sounds wants to increase the number of bookings on their site.

To solve the problem from a user perspective, me and my teammate came up with a more streamlined and effective flow for searching concerts on Sofar Sounds. Solving the problem from a business perspective, we made sure that the search experience is more efficient and easy-to-use, which will lead to more bookings due to it being easier for users to search for their respective concert.

The first thing me and my teammate did was to conduct a usability review of the existing search experience on Sofar Sounds. We did this to identify common pain points of the app, which will assist us in coming up with ideas and solutions to solve or optimize those pain points. At the same time, we also identified "WOW" moments within the app. These are elements or moments in the app that generates a positive reaction from us, this could be anything from the illustrations used to the consistency of the color scheme. Identifying "WOW" moments also helps us decide what elements to keep or improve in our solution.

The search experience is functionally limited and doesn’t give the user flexibility on how they want to search. This negatively impacts the business as users are more likely to drop-out, causing less bookings on the platform.

The search results page is presented in a very confusing way due to lack of hierarchy, which can also result in users backing out. There’s also a lack of a visual element to inform users the location of the concerts relative to their location.

Competitor benchmarking is an essential step to any user research process as it gives us insights into the commonalities and differences between our product and theirs. From this, we are able to identify trends and how users interact with the products.

After doing research on the product and its competitors, we wanted to conduct user interviews as it is a great way to get insights and data from users. We did user interviews because we could use the responses/insights we have gotten to validate our decisions to implement specific features and why we prioritised them over others. Firstly, we came up with an interview script so that we know what to ask the interviewees during the interview. We also discussed on which questions will be the most beneficial to ask in relation to our case study, and these questions are the ones that made it in the final script.

With the interview script finalised, we set out to do our user interviews. We made sure to record our interviews on Zoom so that we can transcribe and analyse the interview later on Dovetail, our UX research tool of choice. We also made sure to not be biased during the interviews and ask open-ended questions, which allowed the interviewee to give us more detailed answers that will help us in deciding which features to add and improve.

Once we have conducted our interviews, we uploaded the recordings to Dovetail and let it transcribe the interviews for us. From there, we were able to analyse the transcript and tag it for keywords and trends that we notice. After tagging both interviews, we then created an affinity map using all the tags that we created. We found Dovetail to be super powerful as it normally takes a week or two to come up with an affinity map manually, whereas we were able to create one in a matter of hours using Dovetail.

We created an information architecture diagram of Sofar Sounds to gain a better understanding of how we could improve the hierarchy of information. This will also help developers when we eventually handoff the designs to them.

Using results gathered from the mind mapping session, we applied our findings into a Crazy 8's session, where we were able to rapidly sketch out ideas in 8 minutes, with 1 minute being spent on each idea. Crazy 8’s is a great technique to put down ideas from everyone in the team in a visual form and come up with multiple solutions to the problem. We did this so that we could come up with multiple solutions to the problem and discuss on which ideas/solutions to move forward with.

The priority matrix helps to have a crystal clear idea in which feature could we focus on first based on effort and impact. This is done to decide which features are we going to add to the search experience that will help increase the number of bookings on the platform.

Creating user flows helps us visualise the path the user takes to achieve their desired goal. We mapped out the current user flow, identified the potential improvements with the interfaces and created an improved user flow that will help the user achieve their goal more faster and efficiently.

With the improved user flow being finalised, we started prototyping our screens in lo-fidelity. Starting with lo-fidelity is important as it is much easier to sketch and edit our designs at this stage as opposed to editing it during the high-fidelity stage. We then voted on which versions of the wireframes we should move forward with and convert to high-fidelity.

Adopting the Atomic Design method allowed us to create a library of reusable interactive components. This is done through the use of component properties, a feature present in Figma where you can set different properties for components. Every component has a state: Default, Hover Focus, Inactive and Disabled. It's important that each state is designed to give users feedback as well as making the handover process to developers easier. The primary palette consists of the original app's colours as we didn't want to stray away from the branding colour. This is accompanied by shades of grey that complements the palette. Additionally, we made sure to test the text colour with the primary colours following WCAG guidelines. As for the typeface, we went with Inter as it is the industry standard and offers great readability for both lower and upper-case text. We used a 12-grid system for web and a 4-grid system for mobile to make sure our content is consistently spaced. Additionally, we followed the 4px grid system (4px rule) to ensure our interface follows a consistent spacing rule.

With our lo-fidelity prototypes finalised, we created our high-fidelity prototype. Our goal with the high-fidelity prototype is to be pixel-perfect so that when we are handing off our designs to developers it will much easier for them to convert our designs to code.

As with every solution, usability testing is vital to finding out if our solution actually improves the experience and usability of the product for the user. Unfortunately for this case study we didn’t test our solution with users due to time constraints. Usability testing will be conducted in the future and used to iterate on the solution.

1. Collecting and analysing user data is essential in creating an accessible and usable product.
2. An information architecture diagram helps both the designer and developer understand the hierarchy of the product.
3. A visual component (such as a map) is great for helping users make decisions regarding location and conveniency.

For the next steps, we would conduct usability testing and compile all the user data we have gathered and look at the major pain points that users experienced while using the app. We would aim to implement changes and ideate upon it. The changes we come up with will be based off the major pain points we have identified during this round of user testing. We would then re-evaluate our hi-fidelity prototypes by going through the ideation process again and arrange for further user testing while asking more in-depth follow up questions. This is done until our design is proven to be more usable and accessible to our users.