Agata Ageieva

Senior Product Designer

CrowdBuilding
2026

Broadcast messaging for initiative admins

One finding turned messaging from a chat between strangers into a tool for admins to keep their members updated.

Role
Senior Product Designer, sole designer
Company
CrowdBuilding
Timeline
May 2026, picked up again in August 2026
Platform
Web

01
Impact

Increase in total messages sent
+43%
Increase in read rate within 72 hours
+38%
Increase in reply rate
+17%

With a clear way to create and send broadcasts, admins kept their groups informed and engaged. Replacing the clunky third-party messaging app increased messages sent by 43%.

02
Context

Admins on CrowdBuilding need a way to keep their members updated. Messaging ran on an external library, essentially a copy of Slack, and it worked poorly.

Part of the problem was the implementation. The bigger part was the audience. Most of our users had never used Slack, and for them it was too much.

We could have improved the existing tool's interface. After a couple of iterations, building messaging in house looked easier, and it let us design around how our users communicate.

The old messaging, in Dutch: a Slack-style chat with a sidebar of channels and direct messages, unread badges, a channel with a file attachment, a thread with six replies, an @mention, a typing indicator and a status bar showing how many members are online.
The old messaging was a Slack-style chat that most members had never used before.

03
Reframe

Not a marketplace yet. A scouting platform.

A busy marketplace where everyone finds each other

  • Landowners find buyers
  • Experts find clients
  • Initiatives find members

A scouting platform for initiative takers

  • Experts weren't using it
  • Landowners struggled to use it
  • Initiatives used it as one channel to attract members, next to their own website, Facebook group and Instagram

When I started, everyone shared the marketplace picture. Before designing anything, I tested it by talking to users, and it didn't hold up. The people using CrowdBuilding were initiative takers, who used it to scout for new members. Their community lived elsewhere.

So the question for messaging became how initiative admins keep the people they've found engaged. Every decision after this point follows from that.

04
Problem

It's mostly admins who message

About 80% of users are regular members, and for them messaging is always one to one. Admins are different. They message one person, and they message many people at once.

So one tool had to work for two use cases, broadcasts from admins and one-to-one messaging for everyone.

That raised the two questions the design depended on.

  • Where does a reply to a broadcast land?
  • How does an admin keep track of the conversation when replies come back from many members?

Two constraints shaped the answer. The engineers had built the system for broadcasts from the start, so the model had to work with it. And for privacy reasons, I couldn't use screen recordings to see how people used messaging.

Diagram. A broadcast goes out to recipients A, B, C and D. A, B and D each reply, and their replies all lead to the admin inbox. Recipient C doesn't reply.
Where replies land. A broadcast goes out to each recipient on their own. Every reply comes back to the admin's inbox as its own conversation, and recipients who don't reply add nothing to it.

05
Method

Talk, measure, then prototype

Without screen recordings, I combined two sources. I talked to admins and members, and looked at the ratio between messages sent, read and replied to. That showed where conversations stalled.

Later I vibe-coded working prototypes and sent them to users, so they could react to something that worked instead of static screens.

Two coded prototypes of the messaging inbox, in Dutch, side by side. Both show a broadcast to all 24 members with replies from two members, each with a link to answer them personally. The left one lists mailing lists in a sidebar and labels replies as private in the header. The right one is a chat-style inbox with a note that only the sender sees recipients' replies, and marks each reply as private.
Two of the coded prototypes users tried. In both, replies to a broadcast are private and come with a link to answer each person one to one. The left one lists mailing lists and marks replies as private in the header. The right one is a chat-style inbox that marks each reply as private.

06
Assumptions

What we got wrong

  1. We assumed members wanted to chat.

    What happened We pictured a lively, interactive platform, but the product wasn't there yet. For now, the people who wanted to communicate were admins, keeping their members updated. Most members weren't looking to chat.

    What changed We designed messaging around admins, with broadcasts to keep members informed and simple one-to-one conversations for everyone else. This is where the broadcast model came from.

  2. We assumed CrowdBuilding was a busy marketplace.

    What happened Experts weren't using it and landowners struggled to. The real users were initiative takers, scouting for members.

    What changed This was the biggest shift of the project, covered in the Reframe section above. Messaging became a tool for initiative admins.

  3. We assumed our audience knew how to use Slack.

    What happened Most of our users had never used Slack. To them it felt like too much, not familiar.

    What changed We designed around how our members communicate, with simple one-to-one conversations and broadcasts for admins.

07
Decisions

The decisions and their trade-offs

  1. Broadcast, not group chat

    Admins send one-to-many messages as broadcasts, which keeps their workspace focused instead of turning every update into a noisy group thread.

    Trade-off: members don't see each other's replies, so there's no group discussion around an update.

  2. Replies to broadcasts live in two places

    Admins can find all replies to a broadcast under Sent, and can also reach each of them from their inbox.

    Trade-off: seeing replies in two places might feel redundant.

  3. Sent and Inbox are separate tabs

    Admins need to see what they sent out to their group.

    Trade-off: a second tab adds complexity.

Where a reply lands. In Sent, the broadcast shows 9/9 read, 1 responded, and lists the response. In the inbox, the reply is its own one-to-one conversation, marked "Group message reply", with the original broadcast folded on top. The admin answers there, and only that member sees it.

08
Solution

We shipped the in-house messaging tool, replacing the Slack-style chat. Members get simple one-to-one conversations. Admins can message one person or broadcast to many, with replies they can keep track of.

To broadcast, an admin picks recipients from their initiatives or personal contacts, or selects everyone in an initiative at once. Each reply lands in the admin's inbox as a one-to-one conversation with that member, linked to the broadcast it answers.

09
Reflection

What I'd do differently

I'd explore letting admins choose whether replies to a broadcast are visible to everyone or only to them. Some updates invite discussion, and others don't.

I'd also talk to users more, and sooner. At times we spent two hours debating something we could have asked users about.