Tour management for people who actually tour. The Tour Management App is a web and mobile product that helps touring musicians plan tours, organize show information, and access what they need while on the road.
One product, two contexts: musicians plan the tour on web, and run the day on mobile.
Early access. The marketing site is public, and the app is in active use by touring musicians on real tours. It's early access, not yet open to the public, so I can't share live product screens or detailed workflows here. This case study focuses on the product-design process, decisions, principles, and systems I can discuss publicly.
Touring involves much more than getting on stage. Musicians and the people working with them have to keep track of shows, venues, schedules, contacts, travel details, documents, and constantly changing information, often while moving from one city to another.
The app began with the idea of bringing that information into one place instead of relying on a mix of spreadsheets, email, messages, and disconnected tools.
I joined during ideation, while the team was still defining what the product should become. We established an initial functional skeleton first, giving us something tangible to evaluate and evolve. From there, my role was to turn that foundation into an experience built around how touring musicians actually work.
Touring musicians aren't just the target audience for the app. They actively inform how we're shaping the product. Two musicians and their manager are using it on tour right now, and those same people are who we design with: I work directly with them to understand how they plan tours, prepare for shows, move between venues, manage information, and use technology throughout the day.
Those conversations help uncover where the product matches their expectations, where it creates friction, and what needs to change. Rather than treating research, design, and development as separate phases, the product continues to evolve through this cycle as we learn more about how it fits into real touring situations.
These conversations aren't a final approval step. They feed directly into the next iteration. I was the one translating what users said into the product: the order of information, the visibility of an action, how much to show at a given moment, and how a workflow moves from one step to the next.
An ongoing loop, not a linear research-to-handoff process.
The challenge isn't fitting a lot of tour information into an interface. It's deciding what someone needs, when they need it, and how quickly they need to get to it. A musician planning dates from a laptop has very different needs from the same musician backstage checking their phone before soundcheck.
The early skeleton established what the product could do, but functionality alone doesn't determine how someone should move through it. I worked through the relationships between tours, shows, schedules, information, and actions to make workflows easier to understand and navigate.
Planning at a desk and running a show from a phone are different jobs. The challenge was one shared product that adapts to each context, not a desktop app shrunk onto a phone.
As the product grew across web and mobile, keeping the experience consistent between the two surfaces got harder. I leaned on familiar layouts, components, and interaction patterns so the product felt like one thing, and so users wouldn't have to relearn it when moving between devices.
The same product language, designed for where each screen is actually used: planning at a desk on web, and quick access in the moment on mobile.
Room and time for deeper work.
The one thing you need, fast.
The shared reference that keeps a two-client, multi-audience product coherent.
Planning a tour at a desk and running a show from a phone are different contexts. Web supports deeper planning and denser information; mobile prioritizes immediacy, hierarchy, and quick access. They share a system without forcing identical interfaces.
Touring already involves a lot of moving parts. Hierarchy, spacing, restrained color, and progressive disclosure help information-dense workflows feel manageable rather than like an enterprise admin tool.
Tour information has different audiences. When something is private, shared, or public, the interface makes that clear so users understand who can see what they're working with.
When actions touch sensitive information or external systems, the interface is explicit about what the app is, and isn't, doing. It shouldn't imply a permission or level of automation it can't actually provide.
Web and mobile share the same product language, component vocabulary, and foundational decisions. Consistency doesn't mean identical. Users shouldn't have to relearn the product when moving between devices.
The app handles complex logistics, but it shouldn't feel like software imposed by an organization. It should feel like a tool a touring musician would actually choose to use.
A sanitized look at the kind of UI foundations I design with: color and type choices, component states, and clear visibility levels. Illustrative, not the live product UI.
The same principle extends to documentation. Instead of relying on static walkthroughs that go stale as the interface changes, our product manager auto-records the real product flows against the live application, so the documentation reflects what actually ships.
We review those recordings together as a team, and they double as a shared surface for catching bugs and inconsistencies. For me, watching the real flows closely, with a designer's eye on hierarchy, states, and cross-platform consistency, is a practical way to spot where the product has drifted from the design.
We didn't define every workflow, finish everything, and then build. The product, users, design, and technical work evolved together.
The same touring musician has very different needs planning weeks ahead from a laptop versus finding one critical detail from their phone at a venue.
Keeping a two-surface product feeling like one thing took deliberate reuse of familiar layouts, components, and patterns, so people never had to relearn it.
Because the app is in early access and not yet open to the public, I can't show the live application, detailed product flows, or the full Figma files. What I can share is the thinking behind the product: how I work with touring musicians, how UX decisions evolve through iteration, how web and mobile are designed for different contexts, and how I keep the experience consistent across both.
In an interview, I can discuss the work in greater depth within the project's confidentiality constraints.
