デザインシステム（or UI コンポーネントライブラリ）の運用・管理体制についてのメモ

This is why it is so incredibly important for the makers of the design system to establish a crystal-clear governance process that helps users understand what to do when:

• They can’t find a component that does what they need
• A design system component gets them 90% of the way there, but not 100%
• They have questions or concerns about the design system

• プロダクト開発をするチームが必要とするコンポーネントが見当たらない
• 実現したいことがほとんど実現できるけども100%ではないコンポーネントしかない
• デザインシステム自体に関する疑問や確認事項がある

という状況でのコミニュケーションプロセスがあることが重要

この記事で紹介されている一例としてのフローチャート

• 既存のコンポーネントが要件を満たす
  • 既存のコンポーネントが要件を満たさない場合
    • デザインシステムのチームにコンポーネントをどうするべきか連絡・相談する（相談窓口がある）
    • コンポーネントがデザインシステムから提供されるべきものか否かを確認する（デザインシステムから提供されている方がプロダクト全体にとって都合が良いかかどうか）
      • デザインシステムから提供すると判断 → デザインシステムのバックログに
        • プロダクト開発チームの要件を満たす初期コンセプトを決める
          • 初期コンセプトをプロダクト開発チームとデザインシステムのチームで要件を満たしているか協議する
            • チーム間での合意が取れたらコンポーネントの実装を行い、各デバイスやブラウザなどのサポート環境でのテストやa11yのテスト、デザインレビューなどを行う
              • 問題なければプロダクト開発チームに最終確認
                • 合意がとれたらドキュメントを追加して、次回のリリースにのせる
                  • リリースの共有を関係するチームに行う
                    • プロダクト開発チーム側で取り込んで、問題があればデザインシステムチームにフィードバック
      • デザインシステムから提供しないと判断 → 該当のプロダクト開発チームのバックログに

コンポーネントがプロダクト開発チームに提供されるまでのフローが冗長になっているというのがあるけども、明確化されているフローに従えば良いようにしている方が関係者のコミニュケーションコストを結果的に軽減するということのよう。
これが良いというのではなくてあくまで一例として。組織規模などに応じてより良い形があり得る。

https://medium.com/societe-generale-design/contributing-to-our-design-system-the-happy-tale-of-creating-a-new-component-767c659bf9cb