Design System Steward

Comms & Contribs: Designing Participation and Buy-In

design systems governance communications strategy
6 min read

Communication and contribution conventions are system design, not PM work. I designed the participation conditions that brought Currency out of stealth, and that let Fluent scale with humans and agents both.

Delivered

14

new members in month one
resolution time cut from 5+ days

In flight

22

contributors in the repo

Enables

38

agile teams reached
by year end

Made Currency legible to the org: a baseline audit, a shared email alias, an open Teams workspace, a messaging matrix, and a published comms calendar.

New contributors onboard without me as the index. The team knows what done means, and the org knows who owns what.

Currency stopped being invisible. Designers and developers stopped hunting for context.

Gave Fluent its participation rules: a workshop that produced CONTRIBUTING.md, AGENTS.md, and named sacred-area ownership, plus a release cadence partner teams can plan around.

Agents work to the same contract, so non-human contributors arrive under the same rules as everyone else.

Leadership moved from asking what the team did to backing the work.

The problem most teams don’t see

A design system lives or dies on whether the people depending on it can participate. Find answers. See what’s changing. Contribute back. When participation is friction-full, adoption stalls even when the system itself is good. When it’s frictionless, the system compounds.

Most teams treat communications cadence and contribution conventions as PM-and-comms work, downstream of the “real” design system. That misreads the layer. The conditions for participation are themselves system architecture. The artifact level and the participation level are both governance.

Two contexts, one move

I’ve worked on this problem in two places. At M&T Bank’s Currency Design System, the system had genuine grassroots adoption but operated in stealth mode. Practitioners couldn’t see what was changing. Leadership couldn’t see the value. Developers couldn’t get answers without routing through designers. At Fluent, a new repo had architecture but no shared conventions for branching, reviews, ownership, or the operating rules for the AI agents now contributing to it.

Different problems on the surface. Same underlying gap: participation wasn’t designed for.

At Currency: making the system legible to the org

I ran a baseline audit. Channel preferences by role, question-resolution time (many beyond five days), access asymmetries (designers had Currency, developers had to route through designers). The audit was itself the strategic artifact. It made the gap legible to leadership, who could then back the work.

The mechanisms followed:

  • A dedicated email alias on every doc, so designers and developers had the same path to the team
  • An open Teams workspace with discipline-split channels and cross-discipline tagging, so specialized routing didn’t fragment into silos
  • A messaging matrix mapping desired outcomes (build trust, increase investment, reduce drop-off) to required messages, audiences, and channels
  • A published comms calendar with weekly practitioner syncs, monthly release demos, and a quarterly leadership rotation through the C-notes newsletter (rotating template, reusable across maintainers)

Currency messaging matrix board. Four columns labeled Audience, Channels, Messages, and Outcomes, each populated with sticky notes. Audience groups practitioners (Product Design, Content Designer, Developers, Researcher, Product Owner) and leadership tiers (Design and Dev management, CX and Segment heads), color-coded by distance from the team. Channels lists Teams channels (#currency-bugs, #design-systems, #wilmington-design, #design-system-team), brand-specific syncs (MT and WT Currency sync), and docsite release notes. Messages lists New version coming, Hot fix, Upcoming work, Feature highlight, adoption and contributor success stories, requests for feedback and contribution, Shout outs, Testimonials, Pro-tips, Known issues, and Admin updates. Outcomes lists Increased adoption, Increased system awareness, Increased trust and decreased user drop-off, Sense of ownership and contribution, Increased investment, Increased business alignment, Increased communal celebration, More cross-brand collaboration, Less repeated work across WT and MT, and Broader sense of community.

The messaging matrix. Audience to channels to messages to outcomes, mapped on a board the team could vote and contribute against.

Within the first month: fourteen new Teams members, drop in unmonitored adoption, decrease in status-related inquiries. Leadership stopped asking what’s happening with Currency and started asking what’s next.

At Fluent: making the system legible to itself

The Fluent repo had structure but no participation rules. Who reviews what, who owns what, what done means for a component, how AI agents should behave when they edit alongside humans. None of this was tractable through unilateral decisions, so I designed a workshop to make them collectively decidable.

The format itself was the move. I prepared a FigJam with bucketed prompts: branching, commits, reviews, sacred areas, deprecation, agents. Each bucket was time-boxed, votes recorded, additions welcomed. Decisions were the output, not consensus theater.

The Design system conventions workshop board. Bucketed columns cover Review groups and required approvals, Review-specific chat, Definition of Done, Merge philosophy and branch deletion, Branch naming, Token governance, NPM governance, Breaking changes and deprecation, Review/Discussion standards, and branch on branch. Each bucket holds colored sticky notes contributed during the time-boxed session.

The workshop board, post-session. Buckets, stickies, votes recorded.

Three artifacts landed from the workshop’s decisions:

CONTRIBUTING.mdThe human-facing conventions: branch naming, Conventional Commits, squash-merge enforcement, definition-of-done for components (spec files, Figma build, HTML demo, review skills), and the review cadence
AGENTS.mdThe same conventions humans follow, encoded as operational rules for the coding agents (Claude, Copilot, Cursor) contributing alongside them
Sacred-area ownershipTokens, NPM packages, and publishing config each have a named owner. Additions allowed, renames after 1.0 forbidden, no silent removals

AGENTS.md was the new category. There was no precedent for it in our repo, and the team had to decide that agents got conventions, not exceptions. Encoding the rules that way also made them readable by the things they govern. An agent reads the contract before it edits, which is the only version of this that scales past the number of rules a person can hold in their head. Naming owners for the sacred areas is what gives the whole thing teeth.

Enabling inheritance and extension

Partner teams needed a way to build on the system without forking it wholesale. Where that landed is modular plugins. Teams take the pieces they need and inherit or extend on top of them in whatever way suits their stack, and the guardrails travel with the pieces, so a team can be opinionated locally without drifting from the system. The part that matters most to me is the reach. Teams that don’t build on Fluent’s tech stacks at all can still take the design literals and the UX guidance. The language layer travels even when the implementation layer doesn’t.

The promotion path runs the other way. When several products extend in the same direction, that pattern gets pulled down into the horizontal layer rather than living forever in each product’s private space.

Publishing and release

The comms discipline didn’t stop at the conventions. I also ran Fluent’s release cycles, which is where encoded rules actually reach the people and systems downstream of them. A convention that lives only in the repo governs nobody. The release is the delivery mechanism, carrying design releases, icon merges, and the comms that announce them on a calendar partner teams can plan against instead of reacting to surprise drops. Same instinct as Currency, at a different scale.

Currency 2022 Touchpoints Calendar in Miro. Twelve months as rows showing daily coverage across the year. Color-coded blocks mark sprint cycles, release demos, planning sessions, and scheduled comms touchpoints. Black callouts mark major milestones: Shop closed (January), Spike for maintenance and addressing technical debt (August), and Shop closed for the year, vacation, maintenance, and new year planning (December).

Fluent April 2026 release calendar in dark mode. Seven-day grid showing the month. Green-shaded days mark sprint cycles, with Sprint start markers on Mondays and Sprint end on Fridays. A pink-bordered Thursday April 23 highlights the Design Release. Friday April 24 carries a Comms marker and an Icon Merge marker. Flags mark holidays (German flag April 1 and 6, Canadian flag April 17). Toggle controls at the top right show the user can toggle sprints and switch months.

Currency’s 2022 touchpoints calendar and Fluent’s April 2026 release calendar. The whole year mapped on one canvas, then the same discipline rebuilt at sprint scale.

Currency C-Notes Q421 Executive Brief. Green header with the C-Notes logo (a stylized coin marked C) and Currency Executive Brief Q421 subtitle. Opening section titled What a year! summarizes 2021 accomplishments: Figma migration in Q1, contribution model in Q2, release cadence and transparency in Q3, and 38 agile teams adopting Currency by Q4. Below: But the best is yet to come previews 2022 plans for an NPM package, a responsive docsite, and web components. Signed with the Currency design system logo and an email contact.

Fluent partner-facing email titled Get ready for something big. Colorful gradient FLUENT wordmark at top with a Q&A subscript label. Body text invites recipients behind the curtain for a Fluent 2 docsite preview, with an embedded screenshot of a Design Principles section. A See the site call-to-action button sits below. Further down: We can't wait to hear what you think invites feedback through forms and Github, and There's more to come previews additional features for design language, UX guidelines, and component guidance with iOS and Android platform expansions. Microsoft footer.

Currency’s C-Notes and Fluent’s docsite-preview email. Different brands, same move: leadership and partners hear from the team on a calendar they can plan against.

What this enables

Both moves were upstream of the artifacts. They designed the conditions under which artifacts could be built, found, contributed to, and trusted.

At Currency, the system stopped being invisible to the people who needed it. Designers and developers stopped hunting for context. Leadership stopped asking what the team was doing and started backing the work.

You’ve created an open, collaborative space that helps teams align on coherence work across Microsoft products. By inviting the broader content design community, you’ve expanded participation and impact.

— Melanie Hogue, Content Designer 2

At Fluent, the repo stopped being a private workspace and started being a shared institution. The team knows what done means. The org knows who owns what. Agents have a contract to operate within. New people, human or otherwise, can onboard without me having to be the index.

The discipline

Communications strategy is governance. Contribution conventions are governance. Designing the conditions for participation is the work most people don’t think to do, and it’s where adoption is won or lost.