Qollab
A collaborative lighting cue platform that helps student theatre organizations align creative visions.
Outcome
Problem
Imagine that you are a student lighting designer at a university theatre club.
You’re experienced but not professional. Like everyone else on the team, you’re doing this in your spare time only because you love it.
Before rehearsal even begins, you’ve already spent days writing cues in a Google Doc, where there are no structured fields for cue element, description, or number. Everything depends on reading your notes and jargon correctly.
Then rehearsal starts...
The first version of your cues gets programmed into the system, and suddenly the director sees the show under stage lights for the first time. As you expected, they don’t like many of them, because they interpreted your intentions differently. That is, if they read your chaotic notes at all.
Therefore, in that 4-hour rehearsal, the whole team spent 2 hours on discussions, revisions, and reprogramming rather than actually using the space to rehearse, and your lighting crew stayed for another 2 hours after, trying to catch up. Even worse, everyone is now expected to come in early the next day because everything is behind.
But none of this is happening because people aren’t talented or committed.
Everyone is working toward the same vision, they just don’t have a shared way to communicate it before the work reaches the stage.
Research + AI?
I came in already knowing the frustration since I was one of the designers.
I wanted to help, but I knew I couldn’t solely rely on my own experience to design around. To see whether the problem was shared, I surveyed multiple groups of student theatre production teams across universities.
Across respondents, the same picture held: a lot of rehearsal time lost to changes, shaky confidence in the result, and a steady streak of questions.
Then I sat down with those doing the work.
I conducted semi-structured interviews to map the process end to end and find where it broke down:
The real conversations about lighting only happened after the cues were already built. By the time anyone could react, the work was done and had to be redone.
And the cost wasn’t just frustration...
One interviewee estimated their team lost around 8 hours a production to rehearsal changes, and the cost to stay in the venue for those hours ranges from a good $800 to thousands of dollars.
Qollab was heavily AI-assisted, but I kept AI out of the research this time.
Early on, I tested Gemini-generated personas and quickly noticed inaccuracies.
One persona claimed student lighting designers commonly used VectorWorks, a professional tool that rarely came up in the survey.
This revealed the limitation.
Student lighting designers are a niche group with little footprint in training data, so it defaulted to what’s most obvious online, which is the industry standard. Here, instead of AI assistance, surveys, interviews, and the actual people are what helped me surface the collaboration insights the whole product is built on.
AI Workflow
The AI-assisted process.
Rather than jumping from idea straight to prototyping with AI, I built a staged pipeline where each phase feeds the next to optimize performance. Through the process, AI assists at every transformation step, but only the transformation step. The research, the priorities, and the tradeoffs stayed human.
Here’s one finding moving through every stage.
"I don't really read the cues. I just wait until it's on stage and tell them what's off."
— Director
Directors need to know what a cue will look like without reading technical syntax, so they react before it's programmed, not after.
Translate technical cue attributes into plain language and a rough visual a non-technical director can read on their own.
Convert the structured cue fields (color, intensity, position, fades) into a natural-language summary plus an approximate stage image, labeled a communication aid, not a render.
AI natural language description & AI preview
This pipeline reinforced my understanding of the product clearly and early at each stage before asking AI to build anything, and writing a measurable target for every requirement makes it obvious which ones I don’t actually understand yet. By the time I reached the PRD, the decisions that needed making were already made.
Compared to a vague brief that leads to generic output, the PRD I produced this way — listing real constraints and targets — gets output much closer to what I actually wanted. Through this pipeline I was able to make the inputs precise enough that AI was useful where it counted: the build.
Solution
