Messenger

Messenger grew one request at a time, until the requests stopped being separate problems.

Role

Senior Product Designer: led research, product framing, UX/UI and interaction design

Challenge

Messenger had to absorb social channels, BYOC, filtering, AI and years of smaller requests, without making a normal conversation feel heavier.

Goal

Bring more customer communication into one place without making existing users relearn Messenger.

6%Social channel adoptionActive Messenger workspaces

18KSocial messagesFirst month across new channels

62%Setup completionStarted setup to connected

8%BYOC adoptionEligible workspaces

+5%Messenger activity

421Social accounts connected

233Filtered views created

Rounded portfolio figures. Directional only, not exact internal data.

How a backlog of small requests turned into one redesign

Messenger did not start with a redesign brief. It started with years of requests: social channels, BYOC, filters, AI and smaller fixes. Individually, none justified a rebuild. Together, they were starting to collide.

01 / Discovery

It was time for the new, better version of Messenger

I put three pressures on one board: users wanted WhatsApp, Facebook and Instagram in Textmagic; Product wanted to move beyond SMS and support BYOC; Messenger itself carried filtered views, AI ideas, customization and UX debt. The interesting part was how often those requests touched the same foundations.

02 / Hypothesis

Which problems were actually worth solving?

A long backlog has an annoying side effect: after a while, everything looks equally important. I treated the scope as assumptions, not commitments. Some already had strong user signals; others still had to survive follow-up research and product constraints.

If Messenger unifies multiple channels, users should switch tools less during everyday conversations.
Confirmed
If WhatsApp, Facebook and Instagram live inside Messenger, customers should keep more of their day-to-day communication inside Textmagic.
Partially confirmed
If channel filters scale with volume, triage should stay fast as more channels are added.
Confirmed
If BYOC lets customers connect the CPaaS providers they already use, adopting Messenger should require less migration and setup effort.
Partially confirmed
If the core conversation model stays familiar, new capabilities should not require relearning Messenger.
Partially confirmed
If advanced controls stay behind progressive disclosure, the default inbox should remain calm and simple.
Partially confirmed
If provider setup lives outside the everyday inbox, Messenger can support more channels without making routine conversations feel heavier.
Partially confirmed
If channels, filters, providers and conversation states share one foundation, one redesign should prevent repeated UX rework across releases.
Confirmed
If backlog items ship one by one, we should move faster without creating temporary interaction patterns.
Failed
If channel-specific differences live in states and details, one Messenger should still feel coherent.
Partially confirmed
If connected channels create real value, users should return to Messenger instead of separate tools.
Partially confirmed
If contacts, context and actions persist across channels, switching channels should feel continuous.
Partially confirmed
If every new option is shown upfront, discoverability should improve without making the everyday Messenger experience feel noticeably heavier.
Failed

03 / Framing

We went back to users with better questions

Once the rough scope was visible, I stopped asking what a “better Messenger” should look like. I asked how the work broke: which channels people used, where switching hurt, what they filtered, and how a new account or provider should connect. Competitor review gave us both familiar patterns and the less glamorous setup mechanics behind them.

User needs

Interviews, surveys, feature requests, support feedback and follow-ups about what customers needed.

Analytics & KPIs

Usage and other measurable signals to check what people actually did in Messenger.

Signal source

Business goals

Strategic priorities, product direction and constraints that shaped where Textmagic wanted Messenger to go.

Competitor research

What other products prioritised, how they solved similar jobs and which patterns had become familiar.

04 / Product definition

By then, it was clear we were not designing one new feature

Mapping the research back to the backlog exposed the real problem: channels affected filtering, provider connections affected setup, and more conversation types multiplied states. Treating each item as a mini-project meant redesigning the same foundations again and again.

Once the dependencies were visible, the backlog stopped looking like a list.

Research board connecting Messenger backlog, customer evidence, product constraints and competitor patterns.

05 / Trade-offs

“Wrong” way to make changes

Smaller releases were easier to schedule. But because the same foundations kept moving, they also meant knowingly shipping temporary patterns. The trade-off was not speed versus scope. It was one larger redesign versus solving the same problem several times.

Small releases vs one connected release

Channels, filters, provider setup and conversation states shared the same foundations. Smaller releases reduced each release, but created temporary patterns we already knew we would replace.

Decision: Group the dependent changes into one Messenger redesign.

More capability vs keeping Messenger familiar

Messenger could do more without feeling like a different tool. Existing users already knew where to look and how a conversation behaved.

Decision: Preserve the core interaction model and layer new capabilities around it.

Show everything vs keep the default experience calm

New channels, filters, AI and provider controls could easily turn Messenger into a cockpit. The complexity had to exist without being visible by default.

Decision: Use states and progressive disclosure instead of exposing every option upfront.

06 / Success criteria

We needed to know whether people actually moved more communication into Messenger

More messages alone would not prove much. The better signal was whether customers connected new channels, finished setup, returned to Messenger and relied less on separate tools. The business bet was consolidation, not a cosmetic redesign.

Channel adoption

Connected social accounts
Connection completion rate
Abandoned / failed setup
Conversations by new channel
Messages via new channels

Messenger engagement

Total messages sent
Active conversations
Time in Messenger
Filtered views usage

Product & business

Multi-channel users
Retention / stickiness
BYOC connection rate
Messages sent via BYOC
Share of communication in Textmagic

Best signal: customers move more everyday communication into Textmagic instead of another tool.

07 / Ready to design

By then, the backlog had turned into an actual release plan

Research did not hand us the interface. It gave us priorities, dependencies and a few clear “do not break” rules. From there the design question was simple: how much capability can we add before a normal conversation starts to feel heavy?

Core states

Before drawing the full flow, I split Messenger into parts that could change independently: chat list, conversation, actions, details and reply. Then I designed states for each. The prototype behaved more like a product, and edge cases stopped hiding between screens.

Annotated Messenger layout with arrows identifying the chat header, navigation, chat list, conversation, actions, details and reply field.

A chat row became a system of states

A chat row looked simple until you added selection, unread state, channel, assignment and status. I turned those into states and variants so we could combine behavior instead of redrawing every scenario. Once the model worked at component level, I applied it across Messenger.

Chat row variants for unread, active, hover and other conversation states. — Chat line item states

Figma component properties controlling the chat row variants. — Chat line item settings

List of chats states

The same model had to hold together as channel, assignment and unread status changed. I checked those combinations as a system rather than as isolated screens, applying only the states each area needed.

A matrix of Messenger chat-list states and combinations from the Figma component system.

More capability, same mental model

By the end, we could walk complete journeys in Figma: switch context, change states, open details and reply. We could watch the rest of the UI react. That mattered because the redesign was never about one screen. It was about whether all the moving parts still felt like one Messenger.

Final Messenger workspace with the chat list and active conversation. — Default Messenger view

Editing a note inside a Messenger conversation. — Edit note process

Messenger settings for 10DLC registration. — 10DLC registration section

General Messenger settings and configuration. — General settings of Messenger section

Summary

Messenger was not redesigned because one feature failed. It was redesigned because years of requests had started colliding. We grouped the shared problems into one release, added channels, BYOC, filters and new states, and protected the familiar interaction underneath.

Early Messenger signals