Redesigning the StreamAlive live session experience

Problem

When I joined StreamAlive, the product already existed. It had been built by the engineering team based on the CEO's vision of what the product should do. Functionally it worked. But users were coming in and leaving. Nobody was sticking around and nobody really understood why.

There had been no user research. No one had sat with a host and watched them try to run a session. No one had asked why people were leaving or what was getting in their way. Features were being added based on what the team assumed users needed, which made it harder to know what to build next or why anything was not working.

The product had functionality. What it did not have was design. Nobody had thought through the experience from the user's point of view. That is where I started.

User Research

The CEO was already talking to clients regularly. I put together a set of research questions and asked him to run the conversations and share the findings back to me. I then synthesised everything using affinity mapping to find the patterns across what hosts were experiencing.

The same problems came up every time. Hosts had no visibility into whether their audience was engaged. They were juggling multiple tools mid-session and losing their flow. After the session there was nothing to learn from.

Assumptions to be validated

Before going into research I documented everything the team believed to be true about users and the business. Writing these down made them visible and gave us something concrete to validate or disprove through the research that followed.

User needs and challenges

I mapped everything into insight statements, problem statements, and how might we questions. For the first time the team had a shared picture of what hosts actually needed. It shifted the conversation from features to problems.

App architecture

With a clear picture of what hosts needed, I mapped the architecture around the core sequence: select an interaction, launch it during the session, let the audience respond in the chat they already had open, and review results afterward. Every section of the product needed to serve one of those moments.

I settled on six core sections:

My Presentations: The host's home base. Create, manage, and launch all presentations and interaction sets from one place.

Interaction Library: The full library of engagement types including polls, word clouds, Q&A, spin wheels, magic maps, and more, ready to add to any presentation.

Sessions: A history of every live session the host has run, with participation data and results for each one.

Themes: Visual customisation for how interactions appear on screen during a live session.

Reports: Session-level engagement analytics showing participation rates, top responses, and audience activity over time.

Integrations: Connections to Zoom, Teams, Google Meet, and other platforms that power the live chat response loop.

Making decisions with Wireframes

Before touching any visual design I built wireframes to check if the structure actually made sense. It was about flow, not looks. I shared them with the Head of Product early so we could sort out priorities before anything was built. Getting feedback at this stage meant changes were cheap.

AI-assisted prototyping

I used Claude to quickly prototype ideas and check what was feasible before committing to a direction. Instead of spending days designing something that might not work, I could test the idea in a few hours and bring something real to the conversation with engineers. It cut down a lot of back and forth and made decisions much faster.

Designing and shipping

I redesigned each section based on what users had told us. Every decision had a reason behind it. I worked directly with engineers throughout, not just handing over files but talking through edge cases, flagging problems early and adjusting when something wasn't going to work technically. We figured out tradeoffs together. I shipped in small pieces, watched how users responded, and kept moving. Each handoff included notes on why decisions were made, not just what they were.

Continuous research

Research ran alongside the whole project. I kept putting questions to the CEO, he kept taking them to clients, and I kept synthesising what came back.

Acting on the feedback

When something needed to change I updated the prototype, the CEO shared it with clients, and I refined it based on what came back. Short cycles meant we were never too far ahead of what we actually knew.

What changed

Hosts went straight to launching an interaction. The quick-launch bar became the centre of the experience because that is what the data showed. Every change was small, focused, and tied to something a real user had told us.

Outcome

Research before redesign. The biggest shift was doing the research before touching the design. Every team had been adding features based on what they thought users needed. Once we had actual user insight, the decisions became much clearer and we stopped building things that did not matter. The users who had been coming in and leaving started staying, and staying started turning into paying.