In-app communications blueprint

Independent components that drift apart over time

For a long time, system→user communication had no shared service-design principles. If a warning, recommendation, or product update needed to be communicated, each domain's designer or PM handled their own component and flow. That keeps teams fast and independent — but the longer it runs, the more these components drift apart, and the overall service design suffers.

Inconsistent, collectively annoying, no source of truth

Per-domain components were becoming inconsistent and, collectively, annoying and incoherent — banners, popups, badges, and walkthroughs with no shared rules, frequency caps, or visual language. There was no single source of truth for which component to use, when, and with what guardrails. The support data backs the cost: fragmented, unhelpful in-product comms push users to leave the product (and even to external AI) and open tickets.

Inventory, converge, document, then lower the barrier

1. Inventoried the component landscape across domains — popups (center / bottom-right / top-right critical), embedded banners, badges, resource center, feedback, guided walkthroughs, overlay/backdrop, notification-count badge.
2. Deep cross-functional collaboration with Product Ops, PMs, and designers across domains to converge on shared rules: frequency caps, dismiss-and-remember across sessions, a global off toggle, page-matched relevance.
3. Wrote it down for non-designers — a blueprint with documentation aimed at Product Ops (not just designers), plus a Figma file and a component ↔ code-existence matrix so teams know what exists vs. what must be built.
4. Lowered the barrier further — built a GIA skill for the Product department: describe your need / idea / goal → get the best-match component, plus next steps for alignment and sign-offs (who to talk to, how to set it up, and the component's limitations / guardrails).

One system, delivered in three layers of accessibility

A reusable in-app communications blueprint: a catalog of components, usage guidelines, guardrails, and a code-existence matrix — turned into simple, followable instructions so any team can keep the experience holistic and non-annoying. Delivered in three layers of increasing accessibility: documentation → Figma → GIA skill.

Principles where there were none — and an interactive tool

Shipped a blueprint + documentation consumable by non-design partners, a Figma source of truth, and a GIA skill that operationalizes it for the Product department — turning a static guideline into an interactive decision tool with sign-off guidance, where no shared service-design principles existed before.