BLOG

Communities are adoption infrastructure, not an event calendar

Internal design communities create value when events connect people to follow-up paths, reusable resources and adoption signals.

DesignOpsCommunityAdoptionProgramme leadership

DesignOps leads, community leads, design managers and UX leaders

An internal design community can look healthy from the outside. There is a monthly session, an annual event, a growing distribution list and enough attendance data to make the update slide look tidy.

That still does not mean the community has changed how anyone works.

The useful question is not whether people showed up. It is whether the organisation became more able to act after the session ended.

At BMW, I ran Knowledge Cafe sessions, UX forums, hackathons and town halls, and led the India chapter of our annual UX community event across two editions. The programmes that mattered were not the ones with the fullest agenda. They were the ones that connected somebody to a next step: a service, a person, a resource, a support route or a reason to contribute.

Operating model diagram showing a local UX hub connected to intake, enablement, global support, consultation, delivery support and improvement paths, with community as one of the foundations.

An operating-model view of community work: the event is visible, but the lasting value comes from the routes around it.

FIG. 1 - EXISTING PORTFOLIO ASSET

The calendar is the visible part

Events are easy to see and easy to manage. They have dates, invitations, run sheets and a number at the end that can be reported.

What the event is actually for is harder to see. Someone discovers a service they did not know existed. A team finds out who to talk to about a problem they had given up on. A practitioner realises the thing they built is worth sharing. A recurring question finally reaches the person who can fix it.

That is the real product. The session is just one way to deliver it.

Recurring and annual do different jobs

We ran both, and they were not substitutes.

Recurring sessions respond to what is happening now. Our Knowledge Cafes ran regularly, usually with fifty to sixty people, and covered the questions teams were already asking: design system usage, UX measurement, in-app feedback, AI workflows and Figma setup. Across the series, attendance reached roughly eight to nine hundred people. The repetition mattered because people who missed one session could catch the next, and the organisers could see what the community was struggling with over time.

An annual event creates a bigger moment. Our UX community event grew from around eighteen hundred unique attendees in 2025 to twenty-four hundred in 2026. Because those figures count unique attendees across the sessions, they are a reach signal I am comfortable using. The event connected locations, brought in outside perspectives and gave internal practitioners a platform instead of leaving them only as an audience.

The two formats fed each other. The annual event surfaced themes and speakers for the year. The recurring sessions turned that energy into something people could use in their own work.

Programme from demand, not from topics

The easiest way to fill a calendar is to pick interesting subjects. The better way is to look at what people keep asking for help with.

When the same questions appear in walk-ins, support channels and post-session conversations, that is the next programme. For us, the demand moved through design system usage, design-to-code AI workflows, Figma access and practical setup. We did not decide those topics were important in isolation. The community told us, repeatedly, and the sessions followed.

That changes the community from a broadcast channel into a listening system. It also makes the programming easier to defend, because the agenda is tied to visible demand rather than personal preference.

Build the path after the session

Every session should be able to answer: "What do I do next, and who helps me?"

A design system session should connect to the starter file and a consultation slot. A measurement session should connect to onboarding for the actual tool. An AI session should connect to the setup people need before they can try anything. A community presentation should connect the audience back to the speaker or the material, not end when the call ends.

Without that path, every event has to generate awareness from zero. Someone may be interested on Thursday and have forgotten by Monday. With a path, attendance becomes the start of a better signal: how many people took the next step.

Attendance needs context

Large numbers look good in a portfolio and in a leadership update. They still need definition before they mean anything.

Were they registrations, live attendees or unique people? Did they describe a global event or one local chapter? Did growth come from a larger audience, better promotion, more sessions or a different counting method?

For this work, the figures I use are unique attendees across all sessions. That is why the growth from eighteen hundred to twenty-four hundred is worth reporting. Reach is real. It is just not the same thing as adoption, and the more useful question is what happened after people arrived.

Community work is leadership without authority

You cannot require attendance. You cannot standardise how every team works. You do not control every speaker, stakeholder or calendar.

Most of the work happens through influence, which makes internal community building a practical test of programme leadership. You have to find the shared need, make the session credible, coordinate senior people and practitioners, manage the logistics and keep the whole thing trustworthy across regions and time zones.

Execution still matters: run sheets, facilitation, accessibility, speaker care and follow-up. If those fail, nothing else lands. The mistake is treating execution as the outcome rather than the floor.

The test I use

After the session ends, is the organisation more able to act than it was before?

Someone knows where to get help. A team adopts a service. A practitioner becomes a speaker. A repeated question becomes a documented answer. A local chapter starts contributing to the global programme.

The calendar is the visible layer. The relationships, follow-up paths, reusable material and feedback into shared services are the quiet layer underneath. That is where a community turns into organisational capability.