Be inviting

• Lead by example: Stage and choreograph the initial meetings so people can feel comfortable after a while to do this in their own. Show by example how you want things to work in the future. Make sure that everyone can answer questions about the new processes.
• Listen to the quiet ones: A big part of having design systems is having conversations. You are actively seeking people out so shouldn’t expect that people just come to you. You should create a space for people who are not vocal, so that these people are still able to participate easily and that they have the same impact as the loud people. Use for a meeting a living agenda made by GitHub issues. Document decisions there. This is also helpful for remote people and people who are on holiday.
• Share work in progress: Updates have an impact to peoples work, no one likes change very much. If users don’t like what you’ve created for them and they’re not invested in it they are starting to rejecting it and this is how design systems die. Have »show and tell« meetings. Share meeting notes which can be commented afterwards. Document everything

— Inayaili de León, Microsoft Azure / Source (YouTube)

Bi-weekly components check-ins

IBM has bi-weekly component check-ins: These meetings are not to approve, deny or decide on other peoples work. These meetings are meant to learn from real use cases. They give the users of the design system the chance to communicate.

Step 1: Don’t be the design police. 👮🏽‍♀️🚨

Step 2: If you see something, say something. 👀🤔

— Bethany Sonefeld, IBM / Source (YouTube)

Design bug rotation

They use a bi-weekly meeting called Design Bug Rotation: “Inspired by the engineering organization, the Design team created the Design Bug Rotation to help pay down our design debt. Every two weeks or so, a group of designers would get together for a couple of hours to fix what we called design bugs. These were things that didn’t hinder functionality and wouldn’t have been filed as an engineering bug, but were places where we were using an old component, an existing one incorrectly, or a one-off alteration. As anyone in the company encountered one of these bugs, they’d file a ticket under a shared Jira board. During a rotation, designers would go through the list and chip away at them.”

— Magera Moon, Etsy / Source (Medium)

Design systems council

The Design Systems Council meets every two weeks. The selected group of representatives is made of product-area, subject-matter, or platform experts. They give updates on anything happening within their product area that could impact everyone and they evaluate, advise, and make decisions on proposed changes to the system. Representatives would rotate roughly every six months to give more individuals an oppor/tunity to participate.

— Magera Moon, Etsy / Source (Medium)

Have a physical space for discussing

This is not a meeting, but a way to make the design language part of the everyday culture. They hang printed designs in their office to create a visual space to talk about component naming. Only if you can see the whole picture, you can analyze the intents and functions of components and give them a proper name.

Taxonomy

— Alla Kholmatova, FutureLearn / Source (Blog)

Use a service desk