Designing a live show interface that grew to nearly 30 controls by Aliaksandr ArekhvaDesigning a live show interface that grew to nearly 30 controls by Aliaksandr Arekhva

Designing a live show interface that grew to nearly 30 controls

Aliaksandr Arekhva

Aliaksandr Arekhva

A live show interface that kept growing.

Speakeasy Live, iOS. Over 18 months, the creator interface grew to nearly 30 actions. The design problem was keeping it clear.

Brief Overview

Speakeasy Live was an education-focused social platform combining live shows, podcasts, and chat. I joined as the sole designer in July 2021, when the iOS app was in open beta and the live show interface had a few basic controls.
Over the next 18 months, the team added what creators actually needed to run a show: recording, premium subscriptions, moderation, Q&A queues, participant management, tipping, and per-message replies. By November 2022, the interface held nearly 30 actions across show controls, participant actions, and chat.
The design problem wasn't fixing a cluttered original. It was keeping the interface clear while it grew.
I structured the screen around three layers based on frequency and urgency. Frequent actions stayed visible at the bottom. Configuration moved into menus. Per-participant actions opened in a modal. The structure held across every feature added.
We gathered continuous feedback from the founders, beta testers, and the team's own testing. By late 2022, the questions had shifted from how the interface worked to what to ship next.
The product reached over 30,000 registered users and 2 million cumulative iOS sessions before development was discontinued in January 2023 due to funding constraints unrelated to the design work.

Project metadata

Role: Senior Product Designer
Timeline: July 2021 – January 2023
Platform: iOS, Android, Flutter web
Responsibilities: Research, Design Direction, Information Architecture, Interaction Design, Visual Design, Design System, Prototyping, Design-to-Development Handoff

The Design Problem

When I joined, the live show interface had a few basic controls. Mic on/off, camera on/off, reactions, and leave. The product was in open beta.
Over the next 18 months, we added what creators actually needed to run a show. Recording and premium shows for monetization. Pinning, reply threads, and moderator assignment for chat control. Participant management with three states (guest on stage, Q&A queue, audience) for managing who appears on screen. Tipping, invites, and Q&A queues for engagement. Plus editing the show title mid-stream.
By November 2022, the interface held nearly 30 actions across show controls, participant actions, and chat. The list grew as the team learned what creators needed.
The design problem wasn't "fix the cluttered original." How do you keep adding features to a real-time interface for two years without it becoming the cluttered thing you're trying to avoid?
A live show isn't a normal interface. The creator is talking to an audience, watching chat, deciding who to invite to speak, and managing the guests already on stage. All at the same time, in real time, with no opportunity to pause. A two-step modal flow, where one tap would have worked, breaks the show.
The constraint compounded over time. A decision made in month three set the rules for the decision made in month thirteen.
How the Live Show creator interface grew over 18 months.
How the Live Show creator interface grew over 18 months.

Three Decisions

The interface didn't end up clear by accident. Three decisions shaped it, each at a different scale: structural, screen-level, and one button.

Decision 1: A three-layer hierarchy for the interface

The bottom action bar had four buttons from the start: Leave, Mic, Camera, and Reactions. As features kept shipping, I had to decide what belonged in the bar and what didn't.
The decision came down to a single control: chat settings. They felt frequent enough to live in the bottom bar. Creators sometimes change them mid-show when the conversation shifts. I drafted a version with chat settings as a fifth button.
It didn't hold up. Chat settings are secondary. Putting them next to mic and camera made the bottom bar feel crowded and pushed the primary actions into smaller touch targets. I moved chat settings into a settings menu, and the bar stayed tight.
That left me with a rule: if an action isn't time-sensitive and frequent, it doesn't belong in the bottom bar.
Applied across the whole interface, the rule produced three layers:
Frequent, time-sensitive actions stayed at the bottom of the screen. Mic, camera, leave. The actions a creator needs without thinking, sometimes mid-sentence.
Configuration moved into a settings menu. Moderator assignment, recording, edit show title, and chat settings. Used during the show, but a beat slower, where opening a menu is fine.
Per-participant actions opened in a modal with the user's profile and the available actions.
The rule held across every feature added after.

Decision 2: Required and Optional Fields in Start a Show

The setup screen for starting a show was small at first. Show title, description, that was it. As the product added recording, premium shows, chat settings, tags, and categories, the form grew with it.
The form had labels and sections, but no visual cue to distinguish required fields from optional ones. Creators only learned which fields were required when validation caught them at submission, in a modal listing what was missing.
Feedback from beta testers was consistent. They didn't know which fields were required until the modal told them. The validation caught errors at the wrong moment, after the creator had already committed to starting the show.
I restructured the form. Required fields stayed at the top, marked clearly. Everything else moved below a header that read "Optional Settings." The creator now knew what mattered before they touched anything.
The validation modal stayed. After the restructure, most creators didn't see it. The form itself had become the signal.
How the Show setup evolved over 18 months.
How the Show setup evolved over 18 months.

Decision 3: The tip button rearrangement

Tipping shipped after the bottom action bar was already designed. The bar for active participants (co-hosts, guests, and the first person in the Q&A queue) had four buttons: Leave, Mic, Camera, and Reactions. All icon-only, all roughly equal in weight, all justified by the actions the user needed during the show.
Tipping was available across the app. Any avatar or username tap opened a profile preview with a Tip button. The bottom bar was the dedicated entry point for tipping the creator, which made it the most prominent surface in the pattern.
The bar redesign came with two constraints:
The flow had to start in context. Tapping the bottom-bar Tip button opens a modal where the user picks an amount and adds an optional message. The user never leaves the show.
The button had to be visually prominent. Tipping was an action the platform wanted to encourage, and a creator's revenue depended on listeners noticing it was available.
Both constraints came from the same place: tipping was one of the platform's three revenue streams, alongside subscriptions and premium shows. Making it visible wasn't a UX nicety. It was a revenue lever.
In the first version, I added a Tip button to the bar next to the others. Functionally, it worked. Visually, it didn't. The Tip button looked like one more option among five, not the action the screen wanted users to take.
The problem wasn't adding a button. The bar was already balanced. To make Tip prominent, I had to make the other actions quieter.
I changed two things. I added a "Tip" label to the button alongside the icon, making it the only labeled button in the bar. And I rearranged the layout, so Tip sat in the center with a filled background, while Leave moved to the far left and Mic, Camera, and Reactions clustered to the right.
Tipping didn't become prominent by being loud. It became prominent because everything else got quieter.

The Final Interface

How we validated the work

Three channels of research shaped the work: video feedback from the founders after testing each build, direct messages from beta testers, and internal test shows the team ran together. We didn't run formal usability testing. I pushed for it, and the team didn't have the budget or the timeline. The founders' videos shifted from asking how the interface worked to asking what to ship next.

Outcomes

By November 2022, the product had real scale on iOS, and registrations were accelerating. Development was discontinued in January 2023. The company didn't close its next funding round. Growth and engagement weren't the issue.

Reflection

1. Plan the action bar as a system from day one, not as a layout.

This is the one I'd do over. I treated the bar as a layout problem when I started, and ended up redesigning it twice as the feature set grew. If I started today, the action bar would be a system with rules from the first sketch: what earns a place, what gets demoted into a menu, and what makes an action time-sensitive enough to stay visible. The rule that eventually held the interface together was the rule I should have started with.

2. Structure answers the user's questions before validation has to.

The Start a Show form taught me this one. A validation modal that lists what's missing tells the creator they got it wrong. A form that visually separates required from optional tells the creator what to do before they try. The first version is reactive. The second version is the design doing its job. I now reach for structure first. Validation is a backup, not a primary signal.

3. Prominence is a relative property, not an absolute one.

The Tip button taught me that you can't make something prominent in isolation. In the first version, the Tip button was a fifth icon on the bar, the same weight as the others. It read as one option among five. The redesign didn't make Tip louder. It made the other buttons quieter. Visual hierarchy is a zero-sum game on a confined screen, and the answer to "how do I make this important" is often "what am I willing to make less important."
Speakeasy is the project where I learned how to design for real-time. The constraints I worked against here shaped how I approach screens that the user can't pause.
Like this project

Posted May 18, 2026

Designed a live show interface that grew from 3 basic controls to nearly 30 actions over 18 months without losing clarity.

Likes

0

Views

0

Timeline

Jul 23, 2021 - Jan 16, 2023