コンテンツ
- 「デザインシステム」とは何ですか？
- 設計システムを実装する前の重要な考慮事項
- 01.製品と会社の成熟度を検討する
- 02.ビジョンステートメントを作成する
- 04.指針となる設計原則を確立する
- 05.テクノロジースタックを確認し、インターフェイスインベントリを実施します
- 06.コアチームを設立する
- 設計システムの作成
- 01.アイデアを売る
- 02.パイロットプロジェクトを選択して完了します
- 03.設計と構築
- 04.起動して維持する
設計システムは、大規模な業界のプレーヤーが設計プロセスを標準化し、それをより予測可能にするのに役立ちます。多くの企業が独自の設計システムを構築するイニシアチブをとろうとしています。しかし、多くの場合、全員の最善の意図にもかかわらず、製品チームが思慮深い設計システムを作成するために費やすすべての努力は、すぐに無駄になってしまう可能性があります。
この記事では、設計システムとは何か、設計システムを構築する前に考慮すべきこと、および組織に設計システムを導入するための最善の方法を定義します。より優れたリソースについては、Webデザインツールのまとめを参照してください。
「デザインシステム」とは何ですか？
「デザインシステム」という名前は、デザイナーだけに価値を提供する何かの誤った印象を生み出す可能性があります。しかし実際には、設計システムは設計者だけに関係するものではありません。代わりに、組織全体が製品を構築する方法についてです（Webサイトが含まれている場合は、トップのWebサイトビルダーと優れたWebホスティングが必要です）。
設計プロセスを成功させるには、通常、製品の作成に関与するすべてのチーム間で機能を超えた緊密なコラボレーションが必要です。また、設計システムとは、チームがより効果的にコラボレーションできるようにする共有言語を構築することです。これは、設計原則、ルール、および標準の完全なセットと、それらの原則、ルール、および標準を達成するために必要なツールキット（デザインパターン、視覚スタイル、および再利用可能なUIコンポーネントのコードライブラリ）です。設計システムにより、製品チームは、設計を再利用可能にすることで、品質を犠牲にすることなく、製品をより迅速に作成できます（資産を保存するための信頼できるクラウドストレージがあることを確認してください）。
設計システムの実装に苦労する最終的な目的は、ビジネスの学習と成長を支援することです。そのため、設計システムは常にビジネスの目的に基づいている必要があります。まったく同じ理由で、すべての設計システムが同じように構築されているわけではありませんが、それでも、ほとんどの設計システムはいくつかの共通の要素を共有しています。
- 設計原則–設計努力が正しい方向に向かうことを保証する価値。
- コンポーネントとパターンライブラリ–これらは設計システムの構成要素です。
- 設計ガイド–の特定の部分を設計する方法に関する特定の規則
製品。これらには、スタイルガイドライン（タイポグラフィ、色、間隔など）とUXライティングガイドライン（声とトーン、言語、ライティングの原則など）が含まれます。 - 設計慣行–システムを存続させ、製品チームにとって価値のあるものに保つのに役立ちます。
設計システムを実装する前の重要な考慮事項
01.製品と会社の成熟度を検討する
設計システムの構築を開始する前に、なぜそれが必要なのかを明確に理解する必要があります。多くの企業は、技術的負債を減らし、製品開発プロセスをスピードアップするために設計システムを導入しています（退屈で単調な活動に費やす時間を減らすことによって）。しかし、企業の設計成熟度はさまざまであるため、すべての企業がこのような問題に直面しているわけではありません。
設計システムを最初から作成することは時間のかかる作業であり、小規模で動きの速いチームは、速度が低下するため、設計システムを必要としない可能性があります。まだ製品市場に合うものを見つけようとしている3〜5人のスタートアップは、おそらくシステムの作成にかなりの時間を費やすでしょう。設計システムの構築にリソースが費やされているとき、それらは製品の構築に費やされていません。したがって、企業が製品の明確な方向性を確立できるようになるまで、設計システムの作成に時間を費やすと、多くの無駄が発生するリスクがあります。
02.ビジョンステートメントを作成する
設計システムとは、人々が共通の目標を達成するためにどのように協力するかということです。そして、人々は次の質問に対する答えを知りたがっています。
- 私達はどこに行くの？
- 何を達成したいですか？
- なぜそれを達成したいのですか？
これらは、共有ビジョンを構築するために答える必要のある基本的な質問です。共有ビジョンは、チームが製品の問題のソリューションを構築するためのガイド付きの方法を提供する設計システムの基盤になります。
ビジョンステートメントは、チーム、製品、または会社が何を達成しようとしているのか、そしてさらに重要なのはその理由を定義します。明確な共通の目標に沿ってチームを調整し、組織全体のノーススターになります。製品開発に携わる人々を結び付け、共通の目的地に導きます。
ビジョンステートメントを作成する簡単な方法を探している場合は、5年間で製品または組織がどのようになるかを説明することを検討してください。そうすることで、目標条件を定義し、それを達成するのに役立つ戦略を作成するのがはるかに簡単になります。
04.指針となる設計原則を確立する
良いデザインをどのように定義しますか？何かを実装する準備ができたことをどうやって知るのですか？設計の品質を評価する場合、設計者は多くの場合、独自の一連の標準に依存します。しかし、そのようなアプローチに従うと、すべての設計者が主観的なアイデアを持っているため、製品設計プロセスに多くの混乱をもたらす可能性があります。そこで、設計の原則が1日を節約できます。
堅実な設計原則は、機能するシステムの基盤です。彼らは、優れた設計が会社にとって何を意味するのかという本質を捉え、それを達成する方法について製品チームに実用的な推奨事項を提供する必要があります（設計原則は常に実行可能でなければなりません）。設計原則は、製品チームの標準として機能し、製品チームが作業を測定するのに役立ちます。
設計原則に取り組む際に覚えておくべきことがいくつかあります。
- 設計原則は、製品の性質を反映する必要があります。たとえば、自動車のヒューマンマシンインターフェイス設計に関して、最も重要な設計原則は「安全第一」である必要があります（目標はドライバーと乗客を安全に保つことです）。そのため、すべての設計上の決定は安全性について測定する必要があります。
- 設計原則は規則のように聞こえるべきではありません。彼らは創造的なエネルギーをブロックするべきではありません。製品の作成者は、制限や制約を感じてはなりません。
- 設計原則は、オープンな議論の結果でなければなりません。多くの場合、人々にガイドラインに従うようにするのは難しいことではなく、むしろ人々にガイドラインに同意させるのは難しいことです。組織に多くの設計チームがある場合は、それらをディスカッションに参加させることが重要です。設計原則に関するフィードバックを取得することで、ユーザーのニーズに原則を適合させることができます。
05.テクノロジースタックを確認し、インターフェイスインベントリを実施します
多くの企業は現在のインターフェースの上に設計システムを構築する傾向がありますが、このアプローチは多くの理由で最善ではありません。あなたの会社がシステムなしで長い間製品を構築してきたと想像してみてください。
製品には、設計にある程度の矛盾がある可能性があります。不整合は通常、設計要素の重複によって引き起こされます。設計要素の重複を特定することで、チームメンバーが要素を最初から作成し、しばらくすると、そのバージョンがすでに存在することがわかるというシナリオを回避できます。
そのため、設計システムの導入を計画している場合は、監査から始めてください。インターフェースインベントリを実施して、何が使用されているかを理解してください。
既存のインタラクションを調べ、インターフェイスを構成するすべてのUI要素を収集し、それらを確認します。この手順は2つのことを理解するのに役立つため、実際の設計システムを構築する前にこれを行うことが重要です。
- 組織にどのくらいの設計債務があり、さらに注意が必要な領域は何ですか。
- 不整合の理由と、将来このような問題を回避するために設計プロセスに導入する必要のある変更。プロセスを変更する必要があるかもしれませんし、新しいテクノロジーを導入する必要があるかもしれません。
06.コアチームを設立する
設計システムの構築には誰が関与する必要がありますか？デザインはチームスポーツであり、デザインシステムの作成も例外ではありません。設計システムを構築するには、部門の枠を超えたコラボレーションによって提供される専門知識と創造的なエネルギーが必要です。そのため、実際にシステムを作成するコアチームには、通常、エンジニア、設計者、製品マネージャー、および利害関係者が含まれます。設計システムの構築を開始するときは、勢いをつけて何かをすばやく構築するのに役立つため、コアチームのサイズを小さくすることが重要です（6〜8人）。
設計システムの作成
設計システムをプロジェクトとして実装することを検討してください。そして、他のプロジェクトと同じように、これは次のステップでしっかりしたプロセスを持っている必要があります。
- アイデアを売る
- パイロットプロジェクトを完了する
- 設計と構築
- 打ち上げとメンテナンス
01.アイデアを売る
設計システムのアイデアを販売することは、設計システムを導入するための最初の最も重要なステップです。通常、トレードオフのために設計システムを販売することは困難です。管理者と製品チームのメンバーの両方が、設計システムの構築に費やされたリソースが機能の出荷に費やされていないことを理解しています。したがって、ある程度の反発を期待するのは自然なことです。デザインシステムを販売するには、次の2つのことを行う必要があります。
利害関係者から賛同を得ます
資金提供を決定する人々がそれを承認しない場合、設計システムは離陸しません。システムが実際のビジネス上の問題を解決することを示すと、経営幹部から賛同を得ることははるかに簡単です。重要なビジネス上の問題点（会社がお金を失う領域）を特定し、設計システムがどのようにその日を節約できるかを示します。明確な提案で戦略を書き、決定を下す主要な人々にそれを売り込みます。
関係者にこのプロジェクトに投資するよう説得するために、プレゼンテーション（または一連のプレゼンテーション）を作成することをお勧めします。プレゼンテーションをストーリーの形でラップすることができます。サクセスストーリーを伝えることで、利害関係者を引き付ける可能性が高くなります。
ユーザーからのサポートを受ける
利害関係者から賛同を得ることは、戦いの半分にすぎません。潜在的なユーザーからのサポートを受ける必要があります。まず、ターゲットオーディエンスを特定する必要があります。誰があなたのデザインシステムを使用し、どのように使用しますか？一般的なユーザーグループは次のとおりです。
- 製品チーム（つまり、デザイナー、開発者）
- サードパーティ（つまりベンダー）
- ビジネス（すなわち、マーケティング、販売、法務）
さまざまなユーザーグループの問題点を特定し、システムがユーザーにもたらす価値を示す必要があります。ユーザーのグループごとに異なる購入トリガーがあります。これは、デザインシステムを使用する理由です。たとえば、開発者にとって、トリガーは実装メソッドの一貫性を高めたり、コードのリファクタリングに費やす時間を減らしたりすることができます。
02.パイロットプロジェクトを選択して完了します
設計システムの基本概念を作成したらすぐに、それを検証することが重要です。概念を検証する最良の方法は、パイロットプロジェクトでそれをテストすることです。
サンプルの実際の製品を選択し、実際のソリューションを強化する設計システムを作成します。選択したプロジェクトは、将来の設計システムの基盤として使用する必要があります。これにより、システムが組織で機能しているかどうかをテストできます。
パイロットの潜在的な有効性を判断するために使用できる一連の基準は次のとおりです。
- プロジェクトには、共通のコンポーネントとパターンの可能性があるはずです。他の製品内で再利用できるコンポーネントとパターンが含まれている必要があります。
- 技術的に優れた実現可能性があり、必要なすべての変更を導入するのは難しくありません。
- プロジェクトは妥当な時間（理想的には数週間）で達成可能であり、さまざまな部門の多くの人々の関与を必要とすべきではありません（独立性を維持することが不可欠です）。
- プロジェクトにはマーケティングの可能性が必要です。このプロジェクトは、他のチームが設計プロセスに設計システムを導入するように促す必要があります。
03.設計と構築
再利用可能なコンポーネントを作成する
私が何度も目にする間違いの1つは、チームが単一のユースケースに焦点を合わせすぎたコンポーネントを作成することです。その結果、システムの柔軟性が低下し、ユーザーは特定のシナリオをカバーする必要があるたびに独自のコンポーネントを作成する必要があります。
単一のユースケースに結び付けられていないが、できるコンポーネントを開発してみてください
複数のコンテキストで再利用できます。再利用可能でスケーラブルであるためには、コンポーネントは次のプロパティを持っている必要があります。
- 基本単位： モジュラーコンポーネントは自己完結型であり、依存関係はありません。
- 構成可能： コンポーネントを組み合わせて新しいコンポーネントを作成することができます。
- カスタマイズ可能： コンポーネントを調整および拡張して、さまざまなコンテキストで機能するようにすることができます。
チームメンバーが新しいコンポーネントを導入するたびに、設計対象のさまざまなプラットフォームでどのように機能するかを検討する必要があります。理想的には、設計するすべてのコンポーネントがすべてのプラットフォームで機能する必要があります。
サンドボックス環境を通じて価値を示す
人々が価値を見るための最良の方法はそれを体験することであることはよく知られています。したがって、製品チームのメンバーが設計システムを使用して製品のプロトタイプを作成するためのサンドボックス環境を作成します。
04.起動して維持する
一部の製品チームは、設計システムが構築されると、作業は完了すると信じています。違います。設計システムは製品であり、プロジェクトではなく製品として管理することが重要です。設計システムでは、必要に応じて継続的なメンテナンスと改善が必要です。
設計システムの採用を奨励する
他の製品と同じように、設計システムにはアクティブユーザーが必要です。世界で最高の設計システムを作成することはできますが、組織内で積極的に宣伝しないと、全体の努力が大きく損なわれます。そのため、システムの最初のリリースから、その採用を促進するために一生懸命努力する必要があります。
- サポーターのコミュニティを作成します。権威あるインフルエンサーやデザイナーが率いる伝道者のグループをまとめて、デザインシステムに関するアイデアを売り込みます。伝道者は、システムが存在することへの意識を高め、それを使用する方法について人々を教育することを目的としたワークショップやミートアップなどの活動に参加する必要があります。
- アップデートを紹介します。更新の待機時間は、設計システムの採用において重要な役割を果たします。大きな公開ではなく、定期的な増分リリースを実践し、常に変更ログ付きの更新を出荷するようにしてください。
人々が設計システムをどのように使用しているかを分析する
設計システムは、使いやすさに基づいて上下します。組織の設計プロセスに設計システムを組み込み始めたばかりの場合は、ユーザーとの一連のインタビューを実施して、人々がそれをどのように使用しているかを理解します。そうすることで、ターゲットオーディエンスが直面している可能性のある一般的な問題を特定できます。
しばらくの間設計プロセスに組み込まれるシステムの場合、システムを最新の状態に保つために必要な時間を測定することが不可欠です。設計システムを最新の状態に保つことが困難になると、すぐに時代遅れになります。
設計上の決定をテストする
物事の予測がどれほど優れていても、特定の変更がユーザーエクスペリエンスにどのように影響するかを予測するのは難しい場合があります。そのため、決定を検証することが重要です。
これがあなたを助ける3つのタイプのテストです：
- ユーザビリティテスト
- コンポーネントスタイルへの意図しない視覚的変更をキャッチするのに役立つ視覚的回帰テスト
- コンポーネントがアクセス可能であることを確認する手動および自動のアクセシビリティテスト
バージョニングを導入する
バージョン管理により変更の追跡がはるかに容易になるため、設計システムにはバージョンが必要です。バージョン管理されたリリースでは、ユーザーは特定のバージョンを依存関係として参照できます。また、新しいバージョンへのアップグレードをいつどのように処理するかを制御することもできます。
バージョン管理には2つのタイプがあります。
- システム全体のバージョン管理。ここでは、システム内のすべてが1つのバージョン番号に属しています。ユーザーとして、モバイルOSを更新するときにシステム全体のバージョン管理を処理します。iOSを更新するときは、ソフトウェア全体を更新します。
- モジュールによるバージョン管理。これには、設計システム内のすべてのコンポーネントまたはスタイルのバージョン番号を設定することが含まれます。システム全体のバージョン管理と比較して、モジュールごとのバージョン管理はより柔軟性があります。ユーザーは必要な要素だけをアップグレードすることを選択できます。
設計システムの作成は、1回限りの作業ではありません。実際には反復的です。設計システムの作成に携わる人々は、それを組織全体をつなぐ生物として考える必要があります。成功した設計システムは組織のDNAの一部になり、一貫したユーザーエクスペリエンスを生み出すのに役立ちます。
このコンテンツはもともとnetmagに登場しました。
