AtomicDesign作者のBrad氏のデザインシステムのガバナンスプロセスというタイトルのブログを読んだ
デザインシステムを更新するまでにどういうプロセスを辿るかのフロー図が載せられていて大変参考になった
ブログにあるようにプロセスを決めておかないと作業が進まないことがよくある
例えば
- コンポーネントがどこにあるのかわからないとき
- デザインシステムにないとわかったとき
- デザインシステムに対する質問や懸念があるとき
これらも含めて、作業のプロセスを決めておくことがデザインステムを健全に保つために必要なことだといえそう
Brad氏が案件を進めていく中で行き着いたフローが以下とのこと
詳細はブログを読んだ方がよいので、見出しと気になった点だけ書いておく
- プロダクトチームはデザインシステムを使用して新しい案件のUIを設計する
- デザインシステムのコンポーネントが存在しないか、要件を満たしていない場合
→チャットや課題管理サービスなどを使ってデザインシステムチームに問い合わせる
→問い合わせの場がなければつくる
→既存のソリューションを提案するか、新規作成や変更を行うかを決める - 新規作成や変更を行う場合、それはスノーフレークか、それともデザインシステムの一部か？
→チームがスノーフレークであると判断した場合、スノーフレークガイドラインに従ってプロダクトチームの作業バックログに追加する「スノーフレーク」とは、特定の１つのプロダクトまたは１つのユースケースにのみ関係する１回限りのコンポーネント（抽象化するのが特に難しいと感じるコンポーネントなど）
- プロトタイプの初期コンセプト デザインシステムの一部にすると判断した場合、プロダクトチームかデザインシステムチームのどちらが主導で初期コンセプトをつくるかを決定すると、そのチームは最初のコンセプトを作成する
- 最初のコンセプトを確認する
- デザインシステムの設計/開発およびテスト
- 製品チームによる最終レビュー
- ドキュメントとリリースのステージング
- 新しい設計システムのリリース
- プロダクトチームの採用とQAプロセス
→質問やバグが発生した場合は、サポートプロセスに従って、質問や問題を処理
ブログで言っているが、プロセスはかなり長くなるけど、デザインシステムを運用していく上での安心感があるとのこと
いまはここまでフローが確立していないので今後考えていきたい
