本文へスキップ
すべての記事

エンジニアリング

デザインシステムは社会契約である

コンポーネントライブラリは成果物ではない。本当に作られるのは、何が政策で何が現場の自由か、そしてどう上手に意見を違えるかについての合意だ。

約 4 分

Meridian での最初の週、デザインシステムのドキュメントを開くと四百のコンポーネントがあった。二週目に、新しい画面のおよそ三分の一しか使っていないと知った。三週目には、驚かなくなっていた。

ライブラリが問題だったのではない。コンポーネントは良く、ドキュメントは丁寧で、空状態のガイドラインまで書いた人がいた。問題は、このライブラリが何のためにあるのかを誰も合意していなかったことだ。チームごとに答えが違い、全員が出荷で忙しかった。

ライブラリは成果物、契約が製品

デザインシステムはコンポーネントの山ではない。デザイナーとエンジニアのあいだの常設の合意だ。どの決定が政策で、どれが共有のデフォルトで、どれが現場の裁量か。コンポーネントは、その合意が見える形になった場所にすぎない。

この区別は学術的に聞こえるが、チームがボタン一つで議論するのを見れば分かる。片方はボタンはシステムのものだと言い、もう片方は、フローがボタンにできないことを必要とするまでシステムのものだと言う。そしてほとんどのフローがそうだ。議論の下にあるのは契約の問いだ。決める権限は誰にあるのか、答えが「あなたではない、今ではない」のときどうするのか。

成熟したシステムはこの問いに明示的に答える。未成熟なシステムは、毎スプリント、少しずつ違う答えで繰り返し答える。

契約に書かれていること

役に立つ契約は、コンポーネントライブラリより条項が多く、そのほとんどが散文だ。

命名。 これを chip と呼ぶことに合意する。pill でも tag でも badge でもない。衒学ではない。共有された言語は、私たちが買えるいちばん安い相互運用性だ。名前が争われればコンポーネントも争われ、議論はすべてのレビューで再演される。

所有。 誰がトークンを変えられるか、誰がコンポーネントの変更をレビューするか、何が破壊的変更か。プラットフォームチームが黙って prop の名前を変えられるなら、それはシステムではなく、親切なウェブサイトの付いた依存関係だ。

バージョン。 番号は約束だ。パッチは直し、マイナーは足し、メジャーは壊す。多くのチームは API にはそうするが、振る舞いには忘れる。デザイナーが実際に感じるのは振る舞いのほうだ。

逸脱する権利。 システムが支えないことをチームがするには、記録された経路が要る。レビューされた書面の例外は、システムが健全に呼吸している証拠だ。静かなフォークは、同じチームが暗闇でもう一つシステムを作っているだけだ。この二つの違いは、完全に社会的なものだ。

公開ではなく保守。 デザインシステムが出荷された瞬間から、難しい部分が始まる。非推奨には通知が、移行には日付が、ドキュメントにはカレンダーに時間のある担当者が要る。

デザインシステムの成功は、コンポーネントが使われたときではなく、新しいエンジニアが誰にも聞かずに良い画面を作れるときだ。

実際の死因

デザインシステムが死ぬのは、コンポーネントが間違っているからではない。社会的な負債のせいだ。

一つ目は委員会レビュー。八人、角丸について四つの意見、PR ごとに六週間。システムはローカルコピーを作るより遅くなり、ローカルコピーが合理的になる。

二つ目は相談時間の不在。質問する唯一の方法がプルリクエストなら、人は質問をやめ、フォークを始める。

三つ目は、いちばんよく見るものだ。「今回だけ」。私が見てきた腐ったシステムはすべて、一度に一つの例外ずつ腐った。どれも個別には合理的で、どれも記録されなかった。システムは悪い決定では死なず、議論されなかった千の決定で死ぬ。

処方は地味だ。毎週三十分、誰でも問題を持ち込める場。その場で開かれる例外の記録。そして、逸脱を出荷した人が、それを説明する記録を書くというルール。

何を測るか

大事な指標は社会的なものだ。新しいチームが一貫した画面を出すまでにどれだけかかるか。UI の仕事のうちシステムコンポーネントを使う割合はどれくらいで、その数字は正直か。月に何件の例外を認め、それは同じ欠けているものに収束しているか。

例外が同じ欠けているものの周りに集まり続けるなら、そのシステムは標準を守っているのではなく、あなたの代わりに機能要望を出している。それは失敗ではなく情報だ。

契約は再交渉される

契約という言葉は硬く響くが、逆だ。契約とは、毎スプリントゼロから議論し直すのではなく、開き直せるように書き留められた会話にすぎない。

「なぜ」をドキュメントに書く。非推奨は大きな声で、日付と移行ガイドとともに。議論は自然にやってくるのを待たず、カレンダーに入れる。そしてライブラリを、それが本来の姿として扱う。合意の証拠であって、合意そのものではない。

私が一緒に働いたいちばん良いデザインシステムは、いちばん悪いものよりコンポーネントが少なかった。月に一度の会議と、とても退屈な変更履歴と、要点はボタンではなかったという共有された理解があった。

タグデザインシステム協働プロセス
RSS

その他の記事