デザインシステムのクイックガイド

導入

設計と開発は、ソフトウェア製品開発における中核的な機能分野であり続けていますが、ほとんどの場合、それらは独自に進化していくという問題があります。しかし実際には、現代のアプリ構築の背後にある複雑さと時間不足は、設計者と開発者の両方に等しく有益な唯一の真実のソースを要求する現実を突きつけています。

ただし、デザイン システムの使用と構築は新しいものではありません。新しいのは、それをどのように使用し、どこに適用するかです。正しく実行すれば、製品設計とSketchまたはFigmaデザインからの移行、UX デザイン、ハンドオフ、ユーザー テスト、フロントエンド開発などのプロセスを大規模に実行できるようになります。

ビジネスの成功の観点から、企業はアプリケーションで魅力的な UX を提供する必要性を認識しています [#]。しかし、魅力的な UX を提供するには、設計と開発の高度なコラボレーションが必要です。そして、現代の仕事のリモート性と分散性を考えると、このレベルのコラボレーションはコストがかかる可能性があります。UX を提供するコストは、設計意図を伝えるために必要な労力や、視覚的な仕様をコードに変換することなど、他の要因によっても複雑になります。これらのコストを削減しない限り、最も意欲的な企業であっても魅力的な UX を提供することは不可能かもしれません。

近年、デザインシステムは、デザインと開発の連携を改善するためのソリューションとして登場しました。デザインシステムのアプローチは、Salesforce.com、IBM、Atlassianなどの組織に採用されており、その魅力を証明しています。

しかし、デザイン システムとは、ユーザー インターフェイスの構築に使用するデザイン アセットのコレクションであるという一般的な定義があります。簡単に言えば、デザイン システムは、ソフトウェア アプリケーションの構築に再利用またはコンテキスト化できる一致するソフトウェア コンポーネントとして実現される UX パターンとブランド スタイル ガイドのインベントリを表します。より大きな視点で見ると、デザイン システムは再利用可能な UI コンポーネントのライブラリ以上のものです。デザイン システムは、次のような手作りの「デザイン エンパワーメント」です。

• 製品チームにとって唯一の真実の情報源として機能します。

• 特定の使用コンテキストとアプリ ドメインに合わせます。

• 設計プロセスを高速化し、一貫性を大幅に向上します。

また、各組織の特定のアプリケーション ドメインと使用コンテキストに合わせて手作業で作成される方法で、コンテンツ、ページ テンプレート、さらにはユーザー フローを作成するための音声とトーンのガイダンスを含めるように拡張することもできます。

すべてを理解するために、この記事で確認する内容は次のとおりです。

• 「デザインのエンパワーメント」の重要性

• 設計開発コラボレーションの段階

• デザインシステムの構造

• デザインシステムを使用する利点

• デザインシステムの未来は自動化とローコードツールと絡み合っている

• App Builderの概要

デザインシステムは「デザインの力」として捉えられる

インフラジスティックスでは、最近のウェビナーに参加した 388 人の開発者を対象に調査を実施しました。その結果、デザイン チームと連携している開発者はわずか 26% 程度で、4 人中 3 人以上の開発者が UI デザイナーとしても活動していることがわかりました。また、開発者の 70% 強が、HTML/CSS の操作と画面のデザインが Web アプリ構築の最大の課題であり、それが作業の遅れやプロセスの複雑化につながっていると述べています。

ユーザー インターフェイス (UI) がアプリケーション開発時間の 60% を占めるため、デザイナーから開発者への引き継ぎ中にミスが発生する可能性は非常に高く、アプリケーションの導入後にはコストが 10 倍になる可能性があります。チームが頻繁に遭遇する問題は、動作や視覚的な混乱、ブランドの不一致、使いやすさの悪さ、設計基準の伝達ミス、製品の設計と開発サイクルにおけるその他の不一致です。また、設計システムの構築から適切な実装までの間に、失敗の瞬間が発生することもあります。

ただし、デザイン システムを導入すると、アプリの作成がはるかにスムーズに行われ、アプリケーションの迅速な市場投入を妨げる、コストのかかる、本来は避けられないやり直しが削減されます。

設計と開発のコラボレーションの進化段階

デザイン システムについて詳しく説明する前に、デザインと開発のコラボレーション成果物がどのように進化してきたかを確認しましょう。これは、大きく 4 つのレベルに分類できます。

• レベル1: 静的な視覚仕様

• レベル2: インタラクティブなビジュアル仕様（検査）

• レベル 3: UI コンポーネントにリンクされたビジュアル仕様 (デザイン システム)

• レベル 4: 設計仕様からアプリを生成する (デザイン システム +)

すべてのレベルにおいて、開発に先立って何らかの設計活動が行われていたと想定できます。つまり、UI とフローの仕様は開発前に作成されます。

レベル1: 静的な視覚仕様

この形式の設計開発コミュニケーションは最も一般的です。このレベルでは、ビジュアル デザイナーが使用するツール (SketchやFigmaなど) を使用してビジュアル モックアップが作成されます。スタイル、レイアウト、サイズなどの仕様は、レビュー用にモックの上に注釈として追加されます。

開発者は開発プロセスの一環としてこのドキュメントを参照し、手動でコードに実装します。このアプローチは、メンテナンスする必要のないカスタムの 1 回限りのプロジェクトには適しています。

レベル 2: インタラクティブなビジュアル仕様 (検査)

このレベルでは、ビジュアル デザイン チームは引き続き開発者とモックアップやスタイル ガイドを共有していますが、静的なドキュメントではなく、よりアクセスしやすい形式で仕様を提供するためのツールに依存しています。Zeplin.io などのツールを使用すると、デザイナーはデザインをマークアップする手間をかけずにデザインをアップロードでき、開発者はブラウザーでデザインを表示できます。さらに重要なのは、開発者がデザインをクリックすると、オンデマンドで、ターゲット プラットフォーム (HTML、CSS など) に合わせた形式で仕様を表示できることです。

このアプローチの主な利点は、デザイナーが手動で注釈を追加する必要がなく、開発者が UI の任意の部分のアセットと仕様を抽出できることです。ただし、組織が使用するソフトウェア コンポーネントにはリンクされません。

レベル3: UIコンポーネントにリンクされたビジュアル仕様

このレベルでは、デザイン部門が開発部門と協力して、ニーズに合ったスタイル、レイアウト、UI コンポーネントのインベントリを作成していることが期待できます。つまり、デザイン システムの概要が作成されたことになります。

ここで、デザインチームは、デザインシステムを反映した標準化された UI キットを使用してデザインを作成します。UI キットは、コードベース内のコンポーネントと一致するデザインツール自体 (SketchやFigmaなど) を使用して作成された、再利用可能なビジュアルデザイン要素のコレクションに付けられた一般的な名前です。これにより、一致する UI コンポーネントがすでに存在するため、開発チームがデザインを実装しやすくなります。

このアプローチでは、開発者は依然として、アプリのスキャフォールディング、レイアウトの作成、仕様に一致するようにコンポーネントをさらに構成するための UI コードを記述する必要があります。実装では合意されたデザイン システム コンポーネントが使用されるため、誤解が生じる可能性が減ります。Storybook などのソリューションを使用すると、UI キット コンポーネントを開発者コンポーネント ツールキットにリンクできます。このタイプの統合は、開発者ツールキットを文書化するためにソフトウェア チームで人気が高まっています。

しかし、より大きな問題は、すべての組織がデザイン システムに投資しているわけではないということです。そのため、このレベルのコラボレーションは、ほとんどの組織にとって目標に過ぎません。さらに、このようなコラボレーションは、デザイン システム コンポーネントまたはデザイン トークンの再利用に重点を置いています。開発者は、各コンポーネントを構成して UI を実装する必要があり、その後、デザイン チームによって承認されます。

レベル3: UIコンポーネントにリンクされたビジュアル仕様

デザイン システムは、設計チームと開発チームが共通のビルディング ブロック セットを標準化するのに役立ちます。ただし、ハンドオフの一部として作成される成果物 (つまり、設計成果物) は、非効率の原因となる可能性があります。前のセクションで説明したように、無駄な労力は、開発チームが設計を実装する必要があることに起因します。具体的には、コンポーネントの構成とレイアウトの再作成です。

一部の組織では、依然として古いフレームワークを使用する傾向があり、BlazorまたはAngularに移行しなければならない段階に達しています。しかし、市場投入までの時間を短縮しながら移行するには、より根本的な解決策が必要です。デザイン システムに基づいて仕様を作成し、それをハンドオフ アーティファクトとして含めることは、その対処方法の 1 つです。ただし、このようなプロジェクトでは、次に挙げるものに限定されない他の課題も克服する必要があります。

• デザインシステム（合意された構成要素）を調査して設計する

• デザインシステムに適合したコンポーネントライブラリの構築と維持

• ターゲット プラットフォーム (例: Angular) に精通し、ベスト プラクティスを取り入れます。

• 開発を支援するために必要な開発者向けドキュメントを作成する

• アプリケーションがビジュアル仕様（レイアウト + テーマ）と正確に一致していることを確認します。

App Builderのようなソリューションは、前のセクションで説明した従来の種類のハンドオフを置き換えることを目的としています (レベル 3 を参照)。仕様書やモックアップを共有する代わりに、開発者は既に実現された設計仕様に基づいたアプリを受け取ります。これにより、仕様の一部を検査して抽出したり、設計を再実装したりする必要がなくなります。

ローコード アプローチでは、デザイナーは Indigo.Design UI キットを使用してモックアップを作成します。この UI キットは、デザイン ツール (FigmaやSketchなど) に適した形式のデザイン システムのバージョンをデザイナーに提供します。これにより、デザイナーは画面レイアウトを作成し、デザイン システムで許可されている内容に従ってコンポーネントを構成できます。

モックアップが完成したら、ユーザーはプラグインを使用してデザインをアプリとして公開できます。プラグインは静的なデザイン ファイルをクラウドベースの WYISWYG エディターを使用してさらに編集できるアプリに自動的に変換します。このエディターを使用すると、開発者はアプリケーションのソース コード全体をダウンロードする前にアプリの編集を続けることができます。

大規模な設計をサポートするApp Builderの主な機能は次のとおりです。

• AngularおよびBlazorプラットフォーム用のスキャフォールディング アプリ シェルとビュー

• アプリのルーティングとナビゲーション

• ウェブレイアウト

• グローバルテーマとトークン

• REST API ソースを使用したデータバインディング

• GitHubとの統合による開発継続

デザインシステムの構造

​設計から開発までのストーリーの中でデザイン システムがどこに当てはまるかがよくわかったので、それがどのように構成されているかを見てみましょう。

デザイン システムは、原子、分子、有機体として最もよく説明できるスケーラブルな要素を構築するためのアプローチを使用します。これは、Brad Frost によって考案された Atomic Design Methodology と呼ばれています。これは、デザイン システムの構造を説明する一般的なアプローチになっています。

原子、分子、生物の比喩に戻ると、まずは最小のコンポーネント (ボタン、アバター、ラベル、見出しなど) を設計することから始めます。この最小のコンポーネントは原子と呼ばれます。

さらに深く考えると、原子は核、陽子、中性子などの粒子で構成されています。デザイン システムの場合、これを基本カラー パレットとタイポグラフィにマッピングして、組織のブランド アイデンティティを定義することができます。

原子から 1 レベル上がると、原子で構成される分子があります。分子はコンポーネントにマッピングでき、メニュー項目、リスト項目、ドロップダウン項目などのより複雑な構造を表すことができます。

次に、レイアウトと複数のコンポーネントを組み合わせることで、次の階層単位である UX パターン、または生物学的な比較に固執する生物が得られます。これらは、「優れた」設計原則に従うことで UX のベストプラクティスをカプセル化し、製品の特定のニーズに合わせて構築されます。

デザイン システムを原子、分子、有機体として表現する目的は、生きたシステムと類似点を描くことです。デザイン システムは静的で変化しないものであってはなりません。製品の UX ニーズを反映し、使用される製品やテクノロジーに合わせて常に進化する必要があります。新しいデバイス レイアウト要件によって新しい要件が生まれ、新しい製品機能やブランド アイデンティティの変更は避けられません。そのため、これらの変化に適応するために、デザイン システムが柔軟で変更に対応できる状態にあることを確認する必要があります。

デザインシステムを使用する利点

標準化されたUX

デザイン システムの最も強力な利点の 1 つは、さまざまなデバイス、製品、サブ製品間で一貫性を維持し、マーケティングやブランディングと連携できることです。

一貫性のなさの一般的な原因は、製品の開発に複数の開発者とデザイナーが関わっている場合です。これに加えて、タイムゾーンをまたいで仕事が分散化していることから、1 対 1 のレビューはコストがかかります。デザイン システムを導入すると、デザイナーと開発者は、デザインの実装に関する低レベルのチェックを必要とせずに、独自のツールで独立して作業できます。代わりに、結果に関する価値の高いやり取りに集中できます。

純粋に顧客の観点から見ると、同じ組織が提供するアプリケーション間で意味のある一貫性があれば、ユーザーは過去のアプリとのやり取りから得た知識を再利用できます。

GitHub の Diana Mounter 氏は次のように述べています。

「デザイン システムは、混沌に秩序をもたらします。全員が同じ認識を持つため、製品全体が一貫して洗練され、常に整った状態を保てます。デザイン システムは、使い慣れた実績のあるパターンを繰り返し使用することで、ユーザー エクスペリエンスを向上させます。ゼロから何かを設計するとエラーが発生する可能性があるため、すでに機能しているものを使用するようにしてください。デザイン システムはワークフローの効率性を向上させます。製品チームは、新機能のコンポーネントがどのように見えるか、どのように実装するかを正確に把握できます。」

設計と開発の共通語彙

一貫性は大きな成果ですが、コンポーネントとパターンの命名について相互に合意するといった単純なことでも、大きな効果が得られます。これは、デザイン システムの現在のユーザーにとっても、将来のメンバーのオンボーディングにとっても役立ちます。命名規則を明示して共有することで、開発者とデザイナーの両方がそれぞれのツール環境でコンポーネントを見つけやすくなります。

時間が経つにつれて、UX パターンの名前が会話の中で浮上し始め、ユーザー要件の代用として機能します。たとえば、コンボ ボックス コンポーネントを使用する必要があると誰かが言うと、デザイナーと開発者の両方にとって、それがサポートする動作の種類と、それがエクスペリエンスの目標にどのように適合するかが明確になります。デザイン システムはコンポーネントをパターンとして文書化するため、通常、特定のコンポーネントをいつ使用するか、例を使用して正しい方法を説明します。したがって、その意味で、デザイン システムはわかりやすい UX ガイダンスのニーズを満たし、デザイン プラクティスを普及させることができます。

設計プロセスと開発をスピードアップ

配信までのスピードは、デザイン システムでコンポーネントを再利用することの明らかな利点です。デザインの観点から見ると、新しいコンポーネントやパターンは既にデザイン システムの UI キットの一部になっているため、それらを作成する必要がないため、効率が向上します。新しい複雑なパターンを作成する必要が生じても、デザイナーはデザイン システムのガイドラインに従い、すでに利用可能な「原子」や「分子」を使用して何かを構築できます。開発者の観点から見ると、このコンポーネントまたはパターンのコードを生成できることは、デザイン仕様とコード間の不一致を回避するのに役立ちます。

学習のスピードは、デザイン システム アプローチを使用することのあまり目立たない利点です。デザイナーはピクセル クラフティングから解放され、真のデザイン プロセスに戻り、ユーザー ジャーニーやフローの設計とユーザーによる評価に集中できます。デザイン成果物の作成に使用されるアプローチは、[ユーザビリティ テスト](#) や [関係者からのフィードバックの取得](#) のための暫定プロトタイプの作成にも使用できます。

変化する状況、あるいはデザインシステムの将来が自動化やローコードツールとどのように絡み合うのでしょうか?

どのデザインツールを使用していますか?

デザイン プロセスは、時には必要以上に複雑で、分散し、混沌としていることがあります。そのような場合、戦略的機能として、またコラボレーションを改善するための手段として、デザイン システムが必要になります。前述したように、デザイン システムは、デザインと開発の連携に役立つ一種の知識共有の場として機能します。これは、チームがベスト プラクティスを (可能な限り) 体系化できるフォーラムです。また、デザイン システムは生きたシステムであるため、新しいパターン、要件、さらにはコード生成ソリューション (プロセス中にローコード アプリ メーカーを使用するなど) を議論し、取り入れる機会も提供します。さらに重要なのは、デザイン システムは単なるリポジトリではなく、コラボレーションの方法であるということです。これは、デザイナーと開発者がコラボレーションする際に直面する課題に対する特効薬ではありません。また、デザイン システムの存在が、2 つの分野間の有意義な会話を妨げるものでもありません。

多くの企業にとって最大の課題は、自社のニーズと進行中のデジタル変革の両方に合致する適切なデザイン システム アプローチを開始することです。すでにさまざまなアプリを運用している企業にとっては、最初の段階は面倒な作業です。参照できるデザイン システムはいくつかありますが、それぞれが独自の親組織向けに作成されています。同時に、UX パターンやベスト プラクティスの点でも多くの共通点があります。そのため、組織が盲目的にコピーするのではなく、独自のデザイン システムを迅速に作成できるようにするためのツールとサービスが必要です。

私たちが話しているような合理化されたプロセスと一貫性は、自動化や、たとえばデザイン ライブラリに包括的なテーマを一度に適用できるプラグインを通じて実現できます。また、デザイナーと開発者の引き継ぎを処理するための革新的ではるかに効率的なアプローチを可能にし、アイデアを説明したり、SketchやFigmaファイルには通常含まれていないアニメーションやマイクロインタラクションを正当化したりする時間とエネルギーを節約することも意味します。

高度にデジタル化された状況では、App Builderのようなツールを使うことが、チームや企業にとって機能的で効果的なデザイン・システムのバックボーンとなる。App Builder、デザインと開発にどのような変化をもたらすかを説明しよう：

• Material UI Kitに、Bootstrap、Fluent、Indigo用のUIキットが追加されました。これにより、デザインチームは、テーマ、画面パーツ、UIパターンをカスタマイズできる一般的なデザインシステムをターゲットにすることができ、App Builderにシームレスにハンドオフして、ピクセルパーフェクトなアプリやAngularのコード生成またはBlazor。

• 多数のコントロールとコード生成機能 – データバインドやナビゲーションコントロールからBlazorのコード生成およびAngularアプリ。

• アプリ テンプレートと画面レイアウト – アプリ デザインを開始し、ワンクリックでレスポンシブ ページを構築できます。開発者にとってアプリ開発の最も難しい部分、つまり Web 用のレスポンシブ CSS を手動でコーディングし、実際のデータにバインドされた実際の UI コントロールを使用して複雑でインタラクティブなレイアウトを作成する作業を軽減します。

デザイン システムは、UX のベスト プラクティスや UI キットだけではないことに注意することが重要です。開発側でも、対応する UI コンポーネントが必要です。デザイン システムの動きは、従来、大規模な組織内のデザイン チームによって推進されてきましたが、真の成功を収めるには、開発チームもデザイン システムの共同所有者/貢献者になる必要があります。

また、原子-分子-有機体構造はデザイン システムの出発点に過ぎませんが、それだけではありません。アプリの動作方法に関する追加情報を含めることができます。以下は、デザイン システムに含める可能性のある候補のリストですが、決して網羅的ではありません。

• インタラクション デザイン ガイダンスでは、ジェスチャー駆動、マウスとキーボード駆動など、ユーザーがアプリケーションとどのように対話するかについて説明します。また、すべきこととすべきでないことの概要を示します。Google のマテリアル デザインは、これを非常にうまく実行します。

• モーションとトランジションは、アプリを使用する際に一定のダイナミズムと楽しさを提供するために、ますます一般的になっています。ただし、一部のトランジションは個別に理解できるかもしれませんが、アプリに対して標準化することが望ましいです (例: マスター詳細トランジションのスライドトランジション)。

• ユーザー ストーリーは、一般的なタスクや特殊なタスクがアプリ内でどのように実現されたかを文書化するのに役立ちます。新しいデザインのヒントとして役立ちます。

• デザインシステムのさまざまな部分がどのように連携するかを示すリファレンスアプリ

デザイン システムを構築、使用、維持することで、コンポーネントやパターンを再構築する必要がないため、より一貫性のあるエクスペリエンスが実現します。デザイナーと開発者は、再利用を促進し、柔軟なデザイン アセットを提供する統合インベントリの恩恵を受け、ゼロからデザインする時間と労力を節約できます。デザイン システムの将来は、一貫したタイポグラフィ、色、声、トーンを通じて明確な基準と実用的なブランド コンプライアンスを管理するプラクティスも決定します。

しかし、それだけではありません。今日の成功したデザイン システムには、次のような共通の文化的変化と異なる考え方も必要です。

• デザイナーと開発者の両方を含むクロスファンクショナルを育成し、アイデアと結果をより適切に導き、最終製品の品質を向上させ、チームが一緒に生み出す影響を高めます。

• すでに確立された UI および UX プラクティスを中心に、App Builderなどのツール、システム、サービスを取り入れることで、ロードマップの洗練、サイロの排除、反復的なタスクの削減、信頼できる唯一の情報源の確立、デジタル製品の設計と開発の速度と品質の向上に役立ちます。

ソリューションとしてApp Builder選択する理由は何ですか?

チームが堅牢で将来性のあるデザイン システムのアーキテクチャを導入するのに役立つだけでなく、時間と労力を節約し、デザイナーが実際のデザインに集中できるようになります。

App Builder特徴:

• すべてのテクノロジーに対してまったく同じデザイン システムに従うサードパーティの UI キットがあるため、デザイナーは選択したツールを切り替えても、特定のツール用に当社が提供するシンボルを使用してデザインすることができます。

• UI キット シンボルの背後にあるメタデータを活用したSketchおよびFigmaのネイティブ ライブラリを表し、設計された画面をApp Builderに取り込み、実際のコンポーネントの観点から視覚化します。

• 状態を持つコンポーネントを提供するだけでなく、デザイン システムのユーザーがコンポーネントの構成を変更すると自動的に調整されるテンプレートとバリアントも提供します。

• App Builder と連携して、Web に実際のコンポーネントを作成します。

• アプリケーションの構造、ビュー、および相互作用を定義する方法を抽象化します。

• 異なるテクノロジーで同じアプリを使用できるようになります。

• デザインを取得し、それをApp Builderが理解できるようにして、AngularまたはBlazor (Web ComponentsとReact近日公開予定) のコード プレビューとコード生成を有効にします。

• テクノロジー全体にわたる共通のパターンを定義します。

• UI キット、App Builder、またはその他のサードパーティ プラグイン上のデザイン ツール パーサーによって生成されます。

• テーマ設定、ブランディング、さらにカスタマイズ オプションのための強力なメカニズムを備えています。

• これらのフレームワークと見た目や操作性がまったく同じ、Material、Bootstrap、Fluent の個別のバリアントを展開します。