From Theatre to Tech: Building a Better UI/UX Design Feedback Process

Richard Baldwin's Technical Blog

From Theatre to Tech: Building a Better UI/UX Design Feedback Process

Toward a Process for Better UI/UX Design Feedback in Startups.

How a Breakdown in Communication Led to a Better Way Forward

Every startup goes through growing pains. For us, one of the biggest challenges was how design feedback was received and implemented. The process had become chaotic—Product Managers and UI/UX Designers felt overwhelmed by conflicting input, while the broader team felt like their voices weren’t being heard. Feedback sessions often turned into free-for-alls, where strong opinions dominated and useful insights were lost. Trust eroded, frustration grew, and we found ourselves stuck in a loop of revisions with no clear direction.

We needed a better way.

That’s when I revisited a process I had used extensively in my decade-long career in new theatre development. As the Artistic Director of Portland Theatre Works, a board member of the Philadelphia Dramatists Center, and an independent theatre director and producer, I worked with playwrights to refine their work without losing their voice in the process. In theatre, feedback can be just as emotionally charged as it is in tech—creators pour their heart and soul into their work, and criticism, even when well-intended, can be counterproductive if not structured thoughtfully.

By adapting a Critical Response Process originally designed for theatre, we developed a structured, constructive framework for product design feedback. This approach ensures that our Beta Team—select members from across the company—engages in meaningful dialogue with Product Managers and Designers before development begins. It fosters collaboration, reduces friction, and ensures that feedback is not only heard but also actionable and effective.


The Beta Team Critical Response Process for Tech Product Development

1. Affirmation

  • Each session begins with Beta Team members highlighting what works well in the design—what they find compelling, surprising, or effective.
  • This creates a positive, open environment where feedback feels constructive rather than adversarial.

2. Product Manager & UI/UX Designer as Questioners

  • Instead of just receiving feedback passively, the Product Manager and Designer drive the conversation by posing specific questions about areas they are unsure about.
  • Example: “Does this flow make sense for a new user?” instead of “What do you think?”

3. Beta Team as Questioners

  • Beta Team members phrase feedback as neutral questions rather than direct criticism.
  • Example: “What problem does this feature solve?” instead of “This feature is unnecessary.”

4. Opinion Time

  • If a Beta Team member has a strong opinion, they must ask permission to share it rather than offering it unprompted.
  • Example: “I have an opinion about the UI layout—would you like to hear it?”
  • If the Product Manager or Designer declines, the feedback is not shared.

5. Subject Matter Discussion (If Needed)

  • If a broader discussion (e.g., business impact, user personas) emerges, it is tabled for a separate conversation to keep the session focused.

6. Iteration & Working on the Work

  • When appropriate, the team collaborates on real-time iterations, brainstorming refinements to the design.

Outcome:

This structured approach fosters trust and clarity, ensuring that feedback serves the work rather than derailing it. It helps Beta Team members feel heard while giving Product Managers and Designers the control they need to make informed decisions.


Why This Works

By shifting feedback from a reactive critique to a structured dialogue, this process avoids the common pitfalls that make design discussions frustrating. No more opinion battles. No more defensive responses. No more wasted cycles on vague feedback. Instead, we have:

A psychologically safe space for honest feedback
A clear distinction between constructive questioning and unsolicited opinions
A method for prioritizing and filtering feedback based on what’s most useful
A structured framework for iteration that keeps the conversation focused

It’s not just about making feedback kinder—it’s about making it more effective.


What This Means for Your Team

If your design feedback process is causing friction rather than fostering collaboration, this approach might be worth considering. It shifts feedback from a battle of opinions to a structured process that serves the work—whether that work is a script or a product interface.

Bringing a method from theatre into tech has given us a repeatable, scalable way to handle design critiques while keeping creativity and collaboration at the core of our work. And if theatre can teach us anything, it’s that the best performances happen when everyone is in sync—on stage and off.


Interested in Implementing This?

I’d love to hear from others who have struggled with design feedback challenges in tech. How do you currently handle feedback in your product development process? Have you found any methods that work particularly well? Let’s start a conversation.