デザインシステム チュートリアル & メリット – Indigo.Design

デザインシステムとデザイン・開発コラボレーションのニーズに関する最も本質的な概要を得る

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

私たちのDesign Systems RefCardでは、デザインシステムを再利用可能なUXパターンとブランドスタイルガイドラインの単なる意図的な目録以上のものとして捉えるための詳細な概要をお伝えします。また、部門を横断したチーム間で一貫した体験とデザイン・トゥ・コードのプロセスの整合性をもたらすために、あなたのデザイン・開発の現場で何をすべきかについても理解できるようになります。

今すぐRefCardを読んで、以下について学びましょう。

• 「デザインエンパワーメント」の重要性: コストのかかる、本来避けられるはずの手戻りを削減する。

• デザインシステムとは何か: 「デザイン資産のコレクション」を超えて、チームをデザインからコードへとより速く導くエンドツーエンドのツールを使用するという概念を包含する。

• デザインと開発のコラボレーションの4つの段階: モックアップやスタイルガイドの交換から、App Builderのようなツールを使用したデザイン固有のコンポーネントの生成まで。

• デザインシステムの解剖学: 原子、分子、有機体になぞらえられ、デザインシステムは製品とツールを念頭に置いた特定のUXニーズを反映して変化する。

• デザインシステムのさらなる利点: デザイン開発チームを必ずしも拡大することなく企業が急速に規模を拡大できるようにし、フル機能のアプリを提供するためのコストと時間を削減する。

• デザインシステムの未来: 自動化されたデジタル製品開発ツールやDevOpsとの容易な統合の可能性を秘め、開発者を最初の段階から招き入れる。

• ひと目でわかるApp Builder™: デザインシステムの堅牢で将来を見据えたアーキテクチャをチームが構築できるようにし、時間と労力を節約する。

はじめに

デザインと開発は、ソフトウェア製品開発における中核的な機能領域であり続けていますが、問題はほとんどの場合、それぞれが独自に進化してしまうという点です。実のところ、現代のアプリ構築の背後にある複雑さと時間の希少性は、デザイナーと開発者の双方に等しく有益な単一の信頼できる情報源(シングルソースオブトゥルース)を求める現実の警鐘として機能します。

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

ビジネスの成功という観点から見ると、企業はアプリケーションにおいて魅力的なUXを提供する必要性を認識しています[#]。しかし、魅力的なUXを提供するには、デザインと開発の間で高度なコラボレーションが求められます。そして、このレベルのコラボレーションは、現代の働き方に見られるリモートかつ分散した性質を考えると、コストがかさむ可能性があります。UXを提供するコストは、デザインの意図を伝える労力や、ビジュアル仕様をコードに変換する労力といった他の要因によってもさらに増大します。これらのコストを削減しない限り、たとえ最も意欲的な企業であっても、魅力的なUXを実現することは現実的に困難になるかもしれません。

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

しかし、デザインシステムとはユーザーインターフェースを構築するために使用するデザイン資産のコレクションであるという広く知られた定義があります。単純に言えば、確かにそれはUXパターンとブランドスタイルガイドの目録を表しており、これらはソフトウェアアプリケーションの構築のために再利用または文脈化できる対応するソフトウェアコンポーネントとして具現化されています。より大きな視点から見ると、デザインシステムは再利用可能なUIコンポーネントのライブラリをはるかに超えた存在です。それらは、次のような手作りの「デザインエンパワーメント」です。

• 製品チームのための単一の信頼できる情報源として機能する。

• 特定の使用状況とアプリドメインに合わせて調整する。

• デザインプロセスを加速し、一貫性を大幅に改善する。

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

これらすべてを理解するために、この記事では以下について確認していきます。

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

• デザイン・開発コラボレーションの段階

• デザインシステムの解剖学

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

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

• ひと目でわかるApp Builder

「デザインエンパワーメント」として見るデザインシステム

私たちInfragisticsは、直近のウェビナーに参加した388名の開発者を対象に調査を実施し、その結果、デザインチームと一緒に働いているのはわずか約26%であることが判明しました。つまり、4人に3人以上の開発者がUIデザイナーとしての役割も担っているということです。開発者の70%強はまた、HTML/CSSの作業と画面のデザインが、ウェブアプリ構築における最大の課題であり、作業を遅らせ、プロセスをさらに複雑にしていると回答しています。

ユーザーインターフェース(UI)がアプリケーション開発時間の60%を占める中、デザイナーから開発者へのハンドオフの際にミスが発生する可能性は非常に高く、アプリケーションが展開された後ではそのコストが10倍にも達することがあります。チームがよく直面する問題は、動作面と視覚面の乱れ、ブランドの不一致、使い勝手の悪さ、デザイン標準の伝達ミス、その他製品デザインと開発サイクルにおける不整合です。それ以外にも、デザインシステムを構築する時点と、それを適切に実装する時点との間で失敗の瞬間が生じることもあります。

しかし、デザインシステムが整っていれば、アプリ作成ははるかにスムーズに進み、アプリケーションが迅速に市場に出るのを妨げる、コストのかかる、本来避けられるはずの手戻りを削減できます。

デザインと開発のコラボレーションの進化する段階

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

• レベル1: 静的なビジュアル仕様

• レベル2: インタラクティブなビジュアル仕様(インスペクト)

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

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

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

レベル1: 静的なビジュアル仕様

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

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

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

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

このアプローチの主な利点は、デザイナーが手動で注釈を追加することを気にする必要がなく、開発者はUIのあらゆる部分についてアセットと仕様を抽出できることです。しかし、これは組織が使用しているソフトウェアコンポーネントには一切紐づいていません。

レベル3: UIコンポーネントに紐づいたビジュアル仕様

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

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

このアプローチでは、開発者はそれでもアプリの骨組みを組み立て、レイアウトを作成し、仕様に合わせてコンポーネントをさらに設定するためのUIコードを書く必要があります。実装が合意されたデザインシステムのコンポーネントを利用しているため、コミュニケーションのミスが起きる可能性は低くなります。Storybookのようなソリューションを使えば、UIキットのコンポーネントと開発者のコンポーネントツールキットを紐づけることが可能です。この種の統合は、開発者ツールキットを文書化するためのソフトウェアチームの間で人気が高まっています。

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

レベル3: UIコンポーネントに紐づいたビジュアル仕様

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

一部の組織は依然として古いフレームワークを使用しており、BlazorやAngularへ移行しなければならない時点に達しています。しかし、市場投入までの時間を同時に加速させようとしながらそれを行うには、より抜本的な解決策が求められます。デザインシステムに基づいた仕様を作成し、それをハンドオフ成果物として含めることは、これに対処する一つの方法です。しかし、こうしたプロジェクトは、次のような課題を含む(これに限らない)他の課題も克服しなければなりません。

• デザインシステム(すなわち合意された構成要素)を調査し設計する

• デザインシステムに合致するコンポーネントライブラリを構築し維持する

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

• 開発中に役立つ必要な開発者向けドキュメントを作成する

• アプリケーションがビジュアル仕様(レイアウト+テーマ)に正確に一致することを確認する

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

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

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

デザインを規模拡大するというストーリーをサポートするApp Builderの主要機能には、以下が含まれます。

• AngularおよびBlazorプラットフォーム向けのアプリシェルとビューの骨組み作成

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

• Webレイアウト

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

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

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

デザインシステムの解剖学

デザインシステムがデザイン・トゥ・開発のストーリーのどこに位置するかについての理解が深まったところで、それがどのように構造化されているかを見ていきましょう。

デザインシステムは、原子、分子、有機体になぞらえて最もよく説明できる、拡張可能な要素を構築するためのアプローチを採用しています。これはBrad Frostによって作られたアトミックデザイン手法と呼ばれています。これはデザインシステムの構造を説明するための一般的なアプローチとなっています。

原子、分子、有機体のメタファーに戻ると、まず最も小さなコンポーネント(ボタン、アバター、ラベル、見出しなど)をデザインすることから始めます。この最小のコンポーネントを原子と呼びます。

さらに一段深く見ると、原子は核、陽子、中性子といった粒子から構成されます。デザインシステムでは、これは組織のブランドアイデンティティを定義する基本のカラーパレットとタイポグラフィに対応させることができます。

原子から一段上に上がると、原子から構成される分子があります。分子はコンポーネントに対応させることができ、メニュー項目、リスト項目、ドロップダウン項目といったより複雑な構造を表します。

そして、レイアウトと複数のコンポーネントを組み合わせることで、次の階層単位であるUXパターン、つまり生物学的な比喩を続けると有機体が得られます。これらは「良い」デザイン原則に従うことでUXにおけるベストプラクティスを内包し、製品固有のニーズのために構築されます。

デザインシステムを原子、分子、有機体として図解するポイントは、生きたシステムとの類似性を描き出すことにあります。デザインシステムは静的で決して変化しないものであってはならず、製品のUXニーズを反映し、製品や使用される技術とともに絶えず進化していくべきです。新しいデバイスのレイアウト要件、新しい製品機能、ブランドアイデンティティの変更によって新たな要件が生まれることは避けられず、私たちのデザインシステムが柔軟であり、こうした変化に適応できるよう変化する準備ができていることを確認しなければなりません。

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

標準化されたUX

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

不整合の一般的な原因は、製品の開発に複数の開発者やデザイナーが関わっている場合です。さらに、タイムゾーンをまたいだ分散型の働き方が拡大していることも加わり、1対1のレビューを行うコストが高くなっています。デザインシステムが整っていれば、デザイナーと開発者はデザイン実装に関する低レベルなチェックを必要とせずに、それぞれのツールで独立して作業できます。その代わりに、成果に関する高価値なやり取りに集中できます。

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

GitHubのDiana Mounterが述べているように、

「デザインシステムは混沌に秩序をもたらします。全員が同じ認識を共有できるため、製品全体を通して一貫性と洗練さが保たれます。デザインシステムは、使い慣れた実証済みのパターンを繰り返し使用することでユーザー体験を向上させます。何かをゼロから設計すると誤りの余地が生まれるため、すでに機能しているものを使うようにしましょう。デザインシステムはワークフローの効率を向上させます。製品チームは、新機能のコンポーネントがどのように見えるべきか、どのように実装すべきかを正確に把握できます。」

デザインと開発の間で共有される語彙

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

時間が経つにつれ、UXパターンの名称が会話の中に現れるようになり、ユーザー要件の代替として機能するようになります。例えば、誰かがコンボボックスコンポーネントを使うべきだと言及すれば、デザイナーにも開発者にも、それがどのような振る舞いをサポートし、体験の目標にどのように適合するかが明確になります。デザインシステムはコンポーネントをパターンとして文書化するため、通常、特定のコンポーネントをいつ使うべきか、そしてそれを正しい方法で使う方法を例とともに説明します。その意味で、デザインシステムは親しみやすいUXガイダンスへのニーズを満たし、デザインの実践を広めることができます。

デザインプロセスと開発の高速化

配信までの速度は、デザインシステム内のコンポーネントを再利用することによる明白な利点です。デザインの観点から見ると、新しいコンポーネントやパターンをすでにデザインシステムのUIキットの一部として作成する必要がないことから効率が生まれます。複雑な新しいパターンを作成する必要に迫られた場合でも、デザイナーはデザインシステムのガイドラインに頼り、すでに利用可能な「原子」や「分子」を使って何かを作り上げることができます。開発者の視点から見ると、このコンポーネントやパターンのコードを生成できることは、デザイン仕様とコードの間の不整合を回避するのに役立ちます。

学習までの速度は、デザインシステムのアプローチを使用することのあまり明白ではない利点です。デザイナーがピクセル単位の細工から解放されることで、真のデザインプロセスに戻り、ユーザージャーニーやフローの設計とユーザーによるその評価に集中できるようになります。デザイン成果物を作成するために使用されるアプローチは、ユーザビリティテストやステークホルダーからのフィードバック取得のための暫定プロトタイプを作成するためにも使用できます。

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

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

デザインプロセスは、時としてそうあるべき以上に複雑で、分散し、混沌としています。そのような場合、デザインシステムは戦略的な機能として、またコラボレーションを改善するための手段として求められます。これまで議論してきたように、デザインシステムはデザインと開発の連携を助ける一種の共有知識基盤として機能します。それはチームが(可能な限り)ベストプラクティスを成文化するためのフォーラムです。また、それは生きたシステムであるべきものなので、新しいパターン、要件、さらには(低コードのアプリメーカーをそのプロセスに沿って使用するような)コード生成ソリューションについて議論し、それを取り込む機会も提供します。さらに重要なのは、デザインシステムは単なるリポジトリではなく、コラボレーションの方法だということです。それは、デザイナーと開発者がコラボレーションする際に直面する課題に対する万能薬ではありません。また、デザインシステムが存在するからといって、両分野の間の意味のある対話が不要になるわけでもありません。

多くの企業にとって最大の課題は、自社のニーズと進行中のデジタルトランスフォーメーションの両方に響く、関連性のあるデザインシステムのアプローチを始めることです。すでに多種多様なアプリを世に送り出している企業にとって、初期段階は骨の折れる作業です。参考にできるデザインシステムはいくつも存在しますが、それぞれが独自の親組織のために作られたものです。同時に、それらはUXパターンやベストプラクティスの面で多くの共通点も持っています。そのため、盲目的にコピーするのではなく、組織が自社のデザインシステムを迅速に作成できるよう支援するツールとサービスが必要とされています。

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

このように高度にデジタル化された状況において、App Builderのようなツールを使用することは、チームや企業にとって機能的で効果的なデザインシステムの背骨となります。App Builderがデザインと開発をどのように前向きに変えるかをよりよく示すために、以下がApp Builderの機能です。

• Material UIキットに加え、Bootstrap、Fluent、Indigo向けのUIキットを提供します。これにより、デザインチームは人気のあるどのデザインシステムでも対象にでき、テーマ、画面パーツ、UIパターンをカスタマイズして、ピクセルパーフェクトなアプリとAngularやBlazorのコード生成へシームレスにハンドオフできます。

• 豊富なコントロールとコード生成機能 - データバインドされたコントロールやナビゲーションコントロールから、Blazorの両方とAngularアプリのコード生成まで。

• アプリテンプレートと画面レイアウト - アプリデザインを素早く開始し、ワンクリックでレスポンシブなページを構築するのに役立ちます。これらは、開発者にとってアプリ開発の中で最も困難な部分、すなわちWeb向けのレスポンシブCSSを手作業でコーディングし、実データにバインドされた実際のUIコントロールを使った複雑でインタラクティブなレイアウトを作成する作業を軽減します。

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

また、原子‐分子‐有機体という構造はデザインシステムの出発点に過ぎず、そこで終わる必要はありません。それは、アプリがどのように動作すべきかについての追加情報を含むことができます。以下は、デザインシステムに含めるべき候補のリストであり、これは決して網羅的なものではありません。

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

• モーションとトランジションは、アプリを使用する際にダイナミズムと楽しさのレベルを提供するために、ますます一般的になりつつあります。しかし、単独ではいくつかのトランジションを理解できるとしても、アプリ全体でそれを標準化しておくのが良いでしょう(例:マスター・ディテールのトランジションにはスライドトランジションを使う)。

• ユーザーストーリーは、一般的または特殊なタスクがアプリでどのように実現されたかを文書化するのに役立ちます。それは新しいデザインのインスピレーションとして機能することもできます。

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

デザインシステムを構築し、使用し、維持することは、コンポーネントやパターンを再構築する必要がなくなるため、より一貫性のある体験へとつながります。その代わりに、デザイナーと開発者は統一された目録から利益を得て、それが再利用を促し、柔軟なデザインアセットを提供し、ゼロからデザインする時間と労力を節約します。デザインシステムの未来はまた、一貫したタイポグラフィ、色、音声、トーンを通じて、明確な基準と実務的なブランドコンプライアンスを統べる実践を規定していきます。

しかし、それだけではありません。今日成功しているデザインシステムには、以下のような共通の文化的シフトと異なるマインドセットも必要です。

• デザイナーと開発者の両方を含む部門横断性を育み、アイデアと成果をより良く伝え、最終製品の品質を向上させ、チームが共同で生み出すインパクトを高める。

• App Builderのような既に確立された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のそれぞれの見た目と操作感にそっくりな独自のバリアントを展開します。