After launch, our focus shifted to stabilizing the product and improving day-to-day workflows. Opening the venues dramatically expanded our user base, but we were  primarily concerned with dome operators—the users running shows in real time. Because CX Pro had been built at warp speed, operators were dealing with bugs, system errors, and an unfamiliar workflow all at once.

To address this, I leaned into operator shifts to note issues as they surfaced. Together, we built and continuously groomed a shared list of frustrations, which at product-side we translated into a prioritized set of design targets that dictated our post-launch iterations.

As users became more familiar with the tool, the reoccurring pain points became more obvious:
- Operators felt overly rushed to set up the next show in back to back schedules.
- Operators were constantly anxious of technical errors that might affect (many) scenes in front of a live audience.
- Operators were getting lost in their scenes as Cosm Run of Shows became more and more complex.

Templates & Show Manager

How can we optimize the show management process so that users can confidently transition to the next show during back-to-back schedules?

Global Controls

How can we quickly fix a show when dome operators encounter an error which spans across many scenes?

Sequencer

How might we help operators easily understand and track the full sequence of scenes during complex Run-of-Shows?

We set an ambitious two-quarter timeline to deliver the next version of CX Pro. Many of the problems we identified required large-scale solutions, forcing me to work on multiple major features simultaneously. For each problem, I created 2–3 concepts, reviewed them with key stakeholders—including lead operators—and aligned on a direction. From there, I had to dive deep into the details to define exactly how these complex systems would work.

Show management came with significant overhead: long file paths, frequent backups, and a workflow that was difficult to move through quickly. The most critical moments in an operator’s shift are the transitions between events. Schedules are often back-to-back, giving operators only minutes to set up the next show. And because live sporting events are constantly in flux, the assets needed to build a show often aren’t available until shortly before the event begins.We identified that streamlining the show-creation process would have the highest impact—reducing setup time, increasing reliability, and ultimately enabling venues to support truly back-to-back events.

Another powerful feature that was shipped during the post launch phase was the parent control system. This system was birthed out of the need for operators to make sweeping changes to their show - as one bug could affect many scenes throughout the entire show which could cause a massive detriment to the audience experience. I crafted a system which gave scenes "states" - with one state being a "parent" and the following states being "children."

What this system did was create a control structure to allow operators to make broad sweeping changes from the parent, while still having minute control of the children states.

The difficulty with a system like this is clarity. So, I created a visual high-light system to indicate the status of properties as changes transferred, and created a help-document for stakeholders & operators to use as a reference.

With the delivery of these new features, users saw a massive boost to workflow speeds. More importantly, our users felt more safe/confident running shows with the added power boost that global controls grants.

"I feel like I can really set up my scenes in a way that makes more sense to me because I know the parent state is there to save me if an error happens"

- Mario R. - Dome Operator

To prepare for external B2B launch, we needed to take a deeper look at all of the intricacies operators deal with so that we can make those intricacies intuitive for new users.
‍
By this time, we had a much stronger sense of what real-world use cases tend to look like & the frustrations operators have. So, we created journey maps for these use cases that gave us a high level view of users process, frustrations, needs, and more.

From this, we were able to ascertain which usability hurdles to tackle first. Additionally, it served as an excellent starting point for determining necessary new tools to incoporate into CX Pro such that other tools are not needed.

Once again we were in a scenario where we had to design for users that did not exist. We knew that university students and professors would likely be our first external users, with a wide variety of use cases. So, our strategy was to leverage our new operator hires - those with the least amount of CX Pro experience. Fortunately, we had two brand new operators that had just came off their training. I conducted user interviews with these new hires and developed a persona board to examine similarities. From these, we found that in order to prepare for large-scale spike of new users, we must conceptually simplify our system.

As CX Pro was operating in a smooth state, we had the advantage to explore concepts. What would CX Pro ideally look like for that university professor who just wants to show their work? 

With this time, I decided to "go crazy" exploring different ways CX Pro could preform its functions. While the concept below was just a thought experiment, there were valuable lessons in it.

After showing these concepts to operators, we were met with immediate excitement. This is what they wanted: an explicit Run-of-show tool.
‍
We could extrapolate from that that CX Pro is simply doing too much things at once. What if instead of having a tool that builds & run shows simultaneously, we had a tool which did one at a time - each with their own specific view?

Product was fully on board with this desire to have a split view, but key stakeholders preferred to organically get there through small steps. So, we took elements of that concept, and gradually incorporated them into the original version of CX Pro.