// background

The idea of Bardic came from a discussion with a friend, who works as an event organizer where sometimes it’s hard for her to find available musicians, and an idea I had of an app which basically works like a dating app but for musicians where they can meet and jam together. Combining those two, I came up with the idea of an app where people can hire musicians for their needs; whether it’s a corporate event, a family get together, or maybe even proposing to their significant others

// target users

While the idea came from a problem that an event organizer had, I aim to facilitate people who need to hire musicians for their needs, whatever it is as I’ve explained previously.

// role and responsibilities

As it’s a personal project, I did everything myself both UX design (users research, making empathy map, users flow, etc.) and UI design (wireframe, mock up, prototype, etc.)

// scope and constraints

I set my scope to design the users’ side of the app with 3 main users flows which I will be getting into later. I began this project in November 28th 2024 and aim to finish it by publishing the case study before the year ends. Let's get into it.

// empathize phase_

My first step was to determine the target users of the app by brainstorming and scoping out both direct and indirect competitors. The method I used for the audit was to check on the reviews of the musicians.

The highlighted parts are types of events where musicians most likely would perform.

After determining the target users, I moved on to defining the users’ needs. But before conducting the research, I prepared few questions to ask to people whom I saw as target users as my method of research was interview. Through acquaintances and friends, I selected 5 people that represented my target users.

After conducting the interviews, I synthesized their answers into empathy maps for better view and understanding of their thoughts, feelings and needs.

Then from that empathy maps, I created a persona that represented the people I interviewed as potential users.

With that persona in mind, I created a users’ journey map to empathize and define what they might need in the app.

// define phase_

To define the users’ need even further, I created Problem Statement, Hypothesis Statement and Goal Statement in that order. My thought process was: because I’ve identified the problem that the users were having, I took an educated guess to determine how to solve that problem and finally I expanded that guess into a specified and measurable goal.

A clear problem, solution and goal helped me focus on what I should design.

// ideation phase_

During this phase, I conducted competitive audit to understand what features should be present for a musician booking app. Before I conducted the audit, I wrote down what features that I think should be present in the app based on the Define Phase. Next, I compared my list to the features that are present within an existing musician booking platforms. By using that method, I was able to figure out features that were missing from my list and features that weren’t present on the platforms which I conducted my audit to.

// design phase_

I started this phase by making several users’ flows. I decided to create 3 flows that I think are the core flows of the app with the list of features from the Ideation Phase as reference.

I put a verification page in the sign up process in order to prevent bots signing up to the app. This also applies to the log in process as well.

Highlights are like Instagram's Reels or Youtube's Shorts. They are short form video uploaded by the musicians as a form of showcasing themselves.

There will be 3 types of bookings: ongoing, completed and canceled. Users will be able to review past bookings.

Users’ flow diagram and storyboard helped me map how the users would experience the app. But I still needed to determine the information organization of the app. For that reason I created a sitemap display the information architecture of the app. This sitemap helped me determine what screens should I make and which features belong in those screens.

The next step was to create wireframes. I started by creating paper wireframes as it was a quick and easy way to get my ideas down. For each screen, I sketched multiple iteration as I kept experimenting with the screen layout. From there, I created one “final” screen which was the combination of ideas from previous iterations that is on a separate sheet of paper than the sketches.

Then I transferred the screens that I have designed into lo-fi prototype on Figma, giving them adjustments and changes as needed also adding basic interactions to emulate the multiple users’ flow that I created earlier

Before I moved on to hi-fi prototype, I created the design system for the app and gathered the assets that will be present within the app. First, I created the logo for the app. I tried to create design system that would go well with the logo, as it would save me time for deciding what kind of design system I should use.

For color palette, the primary color I chose was taken from the logo. Then I chose colors for secondary and accent color, also the neutral colors. After the colors have been determined, I moved on to create sticker sheet for the app.

The sticker sheet contains the elements that are present such as typography, iconography, text fields, buttons, cards and containers. Making a sticker sheet made the design process much easier for me because Figma’s feature to create Component and Instances allowed me to reuse similar objects in the app for different purposes.

Then I inserted the assets that I have gathered previously into the prototype, along with the design system that I have created to bring life into the screens

Finally, I enhanced the interactions that I have previously given to the screens by giving it animations to enhance the users’ experience. You can experience the prototype yourself through this link.

// testing phase_

I wrote a standalone Usability Testing document that covers my method and result of the testing.

Click here to open the document. With the insights I gained from the test, I applied them to the hi-fi prototype.

By removing username, it streamlines the process of signing up to the app. The user's account can be tied to and identified by email/phone number.

Originally my reason for offering users "trending categories" based on their location was because of Hick's Law, where users would likely to spend more time making a decision if they are presented with many options. To prevent that, I highlighted "trending categories" near them, while still giving them option to browse for more.

Renaming the "trending label" to "categories" gives the illusion of showing the categories while keeping Hick's Law in mind.

I originally colored both "suggest correction" and "sign contract" button as the same because I saw them as equal status. Users might want to suggest a correction to the musician before signing it.

I changed the "sign contract" button to green to symbolize that it's a confirmation button. (Confirmation to continue with the process)

Just a slight correction.

In the previous screen, I colored the "cancel" button red to emphasize that it's a cancel button. But with the button being red, it draws too much attention in the white background among other buttons.

I remedied that issue by making the "cancel" button the same color as the other secondary buttons. On top of that, I added a cancellation confirmation overlay after pressing the cancel button to mitigate users accidentally pressing the button.

That’s all I got for now, thanks for tuning in. Cheers. -Ven