Case study · Service design
Designing a communication architecture for a multi-sided marketplace
How the Automated Notification System turned a blind platform into one that could see itself.
- Year
- 2024
- Role
- Senior Product Designer
- Industry
- B2B Commerce · Emerging Markets
- Team
- PM-led, cross-functional
- Scope
- Service-design layer
Image 1 · Communication architecture (before / after)
Three actors (buyer, seller, back office) as nodes: fragmented and blind on one side, linked through a central notification layer on the other. Restrained, editorial, conceptual, not a product screen.
RedCloud runs a multi-sided B2B commerce marketplace across four emerging markets, connecting buyers, sellers and internal field-force teams. By late 2024 the platform had grown to a point where one problem was hurting it operationally and commercially: nobody could see anything.
A buyer would place an order and hear nothing for days. A seller received orders in the system but didn't know when to prepare or dispatch. The back office found out about issues only when a buyer or seller complained. Field teams operated on instinct rather than information.
The symptoms showed up everywhere, back-office burnout from constant firefighting, buyers disengaging because they couldn't tell whether the platform was working, sellers missing opportunities because they didn't know what needed their attention, and revenue leaking through orders that fell through the cracks.
The real problem
It wasn't a design problem or an engineering problem. It was a communication-architecture problem: the platform had no systemic way for the right information to reach the right actor at the right moment.
Every notification was manual, every escalation reactive, and every gap in the experience was quietly costing the business trust and money. That was the trigger for ANS, the Automated Notification System.
Illustration A · The blind marketplace
The 'before' state: buyer, seller and back office each in their own bubble, with question marks and missing arrows between them. Confusion and disconnection, no caption needed.
ANS was led by our PM, Elizabeth, who owned the operational architecture, the technical sequence design and the wider system framing. My role was the design layer underneath it, turning the operational spec into something that mapped to how users actually experienced the product.
The method was straightforward but unglamorous. You can't design a notification system in the abstract; you have to know, at every specific moment in the existing product, where communication is missing and what a user needs to see or know at that point.
So I audited the entire product, screen by screen, across three actor flows (Buyer, Seller, and Internal Field Force) and five customer stages: onboarding, app activity, order placement, post-purchase (delivery and pickup), and payment and reconciliation.
Image 2 · Screen-by-screen annotated flows
A 2×2 grid pulling one representative flow from each stage (onboarding, app activity, order placement, post-purchase), real product screens with communication-gap annotations overlaid.
At each screen I asked the same questions. If I were this user, here, now: what am I trying to do? What am I missing? Where would I want the platform to reach out to me? What would tell me something was wrong before I had to ask? What would make me act, or trust, or stay?
The output was a set of annotated flows, every screen mapped, every communication gap identified, every touchpoint tagged with a proposed trigger and message shape. That ground-truth audit is what let Elizabeth's operational sequences translate into a notification system that fit the actual product, rather than sitting alongside it.
30+
Touchpoints mapped
3
Actor flows
5
Lifecycle stages
4
Success metrics defined
The screen-by-screen audit surfaced 30-plus distinct communication touchpoints across the three actor flows. That was too many to build at once, and not all of them mattered equally. The next design problem was prioritisation: which notifications would move the needle, which were quick wins engineering could ship in a sprint, and which were strategic investments that needed real infrastructure?
We built a priority matrix, plotting every touchpoint on two axes (effort to build against expected impact), colour-coded by actor (buyer, seller, back office, lending) so the distribution across the marketplace was legible at a glance. Four quadrants: quick wins, strategic investments, nice-to-haves, and avoid-or-later.
Image 3 · Priority matrix
The real artifact: all 30+ touchpoints plotted across effort and impact, colour-coded by actor, legend visible so the quadrants and actor colours read at a glance.
Quick wins
Buyer-side transactional moments, cart-abandonment nudges, payment confirmation and failure alerts, dormant-buyer re-engagement, low-stock alerts for sellers, catalogue reminders. High impact, low build, mostly reusing existing platform events.
Strategic investments
The load-bearing ones, onboarding-completion nudges, cancelled-order investigation, seller-performance notifications, payment reconciliation. Higher effort, but each tied to a specific commercial outcome the business was actively losing money on.
Nice-to-haves & later
Documented but deprioritised, ad-hoc internal notifications, one-off campaigns, heavy governance workflows, fully AI-personalised journeys. Real ideas, just not where phase one needed to spend its budget.
Not a wish list
The matrix was a build order. Engineering knew what to ship first, the business knew which commercial outcome each notification solved for, and the touchpoints laddered up into a coherent system, not a pile of features.
ANS shipped as a documented, prioritised and technically specified notification system, ready for engineering to build out in phases. Two artifacts carried the work into production.
Image 4 · Multi-actor journey maps
Three panels across the full customer lifecycle, each stage broken down across every actor (buyer, seller, back office, field force). Colour bands distinguish actors; communication gaps annotated at every step.
The multi-actor journey maps sat as the ground-truth reference for every subsequent decision, every stage, every actor, every gap visible in a single view. When a debate came up about whether a touchpoint mattered, the team could point at the map and see it in context.
The UML sequence diagrams, led by Elizabeth, translated the design layer into technical specification. Every notification the maps identified became a precise sequence engineering could build against, exactly which actor triggered which system event, and what ANS should do in response.
Image 5 · Illustrated sequence flow
One touchpoint end-to-end (cart abandonment): buyer triggers event → ANS receives → conditions met → notification fires to buyer, with a parallel signal to seller / back office. A designed diagram, not a raw UML dump.
The output
Not a set of screens or a new feature, infrastructure. A framework the wider team could build against, phase after phase, without rediscovering the underlying logic each time.
Parts of ANS are live. It's a phased rollout, and engineering has been shipping touchpoints against the priority matrix as capacity allows. Because RedCloud treats performance data as sensitive, I can't share adoption numbers, but I can share how the system was designed to be measured, because that shaped the design work itself.
The load-bearing question the whole system asks: does targeted, contextual communication actually shift behaviour across the marketplace?
Four things designed to be tracked as the rollout continues:
Notification engagement, by actor & touchpoint
Do buyers open payment-failure alerts and act? Do sellers act on inventory nudges? Engagement varies by actor and moment, so the per-touchpoint breakdown matters more than the aggregate.
Downstream conversion on transactional nudges
Cart abandonment, payment failures and dormant re-engagement sit closest to revenue. If they lift completion and re-engagement, the commercial case holds; if not, the messaging or timing needs work.
Back-office ticket volume
The original trigger was a back office drowning in reactive work. If proactive notifications shift the load, ticket volume on preventable issues should drop and the team should move onto higher-value work.
Onboarding completion rate
Dropped onboarding was the highest-priority strategic investment for acquisition. If completion lifts after the onboarding nudges ship, that's direct evidence the framing held.
Every touchpoint the matrix defined had an explicit hypothesis attached about which behaviour it was trying to shift. That was deliberate: as the rollout continues, the team has a clean read on which touchpoints to double down on and which to redesign.
The design problem wasn't the notifications. It was the absence of a communication architecture. A multi-sided marketplace only works when the right information reaches the right actor at the right moment. Engagement, trust, revenue, and back-office capacity all sit downstream of that.
The bigger lesson, the one I've carried into everything since: design at this level is service design first, interface design second. What screens show and what buttons say matters, but only after the systemic question is answered: who needs to know what, when, and why. Get that architecture right and the interface decisions become obvious. Get it wrong and no amount of interaction polish saves the experience.
ANS also taught me the value of designing inside someone else's initiative. Elizabeth owned the operational architecture and the technical framing; my job was to contribute a design layer strong enough that the spec could be built against the real product, not an idealised version of it. That kind of embedded, cross-functional contribution is what most high-leverage senior design work actually looks like, not always leading from the front, sometimes leading from inside.
“Design at this level is service design first, interface design second. Get the architecture right and the interface decisions become obvious.”
Design principle carried into all subsequent product work
Building a design system for an AI-first team
