デザインシステムの成功と失敗に関する6つの質問

最近、デザインシステムの初期設計に参加しながら、いろいろと悩んでいます。

関連して先週 UX Collective で読んだ内容なのですが、社内のデザインシステムメンバー向けに翻訳したものを、もったいないのでここでも共有してみます。

デザインシステムを扱う 10 人のデザイナーにインタビューして要約した内容だそうです。

質問 1. DS の役割で失敗するには？

• 警察になること

• デザイナーとしての力を使うこと（政治の話）

• コンポーネントを統合しておきながら使わないこと

• チームの要求事項を予測する代わりに、後追い対応のように作業すること

• ユーザー（他のデザイナーや開発者）の声を聞いたり調査したりしないこと

• DS のために作られた DS

• 作業の明確なロードマップとプロセスを維持しないこと

• 実現不可能な理想的体験を作ること

• チームと一緒にテストしないこと

• DS を 1 つの製品として理解しないこと

• ツールを作っても、人々に使い方を教育しないこと

• 実際の働き方から外れた理論を持ち込みすぎること

• 一人でできると思い込むこと

• 技術チームの誰かとの知識交換に 100% 集中しないこと

• 柔軟性が低すぎるコンポーネントを作り、Detaching を許可しないこと

• 助けを求めず、人ともつながらないこと（社内でも社外でも）

• すぐ隣ではなく遠くからルールを指示すること

質問 2. DS が成功するために必要なソフトスキルにはどんなものがありますか？

• コミュニケーション、コミュニケーション、コミュニケーション!!!

• ユーザーと共にあること、聞くこと、尋ねること、調査することが本当に重要です。

• 失敗を謙虚に認めましょう

• 忍耐強くありましょう

• 安全な場を作る能力

• 教えること

• 再利用方法についての体系的なビジョンを示すこと

• 拡張においても断固として一貫性を保つこと

• 相手を理解するとき、そこまで強く感情移入する必要はありません。ルールをそのまま受け入れましょう。

• 95% はハードスキルで、5% はルールに反したときのためのソフトスキルです。

• 人々の成長を促し、共有しましょう

• 自律性

• 製品（DS）を売り込み続けましょう

• 戦略的に考えましょう

• すべての人が参加できるようにしましょう

• DS に関する話題を積極的に発信すること

• できるだけ多くのシナリオを見つけるために、できるだけ多くの時間を費やしましょう

• 言葉を揃えましょう。

質問 3. DS の運用方式は、より中央集権的であるべきですか、それともより分散しているべきですか？

方法は大きく 2 つあります。人々がどのようにデザインしているかを確認し責任を持つ中央集権型チームと、全員がそれに責任を持つ方法です。どちらを選ぶのがよいかを人々に尋ねました。

• 私たちは中央集権的すぎるチームなのでボトルネックが発生します。ただし分散モデルにはオーナーシップが弱まる問題もあり得ます。

• 私たちには DS を集約するために 100 人以上が集まっているデザインチームがあります。

• 人々が作るアルファライブラリと協力し、そこから DS チームのバックログを作ります。

• 人々が自発的にコンポーネントを作れるよう教育します。

• 中央集権化するかどうかはかなり政治的な問題です。それを決める前に、どれほどのスケーラビリティが必要かを正確に把握しておく必要があります。

• 期待値を調整し、DS 作りに人々を参加させる必要があります。

• 協業したいとは思っていましたが、その方法がよく分からなかったのでプロセスを作りました。（Culture vs Process）

• 最初は提供のためにやや協力性が低くてもよいかもしれません。成熟すれば、より協力的にしていけます。

• 今はそれを分散化すべき時期に来ています。人々に貢献の仕方を教える必要があります。

• 人々を教育しなければ、彼らは貢献しません。

• デザイナーが標準を超えてより良い成果物を作りたいとき、それをどう標準化するかも同時に考えられる必要があります。

• DS は 1〜2 人ではできません。システムを作ることなので、DS はスクワッド単位で始めるべきです。

• チーム規模によって大きく異なり、場合によっては DS チームがコアコンポーネント開発に集中し、他のアンバサダーがそれを広めることもできます。

• 最終的に私たちは中央集権型チームですが、アンバサダーと協力的に働いています。最終決定は DS チームが行います。

4. DS は、より詳細で制約の多いルールを作るものだと思いますか？ それとも、より広範でデザイナーが新しいレイアウトを作れる自由を与える、オープンなものだと思いますか？

クローズドかオープンか？ デザインシステムの仕事をしているなら、この質問に関心があるはずです。私もそうなので、人々に聞いてみることにしました。

• 「アクセシビリティ」に関することは、より制約的に扱いましょう

• 私たちはみんなで基本構造から始めましたが、いくつかの不整合を作り始めました。そのため 100% クローズドにはしないものの、もう少し制約を設けることにしました。それでも、デザイナーに何かを返せる方法を常に探そうとしています

• 状況によって異なるので、まずリスクを測定してから決めてください。一般的には、チームが小さいほど柔軟性は高くなります

• ただ創造的で新しいコンポーネントを作ることではありません。人々の要求に応えられるよう、十分に柔軟なコンポーネントが必要です

• DS はビジネスです。コンポーネントは少ないほど良いです。

• 人々が DS を使うことを楽しめるべきです。見た目がユニフォームのようだから柔軟性はなくてもよいと思われがちですが（そうではありません）

• 最初から非常に制約的にはできません。十分な時間が経つにつれて、特定のパターンなどへと進化し始めることができます。

• 会社に新しく入るデザイナーには、より多くの制約が役立つこともあります。ルールを破るには、まずルールから始める必要があります。

• 私たちは、人々が自分たちのレシピを作れるように十分な材料を提供します。

• チームの成熟度によって異なります。ジュニアが多いなら、少ない文書しか理解しないため、より多くのデザインガイドラインを求める傾向があります。だからより多くの教育が必要になりますが、それでも彼らを閉じ込めず自由に働けるようにしようと努めています。最大の課題は、人々に文書を実際に読んで使ってもらうことなので、Figma のようにデザイナーにより近い場所へ持っていく可能性があります。

• アクセシビリティと美しさに関することであれば、より制約的であるべきです。

• トークンは一貫性を守るうえで重要です。

• 良いドキュメントは、人々との調和を図ることと自由にしておくことの間でバランスを取ります。

質問 5. ブランディングやマーケティングにつながる DS について、どう考えますか？

（あまり詳しくない分野なので、翻訳が少し難しいですね）

デザインシステムは最終的にデジタル製品に関するものであるべきだとは理解していますが、製品は最も重要なブランドプラットフォームの 1 つにもなり得るため、人々がそれをどう結びつけて考えているのか気になりました。

• DS に結びついたブランディングをどう考えるかというと、それが逆に DS にどう影響するかを考えてみることです。

• 私たちはブランドの見た目と印象を揃えるため、デザインシステムをブランドに合わせ始めました。

• DS はスケーラビリティとブランド ID のためのものですが、この 2 つのつながりはブランディングチームによって異なります。

• Since DS is a language, MKT could support with assets for it;

• ブランディングチームは基本ルールを作るために、最初から DS に参加すべきです。

• 会社によって異なります。DS はブランドを強化するツールなので、整合性を取ることは重要です。両領域のつながりは DS のアクセシビリティにも影響します。

• 戦略を調整するために、ブランディングチームと足並みを揃える方法を見つけることが重要です。

• They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;

• ときにはドキュメントとシステムを一緒に使えることもありますが、たいていはそうではありません。DS はインターフェースです。ブランドチームは別に「ブランディングシステム」を持っており、ライブラリ同士が相互作用する形のほうが一般的です。両者は完全に同じではありません。

質問 6. DS の成功はどのように測定できますか？

• 参加度、採用状況、チームの状態を理解するための認識調査

• コンポーネントのカバレッジ（DS がどれだけ使われているか vs ハードコーディングされているか）

• Adoption

• Time to market

• ROI

• Figma Analytics

• 開発チームの反応

• アクセシビリティ

• コンポーネントが使われた回数

[xguru]

おお、いいですね。まとめありがとうございます！