Band Width

Overview

As the UX/UI designer on Band Width, I led the project from interview to final prototype over a school year. I conducted research on how musicians, fans, and venue hosts currently find and book live music, then designeda single app that serves all three.

Because Band Width has to work for three very different kinds of users at once, my role centered on reconciling competing needs without letting the product feel like three apps stitched together. I focused on a shared visual language while keeping the experience fast, mobile-first, and low-friction for people booking or discovering a show on the go.

The problem

Independent musicians struggle to find venues willing to book new acts, and fans have no single place to discover live shows happening nearby. Venue hosts, in turn, spend hours coordinating bookings over email and text with little visibility into an artist's fit or draw.

Band Width sets out to close that gap with one app that serves all three groups, basically a shared home base for discovering, booking, and promoting live music.

My role

• Led user research: recruited and interviewed musicians, fans, and venue hosts to understand each group's booking and discovery habits.
• Mapped three user flows: designed distinct but interoperable experiences for musicians, fans, and hosts within one shared app.
• Built the prototype: took wireframes to a high-fidelity, testable Figma prototype across 40+ screens.
• Ran usability testing:planned and moderated sessions with each user type and iterated on booking and discovery flows.

Understanding three audiences at once

Booking a gig, discovering a show, and running a venue's calendar are three completely different jobs-to-be-done. Before sketching anything, I needed to understand how each group currently gets by and where the friction was worst.

Wireframes & visual design

With three flows to reconcile, I focused on a shared visual language and navigation pattern that would feel native to each audience without forking the product into three separate apps.

• One shared component library across musician, fan, and host views to keep the app feeling cohesive.
• Role-aware navigation so each user only sees the tools relevant to them.
• Low-friction booking flow, reducing what used to be an email thread to a few taps.

Key screens

Testing results

Ran moderated sessions with each user type, then refined booking and discovery flows based on where testers hesitated.

• Fans moved through show discovery with almost no guidance needed.
• Musicians hesitated at the booking-request step. The venue's "fit" criteria weren't visible up front.

To fix the booking hesitation, I surfaced each venue's genre fit and typical draw directly on the booking-request screen, so musicians could gauge fit before spending a request. The revised flow tested cleanly in the next round.

Building for scale

Supporting three user roles pushed the component library further than a typical single-flow app would have. Every component needed to flex across contexts without losing consistency.

Reflection