デザインシステムは関係についてです

設計システムは非常に役立ちます。 これらは、製品全体で一貫した「ルックアンドフィール」を構築するための再利用可能な要素とガイドラインを提供します。 その結果、ユーザーはある製品から学んだことを別の製品に適用することができます。 同様に、チームはナビゲーションやレビューのために十分にテストされたパターンを展開して、製品をより信頼できるものにすることができます。 効果的な設計システムは、退屈な問題を繰り返し解決できるため、開発者や設計者は新しい問題の解決に集中できます。

しかし、誰かが会議で「設計システム」という用語を使用するとき、私はどのような反応を期待するのかよくわかりません。 新しい働き方に挑戦することへの好奇心と興奮を見てきましたが、デザイナーの創造性を制限するシステムのアイデアに対する欲求不満と懸念も見ました。 一部の設計者は、設計システムが創造性を奪う、または問題を探すための解決策であると主張します。 設計システムは時間の経過とともに断片化し、チームがそれらの使用を停止する可能性があります。

ただし、設計システムはなくなることはありません。 ある調査によると、2018年に組織のわずか15％が設計システムを欠いていました。 前年の28％から減少しています。 一部のチームは、Googleのマテリアルデザインなどの大規模な汎用設計システムを使用していますが、他のチームは、REIのCedarやMozillaのProtocolなどのより小さく特注のシステムを使用しています。

設計システムは、チームを制限するのではなく、チームに力を与える必要があります。 そのためには、もっと総合的に考え始める必要があります。 設計システムは、単なるコード、設計、またはドキュメントではありません。 これらすべてに加えて、システムを作成する人々とそれを使用する人々の間の関係です。 これには、CSSファイルとSketchドキュメントだけでなく、信頼、通信、および共有所有権も含まれます。 結局のところ、このようなシステムの調査に専念する研究分野全体があります。

大きな絵

「社会技術システム」と題された1960年の論文は、技術、人間、およびそれらが存在するより大きな環境の間の相互作用を調査しました。 Enid Mumfordは、研究者はマネージャーと従業員の間のより良い関係を構築する方法を調査することから始めたが、1980年代までに、彼らは仕事をより効率的で費用効果の高いものにすることに焦点を合わせていたと説明しました。 2011年、GordonBaxterとIanSommervilleは、この調査がユーザー中心設計を刺激するのに役立ち、やるべきことがたくさん残っていると書いています。

バクスターとソマービルは、今日でも、従業員の生活の質に焦点を当てた「人間的」研究と、生産性に焦点を当てた「経営的」研究との間に緊張関係があると主張しました。 彼らはまた、テクノロジーと人間の相互作用の両方を考慮することが重要であると説明しました。「システムのパフォーマンスは、技術的サブシステムと社会的サブシステムの共同最適化に依存しています。」

デザインシステムは社会技術システムだと思います。 それらには、システムを作成する人々、システムを使用して製品を作成する人々、およびこれらの製品を操作するエンドユーザーの間の相互作用が含まれます。 彼らはまた、バクスターとソマービルが見たのと同じ効率とヒューマニズムの間の緊張を呼び起こします。

デザインシステムは、画像とコードだけで構成されているわけではありません。 デザイナー、開発者、製品マネージャー、CEO、GitHubのランダムな人々の間の会話が含まれます。 これらの相互作用は、企業、オープンソースコミュニティ、家庭など、さまざまな状況で発生し、文化や組織の境界を越えて発生します。 チームを構築するということは、アニメーション、サウンドデザイン、データの視覚化、触覚、コピーライティングなどの分野の人々を集めることを意味します。 成功する設計システムを作成するには、同等の技術的専門知識とソフトスキルが必要です。

それでも、デザインやエンジニアリングのニュースアグリゲーターを熟読すると、人や会話ではなく、コードやツールという「技術サブシステム」に明確に焦点が当てられる可能性があります。 デザイントークンを追跡するのに最適なクリエイティブツールはどれですか？ React、Webコンポーネント、またはその他の再利用可能なコンポーネントを構築するために使用する必要があるJavaScriptテクノロジーは何ですか？ どのビルドツールが最適ですか？

もちろん、これらの質問に対する答えは「状況によって異なります」です。 誰がシステムを設計、構築、使用しますか？ 彼らのニーズは何ですか？ 彼らはどのような制約の下で活動していますか？ 彼らはどのようなツールやテクノロジーに慣れていますか？ 彼らは何を学びたいですか？

この種の質問に答えるために、バクスターとソマービルは2種類の活動を推奨しています。

• 感作と意識向上活動
  システムを作成して参加するさまざまな人々について学び、その情報を広範囲に共有します。
• 建設的関与
  役割を超えてコミュニケーションを取り、プロトタイプを作成し、システムの技術的部分と社会的部分の両方を検討します。

掘り下げる

2019年の初め、私は大規模な組織の設計システムを構築していたチーム（「チームブルー」と呼びましょう）の一員でした。 このチームと、設計システムを使用してWebアプリケーションを構築していた「チームグリーン」との非公式チャットを促進しました。 数週間ごとに、私たちはすべての開発者と設計者をテーブルの周りに集め、私たちが構築しているものと私たちが解決しようとしている問題について話し合いました。 これらのチャットは、私たちの「感作と意識向上活動」でした。

設計システムを公開する許可がなかったため、次善の策を講じました。それは、組織内の小さなオープンソースプロジェクトのように扱ったということです。 両方のチームがアクセスして貢献を求めることができるリポジトリにコードを配置しました。 チームブルーはこれらの貢献のレビューと承認を担当しましたが、どちらのチームの誰もが貢献できました。 チームブルーも独自のアプリケーションを構築していたため、ある意味で、彼らは設計システムのユーザーであり、管理者でもありました。

これらの相互作用は、チームがより良い製品を構築するのに役立ちましたが、同様に重要なことに、チーム間の信頼を確立しました。 チームブルーは、人々がシステムを慎重に使用し、その上に巧妙な新しいアイデアを構築していることを学びました。 チームグリーンは、システムが本当に彼らのニーズに合わせて調整されていることを学びました。そのため、彼らはそれに反対するのではなく、それを使って作業することができました。 バクスターとソマービルは、この作業を「建設的関与」と呼ぶかもしれません。

どちらのチームも、新しいテクノロジーを学び、完全な製品を迅速に提供するというプレッシャーにさらされていることがわかりました。 言い換えれば、彼らはすでにかなりの認知的負荷の下で動作していた。 その結果、2つのチームは、システムを使いやすくすることに重点を置くことに合意しました。 これは、Webコンポーネントの議論全体を回避し、主にCSSに焦点を当て、ドキュメントが明確で親しみやすいものであることを確認することを意味しました。

すべてを一緒に入れて

あらゆる規模の組織が再利用可能な設計要素を作成し、チームがより一貫性のあるエレガントなアプリケーションを構築できるようにします。 さまざまな組織のニーズとダイナミクスが、設計システムで表現されます。 ここにいくつかの例があります：

• Googleのマテリアルデザインには、さまざまなフレームワークと言語でいくつかの実装があります。 Googleの内外のさまざまな人々によって使用されているため、包括的なドキュメントとデザインアプリ用のさまざまなツールキットがあります。
• MicrosoftのFluentDesign Systemは、4つの非常に異なるプラットフォームを対象としています。 Materialと同様に、UXデザイナー向けのツールキットと包括的なドキュメントが含まれています。
• MozillaのプロトコルはSassとバニラJavaScriptで実装されています。 それは国際化に重点を置いています。 Alex Gibsonは、このシステムはMozillaが「手作業の繰り返しを減らしてより速いペースでブランドのWebページを作成する」のに役立つと述べています。
• REIのCedarはVue.jsコンポーネントで構築されており、他のJavaScriptフレームワークでは使用できません。 Cedarは、主にREIの内部開発者によって使用され、会社のブランドと密接に関係しています。 デザインシステムのコードはオープンソースですが、フォントはオープンソースではありません。
• SalesforceのLightningDesign Systemは、JavaScriptに依存しないCSSフレームワークです。 オプションで、Lightningコンポーネントフレームワークと一緒に使用できます。これには、2つのJavaScript実装が含まれます。1つはWebコンポーネントを使用し、もう1つはSalesforce独自のAuraフレームワークを使用します。
• Red HatのPatternFlyは、会社のクラウドプラットフォーム製品全体で一貫したユーザーエクスペリエンスを提供するために作成されたため、比較的高い情報密度を持ち、さまざまなデータ視覚化コンポーネントが含まれています。 PatternFlyチームは最近、Webコンポーネントでいくつかの実験を行った後、AngularからReactに切り替えました。 PatternFlyには、HTMLとCSSを使用したJavaScriptに依存しない実装も含まれています。 （完全開示：私は元レッドハッターです。）
• IBMのCarbonDesign Systemは、React、Vue、Angular、およびvanilla JavaScriptの実装と、Sketchの設計ツールキットを提供します。 Carbonチームは、Webコンポーネントを実験しています。 （そのリポジトリを追跡するためのJonathan Speekへのハットチップ。）

このようなシステムは、さまざまなチームや役割の人々が協力して構築したため、一貫性があり信頼性があります。 これらのシステムは実際の問題を解決します。 それらは、開発者が設計者に意志を押し付けようとした結果ではなく、その逆も同様です。

JoshMateoとBrendonManwaringは、Spotifyのデザイナーは「共有システムのコアコントリビューターおよび共著者としての役割を認識しています。彼らが所有しているシステムです」と説明しています。 ミナ・マーカムは、パンツスーツのデザインシステムで自分自身を「エンジニアリングとデザインの間の翻訳者」と表現しています。 Jina Anneは、設計システムの背後にあるチームのダイナミクスとユーザー調査を掘り下げます。 デザイナーだけでなく、それ以上のものが必要になるでしょう。」

何かを作ろう！

調査といくつかの例を終えたので、新しい設計システムを構築する方法について話しましょう。 人と話すことから始めます。 誰が設計システムを使用し、貢献するかを把握します。 これらの人々はおそらく、設計、開発、製品管理、ビジネスなど、さまざまな分野にまたがるでしょう。 人々のニーズと目標について学び、彼らが取り組んでいることを共有するように依頼します。 居心地の良い雰囲気を作り出すために、軽食、コーヒー、またはお茶を使った非公式の会議を計画することを検討してください。 これらの人々との定期的なコミュニケーションを確立します。 これは、共有チャットルームに参加したり、定期的な会議をスケジュールしたりすることを意味する場合があります。 カジュアルで親しみやすいトーンを保ち、リスニングに集中します。

自分が取り組んでいることについて話すときは、一般的な問題と目標を探してください。 チームは大量のデータを表示する必要がある場合があるため、テーブルを表示してレポートを生成するためのツールを調査しています。 これらの問題の解決策に優先順位を付けます。

同様のテーマで繰り返されるパターンやバリエーションも探してください。 ボタンとログインフォームはチーム間で少し異なって見えるかもしれません。 これらのバリエーションの重要性は何ですか？ 意図的なバリエーション（たとえば、プライマリボタンとセカンダリボタン）と、偶然に発生したバリエーションは何ですか？ 設計システムは、意図的なパターンとバリエーションに名前を付けてカタログ化することができ、「偶発的な」バリエーションを排除することができます。

ここでの目標は、設計システムを使用している人々との迅速なフィードバックループを確立することです。 より速いフィードバックとより小さな反復は、間違った方向に行き過ぎてコースを劇的に変更しなければならないことを避けるのに役立ちます。 PJ Onoriは、これらの突然の大きな変化を「スラッシュ」と呼んでいます。 彼は、いくつかのスラッシュは良いと言います—それはあなたが変化に学習して対応しているというサインです—しかし、それが多すぎると混乱を招く可能性があります。 「スラッシュを恐れるべきではありません」と彼は言います。「しかし、それがいつ役立つか、そしてその欠点を軽減するのを助ける方法を知る必要があります。 スラッシュの欠点を軽減するための最良の[方法]の1つは、小さなことから始めることです—すべてから始めます。」

いくつかの基本的な要素を設定して、小規模から始めることを検討してください。

• コードを保存するためのバージョン管理システム。 ここでは、GitHub、GitLab、およびBitbucketがすべて優れたオプションです。 システムを使用するすべての人がコードにアクセスして変更を提案できることを確認してください。 可能であれば、コードをオープンソースにして、可能な限り幅広い対象者にリーチすることを検討してください。
• システムを実装するためのCSSコード。 Sass変数またはCSSカスタムプロパティを使用して、「デザイントークン」（幅や色などの一般的な値）を保存します。
• アプリケーションが設計システムを構築およびインストールする方法を定義するpackage.jsonファイル。
• 理想的にはシステム独自のCSSを使用して、設計システムを使用する方法を示すHTMLドキュメント。

CSSフレームワークBulmaのnode-sassドキュメントでは、これらの手順についてもう少し詳しく説明しています。 ゼロから始めたい場合はBulmaのインストールとインポートをスキップできます。また、いくつかの基本事項を整えて始めたい場合は、Bulmaを含めることができます。

ここではJavaScriptについて何も言及していないことに気づいたかもしれません。 最終的にこの要素を追加することもできますが、開始するためにこの要素は必要ありません。 最高で最新のJavaScriptツールを研究しているうさぎの穴を掘り下げるのは簡単であり、この研究に迷うと、始めるのが難しくなる可能性があります。 たとえば、「Webコンポーネントが設計システムに最適な5つの理由」と「Webコンポーネントを使用しない理由」はどちらも有効なポイントですが、システムに適したツールを決定できるのはあなただけです。 CSSとHTMLだけから始めて、時が来たときにこの決定を下すのに役立つ実際のフィードバックを収集できます。

システムの新しいバージョンをリリースするときは、システムのバージョン番号を更新して、何が変更されたかを示します。 セマンティックバージョニングを使用して、「1.4.0」のような数字で何が変更されたかを示します。 バグ修正の場合は最後の数字、新機能の場合は中間の数字、大きくて破壊的な変更の場合は最初の数字を増やします。 デザインシステムを使用している人々とコミュニケーションを取り続け、フィードバックや貢献を求め、少しずつ改善していきます。 この協調的で反復的な作業方法は、「スラッシュ」を最小限に抑え、共有された所有権の感覚を確立するのに役立ちます。

最後に、開発者がコマンドnpm install your-design-systemを実行して使用できるように、デザインシステムをパッケージとしてnpmに公開することを検討してください。 デフォルトでは、npmパッケージはパブリックですが、プライベートパッケージを公開したり、パッケージをプライベートレジストリに公開したり、開発者にバージョン管理システムから直接パッケージをインストールするように依頼したりすることもできます。 パッケージリポジトリを使用すると、更新の検出とインストールが簡単になりますが、バージョン管理から直接インストールすることは、チームが開始するのに役立つ簡単な短期的なソリューションになる可能性があります。

物事のエンジニアリング面についてもっと知りたい場合は、KatieSylor-MillerのBuildingYour DesignSystemが素晴らしい詳細を提供します。 （完全開示：私はケイティと協力しました。）

まとめ

設計システムは、コード、設計、ドキュメント、および関係、コミュニケーション、相互信頼で構成されています。 言い換えれば、それらは社会技術システムです。 設計システムを構築するには、コードを記述してツールを選択することから始めないでください。 システムを使用する人々と話すことから始めます。 彼らのニーズと制約について学び、彼らが問題を解決するのを手伝ってください。 技術、設計、または戦略の決定を行うときは、理論的に「最良の」方法でこれらの人々のニーズを考慮してください。 小さく始めて、繰り返し、そしてあなたが行くにつれてコミュニケーションをとってください。 スラッシュを最小限に抑えるためにシステムを可能な限りシンプルに保ち、共有された所有権の感覚を確立するためにフィードバックと貢献を招待します。

エンジニアリングと対人関係の考慮事項を同等に重視することで、落とし穴を避けながら設計システムのメリットを得ることができます。 私たちは効率的で人道的な方法で仕事をすることができます。 どちらかを選択する必要はありません。 チームを制限するのではなく、チームに力を与えることができます。 権限を与えられたチームは、最終的にユーザーにより良いサービスを提供するのに役立ちます。結局のところ、それが私たちが最初にここにいる理由です。

SmashingMagの詳細：

• 設計システムを管理するためのヒント
• デザインシステムにアニメーションを含める
• ツールを超えて：設計システムを構築することで、作業方法をどのように改善できるか
• 米国政府向けの大規模設計システムの構築（ケーススタディ）