TourPro Case Study

TourPro tasked our team to work on a logistics management platform for festival and tour managers to complete the planning process (advancement) for live performances.

Table of Contents

  1. Load in: Project brief.
  2. Mic check: Kickoff meeting.
  3. Battle of the bands: We dived into the advancement process, and checked out the competition.
  4. All-access pass: User research.
  5. Soundcheck: Synthesis.
  6. Battle of the bands (part II): Concept testing.
  7. Crowd favorites: Role play and synthesis.
  8. Stage plots: Task flows.
  9. Showtime: Prototyping and usability testing.
  10. Tear down: We presented our findings and proposed a product roadmap.
  11. Load out: Project reflection.

My roles in this project:

  • UX designer: In addition to conducting interviews, concept tests, and usability tests with my team, I prototyped the most critical feature of our solution in Axure over two days, delegated the converged prototype design to team members, led Axure troubleshooting and workshop sessions, and refined our final prototype after testing.
  • Lead strategist: My teammates looked to me for facilitating synthesis and diagramming activities to make sense of our research and strategize our next steps.
  • UX architect: I proposed and mapped out a solution through task flows and sitemaps that reconciled contradicting wants and needs between user types through a Gmail extension and a standalone festival/tour management desktop platform.

Load in: Project brief.

Our client:
Ryan, TourPro owner, wanted to create a tool to help tour and festival managers complete the live performance planning process, referred in the music industry as advancing.

Our audience:
We focused on users on both ends of the advancement process.
(1) On the festival/venue side: production managers, artist relations coordinators/liaisons.
(2) On the artist side: tour managers or the artists themselves.

This project gave me the opportunity to step behind the scenes of live performances, and learn all about the advancement process that takes place during weeks leading up to the DoS (day of show). In addition to bringing my web development background which helped me envision the architecture of our solution, I also brought 11 years of drumming (and drum loading) experience as a percussionist and taiko/Japanese drumming performer, which enabled me to jump into the logistics planning process of tour and festival managers.


Mic check: Kickoff meeting.

From the start of our project, we received a bunch of email threads, forms, and spreadsheets related to recent performances Ryan advanced as a festival organizer for Hangout Fest 2017, a huge music festival with hundreds of artists and multiple stages.

Battle of the bands: We dived into the advancement process, and checked out the competition.

We conducted desk research to have a better understanding of the advancement process, and looked into competitors that directly or indirectly helped artists/tour managers and venues/festivals plan the logistics of live performances.

Figure 1: Master Tour. We paid close attention to Master Tour, since Ryan called it out as TourPro’s main direct competitor. Current pain points include lack of flexibility and customization, many required fields that don’t apply to all artists/venues, and lack of in-app messaging.

We also took note of in-app messaging features in our direct and indirect competitors, since Ryan emphasized the importance of communication during the advancement process. We learned that many event planning applications included in-app messaging, whereas most tour/festival planning apps lacked this feature. I sketched and tested a similar in-app chat feature during concept testing.

Figure 2: Planning Pod, an event planning web application.

I conducted the analysis of an indirect competitor, Planning Pod, and synthesized all of the competitive analysis findings for my team. At this point in our research, we realized that competitors made users work within their own systems rather than taking into account individual processes for performance advancement.

All-access pass: User research.

Before we started interviewing users, I synthesized our desk research of the advancement process and our client’s assumptive solution into a task flow. I didn’t know it then, but this would become a key part of my design process: whiteboarding assumptive solutions as task flows and process diagrams to give my team a ground of assumptions to stand on, before validating/invalidating them.

I whiteboarded a task flow of the assumptive solution our client proposed at our kick-off meeting, to give my team a base to evaluate our upcoming user research against.

We wanted to understand the following from our user research:

  • Users’ advancement processes, and how they compare to our assumptive task flow.
  • Points of communication breakdown during the advancement process.
  • Users’ familiarity with existing tour/festival management platforms.
  • Whether festivals and venues had similar or different advancement processes. Our client assumed processes for festivals and venues would be similar.

We remotely interviewed 5 users and 1 SME (with both artist and venue management experiences) over video and voice calls.

We quickly learned that our users were very busy individuals. We heard one of them frying some eggs as we conducted our interview!

Soundcheck: Synthesis.

From behind the scenes with user interviews, we jumped into synthesis, where we fine-tuned lots of data to find emerging patterns. During synthesis, I advocated for increasing specificity of the categories we used, by including a separate color for quotes, and coding the perspectives each data point came from: artists vs. venues/festivals.

I facilitated the affinity diagramming and dot voting exercise on the top 5 categories to focus on. The voting exercise helped our team gain alignment on the specific issues we wanted to address in our solution, and prioritize trends.

While these insights were helpful in highlighting some pain points and key aspects to address in our solution, we were still fuzzy on where these pain points occurred in our users’ journeys, and didn’t fully grasp the process our users went through. To address this, I proposed that our team individually revisit interview transcripts and return as a group to whiteboard and compare each interviewee’s specific advancement process.

I facilitated the whiteboarding exercise, synthesized our aggregated user journeys, and grouped our users’ advancement process steps into 3 phases:

  1. Pre-advance, which consists of email outreach.
  2. Advance, in which artists and venues/festivals confirm their needs.
  3. DoS, which includes last-minute changes on the day of show.

I analyzed our aggregated journey map, and found 4 specific opportunities for addressing pain points users were facing during the advancement process:

  1. Provide validated, up-to-date point of contact information.
  2. Capture changes in the same place data is collected, i.e. provide a single source of truth.
  3. Automatically generate documents to distribute to specific parties.
  4. Provide a portable solution for DoS and sync with real-time changes.

In order to better understand our users’ needs, we came up with a set list of the problem to hone in on and guiding principles to solve for it. We started with a broad problem definition, which we would refine in the near future:

The context: The tour/show advancement process consists of gathering and confirming large amounts of information related to the needs of artists and venues to ensure a successful show. Currently, there is no clear, consistent process for advancing, which results in time-consuming and error-prone data entry.
Tour and venue managers need a platform to serve as a single source of truth for advancement information, and to facilitate communication and confirmation of advancement details with the right parties.
“I’d like to have a centralized location or database that syncs up the entire advancement information.” — Justin, Production Manager

Tour and festival managers like the system they have in place for themselves; it’s the manual data entry involved in updating documents and the communication process that slows everything down.

We synthesized our research into self-imposed guidelines to hone in on the issues of gathering and confirming large amounts of advancement information.

When we presented our initial findings to Ryan, we asked if he wanted us to focus our solution on either tour managers or festival managers for our remaining sprints, and he told us that both audience types were equally important. We kept this in the back of our minds as we moved forward, knowing that we’d have to reconcile both of our users’ needs for our solution to be successful.

Battle of the bands (part II): Concept testing.

Using opportunities and pain points from our user journeys, problem statement and design principles as inputs, we generated lots of different ideas to test on users. I facilitated several rounds of brainstorming exercises.

I contributed 4 concepts to the team’s 13 total concepts. Since we had so many, we needed to be strategic when placing concepts in front of users in order to limit concept test sessions to under an hour each.

Figure 3: Matrix of concept groupings. I developed a matrix to analyze similarities and differences between concepts, coded each concept, then created divergent groupings of concepts based on feature types and user perspectives (artists or festivals/venues). I arranged our concepts along 5 spectrum lines based on how they addressed various issues in the advancing process, and which audience types they targeted.

Concept grouping 1: Form factor (app vs. Gmail integration)

Users preferred a desktop application for data entry during the pre-advance and advancement process. However, they wanted to review advancement information on the DoS on a portable device such as a smartphone.

Concept grouping 2: Communication of changes (in-application chat vs. notifications/issue tracking)

Overall, users preferred notifications and issue tracking over a chat feature, because they already dealt with many communication channels, including email and slack.

Concept grouping 3: Collaboration and sharing (contact circles/groups vs. individual collaborators)

When we tested different sharing and collaboration methods, we found that users on the artist side prefered circles/groups, but raised concerns over handling sensitive and private information. Users on the festival/venue side prefered adding individual collaborators, since they’re generally working with only a handful of people, 2–4 maximum, during the advancement process.

Concept grouping 4: Mitigate data entry (import feature vs. skeleton profile) for artists

In order to address the need to mitigate data entry, we tested an import feature against a “skeleton” profile feature for users on the artist side. Users emphasized that the ability to import documents would help them cut down on data entry. Regarding the “skeleton” profile, users felt that while it’s great to have some preliminary information filled out, there can be instances where specific details must be manually entered.

Concept grouping 5: Mitigate data entry (import feature vs. form creation) for festivals/venues

Initially, we had issues narrowing down the scope of our audience. By testing out these two concept groups, we were able to narrow down users on the artist side, from all artists including one-off performers, to only those doing festival or repeat performances.

Crowd favorites: Role play and synthesis.

At this point in the project, we were still confused about which direction to take with TourPro. We eliminated two concept groupings, 2A and 3A, since those didn’t test well, but still had many contradictory insights, especially surrounding the form factor of our solution — an app, or Gmail integration.

To help my team empathize with our users and understand the context surrounding each insight, I proposed that our team role play, by revisiting each concept test session recording, then return to a group discussion where each team member played the role of a different tester.

I had an epiphany that perhaps it was possible to reconcile the needs of both artists/tour managers and festival/venue managers. The concept tester I revisited, Woo, happened to mention Asana as a workflow tool that helped him manage events. I looked into Asana for Gmail, and discovered that Asana had their own Gmail integration, which inspired me to organize our concept testing insights into two parts of the same solution: a desktop web application for festival/venue managers, and a Gmail integration for artists/tour managers.

After eliminating concept groupings that tested poorly, I organized our concept test insights into two parts of the same system: a desktop web application and Gmail integration.

Stage plots: Task flows.

To gain a better understanding of how the whole system could work, I led a task flow whiteboarding exercise.

I drew out the steps and screens a user goes through from both artist and festival/venue perspectives, starting with the creation of the artist advance form all the way to a successful DoS.

I mapped out 5 task flows. We noticed that users weren’t facing issues with creating forms as festival/venue managers, or with filling them out as artists/tour managers. Both audience types struggled with completing the advance, rather than starting it. Based on this insight, we identified and prioritized 3 of the 5 task flows for prototyping:

  1. On the festival side, flow F2: Send and receive notifications.
  2. On the artist side, flow A2: Utilize the Gmail integration to add a collaborator, then complete the advance form.
  3. On the festival side, flow F3: Review consolidated department data and flag issues.
The entire system, with the festival perspective in white on left, and artist perspective in grey on the right. In the interest of time, we decided to prototype 3 key tasks (A2, F2, and F3) that addressed the most frustrating advancement steps for our users.
Task flow key. For our task flow, I differentiated between actions happening on the platform (as a festival manager or an artist) and on the Gmail integration (as an artist). Festival actions and screens are in white; artist actions and screens are in grey.
Festival flow F2 (left): Send and receive notifications. Artist flow A2 (right): Utilize the Gmail integration to add a collaborator, then complete the advance form.
Festival flow F3: Review consolidated department data and flag issues.
Festival flow F1 (left): Create a new festival advance form. Artist flow A1 (right): Start a new advance application as an artist.

When we presented our sprint findings, Ryan loved the direction we proposed — a Gmail extension on top of a desktop web application — and supported our decision to test the 3 task flows.

Showtime: Prototyping and usability testing.

I planned and delegated the prototype sections to my teammates, designed our Axure team style guide, then built the value proposition of our solution — a platform serving as a single source of truth for advancement information, with issues and changes highlighted for both artists/tour managers and festival/venue managers. I also served as my team’s Axure wizard and helped my teammates add animations and interactions to their prototypes, specifically the Gmail integration sliding panels, hover effects, and popup modals. Afterward, I tied the prototype together by incorporating my team’s screens and navigation links.

Experiencing dead air.

We lost usability testers during the final steps of our project. We started with 4 users provided by Ryan, but 3 of them dropped out. Luckily, we found replacements by reaching out to personal contacts with similar experiences in the music industry.

Task 1: Send notifications, festival flow F2 (part 1). The festival/venue manager sends a message to notify the artist/tour manager of their incomplete advance form.
Task 2: Artist flow A2 (tour manager), receive email notification and add collaborator. The artist/tour manager receives an email notification and uses the TourPro Gmail extension to assign a task to their crew member to complete the missing advance form section.
Task 3: Artist flow A2 (crew member), complete the advance. The crew member receives an email notification from the artist/tour manager who assigned him/her the task. The crew member opens the advance form through the link, and completes the advance.
Task 4: Festival flow F2 (part 2), receive notifications. On the festival side, the festival/venue manager sees a notification on the TourPro platform. They check the updated artist advance and confirm changes.
Task 5: Festival flow F3, review consolidated departments. The festival/venue manager checks the consolidated hospitality list, and suggests an alternate beverage when the requested beverage isn’t available.

After testing, we immediately made updates to our prototype before preparing for a final presentation of our findings. I combed through our final prototype for font size, font weight, color, spacing, and other style inconsistencies, and made tweaks to the auto-generated email preview based on user feedback.

Tear down: We presented our findings and proposed a product roadmap.

In addition to prototype updates, I worked on the following parts of our final handoff:

  • Designed task flows and a sitemap for our presentation to the client.
  • Developed a team template in Sketch for annotated wireframes, then annotated the screens and interactions I developed.

Our solution eliminates unnecessary data entry by providing a single source of truth during the advancement process and prevents email overload for festival/venue managers through in-app notifications when updates are made to artist advances.

Our solution: mid-fidelity Axure prototype.


Ryan was ecstatic to see the TourPro prototype walkthrough. At the end of our presentation, he thanked us for all of our work, and agreed with the team on the next steps to making TourPro a reality — additional design work for the remaining screens and flows to develop and test the complete system, before moving forward into development.

Due to time constraints, we prioritized prototyping 3 out of our 5 task flows for the full TourPro system. Given more time, I’d love to design and test out our complete solution so that Ryan can take his product to the next stage, high-fidelity designs and development.


Our recommended next steps:

  1. Implement changes based on usability test results, and conduct additional testing, specifically around the auto-generated email preview textarea size, and the hospitality shopping list issue tracker.
  2. Design and test additional artist advance form sections (other than Production), and additional consolidated department screens (besides Hospitality), to help festival managers review and confirm data from multiple artists. Minimizing manual data entry is a key goal of our platform, and we see automatically-generated consolidated department information as a promising way to achieve this.
  3. Create and test the initial festival and artist flows from our full vision of the platform. On the festival side, this includes flow F1: create a new festival advance form, and on the artist side, flow A1: start a new advance application as an artist.
From left to right, TourPro task flows F2: individual artist advance department/section screens, A1: artist advance form steps 1–9, and F3: individual department screens. We prototyped a key example from each set of screens from flows F2, A1, and F3, but the complete platform includes all 9 screens for each flow.

Load out: Project reflection.

I learned a lot from my time on TourPro:

  • I gained confidence in my ability to facilitate client meetings and presentations. In my next project, I focused on designing collaborative client meeting exercises, rather than strict presentations and discussions.
  • I gained knowledge of the music industry, specifically the advancement process and sound engineering terminology involved in planning live performances. Learning about an unfamiliar domain would help me dive into unfamiliar medical jargon and design for Ugandan neonatal nurses in my next project.
  • TourPro was early in its development. Faced with a broad scope and undefined product, I mapped out the first iteration of a large system/platform for artists/tour managers and festival managers to start and complete their advances.
  • I learned how to reconcile contradictory user insights, especially during concept testing, through role play and reflection.
  • I learned how to coordinate and conduct remote interviews, concept tests, and usability tests with tour managers and festival/venue managers. This skill would help me in the very near future, when tasked with remotely designing a solution for an international and ESL audience.