Broadcast Builder Redesign

Context

Broadcast is how every Mobile Commons customer reaches their audience, and it's the feature sales leads with to win new ones. When the experience falls short, it's felt by current customers and prospects alike.

Given what was at stake for the company, its customers and its pipeline, I was asked to lead and own the redesign. That meant the full arc: understanding the problem, defining the solution, aligning PM and Customer Success, and seeing it through launch.

The problem

The builder could do a lot, but it showed everything at once with little structure or guidance. Users carried unnecessary cognitive load, and their focus drifted away from the one thing they came to do: send a message.

Picture a marketer halfway through a broadcast who realizes the audience they need doesn't exist yet. They open a new tab, build the audience there, then come back and find their place again. The same detour repeated for links, images and other assets.

• Too much, too soon. Features and options were presented without hierarchy, so users had to work out what mattered at each step.
• Constant context switching. Creating an audience, a link or an image meant leaving the builder for another browser tab.
• No preview while creating. Users couldn't see what their message would look like until they were done.
• A dated interface. Next to competitors and industry standards, the UI looked behind, which matters for the feature that sells the product.

Process

I ran the project from first evaluation to post-launch tuning, bringing PM and Customer Success in early so the solution reflected what customers were actually telling us.

1. Understand. I evaluated the core tasks to find existing issues and opportunities. I interviewed customers about their frustrations, and analyzed how key competitors solved the same problems and where they fell short.
2. Define. I turned those findings into a solution direction anchored on the issues we'd confirmed.
3. Explore with the team. Early drafts went to my PM and Customer Success for fast conversations before any polish.
4. Refine. I designed the high-fidelity version based on that internal feedback.
5. Validate. I ran concept tests with customers to confirm the overall direction before build.
6. Ship. I prepared the handoff for engineering and supported the build.
7. Measure and adjust. After launch, I tracked how it performed and made adjustments. [What did you adjust?]

Key decisions

Each decision maps to a problem we confirmed in research. [Confirm the patterns used and add one line of evidence for each.]

• Create without leaving. Audiences, links and images can be created from inside the builder. [Side panel, modal or inline?]
• Preview as you build. A live preview shows the message as the user writes it.
• Guided structure. The flow surfaces what matters at each step instead of everything at once. [Steps, sections or progressive disclosure?]
• A modern UI. The interface was brought up to current standards. [Built on the design system?]

Outcome

The redesign shipped as a simpler, more intuitive builder that addressed every issue we identified. Users could now stay in one flow, see their message as they built it, and get to send with less effort.

[Add one or two pieces of evidence. Any of these work:]

• [A number: time to create a broadcast, drafts abandoned, support tickets about Broadcast, or adoption of the new builder]
• [A signal from CS or sales: fewer how-to questions, or Broadcast demoing better with prospects]
• [A customer or PM quote]

[Optional, if true: The new structure also gave us room to add new message types later, starting with RCS.]

What I'd do differently