デザインシステムとは、製品の一貫性のある、ブランドのイメージに合ったインターフェースを構築するのに使われるコンポーネント、ルール、スタイルガイド、ドキュメントのセットです。大抵のブランドは独自のデザインシステムを構築していますが、その中で本記事では、そこから多くを学ぶことができる最も一般的なデザインシステムを９つ挙げてみました。ちなみにそのデザインシステムおよびその他のデザインシステムは、Adele というデザインシステムレポジトリで見つかります。

UXPin Merge でデザインシステムの導入とガバナンスを強化しませんか。デザインシステムからインタラクティブコンポーネントをすべてエディタに取り込んで、完全にインタラクティブなプロトタイプを作成し、デザインの一貫性を保ちましょう。UXPin Merge の詳細を読む。

デザインシステムとは

デザインシステムとは、プロダクトチームがアプリ、Web サイト、EC ストア、その他開発が必要な UI デザインの UI（ユーザーインターフェース）を構築するのに使うすべてのデザインリソースの集合体です。

デザインシステムはデザイナーだけのものではなく、デベロッパー向けのものでもあり、必要なフロントエンドコードとドキュメント、デザインガイドライン、関連プラグイン、デザインパターン、スタイルガイド、再利用可能なコンポーネント、ルールとガイドライン、その他 Web デザインと開発ワークフローに役立つ構成要素がすべて含まれた、コードスニペットと開発リソースがすべて含まれています。

このようなデザインシステムは、オンラインの Web サイトとしてホストされて一般に公開されることもあれば（オープンソースのデザインシステム）、ブランド内部で使われることもあります。

そしてデザイン システムは、適用可能な手順や例、プロダクトデザインやコーディングのガイドライン、UI キットの一部などがすべて揃った貴重なドキュメントとして機能する膨大なデータライブラリと考えることができます。

このように、デザインシステムに関連するプロダクトデザインのコンセプトはたくさんあります。デザインシステムとパターンライブラリ、コンポーネントライブラリ、UI キットの違いを知りたい方は、以下のの記事をご覧ください：デザインシステム、パターンライブラリ、スタイルガイド、コンポーネントライブラリの違い

企業が独自のデザインシステムを構築する理由

Shopify、Google、AirBnB などの企業は、以下のような理由から独自のデザイン システムを構築しています：

• 一貫性 – デザイン システムは、デザインと開発の「信頼できる唯一の情報源（Single source of truth）」として機能する。
• 透明性 – デベロッパーは、デザイン上の決定の解釈をする必要なく、デザインシステムのコンポーネントを直接使用できる。
• スケール – デザイナーはプロトタイプをより速く構築し、デベロッパーへの引き継ぎを効率化できる。
• 再利用性 – デザインシステムにより、組織内で共有できる一貫したコンポーネントがあるプロトタイプの作成が促される。
• 明確さ – デザインシステムで、デザイン上の決定が共有された知識に基づいて行われるようになり、それでチーム メンバーが理解しやすく、効果的に貢献しやすくなる。

デザインシステムから学ぶこと

デザインシステムの大半は、むしろ一般的なデザインパターンに従っています。

そしてシステムは、多くの場合はデザイン、コード、言語、コンポーネントなどの主要なカテゴリーを備えたトップナビゲーションを特徴とします。

このようなメインカテゴリには、より詳細な説明があるサブカテゴリがそれぞれあり、アトミックデザインの構造を最大限に活用しています。たとえば、そのサブカテゴリには、タイポグラフィ、色、フォーム、バナーなどがあります。

この直感的なナビゲーションに従うことで、デザインに関するベストプラクティスに関する貴重な情報を得ることができます。

デザインシステムを作成するメリット

適切に構築されたデザインシステムを導入することで、企業はチームワークを大幅に改善して、意思決定プロセスを効率化できますが、デザインシステムの作成で得られるのはそれだけではありません。

このようなガイドライン、要素、データの集まりにより、デザイナーとデベロッパー間のコミュニケーションの問題が最小限に抑えられ、潜在的な UX デザインのバグや UX 負債の発生の余地が最小限に抑えられます。

さらに、このようなリファレンスが豊富なライブラリーがあることで、プロトタイプから実際の製品になるまでに必要な時間が大幅に短縮されます。

例えば、PayPal は Fluent UI を Merge のテクノロジーと共に使っています。これにより、インタラクティブなコンポーネントを UXPin ライブラリに組み込むことができ、そうすることで、デザイナーもプロダクトチームのメンバーも、このコンポーネントに簡単にアクセスし、何度も繰り返しデザインすることができます。

デザインシステムはデザイナーとデベロッパーの間の繋がりが絶たれるのを最小限にする素晴らしい方法ですが、それだけではまだ理想的なソリューションではありません。Merge テクノロジーの革新のおかげで、製品チームのメンバーは同じツールを手軽に使って、DesignOps のワークフロープロセスを改善することができます。つまり、デベロッパーとデザイナーの両方が１つのソースから同じ UI 要素にアクセスして使えるということです。

デザインシステムの課題と解決策

企業がデザインシステムを作ろうとしても、特に要素や文書、コードをすべて管理する際に、特定の問題や一貫性の断絶が起こる可能性があります。

主要なデザインリーダーの１つである Johnson & Johnson社 から、デザイン システムの課題とソリューションについて詳しく学びましょう。当社のウェビナーでは、J&J チームによってベストプラクティスがすべて紹介されました。

例１：ポルシェのデザインシステム

ポルシェのデザインシステムは、その包括的できちんと文書化された高水準のアプローチにより、デザインと実装に対する模範的なモデルとなっており、一流の Web アプリケーションを作成しようとするすべての人にとって貴重な参考資料となっています。

ポルシェのデザインシステムは、視覚的に魅力的で高品質な Web アプリケーションを作成するのに非常に重要なデザインの基礎と要素を提供するという点で際立っています。その主な強みの１つは、Figma 用のピクセルベースのライブラリと、UXPin でコード化されたライブラリにあり、それでデジタルクリエイターのデザインプロセスが効率化されます。さらに、デザインシステムにはコード化された Web コンポーネントと詳細な使用ガイドラインが含まれていることから、デザイン同様にスムーズで一貫性のある実装が保証されます。

このシステムは、ポルシェの厳格な品質基準と企業デザインの原則に忠実であることで真に際立っています。各コンポーネントは入念に製造、テストされ、美しさだけでなく機能的な信頼性も保証されており、このような総合的なアプローチによって、最終製品の美しさと堅牢性が保証され、尊敬を集めるポルシェのブランドが反映されるのです。

例２：Google のマテリアルデザインシステム

最もよく使われているデザインシステムのひとつに、Google のマテリアルデザインがあります。Google は、デザインとデザインの原則について知っておくべきあらゆる事柄について細部まで踏み込んだマテリアル デザイン システムを作成して公開しました。マテリアルデザインのコンポーネントは UXPin のライブラリの１つであるため、UXPin ユーザーであれば誰でも簡単に使うことができます。

そしてユーザーは、このシステムのおかげでさまざまなデバイスやプラットフォーム、入力方法にわたって UI と UX を完全に統一する貴重な情報を得ることができます。

マテリアル デザインによって、他のブランドや個人は、アトミックデザイン、業界のイノベーション、独自のブランド表現に対する独自のアプローチを構築するための強力な基盤を持つことができます。

以下は、Google のマテリアルデザインシステムの主な特徴です：

• スターターキット
• デザインソースファイル
• マテリアルのテーマ設定
• レイアウト
• タイポグラフィ
• 色
• コンポーネント
• モバイルガイドライン

Google のマテリアルデザインシステムは非常に成熟しているように見え、多くのデザインガイドラインがありますが、開発で使われる UI コンポーネントに関する文書も含まれています。そしてそのようなコンポーネントがデザインでも使えることをご存知ですか？UXPin Merge のテクノロジーで、デベロッパーのコンポーネントをデザインに活用しましょう。UXPin Merge へのアクセスリクエストはこちら。

例３：Apple のヒューマンインターフェースガイドライン

Apple にはトップクラスのデザインシステムがあります。それは ヒューマンインターフェイースガイドラインと呼ばれるもので、Web デザインのエッセンスやパターンライブラリ、ダウンロード可能なテンプレートなど、膨大でかなり貴重なデザインシステムのリソースを提示しています。そして iOS の UI キットライブラリも UXPin アカウントで利用可能です。

このシステムは、スティーブ・ジョブズ氏の以下のデザイン原則に従っています：

• 細部までこだわって精密に作り上げる
• UX（ユーザーエクスペリエンス）とユーザーとのつながりを重視する。
• より大きなスケールで本当に重要なことに集中する
• 具体的なデザイン言語と実践により、ユーザーの反応を求める
• 初心者から上級者まで、ハイテクが持つ親しみやすい側面を活かす
• すべてをシンプルにする

Apple のデザインシステムの特徴

Apple のヒューマンインターフェースガイドラインは、iOS、macOS、vOS、watchOS のデザイナーとデベロッパーの両方のための実用的なリソース、ビジュアルガイドライン、スタイルガイドで構成されています。

それには、以下の使用方法に関するデザインシステムのドキュメントが含まれています：

• メニュー
• ボタン
• アイコンと画像
• フィールドとラベル
• ウィンドウとビュー
• タッチバー
• インジケータ
• セレクタ
• 拡張機能
• ビジュアルデザイン
• ビジュアルインデックス
• アプリのアーキテクチャ
• システム機能
• ユーザーインタラクション
• テーマ

例 ４：Atlassian のデザインシステム

Atlassian のデザインシステムは最高峰のひとつであり、連携をシームレスかつ簡単にすることで、世界中のチームに価値ある支援を提供することに重点を置いています。また、Atlassian のデザインガイドラインも UXPin のライブラリコレクションの一部です。

Atlassian のデザイン哲学は、デジタルエクスペリエンスを活用してチームと個々のチームメンバーの生産性と全体的な可能性を上げることであり、それは世界的に使われているコラボレーションツールである Trello と Jira に完璧に反映されています。

とはいえ、Atlassianのデザインシステムは、プロジェクト内の各ステップでのアジャイルな実践と効率的な追跡を特徴とし、最終的に製品の提供と開発において貴重な成果を生み出します。

Atlassian のデザインシステムの特徴

Atlassianのデザインシステムには以下が含まれます：

• UI コンポーネント
• ブランド価値
• UI キット
• UI パターン
• デザイントークン
• イラストレーションライブラリ
• コンテンツのガイドライン

例５：Uber のデザインシステム

Uber によれば、動きはチャンスを呼び起こすものであり、それで彼らのデザインシステムが構成されているらしいです。

結局のところ、Uber のサービスは、配車サービス、乗り合い、フードデリバリー、スクーターや電動自転車を含むマイクロモビリティなど、「移動」が基本となっています。

サブブランドから社内ブランド、製品からプログラムに至るまで、この種のサービスが完璧に機能するために、Uber には世界と共有する効果的なデザインシステムが必要です。

Uber のデザインシステムの特徴

以下は、Uber のデザインシステムの主な特徴です：

• ブランドアーキテクチャ
• コンポジション
• 声のトーン
• モーション
• イラストレーション
• 写真
• アイコノグラフィ
• 色
• ロゴ
• タイポグラフィ

例６：Shopify のデザインシステム Polaris

Shopify はグローバルな EC プラットフォームであり、ブランドのビジネスの運営や成長に必要なあらゆるものが一箇所で提供されています。

彼らのデザイン理念が、より良い、より利用しやすい商業体験を生み出すことに重点を置いているのも納得です。

Polaris という Shopify の公開デザインシステムには、同社の中核となる以下のような価値観が反映されています：

• ユーザーを思いやり、配慮する
• やろうとすることを達成するための適切なツールを提供する。
• ブランドイメージに合った最高レベルの職人技を楽しむ
• 早くて正確なソリューションを提供することで、手間を最小限に抑える
• 常にユーザーの信頼を築く
• ユーザーに安心して使ってもらう

Polaris デザインシステムには、Shopify のプラットフォーム用のデザインについてのわかりやすく実践的なスタイルガイドがあり、UI コンポーネント、ビジュアルエレメント、コンテンツ、デザイン言語を活用し、より良い UX（ユーザーエクスペリエンス）と製品全般を生み出すための膨大な知識ベースを提供します。

Shopify のデザインシステムの特徴

Shopify のデザインシステムである Polaris には、上記の実践に忠実に従った主な機能が以下のように含まれています：

• データの可視化
• アクセシビリティ
• インタラクションのステート
• 色
• タイポグラフィ
• アイコン
• イラスト
• スペーシング
• 音
• リソース

例７：IBM のカーボンデザインシステム

IBM は、大企業の IT のニーズに応えることで、世界規模で事業を展開しています。

そのサービスは、ビジネスコンサルティング、資金調達、ソフトウェア開発、ITホスティング／管理から、「ソフトウェアからハードウェアへ」の製品まで多岐にわたります。

IBM の核となる信念は、科学、理性、知性を活用することで、人間の状態、社会、ブランドのいずれであれ、絶え間ない進歩を遂げることにあります。

IBM によれば、いいデザインは単なる要件ではなく、ユーザーに対する実際の責任であるらしいです。

IBM のデザインシステムの特徴

Carbon デザインシステム は、Adobe、Axure、Sketch のデザイナーやデベロッパー向けのツールやビジュアルリソースが以下のように豊富に提供されています：

• データの可視化
• パターン
• コンポーネント
• ガイドライン
• チュートリアル

UXPin のユーザーだと、自分のアカウントで Carbon から必要なものがすべて見つかります。

例８：Mailchimp のデザインシステム

Mailchimp は、メールマーケティングのリーダーとして有名だった時代から、メールだけにとどまらないオールインワンのマーケティングプラットフォームを提供するまでになりました。

Mailchimp の明確な目標は、ブランドアイデンティティとイメージを忠実に守りながら、中小企業の成長を支援するという一点です。

Mailchimp のデザインシステムの特徴

それが、Mailchimp のデザインシステムと、クリエイティブな表現、より良い UX、最高の品質に焦点を当てたその主な機能を作り上げた多くの理由のひとつでもあります：

• データの可視化
• グリッドシステム
• 色
• タイポグラフィ
• コンポーネント

例９：Salesforce Lightning のデザインシステム

Salesforce は、統合されたクラウドベースの CRM（顧客関係管理）ソフトウェアを通じて、ユーザーに個別化されたエクスペリエンスを提供するために全力を尽くしています。

Salesforce の CRM の目的は、マーケティング、Eコマース、IT、サービス、営業活動の改善であり、ユーザーも自身で同じことができます。

Salesforce のデザイン哲学は、ハワイ語で「意図的な家族」を意味する「オハナ」に反映されており、同社の活動と全体的な文化を推進する以下の４つの中核的な価値観があります：

• イノベーション
• 平等
• 信頼
• カスタマーサクセス

Salesforce のデザインシステムの特徴

Salesforce は、コンテンツ管理システムに携わる人が誰でも以下のような主要な機能を学んで恩恵を受けることができる、独自の Lightning デザインシステムを発表しました：

• デザインガイドライン
• プラットフォーム
• アクセシビリティ
• コンポーネント（多数）

ちなみに、Lightning のコンポーネントは UXPin アカウントライブラリにも含まれています。

デザインシステムを最大限に活用する：UXPin Merge のやり方

Merge tech は、デザインチームと開発チームの間にコミュニケーションギャップがある場合によく起こる一般的な課題に対する適切なソリューションとして作成されました。なので、さまざまな UI コンポーネント、コーディング、ドキュメントの不一致が生じ、製品の効率やメンテナンスに影響を及ぼすことがあります。

正しい方向への第一歩として、必要なコンポーネントをすべて整理するデザイン システムを使って、Merge はその UI 要素をすべてデザイン エディタに直接取り込んでくれます。

矛盾を避けることで時間と費用を節約できるだけでなく、当初思い描いていたものとまったく同じ最終製品を見る喜びも得られます。

Merge tech は、コードコンポーネントによるデザイン、つまりコードコンポーネントをデザインに変換することに重点を置いており、その点で、デザイナーは最終製品の視覚的な側面だけに基づいて（必要なインタラクションのフェイクだけ作りながら）単純にプロトタイプを作成するのではなく、すでにコード化されたコンポーネントを使ってプロトタイプのイメージをデザインできます。

そしてデザインチームは、すでにコード化されたコンポーネントを UXPin のエディタと同期させ、新しいデザインを作成するのに必要なコンポーネントをドラッグ＆ドロップできるため、デザインチームと開発チームの間を行ったり来たりする必要はありません。

基本的に、デザイナーはインタラクションのフェイクを作ったり、追加したり、適切な色を探したりする必要はありません。

その一方で、デベロッパーはプロトタイプのプレビューを入手し、利用可能なプロダクションレディの要素で作業を続けることができます。

どのデザインシステムの例がお好きですか？

デザインシステムは、デザイン作業の最適化や改善を行い、チーム間の一貫性を促すことを目的とした、大量の UI コンポーネントとガイドラインで構成されています。

ただし、デザインシステムのメンテナンスや実装が不十分であれば、そのシステムは、多くの不便で混乱しやすいコードスニペット、ライブラリ、コンポーネントに過ぎなくなる可能性があります。

デザインシステムで、デザイナーがより複雑な UX の問題に対処できるようになる一方で、チームメンバーの一貫性を早く促すことができます。さらに、画期的な Merge のテクノロジーをミックスに加えることで、デザインシステムの編成を次のレベルに引き上げることができます。UXPin Merge の詳細はこちら。

The post ２０２４年のおすすめデザインシステム９例 appeared first on Studio by UXPin.

MUI によって開発・保全されている Material UI は、Googleのマテリアルデザインのガイドラインを実装した人気の Reactコンポーネントライブラリであり、ボタン、カード、メニュー、フォーム要素、事前定義済みのスタイル、テーマなど、再利用可能でカスタマイズ可能なコンポーネントの包括的なセットがあります。

このライブラリは、UI（ユーザーインターフェース）を構築するためのモジュール式で構造化されたアプローチを促進することから、デベロッパーは視覚的に一貫性のあるレスポンシブなデザインを作成できるようになります。Material UI を使うことで、デベロッパーはフロントエンド開発プロセスを効率化し、直感的で視覚的に魅力的な Web アプリケーションを提供することができるのです。

Material UI の Reactコンポーネントを使えば、ピクセルをコードに変換することなく、デザインのプロトタイプやテストができます。UXPin Merge の無料お試しで、プロトタイプ作成がいかにスムーズになるかをぜひご覧ください。

１．Ant Design

おすすめの用途：Web アプリケーション、クロスプラットフォーム アプリケーション、ネイティブ アプリ

Ant Design ライブラリは、Ant Design によって開発された包括的な UI コンポーネントライブラリであり、高品質なアプリケーションの構築のための、再利用可能で十分にドキュメント化された幅広いコンポーネントを提供します。Ant Design は、自身のシステムの原則に従って、使いやすさとアクセシビリティを重視した、クリーンでミニマリストなデザイン美学を重視しています。

また、このライブラリには、国際化サポート、テーマ設定機能、レスポンシブ・デザインなどの強力な機能が備わっていることから、プロフェッショナルでユーザーに使いやすいインターフェースを作成するデベロッパーの間で広く使われています。

そしてデベロッパーは、フォーム、テーブル、ナビゲーションメニューなどの豊富なコンポーネントコレクションを活用することで、一貫性のある視覚的に魅力的なインターフェイスをサッと作成することができます。

Ant Design システムには、モバイルとチャート用のライブラリもあり、それで製品チームは、さまざまなクロスプラットフォームアプリケーションのためのコンポーネントとパターンの包括的なセットを得ることができます。

２．React-Bootstrap

おすすめの用途：Web アプリケーション

React-Bootstrap は、React でレスポンシブ Web アプリケーションを構築するのに広く使われている React UI ライブラリであり、React のコンポーネントベースのアーキテクチャのパワーと、Bootstrap の柔軟性とスタイリング機能を組み合わせることで、デザイン済みでカスタマイズ可能なコンポーネントの包括的なセットを提供します。

また、React-Bootstrap は、ボタン、フォーム、モーダル、ナビゲーションメニューなど、さまざまな UI要素を提供することから、デベロッパーは視覚的に魅力的で機能的なインターフェースを速やかに作成することができます。

React-Bootstrap の詳細なドキュメントと活発なコミュニティサポートによって、再利用可能で十分にテストされたコンポーネントがもたらされることから、Web開発がシンプルになり、それでデベロッパーは強固で使いやすいアプリケーションの構築に集中できるようになります。

３．Fluent UI

おすすめの用途：Web アプリケーション、iOS および Android アプリケーション、ネイティブアプリ、クロスプラットフォームアプリケーション

Fluent UIは、Microsoft が開発した強固で包括的なデザイン システムであり、クロスプラットフォーム アプリやモバイル アプリを構築するための再利用可能なコンポーネントとスタイル オプションを提供します。このライブラリは Fluent  Designの原則に従い、明快さやコンテンツの優先順位付け、スムーズなアニメーションに重点を置いています。

Fluent UI はさまざまなプラットフォームやデバイスにわたって一貫性のある統合されたエクスペリエンスを提供することから、多くのクロスプラットフォームおよびモバイルプロジェクトに適しています。

また、広範なドキュメントと活発なコミュニティにより、チームは Microsoft のデザイン言語に沿った直感的でアクセシブルなUIを構築することができるようになります。ボタンやフォームから複雑なデータグリッドやチャートに至るまで、Fluent UIを使うことでユーザー中心の楽しい体験を提供するために必要なツールを得られるのです。

Material UI と Fluent UI の違いについて：Webアプリケーション – Fluent UIとMUI【 デザイナーが比較】

４．Carbon Design System

おすすめの用途：Webアプリケーション、iOSおよび Androidアプリケーション、ネイティブアプリ、クロスプラットフォームアプリケーション

IBMのデザイン哲学の原則に基づいて構築された Carbonは、シンプルさや明快さ、目的に応じたインタラクションに重点が置かれており、ボタンやフォームからデータビジュアライゼーションやアイコンまで、さまざまなコンポーネントが提供されていることから、デザイナーやデベロッパーは直感的で視覚的に魅力的なインターフェースを作成することができます。

モジュール式で柔軟なアーキテクチャを採用した Carbon Design System は、再利用性と拡張性を促進し、大規模なエンタープライズアプリケーションから小規模なプロジェクトまで対応します。また、このシステムのドキュメントとリソースにより、チームはデザインの一貫性の維持や、連携の効率化ができるようになります。

５．Tailwind CSS

おすすめの用途：Webアプリケーション

Tailwind CSSのライブラリで、デベロッパーはユーティリティ優先の CSS フレームワークを使ってカスタムUIを速やかに構築できます。事前定義されたユーティリティクラスの包括的なセットが提供されているため、カスタム CSS スタイルの記述が必要ないのです。

このライブラリは React、Vue、HTML に対応しており、デベロッパーは、これらのユーティリティクラスを HTML 要素に簡単に適用することができることから、UIコンポーネントの外観や動作をきめ細かく制御できます。

Tailwind CSS は、スタイル設定に対するモジュール式のアプローチを推進しており、デベロッパーはクラスを組み合わせて、ユニークでレスポンシブなデザインを作成することができます。また、Tailwind CSS にはレイアウト、タイポグラフィ、色、スペーシングなどのユーティリティがあることから、デベロッパーは最小限の労力で一貫性のある視覚的に魅力的なインターフェイスを作成することができます。

６．Semantic UI

おすすめの用途：Webアプリケーション

Semantic UI は、UI作成のためのセマンティックで直感的なコンポーネントを幅広く提供する、汎用性の高いフロントエンドフレームワークであり、ボタン、フォーム、メニュー、カード、モーダルなどの Web アプリケーションのためにあらかじめデザインされた UI 要素の包括的なコレクションを提供します。

フレームワークは自然言語の命名規則に従っていることから、ユーザーに使いやすくわかりやすいものになっており、デベロッパーは、Semantic UI の豊富な CSS クラスセットを活用して、視覚的に魅力的でレスポンシブなデザインをサッと構築できます。また、このライブラリは React、Meteor、Ember、Angular のフロントエンドフレームワークに対応しています。

Semantic UI はテーマ設定とカスタマイズに対応しており、デベロッパーはプロジェクトのブランディングに合わせて UI コンポーネントの外観をカスタマイズすることができます。Semantic UI は、その直感的なシンタックスと詳細なドキュメントにより、モダンな Web インターフェースのデザインと開発のための貴重なツールとなっています。

７．Foundation

おすすめの用途：Web アプリケーション、メール テンプレート、ランディング ページ

Foundation は、モダンでモバイルフレンドリーな Web サイトを構築するための CSS と JavaScript コンポーネントを備えたレスポンシブなフロントエンドフレームワークです。モジュール式のアプローチで包括的なツールキットを提供するため、デベロッパーは特定のプロジェクトの要件に合わせてデザインをカスタマイズして調整することができます。

デベロッパーは、さまざまな画面サイズにシームレスに適応するレスポンシブグリッド、ナビゲーションメニュー、フォーム、ボタン、その他のUI要素を難なく作成できます。また、このフレームワークには、インタラクティブな機能とスムーズなアニメーションを実現する強力な JavaScriptライブラリも含まれています。

また、Foundationの豊富なドキュメントと活発なコミュニティサポートにより、デベロッパーは視覚的に魅力的で高機能なWebインターフェースを作成できるようになります。

８．Chakra UI

おすすめの用途：Web アプリケーション

Chakra UI は、UI開発を効率化するためのモダンでアクセスしやすい React コンポーネントライブラリであり、React、Next.js、Meteor、Gatsby などのフレームワークに対応しています。

このプロジェクトはナイジェリアの セグン・アデバヨ 氏によって設立され、アフリカ発の最も著名なオープンソース コンポーネント ライブラリの１つとなっています。

Chakra UIは、あらかじめデザインされたコンポーネントとユーティリティ機能を提供していることから、デベロッパーは、視覚的に魅力的でレスポンシブな Web サイトを作成できるようになります。またデベロッパーは、ボタン、フォーム、カード、ナビゲーション要素などの Chakra UI のカスタマイズ可能で再利用可能なコンポーネントを活用して、直感的でアクセスしやすい UI をデザインすることができます。

さらに、このライブラリは WCAG 標準に準拠することでアクセシビリティにも重点を置いていることから、作成されたインターフェースがハンディキャップのある人でも使用できることが保証されます。Chakra UI のシンプルさ、柔軟性、強固なドキュメントによって、効率的で視覚的に美しい React アプリケーションを構築したいデベロッパーの間で人気の選択肢となっています。

９．Bulma

おすすめの用途：Webアプリケーション、ランディングページ

Bulma は Flexbox をベースとした軽量でモダンな CSS フレームワークであり、柔軟でレスポンシブなグリッドシステムと、すぐに使える UI コンポーネントのセットを提供します。そしてこのフレームワークの直感的なクラス命名規則は、早くて効率的なスタイリングに対応し、モジュラーアーキテクチャはスケーラビリティとカスタマイズを保証します。

Bulma はそのシンプルさ、豊富なドキュメント、コミュニティによるサポートによって、あらゆる規模のプロジェクトで人気のある選択肢となっており、ランディングページ、ダッシュボード、ECサイトのいずれを構築する場合でも、Bulma で美しく機能的なインターフェースを構築するための強固な基盤が得られます。

１０．Styled Components

おすすめの用途：Webアプリケーション、ランディングページ

Styled Componentsは、デベロッパーがタグ付きテンプレートリテラルを使って JavaScript コードに直接 CSS を記述することができる、人気のJavaScriptライブラリです。また、スタイルをコンポーネント内にカプセル化する方法を提供することから、より保守性と再利用性が高まります。

Styled Components は React のエコシステムで広く使われており、人気の UI フレームワークやライブラリとのシームレスな統合を提供します。また、デベロッパーは、コンポーネントのプロップやステートにアクセスする機能などの JavaScript のパワーを活用することで、ダイナミックでレスポンシブなスタイルを作成できます。そしてこのライブラリには、CSS-in-JS、自動ベンダープレフィックス、テーマ管理のサポートなど、多くの機能が備わっています。

１１．PrimeReact

おすすめの用途：Webアプリケーション、ランディング ページ

PrimeReact は React アプリケーションのための包括的な UI コンポーネントライブラリで、すぐに使えるコンポーネントと高度な機能があります。そして、ボタン、入力、テーブル、モーダル、チャートなど、さまざまなデジタル製品向けの幅広い UI 要素を提供します。

PrimeReact はレスポンシブデザインを採用しており、コンポーネントがさまざまな画面サイズやデバイスに適応します。また、このライブラリにはデータバインディング、フィルタリング、ソート、ページネーションなどの強力な機能があることから、データ集約的なアプリケーションの構築に適しています。

PrimeReact の事前構築済みコンポーネントと機能を活用することで、デベロッパーは時間と労力を節約でき、開発サイクルの短縮とユーザー体験の向上を実現できるようになります。また、ライブラリは定期的に更新されることから、最新の React バージョンとの互換性が確保され、継続的なサポートとバグ修正がもたらされます。

UXPinの「Code-to-Design」手法による高品質なプロトタイプ

UXPin Merge のテクノロジーで、製品チームは、デザイナーがコード コンポーネントを使ってプロトタイプの作成やテストをすることができるように、これらをはじめとするオープンソースのデザインシステムを UXPin のデザイン エディターにインポートすることができます。

最終製品の開発に使うのと同じコンポーネントをデザインプロセスで使いませんか。ユーザーテストとデベロッパー向けに没入型のプロトタイプ エクスペリエンスを構築することで、コンセプトを反復して改善するための有意義なフィードバックを得られます。初期段階のデザインから開発、最終製品まで、製品開発環境全体で「信頼できる唯一の情報源（Single source of truth）」を共有しましょう。UXPin Merge をぜひ無料でお試しください。

The post Material UI のおすすめ代替品１１選 appeared first on Studio by UXPin.

ReactJSとReact Nativeの違いを理解すると、デザイナーはエンジニアとのコミュニケーションは円滑になり、コストのかかる技術的な問題は回避され、デザイン引き継ぎ時の摩擦を最小限に抑えることができます。

デザイナーは、JavascriptやReactの基本的な違いを理解するのに、コードを学んだり技術的な詳細に踏み込む必要はありません。デザイナーに関係する最も大きな違いは、ウェブベースの製品とネイティブのモバイルアプリケーションをデザインする際のコンポーネントライブラリとその選び方です。

UXPin Mergeを使用すると、React UIコンポーネントをGitリポジトリからUXPinのデザインエディタに同期させることができるので、デザインチームは問題なく機能するコードベースのプロトタイプを作成できます。この信頼できる唯一の情報源（Single source of truth）により、デザインのズレがなくなり、市場投入までの時間が短縮され、デザイナーとデベロッパー間の結束が高まります。この画期的なテクノロジーへのアクセスに関する詳細およびリクエスト方法については、Mergeについてのページをご覧ください。

ReactJS とは

ReactJS（一般にReactと呼ばれる）は、Webベースのユーザーインターフェース構築のためのオープンソースのJavascriptライブラリです。コンポーネントベースのフロントエンドフレームワークで、バニラHTML、CSS、Javascriptを記述するよりも早く簡単にWebサイトやWebアプリケーションの開発・拡張ができます。

ReactJSでは、基本的なボタンから複雑なチャートやデータグリッドまで、再利用可能なタグやコンポーネントを作成でき、デベロッパーはコード一行でそれを呼び出すことができます。デザイナーがマスターコンポーネントを作成し、それをユーザーインターフェースの他の部分にコピー＆ペーストするのとよく似ていますね。

ReactJS の例

Facebookは、2011年に自社のWebベースの全製品のためにReactを開発し、現在もWhatsApp、Messenger、Facebook、InstagramのWeb版でこのフロントエンドフレームワークを使用しています。

Facebook以外にも、以下のような多くのグローバル企業やFortune 500社が、WebサイトやWebアプリケーションにReactを使用しています。

• Netflix
• Salesforce
• New York Times
• Reddit
• Cloudflare
• Tesla
• PayPal(PayPalがUXPin Mergeを使ってデザイン拡張させ、Reactリポジトリに同期した方法はこちら)

React Nativeとは

 React Nativeは、プラットフォームを超えたモバイルAndroidおよびiOSアプリ、ならびにWebベースのアプリケーションに使用されるReactJSのモバイル版です。ReactJSと同様に、 React Nativeは、モバイルアプリの開発・拡張のための再利用可能なコンポーネントをデベロッパーにもたらします。

技術的な大きな違いとしては、Reactは仮想DOM（Document Object Model）を使ってWebブラウザ上でコードをレンダリングするのに対し、React NativeはネイティブAPIを使ってモバイルデバイス上でUIをレンダリングする点が挙げられます。

Facebookが React Native を作った理由

 React Native 以前は、デベロッパーはApple XCodeまたはAndroid Studioを使用して、iOSとAndroid用の2つの別々のネイティブアプリケーションをそれぞれ作成しなければいけませんでしたが、今は React Native により、デベロッパーは、iOSとAndroid用のネイティブコードを自動的にレンダリングする単一のアプリケーションを開発することができます。

React Nativeの例

Facebookは、Instagram、Facebook、Facebook Ads Manager、Oculusなど、ネイティブモバイルアプリケーションに React Native を使用しています。 また、以下のように多くのグローバル企業がReact Nativeを使用しています。

• Coinbase
• Shopify
• Discord
• Skype
• Bloomberg
• Pinterest
• Baiduモバイル

 React NativeとReactJS の違い

２つの最大の違いは、ReactがJavascriptのライブラリであるのに対して、React NativeはJavascriptのフレームワークであることです。

• ライブラリとは、エンジニアがWebサイトやアプリケーションを開発しやすくするために、あらかじめ用意されたコードのことです。
• フレームワークはより複雑で、Webサイトやアプリケーションを構築するためのライブラリ、テンプレートフレームワーク、API、セッション管理などで構成されています。

その他にも、ReactJSとReact Nativeの決定的な違いは以下のようにあります；

• ReactJSはJavascriptとCSSでアニメーションを行い、React Nativeはアニメーション用のAPIを使用します。
• ReactJSはUIでHTMLをレンダリングし、React NativeはJSXをレンダリングします。
• デベロッパーは主に、Web開発にはReactJSを、モバイルアプリケーション開発にはReact Nativeを使用しています。
• ReactJSではWebページのナビゲーションにReact-routerが使われ、React NativeではNavigationライブラリが組み込まれています。

プロトタイプデザインのためのReact

ここでは、デザイナーがReactのプロジェクトに取り組む方法をいくつかご紹介します。

コンポーネントベースのデザイン手法

ReactJSやReact Nativeでは、コンポーネントベースのフレームワークを用いてUIを構築していました。デザイナーも同様に、コンポーネントベースのデザインマインドセットを使わなければいけません。自身がデザインするUIについてそれぞれ、「デベロッパーはこれをどのようにして核となるコンポーネントに分解できるのか」と自問してみましょう。

React製品をデザインする場合、コンポーネントを作成し、製品デザイン全体で一貫してこれらを再利用します。コンポーネント内でフォントサイズやスペーシングの変更は、エンジニアが新しいコンポーネントを構築したり、追加のスタイリングを記述する必要があるためなるべく避けましょう。

コンポーネントライブラリの採用

ReactJS やReact Nativeのデザインシステムをゼロから構築すると、デザインと開発の間で常に課題が発生し、ズレが生じてしまいます。そこで企業は、カスタマイズ可能なReactコンポーネントライブラリを採用することで、この課題を克服しています。

Reactコンポーネントライブラリを用いたデザインにより、デザイナーは、デザインを最終製品に変換する際にエンジニアが直面する制限や制約がわかってきます。

GoogleのMaterial Design UIをベースにしたMUIは、最もわかりやすく広く使われているコンポーネントライブラリの1つであり、デザイナーは、MUIを基盤として、ウェブサイト、ウェブアプリ、ネイティブアプリケーションのデザインシステムを構築することができます。

UXPinのMUI統合により、デザイナーはReactコンポーネントを使用してUIの構築ができます。UXPinのプロパティパネルでMUIコンポーネントをカスタマイズして、ブランドや製品の要件に対応させることができます。無料トライアルにサインアップし、UXPinでReactコンポーネントを使ったデザインを始めてください。

モーションとアニメーション

モーションとアニメーションは、特にネイティブアプリケーションの場合、デザイナーとデベロッパーの間でしばしば摩擦を起こします。ReactJSでは、エンジニアは比較的簡単にデザインアニメーションを再現できますが、 React Nativeで同じ結果を得るのは、追加のツールやパッケージがなければ困難または不可能です。このような追加には時間とコストがかかり、プロジェクトの制約を超えてしまう可能性があります。 モーションとアニメーションについては、プロジェクト開始時に必ずエンジニアと話し合い、デザインの引き継ぎ時に摩擦が生じないよう、何ができるかを判断しましょう。

ReactとUXPin Mergeでデザインする

UXPin Mergeで、デザイナーはReactコンポーネントを使用してきちんと機能するプロトタイプを構築できます。デザイナーは、他のデザインツールと同様にReactコンポーネントを使用しますが、最終製品に含まれるコンポーネントと同じであるため、忠実度と機能性が大幅に向上します。

UXPin MergeでのデザインのためにReactを理解する必要はありませんが、理解していたら、エンジニアリングチームとのコミュニケーションと連携が改善されつつ、より忠実で機能的なプロトタイプを作成できる可能性があります。

Reactのプロップ

Reactコンポーネントは、色、文字デザイン、ボーダー、シャドウなどのプロパティを確定するのにプロップを使用します。Merge はプロップを自動的に認識し、デザイナーが編集できるようにプロパティパネルが表示され、デザイナーは JSX に切り替えて、コードで表示および編集もできます。

プロップでデザイナーが変更を加えることができますが、同時にプロップは、ブランドの色や書体など、デザインシステムで確定された制約を設定するものでもあります。この制約により、一貫性が維持され、チームメンバーが不正に変更するのを防ぐことができます。

UXPinはベクターグラフィックスではなくコードをレンダリングするため、デベロッパーはデザイナーがコンポーネントのプロップに加えた変更をコピー＆ペーストするだけで、さっとUIを開発できます。

より忠実に、より機能的に

Reactコンポーネントを使ったデザインでは、デザイナーは最終製品の正確なレプリカを作ることができます。たとえば、機能する日付ピッカーを従来の画像ベースのデザインツールで作成することはできませんが、UXPin Merge を使用すると、日付ピッカー、チャート、データ テーブル、グラフなど、エンジニアがレポジトリに追加したあらゆる React コンポーネントでプロトタイプを作成できます。

定義されたインタラクション

インタラクションやアニメーションは、デザインプロジェクトに多大な時間を要し、デザイナーはプロジェクトごとにこれらのインタラクションを作り直さなければならず、エラーや矛盾が生じる可能性があります。

Mergeでは、プロダクションコードから生成された機能的およびインタラクティブな要素を使用してプロトタイプを作成でき、デザイナーは、プロップを使用して新しいインターフェースやコンポーネントに合わせてアニメーション設定の変更ができます。

デザインシステムにアニメーションを組み込むことで、デザイナーはインタラクションの矛盾をなくしつつ、プロトタイピングの時間を短縮できます。

Storybookを使ったその他のフロントエンドフレームワーク

Mergeを使うと、React でのデザインだけにとどまらず、当社の Storybook 統合により、Vue、Ember、AngularJS、Web Components などの他の一般的なフロントエンドフレームワークを同期することができます。

Reactコンポーネントと全く同じようにStorybookコンポーネントを使用して、忠実度の高いプロトタイプのデザインができます。プロップの代わりにStorybook Argsを使用して、UXPinのプロパティ、スロット、スタイル、入力などを変更します。

コードを使ったデザイン

プロトタイピングとテストの強化に向けて、きちんと機能するReactやStorybookコンポーネントを使ったデザインを始める準備はできましたか？ここでは、開始法を2つご紹介します。

1. 14日間の無料トライアルにサインアップすると、MUIのReactコンポーネントライブラリを使用してUIをデザインするためのMUI統合にアクセスできるようになります。
2. または、Mergeページで、ReactのGit統合、またはその他の一般的な技術用の Storybookへのアクセスをリクエストすることもできます。サポートチームのメンバーが、オンボーディングプロセスのお手伝いのご連絡を差し上げます。

The post React Native と ReactJS – それぞれの違い appeared first on Studio by UXPin.

ここ１０年のデザインシステム革命は、製品開発のワークフローを強化するためのさまざまなツールや戦略をもたらしました。

デザイントークンは、UI 要素の実装、管理、更新をしやすくするために Google の Material Design 3 や MUI などの多くのデザインシステムが採用しているツールの１つです。

お知らせ：UXPinのカラー用デザイントークンはベータ版です！サインアップすると、デザイントークンの正式なリリース時に通知します。

組織全体でデザイン業務を最適化しませんか。デザインと開発で React コンポーネントを使うチームを支援する画期的なデザインテクノロジーである UXPin Merge をぜひご利用下さい。Merge の詳細はこちら。

デザイントークンとは

デザイン トークンには、クロスプラットフォーム の UI（ユーザー インターフェース）のスタイル設定と構築に使われる色、フォント、スペース、アニメーション、アセットなどの UI データが含まれています。各 OS（オペレーティングシステム）用に静的な値をハードコーディングする代わりに、デザイントークンには複数のフォーマットが含まれているため、フロントエンドデベロッパーは iOS や Android、さらには Web アプリケーションを構築する場合でも、同じ変数を使うことができます。

クロスプラットフォームの製品開発における課題の１つに、OS で異なるスタイルプロパティとフォーマットが使われる点が挙げられます。例えば、UXPin のWeb サイトでは CTA（Call to Action）に黄色が使われますが、この黄色の16進コードは#FCC821であり、以下のような方法で表すことができます：

• RGB (CSS): rgb(252, 200, 33)
• RGBA: rgba(252, 200, 33, 1)
• Octal (Android/Flutter): 77144041

このような静的プロパティを使う代わりに、デザイナーやエンジニアは、この４つのカラーコードすべてを表す「uxpin.cta.primary」のようなトークンを参照します。これでプラットフォームやプログラミング言語に関係なく、色は常に同じになります。

デザイントークンの種類

組織は、カラーパレット、サイズ、スペース、アセット、ドロップシャドウなど、多くのスタイルプロパティにこのようなデザイントークンを使います。デザイン トークンの主な種類には以下があります：

• カラートークン： デザインシステムで使われるカラーパレットを定める。例えば以下のように、原色、二次色、背景色、文字色、枠色などがある。
  • 例：
    • color-primary: #007bff
    • color-background: #f8f9fa
      
      
• タイポグラフィトークン： テキスト関連のプロパティを指定する。フォントファミリ、フォントサイズ、行の高さ、文字間隔、フォントの太さなどがある。
  • 例：
    • font-family-body: ‘Roboto’, sans-serif
    • font-size-heading: 24px
      
      
• スペーストークン： マージン、パディング、ギャップなどのスペーシング・システムを管理する。デザイン全体を通して一貫したスペーシングを保証する。
  • 例：
    • spacing-small: 4px
    • spacing-large: 16px
      
      
• サイズトークン： コンポーネントや要素のサイズを定める。これには、幅、高さ、最大サイズと最小サイズなどがある。
  • 例：
    • size-button-height: 48px
    • size-avatar-small: 32px
      
      
• ボーダートークン： 幅、スタイル、半径などのボーダーラインのプロパティを指定する。
  • 例：
    • border-width-thin: 1px
    • border-radius-medium: 8px
      
      
• シャドートークン：色、オフセット、ぼかし、広がりなど、デザイン システムで使われる影の効果について説明する。
  • 例：
    • shadow-small: 0 1px 2px rgba(0, 0, 0, 0.1)
    • shadow-large: 0 4px 8px rgba(0, 0, 0, 0.2)
      
      
• 不透明度トークン： 要素の不透明度を定める。
  • 例：
    • opacity-low: 0.3
    • opacity-high: 0.9
      
      
• ブレークポイントトークン： レスポンシブデザインのブレークポイントを指定し、デザインがさまざまなスクリーンサイズにどのように適応するかを指示する。
  • 例：
    • breakpoint-mobile: 480px
    • breakpoint-desktop: 1024px
      
      
• デュレーショントークン： アニメーションとトランジションのタイミングを管理する。
  • 例：
    • duration-short: 200ms
    • duration-long: 600ms
      
      
• イージングトークン：アニメーションとトランジションのイージング関数を定める。
  • 例：
    • easing-in-out: cubic-bezier(0.4, 0, 0.2, 1)
    • easing-bounce: cubic-bezier(0.68, -0.55, 0.27, 1.55)

デザイントークンの起源

デザイントークンの先駆者は Salesforce だと言われており、Salesforce Designer に掲載された２０１４年の記事で、Salesforce UX VP の ゾンケ・ローデ氏によって、同社が複数のプラットフォームやソフトウェアに同じデザイン原則を適用するのにデザイントークンを使っていることが説明されています。

「Salesforce では、まさにこの課題に直面し、不可知論的な解決策を考え出しました。我々は、デザインを一箇所に定めて、それをシステムを使って全プラットフォームにカスケードダウンします。これは「信頼できる唯一の情報源（Single Source of Truth）」と言って、基本的に、我々のデザイントークンを記述する名前と値のペアを含む JSON ファイルのセットとなります」ゾンケ・ローデ氏による Living Design System からの抜粋。

エンジニアは、静的なスタイル プロパティを使う代わりに、デザイントークンを参照し、プラットフォームに応じて正しい値を JSON ファイルから取得します。そして Salesforce はこのプロセスを自動化すべく、「デザイントークンを変換してフォーマットするための抽象化機能」である Theo を開発しました。

アトミックデザインとトークンの違い

「アトミックデザイン」と「デザイントークン」は、どちらもデザインシステムで使われる概念ですが、「デザインの一貫性」と「スケーラビリティ」という異なる側面に対処しています。

アトミックデザインは、ブラッド・フロスト氏によって開発されたデザインシステム構築のための方法論であり、UI を、「原子」、「分子」、「有機体」、「テンプレート」、「ページ」（複雑さの昇順）と呼ばれる、より小さく再利用可能なコンポーネントに分解します。例えば原子は、ボタン、入力フィールド、アイコンなどの基本的な構成要素で、分子は原子の組み合わせ、有機体は分子の組み合わせ、といった具合です。

対するデザイントークンは、デザインシステムにおける色、タイポグラフィ、スペースなどのデザインプロパティを定める変数のセットであり、ビジュアルデザインの決定を抽象的に表現するものです。デザイントークンは、色の16進コードのような「特定の値」を UI コンポーネントに直接ハードコーディングするのではなく、デザインシステム全体でデザインプロパティを一元的に管理や更新をする方法を提供します。

デザイントークンは、デザインプロパティの抽象化と管理を行い、デザイン上の決定を変数に抽象化することから、メンテナンス、拡張性、一貫性がしやすくなります。また、デザイントークンで、デザインに関連する値の「信頼できる唯一の情報源（Single source of truth）」がもたらされます。

デザイントークン３例

タイポグラフィのデザイントークンの例を３つ挙げてみましょう。このトークンで、さまざまなコンポーネントやプラットフォーム間でのタイポグラフィのスタイルの一貫性が保証されます。

例１：フォントファミリー

</p>
{
  "font-family": {
    "base": "Roboto, Arial, sans-serif",
    "heading": "Montserrat, Arial, sans-serif",
    "monospace": "'Courier New', Courier, monospace"
  }
}
<p>

例２：フォントサイズ

</p>
{
  "font-size": {
    "base": "16px",
    "small": "14px",
    "large": "24px",
    "heading": {
      "h1": "32px",
      "h2": "28px",
      "h3": "24px"
    }
  }
}
<p>

例３：行の高さ

</p>
{
  "line-height": {
    "base": "1.5",
    "tight": "1.25",
    "loose": "1.75",
    "heading": {
      "h1": "1.2",
      "h2": "1.3",
      "h3": "1.4"
    }
  }
}
<p>

デザイントークンは適しているか

Google の Material Design 3 のドキュメントには、デザイントークンが最も役立つ場面のリストが以下のように掲載されています：

• 複数のプラットフォームや製品でデザインシステムを使っている。
• 製品のスタイルを簡単に維持・更新したい。
• 製品デザインの更新や、新しい製品や機能の構築を予定している。

Material Design は、デザイントークンが「あまり有効でない」例も２つ挙げています。

• 数年以内に製品を変更する予定がない。
• 製品にデザインシステムがない

デザイントークンを使うメリット

デザイントークンを使う主な利点を３つ挙げてみました。

１．「信頼できる唯一の情報源（Single source of truth）」がある

デザイントークンは、「信頼できる唯一の情報源（Single source of truth）」を作るのに最も有益であり、これが、Salesforce がデザイントークンを使い始めた理由です。例えば複数の製品チームやエンジニア、UX デザイナーが同じ製品に取り組む場合は、みんなそれぞれ同じデザイン言語を話さないといけません。

それがデザイントークンによって、チームは、役割、プラットフォーム、プログラミング言語、責任に関係なく、同じ言語で話すことができるようになります。

２．UI の一貫性の維持

UI の一貫性は、大規模なデザインを行う際の重要な課題です。１つの製品に対して、デザイナーが誤って微妙に違うサイズやブランドカラー、スペースを使ってしまうことは珍しいことではなく、このような不一致でユーザビリティの問題が起こり、リリースのたびにエンジニアリングと UX の負債が増えていきます。

そこでデザイントークンが、デザイナーがみんな同じスタイルとプロパティを使えるように、このような矛盾を解消してくれます。「信頼できる唯一の情報源（Single source of truth）」のもう一つのメリットですね！

３．スケーリングの柔軟性を得る

デザイントークンで、製品やデザインシステムに変更や拡張の柔軟性ができます。なので、チームがプラットフォーム固有のプロパティを追加する必要がある場合は、デザイントークンを更新するだけです。

例えば、Android は HEX や RGB の代わりに 8進数 のカラーコードを使いますが、その際デザインシステムを Android に適応させるのに、DSチームは各デザイントークンに8進コードを追加して「信頼できる唯一の情報源（Single source of truth）」を維持することができます。

このトークンによって、エンジニアはエラーや不整合を減らしながら、新しいプロジェクトをずっと速やかに提供できるようになります。

この柔軟性で、変更もできるようになります。例えば、ある製品がモンセラットからロボトに書体を変更した場合、チームはタイポグラフィートークンを更新するだけで、製品全体の変更を実施できます。

デザイントークン構造の確定方法

デザイントークンの構造を定めるルールはありませんが、Amazon のStyle Dictionary にあるこの例が最もわかりやすく、多くの組織で同じようなフォーマットがデザイントークンに使われています。

Amazon の Style Dictionary は、以下のような階層的なデザイントークン構造を採用しています：

• カテゴリ （色、時間、行の高さ、サイズ、アセット、コンテンツなど）
• 種類
• 項目
• サブ項目
• ステート

例えばこの構造を使って、主要な有効ボタンのためのデザイントークンを作成する場合、color_background_button_primary_active のようになるか、color-bg-btn-primary-active のような短縮形になるかもしれません。そしてこのトークンには、クロスプラットフォームの実装に必要なあらゆる種類のカラーコードが含まれます。

デザイントークン構造は一貫性が鍵なので、ユーザーがトークンを簡単に見つけてシステムを拡張できるように、予測可能な命名規則を使わないといけません。

オプションと決定によるトークンの設計

UX の専門家であり、eightshapes の創設者であるネイサン・カーティス氏は、トークンのアーキテクチャについて素晴らしい記事を書いています。彼は、最初のステップは、デザイントークンを以下のようにオプション（または選択肢）と決定に区分することだと言います。

• オプション： 基本トークン値を作成する。トークンは、色、時間、アセット、コンテンツなど、上記の Style Dictionary で説明されているカテゴリを定める。
• 決定：オプションを使って、例えばインタラクティブカラー、背景色、テキストカラーなどのコンポーネントのプロパティを作る。

このシステムには、白を別の色合いに変更したい場合は、カラー オプションの下の HEX コードを置き換えると、各デザイントークンと関連する UI 要素に自動的に同期されるという利点があります。

ネイサン の方法論だと、オプションを使ってより多くの決定を作成するだけなので、拡張もしやすくなります。トークンの設計に関する詳しい手順については、彼の記事全文をお読みください。

デザイントークンの実際の仕組み

「Design Tokens for Dummies」というお役立ち記事で、ルイ・シェネ氏 は、デザイントークンを使う場合と使わない場合の一般的なデザイン変更ワークフローについて以下のように概説しています。

従来のワークフロー – デザイントークンなし

• デザイナーがデザインツールでスタイルを更新する
• デザイナーがデザインハンドオフのために変更をドキュメント化する
• エンジニアが CSS、LESS、SASS などのコンポーネントのプロパティを更新する
• デザインチームが QA（品質保証）中に変更を確認する

このワークフローには以下のような問題があります：

• デザインハンドオフ中に、より多くの作業と細部への注意が必要。
• エラーや誤解が生じやすくなる。
• チケットが増えるので技術的負債が増える。
• 変更を加えて関連するエラーを修正するのに、不要な時間と費用がかかる。

デザイントークン方式

• デザイナーはデザインツールでスタイルを更新する。
• デザイントークンジェネレーターで、プラットフォーム固有のファイル (JSON／YAML) を作成する集中レポジトリが更新される。
• エンジニアは新しいレポジトリをプルし、新しいトークンを追加して、プロジェクトのスタイルを自動更新する。

デザイントークンを使うと、デザインハンドオフに関するドキュメントが少なくなって、エンジニアのプログラミング時間が節約されます。そしてこの自動化されたシステムによって、人的エラーが大幅に減ることから、開発と QA プロセスが効率化されます。

UXPin Merge による「信頼できる唯一の情報源」

デジタル製品が複雑になっていくと、デザイナーとエンジニアはワークフローを統合するソリューションを見つけないといけません。ちなみに UXPin は、革新的な Merge の技術でこの問題を解決しました。

Merge を使うと、レポジトリからコンポーネントライブラリを UXPin のデザイン エディタにインポートできるため、デザイナーはエンジニアが最終製品の開発に使うのと同じ UI 要素を使うことができます。

Merge のコンポーネントには、レポジトリ内のコンポーネントと同じ忠実度と機能があり、デザイン システム チームは、React のプロップ (または Storybook 統合の場合は Args) を使って変更を制限したり、デザイナーにデザイン上の決定を柔軟に行えるようにしたりできます。

また、エンジニアがレポジトリに変更を加えると、それは自動的に UXPin に同期され、デザイナーに更新が通知されます。Merge にはバージョン管理機能が備わっているため、デザイナーは以前のバージョンに切り替えることができ、それで古いプロジェクトの更新をすることができます。

UXPin Merge で製品開発を新たなレベルに引き上げ、「信頼できる唯一の情報源（Single source of truth）」を作りませんか。アクセスリクエストの詳細については、Merge のページをぜひご覧ください。

The post デザイントークンとは？ appeared first on Studio by UXPin.

コラボレーションはデザインのハンドオフの段階で終わるわけではありません。しかし、その後に何が起こるのかが議論されることはほとんどありません。ポルシェ、IBM、セールスフォースのような企業チームがどのようにコラボレーションを行い、デザインシステムの採用率を高め、一貫性をスケーリングしているのかをウェビナーにてご紹介します。

皆さんの組織でも、これらの戦略に基づいてコラボレーションを強化することができます。5月30日（木）深夜02:00からの無料ウェビナーにご参加ください： 「デザインシステムのワークフローから摩擦を取り除くには？」

👉 ご参加はこちらから

ウェビナーの内容

製品を他社よりも迅速に市場投入したいとお考えですか？それなら、そのためのプロセスとツールを使いこなす必要があります。このウェビナーでは、エンジニア、デザイナー、利害関係者からなる多分野のチームにおいて、スピードを維持するために何ができるかを実際に体験していただきます。

詳細：

1. 開発者とデザイナーのコミュニケーション力を高めるには？
2. インタラクティブなドキュメンテーションでデザインシステムの採用を増やす方法
3. 効率的なバグ報告とデザインシステムライブラリの更新を効率化する方法

👉 ご参加はこちらから

登壇者情報

このウェビナーのホストにDevRelであり、StackBlitz（ウェブアプリ構築のためのブラウザ内開発環境）の創業エンジニアであるTomek Sułkowski氏をお招きしました。彼は、ビルトイン、オープンソース、商用のさまざまなツールを活用することで、チームがブラウザ開発環境を最適化できるよう尽力しています。

ウェビナーでは、デザイナーと開発者のコラボレーションを強化する方法や、開発環境、バージョン管理システム、デザインツールを使ってデザインシステムの導入をコントロールする方法について説明します。

サインアップして、リアルタイムでのコラボレーションの秘密を学び、生産性を向上させましょう。

👉 ご参加はこちらから

The post 【無料ウェビナー】デザインシステムワークフローから摩擦をなくす appeared first on Studio by UXPin.

React デザインシステムをゼロから構築するには、慎重な計画と検討が必要であり、組織とそのエンドユーザーに役立つコンポーネントライブラリを作成するには、複数の部門とステークホルダーからの意見が不可欠です。

そこで本記事では、Reactのデザインシステムと、コンポーネント開発、ドキュメンテーション、ガバナンス、デザインツールなどへのアプローチ方法について見ていきます。また、重要なトピックが１２個もカバーされている、デザインシステムを構築するためのステップバイステップのガイドもあります。

主なポイント：

• Reactデザインシステムは、ReactJSを使って構築された再利用可能なコード化されたコンポーネント、開発ガイドライン、アセットのコレクションである。
• React デザインシステムのコンポーネントには、事前構築されたボタン、フォーム、ナビゲーションメニュー、カード、その他の UI（ユーザーインターフェース）のビルディングブロックが含まれる。
• Reactデザインシステムを始めるには、「MUIやFluent UI のようなオープンソースのReactコンポーネントを使う」か、「ゼロからの構築」かである。
• プロトタイプで React デザインシステムを使うための最良のツールの１つとして、デザイナーが開発で再利用できる実際のコンポーネントを使えるようになることから、UXPin Merge が挙げられる。

UI コンポーネントを UXPin に取り込み、Reactデザインシステムに基づいてデザイン性の高いプロトタイプを作成しませんか。アプリの構築が１０倍速くなって、開発のスピードが上がります。こちらから UXPin Merge をぜひご覧ください。

Reactデザインシステム とは

Reactデザインシステムは、UI（ユーザーインターフェイス）構築のために広く使われている JavaScript ライブラリである React で使うために特別に構築された、再利用可能な UI コンポーネントとガイドラインのコレクションであり、ボタン、フォーム、ナビゲーションバー、カードなど、事前デザイン済みでカスタマイズ可能なコンポーネントのセットと、React アプリケーション内での使用と実装のためのガイドラインが含まれています。

Reactデザインシステムは、プロジェクト間で簡単に再利用できる統一されたコンポーネントとデザインパターンのセットを提供することで、UI開発の一貫性、効率性、拡張性を促進することを主な目的とします。デベロッパーは Reactデザインシステムを活用することで開発プロセスの効率化、コードの重複の低減、アプリケーション全体でまとまりのある洗練されたルック＆フィールの確保ができます。

React デザインシステムの主な構成要素には、大体以下のようなものが含まれます：

• 再利用可能なコンポーネント： 入力フィールド、ドロップダウンメニュー、モーダル、タブなど、一般的な UI パターンや機能をカプセル化した React コンポーネントのライブラリ。
• デザインガイドライン： プロップ、スタイリングオプション、アクセシビリティへの配慮、React アプリケーション内での統合のベストプラクティスなどの情報を含む、各コンポーネントの使用方法に関する明確なドキュメントとガイドライン。
• テーマ設定とカスタマイズ： テーマ設定とカスタマイズに対応していることから、デベロッパーはブランドアイデンティティやデザイン要件に合わせてデザインシステムを簡単に適応させることができる。
• レスポンシブ・デザイン： さまざまな画面サイズやデバイスに対応し、デスクトップ、タブレット、モバイルの各プラットフォームで一貫したユーザー体験が得られるようにデザインされたコンポーネント。
• アクセシビリティ： アクセシビリティを考慮し、アクセシビリティの基準とガイドラインを満たすようにデザインされたコンポーネントだと、デザインシステムで構築されたアプリケーションは、ハンディキャップのあるユーザーを含むすべてのユーザーが使用できるようになる。

つまり、React デザインシステムは、Reactアプリケーションを構築するための強固な基盤を提供し、デベロッパーは最小限の労力で一貫性のある高品質の UIを作成できるようになります。コラボレーション、効率性、保守性を促進し、Reactベースのプロジェクトに取り組むチームにとって貴重なツールとなるわけです。

React デザインシステムのメリット

React デザインシステムの使用や構築には、多くの利点があります。例えば React のコンポーネント駆動型の開発アプローチは、デザインシステムに最適なモジュール形式のUIライブラリになり、フロントエンドデベロッパーは、React コンポーネントを原子まで分解し、それを組み合わせて新しい UI要素、パターン、テンプレートを作成できます。

また、React は最も広く使われている UI ライブラリの１つで、デザインシステムを構築する上で以下のように多くのメリットがあります：

• 質問や問題解決ができる、デベロッパー向けの大きなコミュニティ
• 豊富なJavascriptツールと統合
• インスピレーションの源となるきちんと確立された多くのデザインシステム

React デザインシステムを利用している企業

以下は、デザインシステムに React を使っている企業です：

• Instacart/Snacks
• Shopify Polaris
• Atlassian デザインシステム
• Salesforce Lightning
• IBM のカーボンデザインシステム
• Microsoft の Fluent UI
• Google のマテリアルデザイン で構築された MUI (Material UI)

コンポーネントのシンタックス、ドキュメント、ガイドライン、その他のデザインシステム要素について学ぶには、これらのデザインシステムをチェックするのがおすすめです。

また、デザインシステムのインスピレーションを得るには、Adele をチェックしてみてください。これは、ダウンロードして分析できる GitHub レポジトリへのリンクを備えた、公開されているデザイン システムとパターン ライブラリのレポジトリです。

React デザインシステムの基礎

アトミックデザインの原理

アトミックデザインとは、ブラッド・フロスト氏によって考案された「UI要素を以下の５つのカテゴリーに分類するシステム」です：

1. 原子：これ以上分解できない基本的な UI 要素であり、HTML タグ、フォント、ボタン、アニメーション、カラーパレットなどがある。
2. 分子：原子の集まりで、特定の機能や目的を果たす構成要素を作り出し、検索入力、ナビゲーション リンク、ドロップダウン メニューなどがある。
3. 有機体：組み合わせて UI を作成する複雑な UI パターンであり、ヘッダー ナビゲーション バー、フッター、画像カルーセルなどがある。
4. テンプレート：複数の有機体が連携して動作する完全な UI を表し、ダッシュボード、ニュース フィード、チャット UI などがある。
5. ページ：テンプレートのさまざまなインスタンスと、画面内でコンテンツがどのように変化するかを表し、例えば、ニュースフィードのコンテンツの更新や、チャットでのメッセージ受信などがある。

アトミックデザインが React のデザインシステムにとって重要な理由

アトミックデザインの方法論で、React のモジュール性と再利用性の利点を活用できるようになります。デザインシステムを多くの原子の集合体としてアプローチすることで、製品に適応し進化できる柔軟でスケーラブルな UIライブラリを開発しやすくします。

そしてデザインシステムチームは、原子や分子を組み合わせることで、新しいコンポーネントやパターンをより速やかに構築することができ、また、このモジュラーアプローチは、ゼロから開発するよりも、今あるものを組み合わせればいいので、ワンオフの構築がより簡単で、コスト効率も高くなります。

React デザインシステムにおけるコンポーネントの役割

React コンポーネントは、UI やアプリ全体の一貫性、再利用性、保守性を確保するのに役立つビルディングブロックであり、その UI 要素は、以下のような多くの重要な目的を果たします：

• モジュール性： React コンポーネントはデザイン上モジュール化されているため、UI ライブラリの組み合わせ、再利用、管理がしやすくなる。
• 一貫性： React の簡単な再利用性により、デベロッパーはデザイン原則、スタイル、インタラクションを各コンポーネントに組み込み、アプリケーションのどこからでも呼び出すことができる。
• 再利用性： デベロッパーは、再利用可能なコンポーネントの UI ライブラリを活用することで、新製品を開発する際の時間とリソースを節約でき、この再利用性により、ゼロからコードを書く必要がなくなるため、エラーや技術的負債も減らすことができる。
• カスタマイズ性：デベロッパーは、デザインガイドラインに従ったり、UI ライブラリに影響を与えながら、特定のコンポーネントを簡単にカスタマイズすることができる。
• 保守性： コンポーネントが一元化されたレポジトリに保存されているため、デベロッパーは更新やバグ修正を１つの場所からプッシュすることができ、それによってデザインシステムとその製品の保守と改善がしやすくなる。
• スケーラビリティ： エンジニアは、React コンポーネントを拡張して適応させ、製品や新技術に合わせて進化させることができる。
• アクセシビリティ： デベロッパーは、コンポーネントレベルで基本的なアクセシビリティ標準を組み込むことができるため、製品全体への実装がしやすくなる。

デザイントークンを使うことの重要性

デザイントークンには、React デザインシステムのコアバリューが組み込まれており、そのトークンには、色、タイポグラフィ、スペーシング、サイジング、ステート、インタラクティブ性などのプロパティが含まれ、複数のプラットフォーム、デバイス、OS（オペレーティングシステム）にわたって一貫したデザイン言語を維持します。

デザイントークンは、複数のプラットフォーム用に多くの値を含むことができます。例えば、UXPin のホームページでは CTA（Call to Action）に黄色を使っており、この黄色の16進コードは「#FCC821」で、以下のような方法で表現できます：

• HEX: #FCC821
• RGB (CSS): rgb(252, 200, 33)
• RGBA: rgba(252, 200, 33, 1)
• Octal (Android/Flutter): 77144041

そして、この４つの値をすべて１つのデザイントークンの下に以下のようにカプセル化することができます：

• cta-background-primary

なので、この色をプラットフォームに実装する場合は、コードの代わりにトークンを使います。 また、例えば同じ色でも、あるチームは 16 進数、別のチームは RGB、また別のチームが 8 進数を参照すると混乱が生じてエラーにつながるような可能性がありますが、デザイン トークンを使うと、全員が同じ言語を使用するため、部門を超えたコラボレーションがしやすくなります。

また、デザイントークンで、デザインシステムチームはトークンファイルのプロパティの変更だけで製品全体の変更を実装するこができるようになります。例えば、４つのコードを１か所で調整することで、インスタンスやスタイルシートを個別に更新するのではなく、製品エコシステム全体で cta-background-primaryのデザイントークンを黄色から青色に変更できます。

 Reactデザインシステム を始める

表面的には、デザインシステムはシンプルに見えますが、実際には、その UI ライブラリは、多くの可動部分を持つ複雑な有機体です。ここでは、Reactのデザインシステムを計画する際に考慮すべき点を見ていきましょう。

これらの要素は、デザインシステムのガバナンスプロトコルと手順の基礎を築くことになることから、この初期の意思決定プロセスの各段階をドキュメント化することが非常に重要です。

モノレポ と ポリレポ のレポジトリ

デザインシステムの React コンポーネントライブラリに「モノレポ（単一のレポジトリ」を使うか、「ポリレポ」を使うかを決定します。

モノレポは依存関係の管理をシンプルにし、複数のパッケージを同時に扱いやすくします。対するポリレポは、パッケージ間のモジュール性と分離性を高め、個々のコンポーネントを独立して保守・使用しやすくします。

アクセンチュアでモノレポとポリレポの長所と短所について語られています（英語）

コンポーネントの構成

製品およびチームにとって最も理にかなった方法でコンポーネントライブラリを整理しましょう。例えば、コンポーネントを機能性、ドメイン、または Atomic Design-MUI はでグループ分けできます ‐ ちなみに MUIはUIライブラリを以下のように機能別に整理しています：

• 入力： ボタン、スイッチ、テキストフィールドなど
• ナビゲーション：ドロワー、メニュー、ページネーションなど
• レイアウト：ボックス、コンテナ、グリッドなど
• データ表示：アバター、アイコン、リストなど

ただ、このようなコンポーネントがどのように分類されるとしても、それぞれに独自のソースコード、スタイル、テスト、ドキュメントがないといけません。

デザイントークンの管理

デザイントークンの管理を、デザインシステムチームが管理する専用のフォルダまたはパッケージに一元化します。この集中管理により、変更と更新はシンプルになりながら、より良いメンテナンスとガバナンスは促進されます。

テーマ設定とカスタマイズ

デザインシステムのテーマ設定とカスタマイズは、最新の製品開発には不可欠であり、大体は「ライトモード」と「ダークモード」の少なくとも２つのテーマが必要です。また、マルチブランドのデザインシステムには、より大きなカスタマイズ性と柔軟性が要求されるため、開発前にこのような要素を考慮する必要があります。

React ライブラリのテーマの設定方法については、CSS Tricks の「Theming and Theme Switching with React and styled-components」をご覧ください。

ドキュメンテーション

デザインシステムのドキュメント化は、導入の成功や、一貫した実装に不可欠であり、そのドキュメントには、デザイン言語、 (コンテンツ、デザイン、コード、アクセシビリティなどの）ガイドライン、スタイル ガイド、ユースケース、コード例、ツール、その他の重要な情報が含まれていないといけません。

Storybook のようなツールで、デザインシステムのドキュメント管理と更新を一元化することができ、 Merge を使って Storybook を UXPin に同期し、デザインと開発全体にわたって「信頼できる唯一の情報源（Siingle source of truth）」を作成できます。

テスト

コンポーネント テストを管理および組織するための構造を計画します。‐ これが、Storybook を検討するもう 1 つの理由です。 Storybookは、ビジュアル、インタラクション、アクセシビリティ、スナップショットなどの複数のバグ防止テストを備えた自動のコンポーネントテストが内蔵されていますからね。

バージョン管理とリリース管理

React ライブラリのバージョン管理戦略とリリース管理プロセスを確立して、デザインシステムが常に更新され、製品と互換性があることを確認します。

デザインツール

デザイナーは、プロトタイプとテストのために React デザインシステムにアクセスする必要があります。 一般的な戦略はベクターベースのツールの使用ですが、これは React デザインシステムの以下の２つの形式を更新して維持するということです：

• レポジトリ内のコンポーネント ライブラリ
• デザインチーム向けの UI キット

UXPin Merge を使うと、React ライブラリを UXPin のデザイン エディターにインポートできるため、デザイナーとエンジニアはまったく同じUIコンポーネントを使うことができます。 そしてコードコンポーネントの同期には、いくつかのオプションがあります。 UXPin Merge についての詳細は、こちらからぜひご覧下さい。

The post Reactデザインシステム の始め方 appeared first on Studio by UXPin.

Figma のコンポーネントライブラリは、再利用可能な UI要素を作成してチームメンバーと共有できる素晴らしい方法です。

デザイナーは、Figmaでコンポーネントを使ってUIやプロトタイプを作成することができ、プロジェクト間の一貫性を維持することができます。

ただ、Figmaのコンポーネントライブラリには、インタラクティブなプロトタイプを作成できないなどの制限がいくつかあります。

一方 、UXPin MergeはFigmaと異なり、実物に近くて完全にインタラクティブなプロトタイプを作成することができます。

主なポイント：

• Figmaコンポーネントライブラリは、再利用可能な UI要素を作成してそれを共有するための素晴らしい方法である。
• UXPin Mergeは、Figma のコンポーネントライブラリに代わるもので、完全にインタラクティブなプロトタイプを作成できる。
• Figmaのコンポーネントライブラリには、インタラクティブなプロトタイプを作成できないという制限がある。
• MergeはUI コンポーネントをレポジトリからデザインプロセスにインポートすることで、デザインと開発の間に「信頼できる唯一の情報源（Single source of truth）」を作成する。
• Merge では、デザインプロセスでコードコンポーネントを使って完全にインタラクティブなプロトタイプを作成し、テストを改善することができる。

Figmaでの基本的なプロトタイプから、UXPinでの高度なプロトタイプに切り替えてみませんか？こちらから UXPin Merge をぜひご覧ください。

Figma のコンポーネントライブラリとは

Figma のコンポーネントライブラリでは、Figma のコンポーネントとスタイルを作成し、そのファイルを公開することによって、チームメンバーと共有することができます。

そしてチームメンバーは、この共有ファイルにアクセスし、コンポーネントやスタイルをデザインシステムとして使うことができます。

デザインチームは、このようなコンポーネントやスタイルを変更し、それをライブラリにプッシュすることができます。

また、権限を作成して、権限を与えられたチーム メンバーだけがコンポーネントライブラリを変更できるようにもできます。

Figma のコンポーネントとコンポーネントインスタンスとは

Figma のコンポーネントは、コンポーネントライブラリの一部を構成する、単一の再利用可能な UI 要素であり、Figma のドキュメントによると、コンポーネントライブラリには、以下のような様々なものを保存することができます：

• UI コンポーネント
• 企業ロゴとブランドアセット
• アイコン
• デバイスモックアップ
• Android、iOS、Linux、OSX など、プラットフォームOSコンポーネント
• カーソル
• 赤線と注釈のコンポーネント
• 共同デザインスプリントを実行するための付箋と投票用「ステッカー」
• 流れを示す矢印やフローチャートの形などのダイアグラム作成用「ヘルパー」

このようなマスターコンポーネントは、プライマリコンポーネントファイルか、左サイドバーの［assets（アセット）］のタブで見ることができます。

コンポーネントインスタンスは、UI やプロトタイプの作成に使われるライブラリコンポーネントのコピーです。例えば、ライブラリに２０画面に表示されるアプリバーのコンポーネントがあるとします。

この２０個のアプリバーは、ライブラリコンポーネントのインスタンスになります。

ライブラリコンポーネントを更新すると、そのインスタンスもすべて変更されます。Figma では、コンポーネントが更新されるたびにそれがデザイナーに通知され、いつ最新バージョンを受け入れるかを選択できます。

Figma の「スタイル」とは

「スタイル」によって、チームやプロジェクト間で一貫性が保たれ、誰もが同じプロパティや値を使えるようになります。

Figmaでは、色、タイポグラフィ、サイズ、間隔、ボーダー半径など、再利用可能なスタイルプロパティを保存でき、これは CSS の変数に相当します。

そして、HEXコードやフォントサイズの値を入力する代わりに、例えば、プライマリーブルーや見出し１などの定義済みのスタイルを選択します。

Figma でコンポーネントライブラリを見つける方法

Figma のコンポーネントライブラリを探すには、以下のような方法があります：

• デザインライブラリのファイルの中で作業している場合は、コンポーネントを右クリックし、［Go to main component（メインコンポーネントに移動）］を選択する。また、右サイドバーのコンポーネント名の横にある［Figma Component（Figmaのコンポーネント）］のアイコンをクリックすることもできる。
• メインのファイルにアクセスできない場合、Figma のコンポーネントライブラリにアクセスすることはできないが、左サイドバーの「Assets（アセット）」タブで、のコンポーネントをすべて見ることができる。

Figma のコンポーネントライブラリのコンポーネントの使い方

• 左サイドバーの「Assets（アセット）」タブをクリックする。
• 検索フィールドを使ってアセットを検索するか、下のドロップダウンから「ライブラリ」を選択する。
• 「Assets」タブからコンポーネントをクリックするか、キャンバス上にドラッグする。
• 左サイドバーの「Design」タブでコンポーネントのプロパティと変数を調整する。

インスタンスを切り離すことで、コンポーネントを再デザインできます。

そして、切り離したインスタンスに加えた編集は、以前のコンポーネントやインスタンスには影響せず、変更が完了したら、これを新しいコンポーネントとして保存し、「Assets」のフォルダに表示されます。

Figma のコンポーネントライブラリの限界と課題

Figma のコンポーネントライブラリで、UI 要素の再利用や共有がしやすくなりますが、それを使ってできることには、以下のような制限があります：

• Figma のコンポーネントは、美しい UI デザインを作成するが、インタラクティブなプロトタイプを作成する機能がないため、デザイナーが達成できる範囲は限られる。
• デザインチームは、Figmaのコンポーネントをよりインタラクティブにするには追加のツールやプラグインが必要であり、コストとワークフローの複雑さが増す。
• コンポーネントで、デザインチームは Figma で UI や基本的なプロトタイプを構築することができるが、デベロッパーにとって使いやすいものではなく、コードのUIコンポーネントとずれる可能性がある。
• インスタンスを切り離すのは、新しいコンポーネントを作成するのに便利だが、デザインチームが UI要素を許可なく編集や操作をできるということになる。
• Figmaのコンポーネントライブラリをデザインシステムに使う場合、DS チームは、「Figma用」と「コード用」の２つのバージョンを管理しないといけない。

インタラクティブなプロトタイプでより良い結果を得ませんか。世界最先端の UX デザインテクノロジーである Merge をぜひお試し下さい。

UXPin Merge – Figmaのライブラリに代わるおすすめライブラリ

UXPin Merge のテクノロジーは、UIコンポーネントを Github や Bitbucket、GitLab などのレポジトリからデザインプロセスにインポートします。

そしてデザインチームは、この完全にインタラクティブなコードコンポーネントを使って、最終製品のように見えるプロトタイプを作成できます。

スタイリングとインタラクティブ機能

Merge のコンポーネントには、スタイリングやインタラクティブ性などのプロパティが「ベイクイン」されているため、デザインチームは正しい値の入力や、コードコンポーネントライブラリからのアニメーションのコピーを気にする必要はありません。

また、デザインシステムチームが、React props や Storybook Args を使ってプロパティを確定すると、UXPin のプロパティパネルにそれが表示されます。

例えば、ボタンのステート、テキストスタイル、色、サイズ、アイコン、インタラクションは、デザイナーがドロップダウンで選択できます。

さらに、Mergeでデザインドリフトがなくなり、UI要素への誤った修正を防ぐことができます。

デザイナーは Mergeコンポーネントを切り離して変更することはできず、デザインシステムチームのみが、UXPinに同期するレポジトリ内のコードコンポーネントを変更してデザイナーに更新を通知できます。

信頼できる唯一の情報源（Single source of truth）

多くのデザインツールは、「信頼できる唯一の情報源（Single source of truth）」が提供されていると主張してますが、現実には、画像ベースのソリューションは、デザインツール、プロトタイピングツール、ドキュメンテーション、コード UI ライブラリなど、複数の分野でのアップデートが必要です。

そこで Mergeを使うと、製品開発チーム全体 （UX デザイナー、製品チーム、エンジニア）が同じレポジトリからコンポーネントを引っ張って来れます。

レポジトリへの変更はすべて UXPin に自動的に同期され、その更新がデザイナーに通知され、これが真の「信頼できる唯一の情報源」となります。

UI キット、コードコンポーネント、関連ドキュメントを更新する代わりに、デザインシステムチームは１つのリリースを全員に同時にプッシュするということです。

UXPin で Merge のコンポーネントライブラリを使う方法

デザインシステムチームがセットアップを完了すると、コンポーネントライブラリを UXPin で使えるようになります。

Merge のコンポーネントライブラリの使い方についてのステップバイステップのチュートリアルを以下で見てみましょう：

ステップ 1. デザインシステムのライブラリを開く

デザインシステムは、UXPin の左サイドバーのデザインシステムライブラリの下に全て表示されます。

カテゴリーは以下の２つです：

• MERGE LIBRARIES：レポジトリからのコードコンポーネントライブラリ
• CLASIC LIBRARIES： 通常の UXPin コンポーネント

ステップ2. デザインシステムを選択する

作業したいデザインシステムを選択すると、コンポーネントライブラリが左サイドバーに開きます。

ライブラリの上には、［コンポーネント」と［Patterns（パターン）］のタブがあります（パターンについては後ほど…）。

コンポーネントにはコンポーネント ライブラリが含まれており、ドロップダウンにはボタン、スイッチ、カード、アイコンなど)の使用可能なカテゴリが表示されます。

ステップ3. コンポーネントライブラリの使用

コンポーネントをクリックしてキャンバスに追加します。

コンポーネントのプロパティを表示し、右側のプロパティパネルで調整します。

このプロセスを繰り返して、UI とプロトタイプを作ります。

ステップ4. UXPin – Pattern（パターン）の使い方

パターンを使うと、デザインシステムから複数の UI 要素を組み合わせて新しいコンポーネントやテンプレートを作成でき、複数のコンポーネントライブラリからコンポーネントを使って、新しいパターンをデザインシステムに昇格させる前にテストすることができます。

また、パターンでコンポーネントの複数の状態や変数を作成すこともできいます。

例えば、UI に「ライトモード」と「ダークモード」のバージョンが欲しいけどデザインシステムには「ライト」の変数しかない場合、UXPinでこの「ダークモード」の変数を作成し、それをパターンに保存して、チームメンバーと共有することもできます。

ステップ5. インタラクティブコンポーネントを使ったプロトタイピングとテスト

UXPin でプロトタイプをテストするには、以下の２つのオプションがあります：

• プレビューと共有： ブラウザでプロトタイプを起動
• UXPin Mirror： iOS および Android デバイスでのテスト用アプリ

Merge のプロトタイプで、デザインチームはエンジニアが開発に使うのと同じコンポーネントを使って複雑なプロトタイプを作成できるようになります。

ステークホルダーやユーザーは最終製品と同じように Merge プロトタイプを操作することができ、デザインチームは反復と改善のための有意義なフィードバックを得ることができます。

高品質のインタラクティブプロトタイプを使うのは、デザイナーはデザインプロセスにおいて、より多くのユーザビリティの問題を解決し、より良いビジネスチャンスを特定できるということです。

ステップ6. デザインハンドオフ

Merge ではデベロッパーとエンジニアが同じ UI ライブラリを使うため、デザインから開発への移行はシームレスです。

また、UXPin は本番環境で使用可能な JSX を生成するため、デベロッパーはコードを IDE （統合開発環境）にコピー/貼り付けて開発することができます。

世界最先端の製品デザインツールで、デザインと開発のギャップを埋めませんか。詳しくは Mergeページをぜひご覧ください。

The post 【FigmaとUXPin】 コンポーネントライブラリにおける違い appeared first on Studio by UXPin.

デザインシステムエンジニア（DSE）は、単にデザインと開発のギャップを埋めるだけの役割ではなく、ピクセルからコードへのスムーズな移行をサポートをします。このガイドでは、DSEの仕事内容、必要なスキルセット、製品開発サイクルでの位置づけについて包括的に深く掘り下げていきます。

DSEを目指す方、採用担当者の方、あるいはデザイン・開発関連の職種に興味がある方など、ぜひご一読いただき、DSEの多面的な役割を紐解いていきましょう。

主なポイント：

• DSE は、デザイナーとデベロッパーをつなぐ重要な役割を担い、UIコンポーネントやデザインガイドラインを標準化する。
• DSEは、コードやデザインにとどまらず、品質保証、文書化、チーム間の連携においても積極的な役割を果たしている。
• HTML、CSS、JavaScript などのフロントエンド開発言語や、Sketch、Figma などのデザインツールの習得は、DSEにとって非常に重要である。
• DSEは、製品開発サイクル全体を通じて重要な役割を果たし、デザインシステムの一貫した実装と更新が保証される。
• Gitのようなバージョン管理システムやReactのようなフレームワークに詳しければ、DSEによるデザインシステムの効果的な管理および拡張の能力が上がる。

  UXPin Mergeのテクノロジーでデザイナーとエンジニアのギャップを埋め、より効率的にサービスを提供しませんか。詳細とアクセスリクエスト方法については、Mergeのページをぜひご覧ください。

デザインシステムエンジニア（DSE）とは

  DSE（デザインシステムエンジニア）は、視覚的なコンセプトから機能的なコードにシームレスな移行をします。

また、DSEは、UIコンポーネントとデザインガイドラインを標準化した中央レポジトリであるデザインシステムを管理および維持し、デベロッパーとはコードを、UXデザインチームとは UX（ユーザーエクスペリエンス）とデザイン原則を共有します。

そして DSE には、デザインツールやデザイン思考から、HTML、CSS、Javascript のコードの記述や、React、Vue、Angularなどのフロントエンド技術の使用までの幅広いスキルがあり、デザインシステムの一貫性、コンポーネントの構造、デザインシステムチーム内のチーム横断的な連携を実現するエキスパートです。また、DSE で、デザインと開発のワークフローが一貫性のある合理的なものに保たれます。

DSE と UXデザイナーやフロントエンドエンジニアとの違い

  デザイナー、デベロッパー、DSE の３つの役割がすべて果たされることで、ユーザーのニーズから機能的で優れたデザインの製品へとシームレスに移行することができます。各ポジションが他のポジションを補完することで、何一つ抜け落ちることがなくなるのです。

• UX デザイナー：製品の全体的な UX に焦点を当てる。彼らの領域はユーザー中心のデザインであり、コードではない。
• デベロッパー：デザインを機能的なアプリケーションに変える。UX の原則を深く理解している場合もあれば、そうでない場合もある。
• DSE：デザインと開発の間のギャップの橋渡しをする。 デザインシステムを実装し、製品間の一貫性と拡張性を確保する。

  デザインシステムの開発と維持において、この３つはどのように補完し合っているのでしょうか：

• ユーザーインサイト： UXデザイナーは貴重なユーザーインサイトをもたらし、エンドユーザーにとって何が最適かをチームに導く。
• 技術的な実装： デベロッパーは、内部ですべてがきちんとスムーズに動くようにする。アプリケーションが動かなければ、ユーザーインサイトもデザインシステムも意味がない。
• デザインの拡張性： DSEは、デザインの一貫性を維持、プロジェクトのさまざまな部分で実装しやすくなるようにすることによって、デザインチームとエンジニアリングチームの両方がより効率的に作業できるようになる。

DSE の仕事内容

• デザインシステムの構築および更新：基礎となるデザインシステムを構築し、プロジェクト要件に合致するように更新し続ける。
• QA（品質保証）： UI コンポーネントの自動テストを実施し、デザインと機能の基準を満たしていることを保証する。
• ドキュメンテーション： デザイナーとデベロッパーがデザインシステムを理解できるようにする、明確で実用的なガイドラインを作成する。
• バージョン管理： Git のようなツールを使って変更を管理し、各更新が適切に追跡され、文書化されるようにする。
• コードレビュー：コードのレビューに参加し、デザインガイドラインの遵守とコードの品質を保証する。
• チームを超えた連携：デザインチームと開発チームの連絡役となり、デザイン原則がコードに正確に実装されていることを確認する。
• トレーニング：ワークショップやトレーニングのセッションを実施し、デザインシステムの構成要素やベストプラクティスをチームメンバーに周知させる。
• ツールの統合： デザインシステムの導入をしやすくする Storybookのようなツールのセットアップおよびメンテナンス。
• パフォーマンスの最適化： 定期的にデザインシステムを監査し、冗長性を排除して読み込み時間を改善する。
• ステークホルダーとのやり取り：デザインシステムの状態、変更点、プロジェクトへの影響について、ステークホルダーに定期的に報告する。

DSE に必要なスキル

  DSE は専門職ですが、多面的な要求に応えるには幅広いスキルセットが必要です。ここでは、DSE に必要なハードスキルとソフトスキルを見ていきましょう。

ハードスキル

• フロントエンド開発： HTML、CSS、JavaScriptは言うまでもなく、強固なデザインシステムを実装するための基盤である。
• フレームワークとライブラリ：ReactやAngular、Vueが最新の Webアプリケーションを強化していることを考慮すると、多くの場合はこのようなテクノロジーに詳しいことが求められる。
• バージョン管理： Git に詳しいことも、デザインシステムの変更の追跡および管理には譲れない条件である。
• デザインツール： Sketch、Figma、または UXPinを使いこなすことで、デザインチームとの連携がしやすくなり、UI コンポーネントの作成や修正がしやすくなる。
• 自動テスト： Jest、Mocha、または同様のテストフレームワークのスキルにより、デザインシステムの品質と信頼性を保証する。
• アクセシビリティ基準： WCAGガイドラインを理解して、デザインシステムが包括的で法令に準拠していることを保証する。

ソフトスキル

• コミュニケーション能力： 複雑な技術的アイデアをデザイナー、デベロッパー、ステークホルダーに明確に伝えることで、それぞれの負担を軽くする。
• 細部へのこだわり： 些細な視覚的、機能的な不一致がプロジェクトを頓挫させることがあることから、正確さが鍵となる。
• 問題解決能力： デザインシステムは複雑であり、迅速かつ効果的な問題解決能力が求められる。
• 連携： この職務はデザインと開発が交わるところに位置するため、チームワークのスキルが不可欠である。
• 時間の管理： デザイン、開発、ステークホルダーとのミーティングをこなすには、強力な組織力が非常に重要である。

製品開発サイクルにおける DSE の役割

  DSE は、製品開発サイクル全体を通じて、デザインと機能性が確実に一貫した拡張性のある製品に統合されるようにし、さまざまな部門間の橋渡し役として機能して、デザインシステムの一貫性と最新性を維持します。

インセプション段階

  アイデアの検証や計画段階で、DSE は、再利用や転用が可能なデザインシステムやコンポーネントの候補を評価します。また、プロダクトマネージャーやデザイナーと密接に協力し、デザインシステムのスコープ、実現可能性、技術要件を確定します。

デザイン段階

DSE は、UX/UIデザイナーと積極的に協力してデザイン批評を行い、機能性を損なうことなくデザインシステムを実装するための技術指導を行います。

例えば、UXデザイナーが新しいボタンスタイルを提案する場合、DSE はそのデザインが既存のパターンに適合し、コードで簡単に実装できることを確認します。

開発段階

  DSEは、承認されたデザイン要素を再利用可能なコードコンポーネントに変換し、デベロッパーによる実装がしやすくなるための文書も提供します。

例えば、デザイナーが新しいカードのレイアウトを作成した場合、DSE はそれをコードに転送し、再利用可能なコンポーネントにして、さまざまな場面での実装方法を文書化します。

ローンチ後

リリース後、DSEはデザインシステムのコンポーネントの使用状況を監視し、スケーラビリティとパフォーマンスのアップデートを行います。さらに、継続的な改善のためのフィードバックも集めます。

例えば、ナビゲーションのコンポーネントが期待したほど直感的でないことがアナリティクスで示されると、DSE はデザイナーやデベロッパーと協力して、そのコンポーネントを最適化します。

DSEになるには

DSEになるための学歴およびキャリアのステップ

• 学士号（+- 4年）の取得： 通常は、コンピューターサイエンス、グラフィックデザイン、または関連分野の学士号を取得する。
• 関連スキルを学ぶ： 学位と並行して、HTML、CSS、JavaScript をマスターし、Figma、UXPin、Sketch などのデザインツールに詳しくなっておく。
• エントリーレベルのポジション： ジュニアレベルのデベロッパーまたはデザイナーとしてスタートし、通常１～２年の経験が求められる。
• 専門トレーニング： デザインシステムや UX/UI デザインの専門コースを数カ月から１年間受講する。
• 中堅レベルの役割： フロントエンドデベロッパーや UX デザイナーのような役割に移る。
• デザインシステムの経験を積む： 中堅レベルのポジションでは、デザインシステムを扱うプロジェクトに集中する。
• DSE への移行：十分な経験と強力なポートフォリオがあれば、DSE の役割に移行する。

DSE としての成長の見込み

• リードDSE： プロジェクトやチームをリードする。DSE として少なくとも２～３年の、実績のあるリーダーシップスキルが求められる。
• デザインシステムマネージャー： プロジェクトおよびデザインシステムを複数統括。４～６年の専門経験が求められる。
• デザインまたはエンジニアリングディレクター： 部門全体を統括して頂点を極める。一般的に１０年以上の現場経験と豊富なリーダーシップが求められる。

DSE に必要なもの

  ここでは、DSE にとって非常に重要なツールのカテゴリーと例を見ていきます。このようなツールに詳しいと、それがキャリア展望に役立ち、この複雑な役割に対する理解が深まるでしょう。

バージョン管理システム

• Git： バージョン管理の定番で、変更の追跡や他者との共同作業に欠かせない。
• SVN：Git ほどよく使われてはいないが、特定の企業環境では価値がある。

デザインツール

• Sketch：強力なデザイン機能がある。ただし Mac 専用。
• Figma： クラウドベースで連携ができ、リアルタイムの変更が可能。
• UXPin Merge： デザインコンポーネントとコードコンポーネントを組み合わせて再利用できるユニークな機能。

プログラミング言語とフレームワーク

• HTML： Web開発の構成要素
• CSS： スタイリングとレイアウトに不可欠。
• JavaScript： インタラクティブ性を実現し、Webの動作を制御する。
• React： コンポーネントベースのアーキテクチャーとクロスプラットフォームの効率性により、デザインに最適なライブラリである。

UXPin MergeとReactを使ってデザインシステムのデザイン、開発、保全、拡張する

  デザインシステムの構築と維持は、多部門のチームと膨大なツールセットを含む複雑で時間のかかる仕事ですが、UXPin と Merge のテクノロジーを React、Vue、Angular、その他の一般的なフロントエンド技術のフレームワークと組み合わせることで、デザインと開発の橋渡しをしながら、デザインシステムの管理とガバナンスをシンプルにできます。

信頼できる唯一の情報源（Single source of truth）

  デザインシステムの成熟度における最大の難関は「信頼できる唯一の情報源（Single source of truth）」ですが、この段階に達する組織はほとんどなく、高いコストとツールの制約により、大抵のデザインシステムは以下の２つのバージョンを維持しています：

• デザインツールUIキット
• 開発コンポーネントライブラリ

デザインと開発にはプラットフォーム固有の文書が必要で、それでメンテナンスとコストがかさみます。

Merge は、デザインシステムのレポジトリから UXPin に UI コンポーネントをインポートすることで、真の「信頼できる唯一の情報源（Single sourdce of truth）」を実現します。この統合は、エンジニアが最終製品の開発に使うのと同じ UI ライブラリを、デザイナーがデザインプロセスで使えるということになります。

レポジトリへの変更は自動的に UXPin に同期され、デザインチームに更新が通知されます。また、Merge のバージョン管理により、デザイナーは最新リリースに切り替えるタイミングや古いバージョンに戻すタイミングを選ぶことができます。

UXPin のパターンを使ってデザインシステムを拡張する

  DSE は、UXPin の パターン（Patterns）を使って、デザインチームと協力してデザインシステムを拡張することができます。パターンでは、ゼロから始めるのではなく、デザイナーが複数のデザインシステムから UI要素を組み合わせて、新しいコンポーネント、パターン、テンプレートのプロトタイプを作成することができます。

そしてデザイナーは、DSEと協力して新しいコンポーネントをデザインシステムのライブラリに昇格させる前に、UXPin でこのパターンを徹底的にテストすることができます。

DSE のデザインハンドオフの円滑化

デザインハンドオフは、製品開発における最大の課題の一つであり、DSEがデザインと開発の両側で能力を発揮したとしても、実際にはデザインをコードに変換するプロセスは時間がかかり、ミスが起こりやすいです。

デザインと開発にコードコンポーネントを使うことで、ハンドオフが効率化されます。

パターンを使って新しいコンポーネントを作成することで、デザインチームはゼロからデザインする必要がなくなり、既存のオープンソースライブラリを活用しながら、DSEやデベロッパーにとって実装しやすいものにします。

UXPin MergeとDSEに共通点が一つあるとすれば、デザインと開発のギャップを埋めるという点です。

世界最先端のデザインツールでデザインシステム管理をシンプルにしませんか。詳細およびアクセスリクエスト方法については、Mergeのページをぜひご覧ください。

The post デザインシステムエンジニア（DSE）：職務内容、責任、スキル appeared first on Studio by UXPin.

デザインシステムツールは拡張や維持がしやすくなるだけでなく、導入の促進につながります。いくつかの選択肢があるなかで、自社製品に適したツールを判断するにはどのようなポイントに気をつけるべきでしょうか。

ここでは、１０年以上にわたってデザインツールに携わるUXPinが、デザイナーとエンジニア向けのデザインシステムツールを７つご紹介します。

デザインシステムからUXPinにコンポーネントライブラリを追加して、コンポーネント駆動型プロトタイピングが持つインタラクティブ性をお楽しみください。自社コンポーネントを使うことでメンテナンスは容易になり、デザインとコードの「信頼できる唯一の情報源（Single source of truth）」として開発者と共有することができます。UXPin Merge へのアクセスのリクエストはこちら。

１．UXPin

UXPinは、ゼロから作成または既存のデザインシステムを使用して、構築、成長、拡張のためのツールと機能を提供します。

デザイナーは、インタラクティブコンポーネント、アセット、タイポグラフィ、カラーを保存してデザインシステムをゼロから作成できます。デザインシステムを構築後は、組織全体で共有し、アクセス許可の設定が可能です。 これは、ガバナンスの手順やプロトコルの管理にピッタリですね。

また、デザイナーは、デザインシステムのコンポーネントやアセットをキャンバス画面にドラッグ＆ドロップするだけで、簡単にレイアウトの構築を開始でます。外部ファイルやプラグインは必要ありません。UXPinはすべてが揃っており、チームはデザインシステムのドキュメントを見るためにツールを離れる必要がないため、最大限の一貫性と効率性を得ることができます。

さらに UXPinではStorybookでホストされているコンポーネントライブラリのようなエンジニアのための外部ドキュメントへの接続も簡単です。

デザインシステムが成熟してきたら、UXPin Mergeにアップグレードしてみましょう。UXPin Mergeでは、デザイナーが完全に機能するコードコンポーネントを使ってレイアウトを構築できるように、レポジトリからUXPinのエディタにデザインシステムを同期させることができます。

Mergeを使うと、デザイナーとエンジニアは同じコンポーネントを使用できるので、デザインシステムの「信頼できる唯一の情報源（Singe source of truth）」が構築されます。また、レポジトリの更新はUXPinのエディタに自動で同期され、デザイナーに新しいバージョンが通知されます。

さらに、UXPinのバージョン管理を使って、さまざまなバージョンのデザインシステムを切り替えることができ、プロジェクトやプロトタイプにに合わせて自由に色々なバージョンを使うことができます。

２．Zeroheight

Zeroheight は、組織全体で共有可能なデザインシステムのドキュメントをホストする中心的な存在です。Zeroheightは、UXPinのようにデザイナーがライブラリから直接コンポーネントを作成するのではなく、チームメンバーがダウンロードまたはインストールする必要があるデザインファイルをあなたがホストすることができます。

Zeroheightでは、コードスニペットでStorybookからデザインシステムのコンポーネントを埋め込むことができます。

Lightning、Polaris、Stacksと同様に、左側に「メインナビゲーション」があり、右側に「目次」にあるデザインシステムでの標準的なダッシュボードレイアウトです。この馴染みやすいレイアウトによって初めて使う人でも使いやすく、チームにとってもデザインシステムから探したいものを見つける際のナビゲーションとしても役に立ちます。

また、デザインシステムでのすべてのアセットはZeroheightに保存可能です。デザインシステムチームはチュートリアルや説明向けにYouTube、Vimeo、Loom、Google Driveの動画を埋め込むこともできます。

３．Supernova

Supernovaは Zeroheightの代わりになる優れたツールです。レイアウトや機能は似ていますが、機能面で言うとSupernovaの方が少し高めです。

Supernovaの最大の特徴として、デザインデータをどんな技術スタックのコードやアセットにも自動変換できる機能があることです。また、iOS、Android、React、Angular、Flutterのようなプロダクトフォーマットにデベロッパー向けのスターターテンプレートを含めることもできるので、エンジニアは常に正しいコードとアセットを確実に持つことができます。

SupernovaのVSCodeエクステンションは、多くの人に使われているIDE（Integrated Development Environment／統合開発環境）とデザインシステムを同期することができます。デベロッパーは必要なものをすべて1か所で入手可能です。また、Supernovaといくつかのデザインツールは同期可能なため、デザイナーはファイルのダウンロードやインポートをする必要がなくなります。

４．Storybook

Storybookは、コンポーネントを１つずつ構築および保存したいエンジニアに人気のツールです。他のデザインまたは開発ツールとも統合することができ、そのうちの1つがUXPinとの統合です。

MergeのStorybook統合により、ライブラリをUXPinのエディタに同期することができ、デザイナーとエンジニアは同じコンポーネントにアクセスすることができます。

Storybookのサンドボックス環境によって、エンジニアはステートやインタラクションなどの各コンポーネントに集中しやすくなります。また、ダッシュボードのレイアウトでStorybookのコンポーネントライブラリが整理・分類できるので、必要なものを簡単に見つけることができます。

Storybookは、新しいコンポーネントについてチームやステークホルダーと話し合い、公開前に意見や承認を得ることができるコラボレーションツールです。Chromaticアドオンを使うと、ブラウザ間でのビジュアルテストを自動化でき、QAチームからのフィードバックを集めることができます。

また、Storybookでは各UIコンポーネントの基本的なドキュメントが自動作成されますが、このドキュメントは、デザインシステムのガイドライン、使用方法、原則などを含めて編集することができます。

そして、Storybookはオープンソースのツールで無料であり、包括的なドキュメントに従うだけで始められます。ご参考までに、こちらのベストプラクティスと Storybookの例をご覧ください。

５．Pattern Lab

Pattern Labは、デザインシステムのコンポーネントを構築、表示、テスト、公開するためのオープンソースのフロントエンド環境です。このプラットフォームでは、パターンやテンプレートを構築するために “stitches together UI components”（UIコンポーネントをつなぎ合わせる）という、ブラッド・フロント氏の 「アトミックデザインの原則」が使われています。

また、HandlebarsまたはTwigsマークアップでのコンポーネント構築や、別のJSONファイルを使ったバリエーションの作成ができます。Pattern Lab が要素を自動分類し、ダッシュボードスタイルのUIに表示してくれるのです。

そしてユーザーは、ダッシュボードから各要素を検査し、マークアップとCSSクラス付きHTML言語を表示できます。また、各コンポーネントにドキュメントを含めることで、ユーザーに詳細な情報とコンテキストを提供することもできます。

カスタムデザインシステム管理ツールを構築している場合、Pattern Labはカスタマイズする上で最適な出発点といえるでしょう。

６．Adobe XD

Adobe XDには、デザインシステムを管理ための機能はありませんが、Zeroheight、Frontify、Zeplinなどのデザインシステムツールと統合することができます。

UXPinのように、デザイナーはドキュメントやスタイルガイドのコンテキストや指示がなくても、デザインシステムからコンポーネントライブラリやアセットを共有することができます。

ただ、成熟したデザインシステムにAdobe XDを使う際の問題点として、「デザイン」と「開発」で別々のコンポーネントがあり、一方はコードベース、もう一方はデザイナーがXDで使う画像ベースのものという状態です。また、デザインシステムを同期および管理するために追加でツールやプラグインも必要です。

７．Design System Manager – InVision

InVisionのDSM（Design System Manager）もまた多く使われているデザインシステムツールです。DSMはダッシュボードのレイアウトや直感的なナビゲーションは SupernovaやZeroheightと非常によく似ています。

DSMはInVisionのデザインツールと同期するため、デザイナーはデザインシステムからコンポーネントをドラッグ＆ドロップでレイアウトを構築できます。UXPinのように、デザインチームは１つのツールで完結するということですね。

また、InVision Inspectで、React、Vue、Angular、HTMLなどの一般的なフロントエンドフレームワークのコードスニペットを保存でき、Inspectは、コードとステートを持つサンプルコンポーネントを表示します。

ただ、SketchやInVision Studioを使っていない場合、DSMでは制限されることがあります。DSMの無料プランでは基本的な機能しか提供されておらず、デベロッパーとの統合やバージョン管理などのデザインシステムに不可欠な機能を利用するためにはエンタープライズプランにアップグレードが必要となるでしょう。

デザインシステム管理ツールに求めるもの

デザインシステム管理ツールは、デザイナーやエンジニアのために最適なUXを提供しなければいけません。ここでは、デザインシステム管理ツールを選ぶ際に覚えておくべきポイントをいくつかご紹介します。

バージョン管理

バージョン管理は、デザインシステムに重要な機能です。チームがバージョンを切り替えられるように、デザインシステムのリリースごとに新しいファイルを作成します。そして、デザインシステムのバージョン管理には、以下のような利点があります：

• チームの準備が整い次第、最新のデザインシステムに更新できる。- ワークフローの中断を防ぐ
• チームが同じファイルで同時に作業可能
• 時間の経過に伴う変更の追跡
• 各リリースの内容のチームへの通知
• バージョン間の切り替えが可能
• 不具合を発見した際に役立つ

バージョン管理についてもっと読む：デザインのためのバージョン管理 – なぜ設ける価値があるのか？

スタイルガイド

デザインシステムは、大抵デザイナーがコンポーネントやUIデザインに使うためのスタイルガイド（通常は PDF ）から始まります。スタイルガイドは、色のHEXコード、タイポグラフィのスケール、使い方、注意点など、デザインシステムのパターンや構成要素にコンテクストや指示を与えるものです。

コンポーネントストレージ

コンポーネントのサンプルは、インタラクティブでコードスニペットが含まれているため、デベロッパーにとっては最も便利なものであり、これは、エンジニアがコンポーネントがどのように動作するかを正確に確認できるので重要です。

アセットストレージ

ロゴや画像など、デザインシステムのアセット（資産）を全てコンポーネントライブラリやドキュメントと一緒に保管し、すべてを一箇所にまとめることが重要です。

ドキュメントとガイドライン

ドキュメンテーションは、あらゆるデザインシステムの中核ともいえます。このドキュメントで、ユーザーは以下のような製品をデザインするための原則やガイドライン得られます：

• ブランドのガイドライン
• デザイン原則
• コピーガイドライン
• デザインシステムガバナンス
• デザインとコードにおけるベストプラクティス
• デザインシステムでのアクセシビリティ
• リソース
• ツール

フィードバック

どんなデザインシステムでも、バグやエラーを発見するためにチームの意見や提案を取り入れることは覚えておきましょう。デザインシステムに「問い合わせページ」や「コメント欄」があることで、フィードバックを送信することができますね。

どのデザインシステム管理ツールを選ぶべきか

ここでご紹介したツールの比較はいかがだったでしょうか？実際に使ってみて、最適なデザインシステムのツールを選びましょう。インタラクティブプロトタイピングのスピードアップ、DesignOpsの拡張、チームの連携強化でお困りの方は、ぜひUXPin Mergeをお試しください。詳しくはこちらのページにて。14日間の無料トライアルはこちらから。

The post デザインシステム 管理ツール ７選 appeared first on Studio by UXPin.

デザインシステムのガバナンスを「急成長、創造性、柔軟性を阻むもの」だと考える人もいますが、デザインとユーザビリティの一貫性を維持しながら適切に実施することができれば、デザインシステムのガバナンスはスケーラビリティと創造性を促進できるのです。

いいデザインシステムのガバナンスは、成長や利益よりもユーザーを優先させることです。また、企業文化においてもチームメンバーが従い、受け入れるガバナンスのプロセスをどのように導入するかに重要な役割を果たします。

UXチームとエンジニアリングチームのツールは、デザインシステムのガバナンスにも影響を及ぼします。UXチームは、最終製品の変更に合わせてデザインツールの更新が必要にあり、プロセスが人的エラーにさらされることになるのです。

UXPin Merge を使えば、チームは２つの別々のデザインシステムのアップデートを心配する必要がありません。UXPin Mergeは、GitレポジトリやStorybook 統合（React、Revue、Angular、Emberなどとの接続が可能）のコードコンポーネントとエディタツールを同期し、別々のデザインシステムの必要性をなくし、ヒューマンエラーを軽減しますからね。

UXPinがデザインシステムのガバナンスを強化する方法をぜひコチラからご覧ください。

デザインシステムのガバナンスとは

デザインシステムのガバナンスとは、製品のデザインシステムを維持・更新するためのプロセスやプロトコルのことです。

例えば、アプリの終了アイコンを「X」から「ー」に変えるような小さな変更であっても、何段階もの承認と実施プロセスを経ないといけません。

デザインシステムのガバナンスは、以下のような目的を果たします：

• デザインとブランドの一貫性の維持
• ユーザビリティの問題につながる誤ったデザインの決定の防止
• チームメンバーへの、創造的な思考や、変更を試みる前の手持ちのツールでの問題解決の促進
• アクセシビリティを考慮した確実なアップデート
• 組織全体への変更点の周知
• デジタル製品およびデザインドキュメントの更新

効果的なデザインシステムのガバナンスがなければ、新しいコンポーネントの編集やアップデートは、ユーザビリティの問題や矛盾を生み出して製品の評判を落とすような「無法地帯」のようになる可能性があります。

デザインシステムの維持の課題

デザインシステムの維持には多くの課題があり、どの組織でも、デザインシステムの管理者またはチームがないといけません。。

ここでは、デザインシステム維持のための一般的な課題７つと、効果的なガバナンスモデルが不可欠である理由を見ていきます。

１．社内政治

残念ながら、うまくいっているデザインシステムであっても組織内の権力闘争から逃れられるわけではありません。経営者の力を使って、デザインシステムチームの最初の決定を覆してデザインの変更の推進や阻止に働くチームメンバーがいることだってあり得ますし。

その点ガバナンスは、経営陣やその他のステークホルダーにデザインの変更とその理由を十分に伝え、賛同と承認を得やすくしてくれます。

２．複数のチームや部署からのインプットの管理

デザインシステムは、UXやエンジニアリングチームだけのものではなく、企業のデザインシステムは、製品チームやその他のステークホルダーが共有しています。

このようなインプットをすべて管理するのは、適切なガバナンスシステムがなければ大変です。

３．デザインシステムは、よく後付けやサイドプロジェクトになる。

多くの企業、特に設立間もないスタートアップ企業では、製品のデザインシステムは優先事項ではなく、UXデザイナーが暇な時や週末に行うサイドプロジェクトで、成長需要との整合性を保つために細々とやっています。

このような環境では、デザインシステムは乱用されやすく、誤ったデザイン決定が行われがちです。ガバナンスが不十分なため、UX チームがユーザビリティの問題を修正するのに変更を元に戻さなければならないといったこともよくあります。

４．お粗末なコミュニケーション

部署間、チーム間、個人間の適切なコミュニケーションがなければ、例えば２つのチームが同じ作業を別々に行うことになったり、「他の人がやっている」と思い込んで肝心のユーザビリティの変更が忘れられたりなど、デザインシステムはバラバラになってしまいます。

そこでデザインシステムのガバナンスによって、組織全体のコミュニケーションが促され、誰もが最新の情報を得ることができるのです。

５．チームメンバーの消極的な姿勢

製品のデザインシステムに難色を示すチームは、気に入った部分だけ選んで、あとは「より良いデザイン方法」を開発します。新しいメンバーや、デザインシステムの構築に携わっていない人が、「自分の方がうまくやれる」と思い込んでしまい、他の人の努力を台無しにしてしまうのです。

このような消極的な姿勢は、製品の使い勝手や一貫性に影響を与えるだけでなく、要らぬ対立を生むことにもなりかねません。

そこで抑制と均衡が複数備わっているガバナンスモデルによって、デザインシステムがチームメンバーに乗っ取られるのを防ぎます。

６．変化に対する抵抗

時にはその逆もあります。システムは今のままでいいと考え、いかなる変更も跳ね除けてしまうデザインシステムの管理者もいます。デザインシステムは決して完全なものではなく、組織の成長のために進化しなければならない、進行中の作業なんですけどね。

７．「信頼できる唯一の情報源（Single source of truth）」のジレンマ

多くの企業が、UXデザイン、プロダクト、エンジニアリングを中心としたすべての部門間で単一のデータセットを扱うという、『信頼できる唯一の情報源（Single source of truth）』のジレンマに悩まされています。

UXチームはデザインツールを使い、エンジニアはコードを使い、プロダクトチーム（技術的なノウハウが乏しい場合が多い）はパワーポイント、PDF、紙など、あらゆる種類のツールを使って仕事をします。

このようにワークフローが分散しているため、『信頼できる唯一の情報源』の維持は大変であり、全員が最新の情報を得られるようにするために、追加のスタッフやリソースが必要になることも少なくありません。ガバナンスシステムがよくても、「信頼できる唯一の情報源」のジレンマは常に付いて回る課題なのです。

世界的な決済サービスの大手である PayPal は、『信頼できる唯一の情報源』のジレンマをUXPin Mergeで解決しました。同社は、UXPin Mergeを使って、Gitレポジトリからのコードコンポーネントで内部 UI（ユーザーインターフェース）のデザインシステムを構築し、それを維持しています。

デベロッパーが新しい変更を実施すると、UXPin のデザインエディターのコンポーネントが同時に更新されるため、デザイナーとエンジニアは常に同じデザインシステムで作業することができます。

デザインシステムのガバナンス規準の確立

デザインシステムの変更や更新が必要となる主なシナリオは４つあり、そのシナリオでは、プロトタイプの作成や修正を依頼したりする前に、チームが一連の質問やテストを行う提出プロセスが必要です。

• 新要素の導入：新しい要素を追加するためのワークフローを確立することで、デザインシステムの整合性を確保しながら、各チームメンバーには追加する機会が平等に与えられます。
  
  
• パターンの推進：パターンは、「１回限りのもの」と「新しいベストプラクティス」の２種類に分類され、チームは、この新しいパターンを推進する前に、現在利用可能なものと比較してテストしないといけません。
  
  
• パターンのレビューと適応：どのデザインシステムにも、リリース前にパターンをレビューする、少なくとも２名で構成されたチームが必要です。このレビュープロセスにより、新しい要素が現在のデザインシステムの規準と実践に合致していることが保証されます。
  
  
• デザインシステムのアップデートのリリース：チームは新しいアップデートの準備ができたときにリリースするのではなく、アップデートのリリーススケジュールのきちんと作らなければいけません。厳密なリリーススケジュールを設定することで、品質保証と文書化のプロセスを正しく実行できるようになります。

このサブミットプロセスを管理するには、変更が必要なステップを全てマッピングしたシンプルな決定木の使用が効果的です。

このInayaili de León氏による優れた例では、Canonicalチームが、コンセプトからリリースまでのシンプルな決定木に従って、新しいパターンをデザインシステムに追加する方法を示します。

彼女は、デザインシステムと同様、決定木も製品の進化に合わせて更新・改良していく作業であることを認めています。

ステップバイステップのガバナンスモデル例

デザインシステム・ガバナンスのアプローチには様々な方法がありますが、ここではデザインシステムの第一人者であるブラッド・フロスト氏 にヒントを得た１０個のステップからなるプロセスをご紹介します：

１．使えるものを使う

製品チームは、現在のコンポーネント・ライブラリを使ったソリューションを見つけるためにあらゆる努力を払わなければいけません。これは、デザインシステムが十分に文書化され、誰もがアクセスできるものでなければならないということであり、現在のデザインシステムが新しい要件を満たしていない場合、チームはステップ ２に進むことができます。

２．デザインシステム（DS）チームへの連絡

製品チームはDSチームに連絡し、問題と変更案について話し合います。この場合も、DSチームと製品チームは協力して既存のソリューションを探します。デザインシステムを熟知しているDSチームは、製品チームが見落としていたものを発見することもありますが、それでもソリューションが見つからない場合、チームはステップ３に進みます。

３．その変更が単発のものなのか、デザインシステムの一部なのかの判断

製品チームとDSチームは、その修正が一度限りのもの（スノーフレーク）なのか、デザインシステムの一部なのかを判断します。通常、一度限りの変更は製品チームが担当し、デザインシステムの変更はDSチームが担当しますが、いずれにせよ、チームは変更の優先順位を決め、スケジュールを立てる必要があります。

４．初期プロトタイピング

チームが製品の変更をプロトタイプにしてテストを実施します。

５．初回レビュープロセス

DSチームとプロダクトチームは、プロトタイプとテストの結果を確認します。両チームとも異論がない場合は次のステップに進み、変更点が不足していると判断した場合はプロトタイプとテストに戻ります。

６．UX および開発テスト

デザインが最初のレビューに合格すると、UXチームと開発チームに送られ、変更が UX（ユーザーエクスペリエンス）と技術要件を確実に満たしているようにするためにさらなるテストが行われます。

７．最終確認

プロダクトチームとDSチームが再度集まり、UXと開発でのテスト結果を確認します。両チームが満足すれば、次のステップに進みます。そうでない場合は、繰り返しテストを行います。

８．ドキュメント作成とリリーススケジュール

チームは新しい変更のドキュメント化や変更履歴（例：Github）の更新、さらにリリースのスケジュール化を行います。

９．変更点のリリース：変更点のリリース、バージョン管理ガイドラインに従った製品のバージョンアップ、全チームへの通知（Slack、Asana、Trello、Githubなど）を行います。

１０．品質保証

品質保証のため、製品チームが最終的な変更点を確認します。

この１０ステップのプロセスにより、先に説明したデザインシステムに共通する７つの課題をすべて軽減できることがおわかりいただけると思います。複数の抑制と均衡により、デザインシステムはその完全性を維持しながら、変更を組織全体に伝達することができるのです。

このプロセスは、デザインシステムの多くの課題を解決しますが、抑制と均衡は人的エラーを排除するものではありません。なのでチームには、「信頼できる唯一の情報源（Single source of turh）を提供するツールが必要です。

UXPinによるデザインシステムのガバナンスの強化

UXPin Merge が、デザインとコードの間のギャップを埋めて「信頼できる唯一の情報源」を作成することで、デザイナーとエンジニアは常に同じツールで作業できるようになります。

ベクターベースの一般的なデザインツールでは、この問題は解決されず、デザイナーとエンジニアは、同じシステムを別々に更新し、同期させないといけません。

UXPin はコードベースのデザインエディターであり、Git や Storybook を介してコードコンポーネントを同期させ、プロダクトチーム、UXデザイナー、デベロッパーが同じコンポーネントで作業できるようにするものです。

最後に、プロトタイプはコードベースであるため、製品のアップデートやデザインシステムの変更に要する時間が大幅に短縮されます。

優れたデザインシステムのガバナンスを育む唯一のデザインツールをお試しになりませんか？UXPin Merge を使えば、デザインシステムを最大限に活用し、デザインコンポーネントとコードコンポーネントを全て最新の状態に保つことができますよ！

The post デザインシステムの ガバナンス とは？ appeared first on Studio by UXPin.

デザインシステムは『信頼できる唯一の情報源（Single source of truth）』として機能し、チームが製品をデザイン、プロトタイプ作成、検証、開発する際に使用する全ての要素を１つにグループ化します。

これにはパターンライブラリ、コード化されたコンポーネントライブラリ、コードサンプル、API、ドキュメントが含まれます。

組織は４つの段階で構成されるデザインシステムの成熟度を用いて、デザインシステムの「成熟レベル」を評価します。

多くの組織にとっての最終的な目標は、デザインシステムでのレベル4の成熟度を達成することです。レベル4では、コードコンポーネントを完全にデザインプロセスに取り入れることを目的とします。

しかし、実際ではこのレベルを達成するために必要なツール、システム、知識、リソースなどが不足することからレベル３で停滞してしまうのが大半です。

UXPin Mergeでは、コードコンポーネントをデザイナーが使う「ビジュアル要素」に変換させることでデザインシステムの成熟度を高めることができます。

これによって、開発フローでのデザインと開発のギャップを埋めることができます。

2024年はワークフローを見直し、コンポーネント駆動型のプロトタイピングに移行しませんか？

UXPin Mergeでは、少ないリソースでデザインシステムの成熟度のレベル４を素早く達成することができます。詳細はこちらのページをぜひご覧ください。

デザインシステム成熟度指標

UXPinには、あらゆる成熟度レベルの組織に対応可能なツールと機能があります。この包括的なツールセットを使用することで組織はレベル４の段階にすばやく進むことができます。

UXPinをレベル１および２段階で使用する場合

• レベル１：組織にはデザインシステムはないが、共通のアセットが確定されていたり、文書がいくつかある可能性がある。
• レベル２：組織にはデザインコンポーネントがあり、HTMLとCSSのガイドラインを提供できる。ただし、コンポーネントはこの時点ではコード化されておらず、開発が必要なパターンである。

UXPinをレベル３および４で使用する場合

• レベル３：組織にはライブラリが以下のように２つあり、デザインと開発は今でも別々のサイロで管理されている
  • デベロッパー向け：コードコンポーネントライブラリ
  • デザイナー向け：デザインパターンライブラリ
    
• レベル４：組織には、デザイナーとエンジニアが同じコンポーネントとドキュメントを使用可能な「信頼できる唯一の情報源（Single source of truth）」を含む完全に統合されたシステムがある。デザインドリフトをなくし、インターフェースを構築するためのコーディングや解釈は不要。

UXPinでデザインシステムをレベル１から３に拡張する

プラットフォームのナビゲーション

UXPinはコードベースのフルスタックUX/UIのデザインプラットフォームであり、デザインと開発の連携における制約をなくします。Hi-Fi（高忠実度）プロトタイプを含むアイデア出しやハンドオフといったUXプロセス全体を１つのツールで補うことができます。

デザイナーは、キャンバス上で簡単にデザインライブラリにアクセスできます。具体的には次のようなものを含みます。カラー（トークン）、テキストスタイル、アセット（アイコンやロゴ）、デザイン要素（コンポーネント）など。

そして、ドキュメンテーションはデザインシステムで欠かせない一方、その作成や管理、維持は極めて大変です。

UXPinでは、ライブラリごとにカラー、タイポグラフィ、アセット、パターンライブラリなどを含むドキュメンテーションが自動で生成されます。生成されたドキュメンテーションのページ編集や、各コンポーネントにおける使用例や使い方のヒントなどといった情報も追加することができます。

さらに、UXPinにはコンポーネント仕様ツールも含まれているので、デベロッパーはプロパティを調べたり、CSSの取得が可能になります。これは、パターンをコードで再構築する上で不可欠です。

このツールは、デザインシステムの成熟度レベルが１および２、またはチームが新しい要素やパターンを開発する上で非常に重要です。デベロッパーはUIライブラリのためにモックアップを機能的なコンポーネントに変換できるようになります。

UXPinでデザインシステムの基盤を構築する – レベル１および２での場合

デザイナーは、UXPinのフォーム、シェイプ、テキスト、ボックスツールをベースとして使ってコンポーネントをゼロから作成可能です。また、インタラクションの追加やマスターコンポーネントを単独で編集することもできます。

画像ベースのツールとは異なり、UXPinではコンポーネントでインタラクティブを追加する際に、複数のフレーム作成したり、要素の複製などをする必要はありません。例えば、マスターコンポーネントのインタラクションやプロパティを編集するだけで、デフォルト、ホバー、アクティブ、無効（disabled）など、ユーザーやシステムのアクションに応じて変化するボタンのステート（状態）を複数デザインできます。

また、UXPinのドキュメンテーションには、デザインシステムチームがビジュアルコンポーネントの横にコードサンプル（CSS、Handlebars、HTML、Javascript、JSX、Ruby、PHPなどを含む）を追加できるスペースがあります。

このような機能によって、デザインチームはデザインシステムのレベル１と２をナビゲートすることができ、UXPin内のドキュメンテーションを含む完全なパターンライブラリを使用することができます。

成熟度レベル３

パターンライブラリが完成し、デベロッパーがコンポーネントのコード化に成功すれば、この時点でレベル３の成熟度に達していることになります。

多くの組織では、このレベルを「信頼できる唯一の情報源（Single source of truth）」といいますが、実際にはライブラリと、更新または維持用のドキュメンテーションが２つあります。

レベル３はレベル２よりもかなり優れていますが、別々のライブラリを維持・更新するためには、DesignOpsにおける以下のような課題があります：

• 倍かかる時間とリソースを要する
• デザインツール、プロトタイピングツール、ドキュメンテーションなど、デザインプロセスに必要な多くのツールが必要
• 複数のプラットフォーム向けのリリースを管理していることによる更新の遅れ
• エラーと不整合
• 旧式バージョンのデザインシステムで作業するチーム
• デザインとエンジニアで別々の言語が使用される
• デザインプロセスにおけるプロトタイプの忠実性とインタラクティブ性の欠如

そしてレベル３には、多くの場合でコードがプロダクションレディではないというもう１つの課題があります。デザインシステムのレポジトリを持っている組織もいます。しかし、大半はドキュメンテーションからのガイダンスを含むコードサンプルに頼り、単一のレポジトリにホストされているコード化されたコンポーネントライブラリがない場合、開発プロセスにエラーや不整合が生じる可能性があります。

完全統合 – 成熟度レベル４

レベル４では、デザイナーは最終製品を構築するために開発者が使用するレポジトリから取得したコードコンポーネントを使います。

UXPinでは、Mergeテクノロジーによってこのコンポーネント駆動型プロトタイピングの手法が実現します。

MergeはレポジトリからUIコンポーネントを取り込み、デザインチームがプロトタイプを作成するためにUXPinでレンダリングします。

このワークフローには次のようなメリットがあります：

• 高い忠実度とピクセルパーフェクトなパリティ
• 一貫したUX
• デザインと開発の迅速化
• コードの再利用
• ガバナンスのシンプル化
• デザイナーとデベロッパー間の調和
• 真の「信頼できる唯一の情報源」

Merge統合

組織には、コンポーネントをインポートするための主な方法が３つあります：

• Git統合：パターン、バージョン管理、および Reactライブラリ専用のJSXプリセットを含むMergeの完全な機能セットへのアクセスが可能。- Reactライブラリでのみ使用可能
• Storybook統合： UXPinはVue、React、Angular、Web Components、etc.と連携可能。
• npm統合：Mergeコンポーネントマネージャーを通じてオープンソースライブラリからコンポーネントをインポートする。

ギャップの解消

従来のデザインソフトウェアでは、プロトタイプ、アセット、ドキュメンテーション、赤入れが提供されますが、これではギャップを完全に埋めることはできません。プロトタイプの忠実度はせいぜい中程度で、変換や仮説を必要とするため、製品の流出やコスト増につながる可能性があります。      

レベル４の段階になると、レポジトリからコードコンポーネントを使って、デザイン開発のギャップを埋め、『信頼できる唯一の情報源（Single source of truth）』として機能します。

UXPin Mergeはコードを変換してコンポーネントをツールセットに統合し、開発者はこれらのコンポーネントをコードで活用します。

Mergeを使うことで、仮説なしでも完全に機能、検証可能な高忠実度のプロトタイプを作成できます。

これによって、デザインと開発間のピクセルパーフェクトな整合性、デザインプロセスの迅速化、コードの再利用、そして最終的な利益の向上が保証されるのでデザイナーとデベロッパー間の連携強化や相互理解にもつながります。

Mergeの機能を理解する

コンポーネントプロパティ

Merge を通じてUXPinにインポートされたコンポーネントは、デザインシステムのレポジトリで定義されたプロパティによって駆動し、そのプロパティはデベロッパーが使用するものと同じです。

これらのプロパティは、開発者が使用するものと同じです。例えば、ボタンコンポーネントはラベル、カラー、バリアントプロパティを持ちます。これらはUXPinのPropaties Panel（プロパティパネル）で調整可能です。

実際のコードコンポーネント

UXPin Mergeのコンポーネントは実物同様のコードコンポーネントです。ホバー効果などのコンポーネントの動作はコードに内在しているのでデザイナーが設定する必要はありません。デザインプロセスにコードを使用することで最終製品との間での高い忠実度が保証されます。

アトミックデザインの手法

アトミックデザイン手法では、デザイナーは「原子（アトム）」と呼ばれる最小の構成要素から、より複雑なパターン（分子、有機体、テンプレート、ページ）までコンポーネントを構築します。

UXPin Merge では、デザイナーは、他のコンポーネントを使ってコンポーネントを構成でき、各コンポーネントで独自の設定ができるプロパティがあります。

コンポーネント構成

UXPinでは、デザイナーはコンポーネントの初期構成に制限されず、要素を追加や削除することで、コンポーネントを変更することができます。

例えば、カードコンポーネントからヘッダーの削除や、ビデオプレーヤーの追加、タイポグラフィの調整などは、すべてUXPinでできます。

JSXコードによるスペックモード

UXPinのSpecモードには、デザイナーがプロパティで設定したクリーンなJSXコードがあります。このコードは開発者はコンポーネントをデザイン通りに再現するために必要なコードに正確にアクセスできるようになります。

完全にテスト可能なプロトタイプ

コンポーネントはコード化され、固有のビヘイビア（Behaviour）があるため、UXPin Mergeで作成されたプロトタイプは完全に機能し、仮定なしでテストすることができます。この強化されたテストは、特にドロップダウンメニューやタブなどのステートを持つコンポーネントで有効です。

連携とドキュメンテーション

UXPin Mergeは、コンポーネントのドキュメント、プロパティ、ビヘイビア、ルールセットへのアクセスを提供することで、デザイナー、ステークホルダー、デベロッパー間の連携を促進します。

アクセシビリティと設定

デザイナーは、ARIA（Accessible Rich Internet Applications ） タグをプロパティとしてエクスポートすることにより、アクセシビリティのためにコンポーネントを設定することができます。また、この設定で、チェックボックスの有効化や無効化、データテーブルのフィルタリングなど、より複雑な機能を実現することができます。

データコンポーネント

従来のデザインツールでは、インタラクティブ性の点からダッシュボードやテーブルのプロトタイプ作成は不可能に近いものでした。しかし、Mergeを使用することで、デザイナーはソーティング、選択、および絞り込みができるデータグリッドコンポーネントをインポートができます。スプレッドシートからコピー＆ペースト、またはコンポーネント内のAPI連携を介してデータを入力することができます。

コンポーネント間の通信

UXPin では、コンポーネント同士を通信させることができます。例えば、ボタンは最終製品と同様に、ダイアログのコンポーネントをトリガーします。ダイアログには、その可視性を制御するopenのプロパティがあり、デザイナーはボタン（または他の要素）を使ってこれを有効化できます。

バージョンコントロール

UXPin Merge には、デザインシステムのスケーリングと将来性の確保に非常に重要であるバージョン管理機能があります。各プロトタイプはデザインシステムのバージョンにリンクしており、デザイナーはさまざまなバージョンやブランチを切り替えることができます。このバージョン管理は、新しいバージョンのテスト、さまざまなテーマでの作業、同じデザインシステムを使用する複数の製品の管理に有効です。

レスポンシブデザイン

コンポーネントにレスポンシブなプロパティがある場合、メディアクエリはUXPinに反映されます。この応答性により、デザイナーはさまざまなブレイクポイントに適応する単一のプロトタイプを作成できます。

適応性と拡張性

UXPin Mergeが提供する機能は適応性と拡張性があり、新しいバージョンのデザインシステムでプロトタイプをテストしたり、製品やクライアントごとに異なるテーマを管理したり、新しいコンポーネントで新しいデザインシステムを展開したりと、さまざまなユースケースに対応できます。

UXPin Mergeでデザインと開発のギャップを埋めることで、デザインシステムの可能性を最大限に引き出しましませんか。

コンポーネント駆動型のプロトタイプのパワーを体験し、プロジェクトの一貫性を確保しましょう。詳しくは Mergeのページをぜひご覧ください。

The post UXPinで デザインシステム を 拡張 する方法【実践ガイド】 appeared first on Studio by UXPin.

グローバルデザインシステムのコミュニティであるInto Design Systemsは、２０２３年７月にデザイナー、デベロッパー、デザインリーダー、デザインマネージャー、DesignOps実践者に向けたバーチャル会議を開催しました。講演では、ゲストスピーカーであるMarcel Bertram氏が「Systematic Design With Code（コードによる体系的デザイン） 」について語りました。

ゲストスピーカー：Marcel Bertram氏について

世界的な自動車メーカーでデザインシステムチームを率いるブランドデザイン専門家。また、UXデザイン運用のコンサルタント会社のMUDX.designの共同設立者兼UXコーチも務める。

また、ベクターとコードベースでデザインツール比較を行い、組織が「信頼できる唯一の情報源（Single source of truth）」を持つためにコードベースデザインツールの活用方法を紹介しました。このコミュニティのイニシアチブは、業界と組織の成長に役立つ知識の共有です。

本記事は、Marcel氏のInto Design Systemsの講演「The Power of Design, Code & Ai in Design Systems（デザインシステムにおけるデザイン、コードおよびAIの力）」の要約となります。

ウェビナー全体（３時間）はこちらからご覧いただけます。

主なポイント：

• ベクターベースデザインツールは、デジタル環境でのさまざまな解像度にも対応可能なスケーラビリティと鮮明さを実現するために誕生した。
• ２０１９年に開発されたUXPin Mergeテクノロジーを使用することで、デザインパラダイムに大きな変化をもたらし、コードコンポーネントをデザインプロセスに直接融合させて一貫性のあるUIライブラリを提供する。
• コードを「信頼できる情報源」として認識することで、一貫性、効率性を確保し、デザイン・開発チーム間でアプリケーションの仕組みについて全体的な理解力が深まる。
• ドイツ拠点のIT企業dotSourceはUXPin Mergeを利用して、コード、デザイン、ドキュメントを同期させてデザインと開発のギャップを埋めることに成功した。
• UXPin Mergeテクノロジーでプロトタイピングの質を高めることができ、ユーザーインタラクションの検証においてより正確なインサイトを得ることができる。

コードコンポーネントをデザイナーとデベロッパー間の「信頼できる唯一の情報源」として使ってみませんか？

UXPin Mergeを使って製品開発プロセスのギャップを埋めて、製品のリリースを高速化しましょう。

こちらからUXPin Mergeの詳細をご覧ください。

ベクターベースのデザインツールがある理由

デジタルデザインの黎明期には、フィジカルアートの精密さを再現することが求められていました。

ピクセルベース手法のように小さな点から画像を構成するのではなく、ベクターは数式を使ってグラフィックを形作ります。

その結果、画像サイズに調整を加えても正確で、柔軟な状態を保つことができます。

ベクターツールは従来のグラフィックデザインによって築かれました。業界ではAdobe Illustratorのようなツールが採用され始め、プラットフォームや解像度を問わず一貫した鮮明なデザインを提供できようになりました。

また、Webサイト、アプリケーション、デジタル広告の増加に伴い、アダプティブなデザインへのニーズが高まったことでデザイナーは自然とベクターベースのツールを使用する人が増加しました。

ベクターベースのデザインツールは、単に美的なものだけでなく、デジタル環境における実用的なニーズに応えるものだったのです。

コードベース革命

2019年に、UXPin Mergeテクノロジーが登場するまで、ベクターベースツールではデザインと開発のギャップを埋めることはできませんでした。

Mergeのコードベース手法は、コードコンポーネントをデザインプロセスに取り込むことで、デザイナーはプロトタイプに、エンジニアは最終製品での開発で同じUIライブラリを使うことができます。

ベクターベースとコード化されたデザインシステム

デジタル製品デザインは徐々にベクターベースのシステムから革新的なコードベースへとシフトしてきました。

デザインプロセスにコードが統合されたことで、デベロッパーとデザイナーの連携方法が変わり、製品開発プロセス全体の効率化に繋がりました。

次のチャプターからは、この進化をさらに深掘りしてデザインシステムとプロトタイプへの影響をみていきましょう。

ベクターベースのシステムを理解する

それは何？：

• コンピュータグラフィックスで画像を表現するために数式が使われるツールのこと。
  FigmaやAdobe Illustratorなどが有名。

メリット：

• 静的なプロトタイプとビジュアルデザインに最適
• デザイナーが直感的に視覚化し、下書きなど、すぐに変更を加えることができる

デメリット（制限）：

• 実際のアプリケーションの使用感がわかりづらい
• ユーザーとのインタラクションやトランジション、高度なコンポーネントの動作を、常に正確に模倣できるわけではない。
• コードの複雑さと可能性が見えづらい。

コード化されたデザインシステムを理解する

それは何？：

• UXPinのように、デザインキャンバス上で実際にコード化されたコンポーネントを使用するデザインツールのこと。

メリット：

• デザイナーとデベロッパーの自動更新により、組織全体にわたる「信頼できる唯一の情報源（Single source of truth)」を作成できる。
• デザインと開発のシームレスな移行。
• リアルなプロトタイプのために、コンポーネントの実際の動きなどを正確に表現する。
• より有意義なユーザーテストやステークホルダーからのフィードバック
• 複雑なプロトタイプにおいてエンジニアリングチームへの依存が減る。
• アクセシビリティ機能、セマンティクス、パスワード管理などのブラウザ機能の統合。
• 実際にコード化されたUI要素に基づく探索がしやすくなる。
• デザイナーはコードのメリットを得ながら、使い慣れたデザインツールのインターフェースで作業できる。

デメリット（制限）：

• 変更を実装できるのはデザインシステムチームのみのため、ガバナンスにおいて有益である。

「信頼できる情報源」としてのコード

最終的なデジタル製品はコードに基づいており、デベロッパーはコードを使って作業をします。

一方デザインチームはベクターベースのツールを使うため、彼らと最終的な製品の間にはギャップが生じてしまいます。

そのため、コードを中心的な参照点、つまり「信頼できる情報源」として認識することが極めて重要です。

この哲学で以下が保証されます：

• 一貫性と結束： デザイナーとデベロッパーが同じレポジトリからコンポーネントを作成することで、全体的な統一性が確保される。
• 効率性： 全員が同じライブラリや文書を参照することで、伝達ミスや食い違いが発生する余地が少なくなる。
• 深い理解： アプリケーションがどのように機能するかの「中核となるメカニズム」を理解するようデザイナーに促し、それによってより総合的なデザイン手法を促進する。

UXPin Mergeによる「信頼できる唯一の情報源（Single source of truth）」

dotSourceのユースケース

ドイツを拠点とするソフトウェア開発会社であるdotSourceはUXPin Mergeを導入する以前、製品開発フローにおいて問題を抱えていました。

新しいパターンやコンポーネントをデザインシステムに追加するには、多くの重複したプロセスが必要です。

デザインシステムのリリースのほとんどは、少なくとも以下の3か所の更新を必要とします：

1. デザインシステムのコードベース（コンポーネントライブラリ）
2. デザインチームが使用するUIキット（デザインツール）
3. デザインシステムのドキュメント

「各UIコンポーネントに”信頼できる唯一の情報源（Single source of truth）”を３つ持つのはは、直観通りにはいかず、エラーの増加につながります。このようなデザインシステムの更新プロセスとテクノロジーの整合性がとれないと、１つの変更のために３つの場所での更新が必要になります。チームは余分な作業を終始することになってしまいます。」

dotSourceは、この問題に対する唯一の解決策は、コードベースのデサインプロセスを実装し、デザインと開発の間に本当の「信頼できる唯一の情報源（Single source of truth）」の作成が必要であるとわかりました。

そこでUXPin Mergeを導入し、デザイナーはコードコンポーネントを使ってプロトタイプの作成、製品のデザインシステムをUXPinにインポートできるようになりました。

「UXPinのStorybook統合を利用したことで、デザイナーはUXPinのエディタ上ででデザインシステムの Storybookコンポーネントを使用できます。

これによって、コード、デザイン、ドキュメントの同期が全て揃ってできるようになるため、次のことを実現します：

• デザイナーの QA（品質保証）への参加および、デベロッパーのバグの特定のサポート

• デザイナーとエンジニア間の連携強化
• 高忠実度のインタラクティブ コンポーネント （コンポーネント駆動型プロトタイプ）による、テストの改善と反復の高速化」

最新のプロトタイプ – スタティック vs. インタラクティブ

静的なプロトタイプ

Figmaのようなベクトルベースのツールの使用は、複雑なインタラクティブレイヤーを使わずに静的な視覚表現を提供するため、理解度や美的感覚を測ることが目的の場合で効果的です。

デザイナーは通常、ベクターベースツールからプロトタイピングツールに移行しますが、これにはコストと運用の負担がかかり、コードに匹敵する結果は得られません。

インタラクティブプロトタイプ

コードベースのデザインツールは、より包括的な機能とユーザージャーニーテスト向けにプロトタイピングの範囲を広げます。

UXPinのようなツールで、実際のインタラクション、トグル機能、入力フィールドの動作などを再現し、よりリアル感のあるユーザー体験を提供します。

UXPin Mergeのテクノロジーは、プロトタイプの実際の使い心地を体験するために、見えるもの以上の情報を提供します。

デザインチームは、検証で得たインサイトを活用し、より正確な反復と改善を行うことができます。

デザイナーはユーザビリティを向上させ、デザインプロセスにおいてより多くのビジネスチャンスを特定することで企業価値向上にもつながります。

コードベースのデザインワークフローへの移行

デジタルデザインの世界は広大で、進化し続けています。ベクターベースツールは初期のデザイン段階では効果的かもしれません。

しかし、非効率やミスコミュニケーションを減らし、検証において正確性のあるユーザー体験を提供できることから、コード化されたデザインシステムを取り入れることが将来的に必要になるでしょう。

デザイナーとデベロッパーが連携をするなかで、最終目標はユーザー中心、効率的、見た目にも美しいアプリケーションを作成することだと覚えておくことが重要です。

そのため、適切なツールを理解し活用することは重要な選択の一つです。

UXPin Mergeでデザインシステムの成熟度を高める

UXPin Mergeは現代の製品開発フローにおける課題を解決するオールインワンのUXデザインツールを提供します。

組織間でUIライブラリやドキュメントを共有で使うためにデザイナーとデベロッパーとの完全に統合するには何年もかかるかもしれません。

組織にとって、”成熟したデザインシステム” つまり、デザイナーとデベロッパーが使用するUIライブラリやドキュメントなどを統合するには時間がかかるかもしれません。

そして大抵はそこにたどり着かずに、dotSourceのケースのように「信頼できる情報源」を複数持ってしまうことになります。

しかし、UXPin Mergeを使用することで、デザインと開発のギャップを埋めることができます。

組織は初期段階から完全統合されたデザインシステムを構築でき、リソースの無駄を省くことができるのです。

また、UXPin Mergeの使用で次のことができるようになります：

• GitやStorybookを使って、React、Vue、Angular、Ember などの Javascript ベースのデザインシステムをインポートする。
• UXPinのPatterns（パターン）機能を使って複数のデザインシステムからUI要素を組み合わせ、新しいデザインシステムのコンポーネントを作成する。
• オープンソースのデザインシステムからコンポーネントをインポートして、開発に着手する前に新しいパターンを検証する。
• 従来のベクターベースのデザインツールより８倍速くプロトタイプを構築する。
• バージョン管理を使って、デザイナーが更新とデザインシステムのバージョン履歴を管理できるようにする。
• 製品チームのためのドキュメントを作成し、すべてを１つのプラットフォームで管理する。
• JSONを介してプロトタイプに実データを使う。

ここまで読んでいただきましてありがとうございます！コードベースをメリットを実感してみたくなりましたか？

こちらのページからアクセスをリクエストし、デザインシステムにおける「信頼できる唯一の情報源（Single source of truth）」を作成しましょう。よりユーザーフレンドリーな製品体験を提供する方法をぜひご覧ください。

The post コード と デザイン ‐ どっちがより信頼できる情報源？ appeared first on Studio by UXPin.

最初に

多くのチームが、デザインシステムの作成は大変で時間のかかるプロジェクトであると想定しています。

UI監査や、デザインシステムの要素とデザインガイドラインのレポジトリの作成、組織全体が使えるようにデザインシステムを組み合わせることをチームメンバーに強制しますからね。

デザインシステムを構成する方法は、これだけではありません。デザインプロセスのスピードアップを目的としたこのツールキットには、よりシンプルな作成方法がいくつかあります。

そこで本記事では、このような目的を達成するためのデザインシステム作り方の最適なアプローチを探っていきます。

プロトタイプでデザインシステムを最大限に活用しませんか。

デザインシステムのビルディングブロックを UXPin に取り込み、デベロッパーがすぐにコードに変換できるインタラクティブなプロトタイプをデザインしましょう。

詳しくはUXPin Mergeをぜひご覧ください。

デザインシステムを 構造 する方法

デザイン要素と関連するドキュメントやガイドラインを組み合わせると、システムはブランドのUI構築に重要なことを、一貫したレポジトリとして形成していくはずです。

ただし、最適なデザイン効率とシステム効果を得るには、まず、それを識別可能な構成にアレンジする必要があります。

つまり、チームのニーズと組織のデザイン目標に最も適したものです。

では、デザインチームが使う３大 構造 をみてみましょう。

１．シンプルなビジュアルデザインレポジトリ

これはデザインシステムの最も基本的な構造です。

Nielsen Norman Groupの説明にあるように、こういったビジュアルデザインレポジトリにはさまざまな構成がありますが、ここでは「シンプルさ」に重点を置いています。

基本的なレベルでは、シンプルなレポジトリの主要なデザインシステムのコンポーネントは【スタイルガイド】、【コンポーネントライブラリ】、【パターンライブラリ】で構成されています。

これらが一体となって、機能性のあるデザイン システム レポジトリの基本要素を形成します。

この構造には、システムを構成するのに必要不可欠なものだけが含まれています。

チームメンバーに必要なものを最初から提供することが意図されているので、チームメンバーは他のアセットやドキュメントの作成や追加ができます。ちなみに、Shopify の PolarisやAtlassian Design Systemはこのタイプのデザインシステム構造を採用しています。

メリット

• 配置の作成や実施が簡単。

• デザインシステム チームがシステムの基本構造を最初から識別できるようになる。

• 意思決定が稼働中に行われ、開発が早まる。

デメリット

• この配置には、厳格なヒエラルキーが提供する構造が欠けている。

• チームは、重要な違いを無視して、デザイン システムの要素をアルファベット順や重要度順に並べる傾向がある。

• 配置の更新や維持がしにくい場合がある。

２．アトミックデザイン

『アトミックデザイン』の 構造 は、デザインシステムの提唱者であり、著者でもあるブラッド・フロスト氏によって作られた、効果的な UI デザインシステムの構築のために、秩序と構造化された階層（ヒエラルキー）を使うことに焦点を当てたものです。

アトミックデザインの方法論は、プロセスを５つのステージに分けることで、デザインシステムの構造手法です。

最初の３つは化学の世界をモデル化し、後の２つは目に見える世界の側面に関連するものになっています。アトミックデザインシステムとそのコンポーネントについては、別の記事でご紹介しましたが、ここでは最も重要な情報をまとめておきましょう。

各ステージは、前のステージを基礎としており、各階層は、前段階のものを集約して構成されています。

原子が分子を構成し、分子が有機体を構成するように、最小の構成要素から大きな構成要素に移行していくという構造です。

原子

デザインシステムの最も基本的なコンポーネント。

分子

その「原子レベル」の個々の要素がグループに結合されると、より大きな要素が見え始め、レゴのピースのように合わさる。

有機体

デザイン要素の組み合わせを分子単位で発展させることで、「有機体」ができ、より複雑なデザインシステム UI コンポーネントを形成する。

テンプレート

次のステージは、化学の領域を離れ、より「マクロ」な世界になり、有機体はテンプレートで整理されて、まとまりのあるデザインに仕上がる。

ページ

テンプレートを使ってカスタマイズすれば、１つのページができあがり、テンプレートのプレースホルダーのコンテンツをデザインのコンテンツに置き換えることで、デザインシステムの最終的な具体的な成果物が得られる。全ケースに逐一対応する必要はないかもしれないが、バリエーションをいくつか用意しておくといい場合がある。

メリット

• アトミックデザイン構造には、再利用可能なコンポーネントが利用される。チームは様々な要素を基本的な原子に分割することができ、それをさまざまな組み合わせや構成で適用や再適用ができる。

• Webサイトやアプリの中で、さまざまな要素コンポーネントを必要とする部分をチームで簡単に見つけ出し、それに応じた分子や有機体を作ることができる。

• この配置により、デザイナーはコンテンツと構造の分離をハッキリと確定するデザイン言語を使うことがができる。

• 同じコンポーネントでさまざまなバリエーションが生まれ、よりクリエイティブになる。

デメリット

• アトミックなデザイン構造では、長く複雑な部品リストになってしまう可能性がある。

• 場合によっては、コンポーネントの数が少ないと、複数のカテゴリーを用意しても意味がなく、それが、全体の方法論を複雑にする可能性がある。

３．コードベースのデザインシステム 構造 

このアプローチは、システム構造をデザインする上で最も強力で効果的な方法のひとつであり、デジタル製品や新機能の開発に携わるデザインチームに最適です。

例えばマテリアルデザインや Fluent UI デザインシステムについて考えてみましょう。

この構造により、デベロッパーが作った最終製品と同じような外観と動作をするプロトタイプを開発することができます。

これによって、デザイナーとデベロッパーの連携が促され、プロダクトチーム全体が、「信頼できる唯一の情報源（Single source of truth）」を頼りに、作業をすることができるのです。

コードベースのデザインシステムの構造は、デジタル製品のシステムデザインにおいて比較的新しいアプローチと考えられています。

デザイナーは、デジタル製品のデザインを拡張するために、デベロッパーが認めた機能的なコード化された UI 要素を採用することができるようになりました。

メリット

• この構造でデザイナーとデベロッパーの協力関係がよくなる。

• チームは、UI 要素の変更をより効果的に追跡できる。

• プロトタイプからデザインハンドオフまで、全体的な効率が上がる。

デメリット

• デザイナーがコードベースのデザインシステムの恩恵を受けるには、UXPinと Mergeテクノロジーのようなツールが必要。

• コンポーネントの作成に時間がかかる。

• デザイナーは、システム開発にデベロッパーの助けが必要な場合がある。

自分に合ったデザインシステム構造の選び方

より効率的なデザインに必要なフレームワークをチームに提供するには、正しいデザインシステムの構造を決めることが重要です。

例えば、製品デザインの目的に沿ったデザインシステム構造は、デザイナーの連携を促し、それによってデザイナーは、自分たちの能力を発揮できるデジタル製品を生み出すことができるようになります。

製品チームのニーズに合ったデザインシステム構造をきちんと選ぶために、以下について考えてみて下さい：

• 誰のためのデザインシステムの最適化なのか：組織全体の全員のためなのか、UXデザイナーのためなのか、それとも例えばフロントエンドデベロッパーだけのためなのか。

• デザインパターン、コード化された UIコンポーネント、デザインガイドラインからロールアウトプラン、ベストプラクティスのポリシーまで、どれだけのコンポーネントとコンテンツタイプをシステムに統合しようとしているのか。

• 現在使っているデザインシステムはどのような成熟段階にあるのか

効果的なデザインシステムは、成長と変化に伴う課題に適応することができるダイナミックな存在です。

デザインシステムの本来の価値は、無駄な労力を減らし、連携を促進する能力にあるのです。

UXPin がコードベースのデザインシステムのを好む理由

デザインシステムでコード化されたコンポーネントを使うことで、デザインチームとデベロッパーチームの間での共有が実現します。

それによって、デザインチームと開発チームは、「信頼できる唯一の情報源（Single source of truth）」に依存することができ、より効果的な連携が実現します。

また、組織内の各チームは、デザインやプロトタイプのプロジェクトをすべて同時に管理することができ、それによってより高度な一貫性を保つことができます。

その結果、デベロッパーはデザインパターンのデベロッパー向け言語への翻訳に集中できるようになります。

UXPin Mergeは、コードベースのデザインシステム構造を使って、「信頼できる唯一の情報源」でプロトタイプをデザインします。

これにより、デザイナーはデベロッパーのワークフローと整合性のあるデジタル製品のプロトタイプを作成することができます。

詳しくは、UXPinの Code-to-Designソリューションをぜひご覧ください。

The post デザインシステム 構造 トップ３ appeared first on Studio by UXPin.

デザインシステムは、製品のデザインプロセスを効率化し、チーム間の一貫性と拡張性を確保します。

Figma と UXPin には、それぞれさまざまなニーズに合わせた独自の機能を備えた、強固なソリューションがあります。

そこで本記事では、Figmaのチームライブラリやとその利点、そして潜在的な欠点についてお話します。

また、UXPinのデザインシステムとMergeの技術を使った、チームライブラリの代替案もご紹介します。

主なポイント：

• Figmaのチームライブラリで、デザインシステムの作成と共有がしやすくなり、それによって一貫性が保証される。

• Figmaのデザインシステムは先進的ではあるが、デザイナーとデベロッパー間のギャップを埋めるという点では課題がある。

• UXPin Mergeは、一元管理、究極の一貫性、複数のフロントエンド開発をサポートし、デザインと開発プロセスを統一するという点において、Figmaのプロトタイプ ・ チームライブラリを上回る。

UXPin の Merge技術で、組織・プロトタイプ全体 で「信頼できる唯一の情報源（Single source of truth）」を作成し、製品開発プロセスをシンプルにしませんか。詳しくはUXPin Merge をぜひご覧ください。

Figma でデザインシステムを作成できるのか

チームライブラリ機能により、デザイナーは Figma でデザインシステムを作成することができます。

さまざまなファイルやプロジェクト間で、UIコンポーネントやスタイルを公開し、共有することができます。

デザインの要素が更新されると、その要素が使われている各デザインファイルに一貫性と最新性が保たれ、それによって組織全体は最新リリースが同期された状態が保たれます。

アトミックデザインとは ‐ Figma のデザインシステムに適用するために

Figma は、ブラッド・フロスト氏の「アトミックデザインの原則」に基づき、チームライブラリを設計しました。

アトミックデザインは、UI （ユーザーインターフェース）を以下のように分解します：

• 原子： カラースタイル、ラベル、テキストスタイル、スペーシングなど、Web ページの基本的な構成要素。

• 分子： 例えばボタン、フォーム入力、チェックボックスなど、色のように原子をいくつか組み合わせ、ラベルと形をつけると分子になる。

• 有機体：複数の分子を結合させると有機体になる。サイドバーやヘッダーなど、より複雑な UI 要素になることもある。

• テンプレート： さまざまな生物を組み合わせると、ページ全体のレイアウトを形成するテンプレートができあがる。

Figma のアトミックユニット：コンポーネントとスタイル

コンポーネントとスタイルは、Figma のデザインシステムの原子単位です：

• コンポーネント： ボタンやアイコンのような再利用可能なデザイン要素

• スタイル： 色やタイポグラフィなどのデザイン仕様

この要素は、デザインシステムのチームが作成したオリジナルのファイルに存在しています。

さまざまなファイル間でアクセスできるようにするには、ファイルの所有者がチームライブラリに公開するといいでしょう。

Figma のチームライブラリにアクセスするには？

コンポーネントとスタイルを公開すると、Figma のチームライブラリで見つけることができます：

• デザインファイルを作成するか、開く

• Assets のタブから［Team Library（チームライブラリ）］をクリックして開く

• 目的のチームライブラリを検索または参照する

• ライブラリを有効にして、そのコンポーネントをアセットパネルで利用できるようにする

チームライブラリを有効にすると、デザイナーはそのコンポーネントのインスタンスをデザインファイルに簡単にドラッグ＆ドロップでき、それによってデザインの一貫性が確保されます。

Figma のデザインシステムの主な特徴

• スタイル： コンポーネントの色、文字、エフェクト、レイアウトグリッドを確定する

• 変数（ベータ）： 色値、数値、文字などの再利用可能な値を保存して、コンポーネントを半インタラクティブにしたり、明暗モードを切り替えたりできる

• バリアント： コンポーネントとパターンのバリアントとステートを作成する

• デザイントークン： デザインシステムチームが複数のデザインファイルで共有できる動的なスタイルで、変更と更新を一元管理する

• Storybook：デザイナーは、Figma のデザインをStorybookコンポーネントに埋め込むことができ、関連する Figma コンポーネントとともにストーリーをインポートして参照することができる

• ライブラリー分析： デザインシステムのチームがパターンやコンポーネントの使用状況や採用を監視できるようにする

• バージョン履歴： Figma ファイルのバージョン履歴を表示し、古いバージョンを復元する

Figma のチームライブラリを使うデメリット

Figma のデザインシステムは、デザインをシンプルにするために進化してきましたが、デザイナーとエンジニア間のギャップを埋めることはできません。

デザインシステムチームは、Figma 用とコード用の２つのライブラリを管理が必要になります。

UXPinは、２０２３年に Whitespaceと共同出版し、そこでデザインシステムの課題とその克服方法について、世界的に有名な１９社にインタビューをしたレポートを発表しました。

インタビューを行った企業では、Figma や Sketch のような画像ベースのツール を使用して いました。

筆者たちは、各組織にとっての主要な目標が「信頼できる唯一の情報源（Single source of truth）」であることがわかりました。

企業はこの目標を達成するためにプラグインやカスタムソリューションに依存し、コストを増加させ、フローを複雑にしているのです。

以下に、デザインシステムに画像ベースのツールが使われる場合での、主な問題点を挙げてみましょう：

• デザイナーと開発者は別々のライブラリ (Figma用のUIキットとデベロッパー用のコードコンポーネント) を使用するため、組織が「信頼できる唯一の情報源（Single source of truth）」を得ることはできない。

• 変更の更新には、デザインシステムレポジトリ、Figma、プロトタイピングツール、関連ドキュメントなど、複数の場所の変更が必要。

• 単一のUIライブラリを一元管理しないと、さまざまなバージョンを使っているチーム間でエラーが発生する。

• ハンドオフでは、インタラクションを説明するための長いドキュメントが必要であり、２０２３年のリリースでも、コードに匹敵するインタラクティブ性を実現できない。

• デザイナーは、プロトタイプやテストのために追加のツールやプラグインを使わなければならず、それによってコストや運用の負担、ミスの可能性が増大する。

UXPinのデザインシステムと Figmaのチームライブラリの比較

UXPinは、デザインシステムの成熟度に応じて２つのソリューションを提供しています：

• デザインシステム： コンポーネント、アセット、タイポグラフィ、ドキュメントを含むデザインシステムを作成する。

• Merge技術： レポジトリから UXPin にコードコンポーネントライブラリをインポートして、プロトタイピングとテストを行う。

UXPin のデザインシステム

UXPinのデザインシステムは、Figmaのチームライブラリと同じように機能します。

組織は、デザインシステムを作成し、チームメンバーと共有することができ、デザインシステムチームは、権限のない変更を防ぎ、システムの完全性を確保するために、権限 を設定することができます。

UXPin のビルトインデザインライブラリの活用

組織は、iOS、マテリアルデザイン、Bootstrap、Foundation など、UXPinのビルトインデザインライブラリのいずれかを基盤として使うことで、デザインシステムをサッと構築して拡張することができます。

インタラクティブ性の向上

FigmaとSketchは画像ベースのデザインツールで、デザイナーは最小限の機能しか持たない静的なプロトタイプしか作成できません。

一方、UXPinはコードで動き、ベクターグラフィックスを生成する代わりに、キャンバスは HTML、CSS、Javascript を裏でレンダリングします。

つまり、UXPinのようなコードベースのプラットフォームを使うことは、デザイナーが、完全に機能する入力要素、状態管理、複雑な UI パターンなど、最終製品のコンポーネントを忠実に模倣したインタラクティブ性を実現できるということです。

以下に、UXPinが他のデザインツールと一線を画す４つの特徴を挙げましょう：

• ステート（状態）：デザイナーは、１つのUI要素に対して複数のステートを設定し、ドロップ ダウンメニュー、タブメニュー、ナビゲーショナルドロワー などの複雑なインタラクティブコンポーネントをデザインできる。

• バリアブル：ユーザーの入力からデータを取得し、アプリバーに名前やプロフィール画像に表示され るなど、個別化された動的なユーザー体験を作成する。

• Expression： Javascript のような関数で、複雑なコンポーネントや高度な機能を作成できる

• 条件付きインタラクション：ユーザーのインタラクションに基づいて「if-then」と「if-else」の条件を作成し、複数の結果を持つダイナミックなプロトタイプを作成して、最終的な製品エクスペリエンスを正確に再現する。

UXPinの高度なコードベース機能により、企業はプロトタイプやテストに外部ツールやプラグインを必要とせず、それによってコストや重複したワークフロー、運用タスクが削減されます。

UXPinのデザインシステムは、デザインシステム成熟の初期および中期段階を支援し、Merge の技術により、組織は最終段階である完全に統合された「信頼できる唯一の情報源（Single source of truth）」を達成することができます。

Merge の技術で「信頼できる唯一の情報源（Single source of truth）」を実現する方法

Mergeの技術は、デザイナーとデベロッパーがまったく同じコンポーネントライブラリで作業するという究極の成熟を実現します。

１回の更新で、ドキュメントを含むデザインとエンジニアリングの変更が同期されるのです。

真の 「信頼できる唯一の情報源（Single source of truth）」

Mergeを使うと、組織はレポジトリから UXPinにUIライブラリをインポートできます。

そのため、デザイナーはデザインプロセスで、エンジニアが最終製品を開発するのと同じデザインシステムコンポーネントを使うことができます。

レポジトリへの変更は自動的にUXPinに同期され、最新バージョンがチームに通知されます。

この新しい UXPin Mergeのアプローチにより、より連携しやすく統合的なデザインプロセスが実現します。

デザイン、プロトタイプ、開発を分離するのではなく、UXPinを使うことで、プロセス全体を通してエンジニアリングチームと製品チームを関与させる統合フローを構築することができます。

そしてその結果、製品の最終品質は劇的に上がりました。

ー エリカ・ライダー氏、プロダクト、UX、DesignOps のソートリーダー。

バージョン管理でチームの同期を保つ

デザイナーは UXPinのバージョン管理を使って、最新リリースに切り替えるタイミングを選択し たり、必要に応じて古いバージョンに戻すことができます。デザイナーとエンジニアが同じバージョン管理で同期しているため、混乱や伝達ミスがなく、デザインシステム全体の変更履歴が１つで済みます。

Merge が Figma のチームライブラリより秀でている点

Figmaのチーム ライブラリを使う場合、組織は 2 つのバージョンのデザインシステムを維持する必要があります。

さらにプロトタイプとテストにさまざまなツールを使う場合は、さらに多くのバージョンを維持することもあります。

一方、それがMergeの場合、管理するのはデザインシステムのレポジトリのみです。

一元管理

デザインシステムチームは、デザインチームとエンジニアリングチームのためのレポジトリを一元で管理します。

この一元管理によって、チームはコンポーネントライブラリ、更新、ガバナンス、ドキュメント化、パターンの推進を完全にコントロールできるのです。

究極の一貫性

デザインシステムを一元管理することで、コンポーネントライブラリへの不正な変更を防ぐことができ、インタラクティブ性やスタイリングなどのプロパティは、コンポーネントやパターンに織り込まれます。

デザイナーがコンポーネントを取り外して調整できる Figma とは違って、Merge の要素とそのプロパティは固定されます。

デザイナーは、UXPin のプロパティパネルに表示される、デザインシステムのレポジトリで定義されたプロパティのみを扱うことができます。

デザインシステムチームは、React propsまたはStorybook Argsを使ってコンポーネントのプロパティを確定でき、デザイナーは、プロパティパネルで確認および調整をすることができます。

このような制約は、デザイナーとエンジニアが常に同じパラメータと制限の中で作業するということであり、リリースのたびにピクセルパーフェクトな一貫性がもたらされます。

MergeはUX負債と技術的負債を大幅に削減しながら、ドリフトを排除するのです。

複数のフロントエンド技術に対応

ほとんどの Javascript フロントエンド技術を 以下２つの統合機能を使って UXPin と同期させることができます：

• Git統合： Reactレポジトリに直接接続

• Storybook 統合： React、Vue、Ember、Angular など、あらゆる Storybook ライブラリを同期する

Figmaの Storybookプラグインは、componentとStoryを視覚化させるだけですが、UXPinのStorybook統合は、エディター内で完全にインタラクティブなプロトタイプを構築するためにコンポーネントライブラリをインポートします。

デザイン、プロトタイプ、テストを１つのツールで

Figmaではインタラクティブなエフェクトやアニメーションなどの制限もまだあるため、多くの企業はデザインとプロトタイプに複数のツールを使わないといけません。（例：プロトタイプに Zeplin の使用など）

一方、Mergeテクノロジーの場合、１つのツールだけで完結するので、ワークフローはシンプルになり、同時にコストも削減されるでしょう。

デザインプロセスでコードコンポーネントを使うことは、デザイナーが最終製品のような外観と感触のプロトタイプを作成できるということであり、プロトタイプの幅は広がるため、ステークホルダーやユーザーテスト参加者からのより良いフィードバックの取得に繋がります。

オープンソースのコンポーネントライブラリを使ってプロトタイプを作成して進化させる

UXPinには、Fluent UI、Ant Design、MUI、UXPin BoilerplateなどのMergeライブラリがあります。これらの使用によって、完全に機能する高忠実度なプロトタイプやテストのための MVP（実用最小限の製品）を作成することができます。

また、MergeのGit統合を使っているチームは、上記のライブラリからコンポーネントを組み合わせて、新しいパターンの構築や新しいパターンの検証できるのです。開発者のサポートなしでもデザインシステムの進化が促進されるのです。

UXPinのコードベースのソリューションを使用することで、ワンランク上の製品設計をしてみましょう。

Mergeテクノロジーを使って、「信頼できる唯一の情報源（Single source of truth）」でデザインと開発をつなげましょう。

詳細とアクセス権については、Merge のページをぜひご覧ください。

The post FigmaとUXPin【 デザインシステム 徹底比較】 appeared first on Studio by UXPin.

デザインシステムの開発および維持のための「DevOpsツール」といえば Storybookですね。優れたドキュメントや直感的なUI、さらに内蔵されたテスト、コラボレーション機能は、コンポーネントの構築や市場投入するために最適なツールです。

Storybookの仕組みを理解することで、デザイナーとフロントエンドの連携強化や、プロトタイプやテストへのデザインフロー改善のために内蔵された機能を最大限に活用することができます。

Mergeはドラッグ＆ドロップによってプロトタイプが作成可能な環境を提供します。レポジトリにあるコンポーネントを使ってインタラクティブなプロトタイプを作ってみましょう！詳しくはUXPinのStorybookページをご覧ください。

エンジニアがデザインシステムで Storybook を選ぶ理由

Storybook がデザインシステムの管理に最適なDevOpsツールであるのには、以下のような理由があります。

コンポーネントを切り離して開発およびテストをする

Storybookで、エンジニアは UIコンポーネントを分離して開発できるようになります。この開発ワークフローは、デザインシステムや多くの組織でコンポーネントライブラリに使われているReactのようなコンポーネント駆動型のフロントエンドフレームワークに最適です。

Storybook以前では、エンジニアは CodePenやCodeSandboxのようなサンドボックス（プログラムがシステムの他の部分に悪影響を及ぼすことのないように設計された環境）のプラットフォームを使って、コンポーネントを分離して構築やテストをしていました。Storybookは、このサンドボックス型の開発環境を、エンジニアやステークホルダーが UI 要素を閲覧、テスト、承認するための直感的なユーザーインターフェースで提供します。また、コンポーネントを組み合わせたり、テスト用の小さなプロトタイプパターンの作成もできます。

QA（品質保証）

分離して開発することは、デザインシステムの QA（品質保証）においても多くのメリットがあります。エンジニアは、リリース前にデザイナー、プロダクトマネージャー、その他のステークホルダーに新しい UI要素のテストやフィードバックを依頼することができます。

ドキュメント作成

コンポーネントライブラリにとってドキュメント作成は非常に重要ですが、時間を要するので、誰でも後回しにしたいと考えてしまいますよね。

StorybookのDocsPage は、基本的なドキュメント作成を自動化するzero-config（設定不要）でのデフォルトドキュメントであり、プロダクトチームやエンジニアリングチームは、このドキュメントを活用して、使い方やガイドラインの情報を作成することができます。

信頼できる唯一の情報源（Single source of truth）

クロスプラットフォームアプリケーションのコードベース管理は大変ですが、Storybook だと、一元化された環境から各プラットフォームのコンポーネントやパターンをテストするための「信頼できる唯一の情報源（Single source of truth）」が提供されます。

エンジニアはコンポーネントやパターンを並べて見ることができ、iOS、Web、Androidなど各プラットフォームを担当するエンジニアと連携できるため、一元管理された環境はデザインの一貫性を高めます。

アクセシビリティ

Storybook の A11y Accessibilityアドオンで、エンジニアはアクセシビリティテストを自動化することができます。このアドオンでは、各要素に新しいアクセシビリティタブが作成され、以下の３つのカテゴリーで WCAG （Webコンテンツのアクセシビリティに関するガイドライン）規格が表示されます：

• 違反：解決すべきアクセシビリティの問題がある
• 合格：基準を満たしている
• 未完成： アクセシビリティの ToDoチェックリストに追加

Storybook デザインシステムの活用方法

Storybookのドキュメントには、デザインシステムにおける5ステップのワークフローを紹介します：：

• ビルド
• ドキュメント作成
• レビュー
• テスト
• 分配

１．ビルド

エンジニアは Storybookをセットアップし、GitHubレポジトリに接続すると、各コンポーネントとそのバリエーションの開発を始めます。例えば、ボタンにはステートやサイズ、タイプなどいくつかありますね。

ビルドプロセスにおいて、エンジニアは Storybookのアドオンをインストールすることで、ワークフローの自動化、他のツールとの統合、Storybook 環境の拡張ができます。

２．ドキュメント作成

エンジニアは、ビルドプロセス中にコンポーネントにコメントを追加して、自動生成されるドキュメントを充実させることができます。Storybookのドキュメントにあるこの例では、このようなコメントが StorybookのUIにどのように表示されるかが示されています。

このドキュメントは、フロントエンドエンジニアがデザインをどのように解釈し、それぞれのプロップが何を表しているかをステークホルダーに示すことから、次のステップで非常に重要になります。

３．レビュー

これでコンポーネントはステージングされ、デザインシステムにする準備は整いました。エンジニアは、デザイナー、プロダクトマネージャー、その他のステークホルダーに聞いて、要素のデザインやインタラクティブ性を確認するといいでしょう。

従来は、エンジニアがステージング環境を作ったり、ステークホルダーと会ってコンポーネントをプレゼンする必要がありましたが、Storybook では、Webサイトにアクセスするのと同じくらい簡単に、レビュープロセスをより身近なものにすることができます。

そしてステークホルダーは、好きなタイミングでログインし、コンポーネントに触れ、ドキュメントを読み、フィードバックを残すことができます。

変更点があれば、エンジニアは新しいコンポーネントがステークホルダーの要望に応えるまで、ステップ１から３を繰り返すこともできます。

４．テスト

JestとPlaywright は、Storybook の「フレームワークにとらわれないテスト」を実現します。エンジニアがコンポーネントを作成すると、Storybook は、以下のようなプログラミングエラーが確実にないようにするために、コードをテストします：

• ビジュアルテスト（視覚的回帰テスト）：各コミットのスクリーンショットを作成し、それを比較することで UIの不整合を検出する。
• アクセシビリティテスト：WCAG（Webコンテンツのアクセシビリティに関するガイドライン） 基準に照らしてコードを実行し、問題があれば報告する。
• インタラクションテスト：リンクや機能に問題がないか、インタラクティビティやステートをチェックする。
• テストカバレッジ：条件、論理分岐、関数、変数など、業界標準に照らし合わせてコードを検査する。
• スナップショットテスト：レンダリングされたコードをベースラインと比較することで、マークアップの変更を特定する。

５．分配

最後は、GitHub でのデザインシステムのパッケージの更新です。完了すると、変更内容が自動的に npm に同期され、エンジニアはその更新されたnpmパッケージをインストールすることで、新しいコンポーネントを使えるようになります。

UXPin Mergeでデザインを Storybook と同期させる

デザインチームが UXPin Mergeを使っている場合、このような技術的変更はUXPinのエディター上で最新のデザインシステムのリリース内容がチームメンバーに通知されます。

バージョン管理は、デザイナーがいつでも変更でき、以前のバージョンのデザインシステムに切り替えることもできます。

UXPin Merge とは

UXPin Mergeは、デザインと開発のギャップを埋める（Mergeする）技術です。組織は、デザイナーがエンジニアと同じコンポーネントライブラリを使って、完全に機能するプロトタイプを構築することができるように、レポジトリにホストされているデザインシステムをUXPinのデザインエディターに同期させることができます。

Mergeコンポーネントは完全にインタラクティブであり、色、タイポグラフィ、ステート、サイズなど、デザインシステムで確定された Reactプロップ (StorybookではArgs) を含みます。そのプロップは、デザイナーが絶対的な一貫性と摩擦がない状態を維持しながら、プロトタイプの要件を満たすようにコンポーネントを調整することができるように、UXPinのPropaties Panel（プロパティパネル）に表示されます。

テストとステークホルダーからのフィードバックの強化

Mergeのプロトタイプには、同じコンポーネントが使われるため、最終製品のような見栄えと機能が備わっています。たとえば、Storybookのボタンは、UXPinでもインタラクティブ性やスタイリングを含めてまったく同じようにレンダリングされます。

ユーザビリティテスト参加者やステークホルダーは、このような UI要素やMergeプロトタイプを最終製品と同じように操作することができ、それによってデザインチームに正確で実用的なテストインサイトがもたらされます。

「UXPinを使うことで忠実度の高いプロトタイプを作成できるのでとても助かっています。高忠実度のプロトタイプをより早く作成・修正できて、すぐにフィードバックを得ることができます。」Erica Rider – UX Lead EPX,  PayPal「PayPalがUXPin Mergeでデザインプロセスを拡張した方法」

UXPin Patterns（パターン）によるコンポーネントライブラリの拡張

デザインシステムは、製品の成長や規模に合わせて進化していき、デザインシステムチームは常に新しい変更を加え、新しいUI要素やパターンを推進しています。

Patterns機能で、デザインチームがデザインシステムに対して新しいパターンを作成できます。デザイナーは、分子や原子単位でUI要素を組み合わせて新しいパターンを作成できます。現在のライブラリがニーズに対応していない場合は、npm統合を使用して、オープンソースライブラリからコンポーネントをインポートすることができます。

デザイナーは，このようなパターンを保存して組織全体で共有することができるため、チームは、デザインシステムチームがガバナンスの手順に従って新しいコンポーネントを開発しリリースするのを待つ間、プロトタイプを作成し続けることができます。 上で説明した５つのステップのStorybook開発プロセスに沿った作成ですね。

UXPin Mergeによる第４段階のデザインシステム成熟度

Iress は２０１７年に第３段階のデザインシステム成熟度を達成しました。その後数年間、デザインシステムチームは、最終成熟度である第４段階 – 完全統合に到達するためのデザインツールを探しました：

1. コード又はノーコードでデザインする
2. デザインドリフトがない
3. 一貫性のあるデザイン
4. シームレスなハンドオフ

Mergeは、この４つのデザインシステムの課題を以下で解決します。

• デザイナーは、スタイリングやインタラクティブなプロパティを備えた既製のコンポーネントを使うため、ゼロからデザインする必要がない。UI要素をドラッグ＆ドロップして、新しい製品をデザインすることができる。
• コードでの開発なし。エンジニアはパッケージをインストールし、まったく同じUI ライブラリを使ったプロトタイプをコピーする。UXPinは各コンポーネントのJSX をレンダリングするので、エンジニアはコピー＆ペーストでスタイリングやインタラクティビティを適用できる。
• 全員が同じ制約のもとで同じコンポーネントライブラリ（デザインチームとエンジニアリングチーム）を使用すれば、ドリフトは存在しない。
• 制約を組み込んだ同じコンポーネントを使うことで、デザインチーム間で一貫性を保つ。
• Mergeでは、デザイナーとエンジニアが同じ「信頼できる唯一の情報源」を使うので、シームレスなハンドオフが可能であり、デザイナーは UIを説明したり、プロトタイプを説明するドキュメントを延々と作成したりする必要がない。（すでに最終製品のような見た目と機能を備えているため）

UXPinは、デザインシステムの成熟度を示す４つの段階を、以下のようにわずか２つに短縮します。

1. UXPinのデザインエディタを使ってライブラリをデザイン。
2. デザインをコードコンポーネントに変換してレポジトリに追加し、Mergeを使って UXPinに同期させる。反復して拡張させていく。

デザインシステムに最適な２つのデザインとエンジニアリングツールを融合させることで、製品開発は次のレベルへ上がれます：

UXPin Merge + Storybook = 信頼できる唯一の情報源

ここまでお読みいただきありがとうございます。14日間の無料トライアルはこちらからご体験いただけます。詳細とリクエスト方法については、UXPin MergeでのStorybook連携ページをご覧ください。

The post Storybook をデザインシステム開発で活用するには？ appeared first on Studio by UXPin.

コンポーネント駆動型のプロトタイプは、UXデザインの次なるイテレーションです。デザイナーはもはやゼロからデザインすることはなく、エンジニアが書くコードはより少なくなっています。  

これによってもたらされることは、機能横断的な連携の強化、市場投入までの時間短縮、一貫性、エラーの減少、より良いテスト、ステークホルダーからの有意義なフィードバック、そしてスムーズなデザインのハンドオフが実現します。  

UXPin Mergeを使うことで、これらのメリットがすべて実現可能です。詳しくはこちらのページをご覧ください。  

 コンポーネント駆動型 プロトタイプとは

  コンポーネント駆動型のプロトタイプは、デザイナーが既製のUI（ユーザーインターフェース）要素を使ってUIを構築する製品デザイン手法の１つです。ゼロからデザインするのではなく、インタラクティブなコンポーネントをドラッグ＆ドロップしてプロトタイプを作成します。  

このデザイン手法は、フロントエンドエンジニアがゼロからコーディングするのではなく、既存のコンポーネントライブラリを使ってUIを構築するコンポーネント駆動開発に由来するものです。  

Storybookはこの開発方法でよく使用されるツールであり、エンジニアはコンポーネントを分離して構築・管理することができます。

コンポーネント駆動型プロトタイプも同様に、ゼロからデザインするのではなく、オープンソースのUIライブラリや製品のデザインシステムを使って、既製のコンポーネントでUI構築に集中することができます。  

コンポーネントは通常、色、タイポグラフィー、サイズ、スタイルなどの定められたプロパティで完全にインタラクティブであり、それによってデザイナーはプロトタイプ作成、テスト、イテレーション、デザインプロジェクトの提供をより速く、より正確に行えるようになります。  

 コンポーネント駆動型プロトタイプ の手法

  コンポーネント駆動型のプロトタイプはコンポーネント駆動開発からヒントを得たものですが、ブラッド・フロント氏のアトミックデザイン原則がデザイン手法の基礎となります。  

アトミックデザインにおいては、UI構築の際に最小のUI要素から始めて徐々に規模を拡大していく段階的な取り組み方法を採用しています。ゼロからデザインするのではなく、要素を組み合わせ、より大きなコンポーネントやテンプレート、UI（ページ）を作成します。

アトミックデザインの5つの要素には、以下のようなものがあります：  

1. 原子（Atoms）：HTMLタグ、フォント、アニメーション、カラーパレットなど、UIの基礎となる要素。デザイナーはこれらの要素を分解することはできない。
2. 分子（Molecules）：原子が組み合わさって、フォームのラベルや入力フィールドのような小さなインタラクティブなコンポーネントを作る。
3. 生体（Organisms）：ユーザビリティやアクセシビリティの問題を解決するために、デザイナーが使うインタラクティブ性の高い複雑なUIコンポーネントであり、ロゴ、検索フィールド、プライマリーナビゲーションなどが例として挙げられる。
4. テンプレート：ブログのフィード、カルーセル、導入事例、フッターなど、さまざまなウェブサイトやアプリケーションの部門の構造を定めるものであり、テンプレートには、このような大きな構造を作成するための原子、分子、生体のグループ化が含まれている。
5. ページ：ユーザーのニーズとビジネスゴールを一致させ、まとまりのあるUIを作成するためのテンプレート集を使った完全な画面。

コンポーネント駆動型プロトタイプにおける8つのメリット

1. 信頼できる唯一の情報源（Single source of truth）

  コンポーネント駆動型のプロトタイプの最も大きなメリットは、デザインと開発の連携の強化であり、デザイナーとエンジニアは、レポジトリやnpmパッケージ、Storybookでホストされている同じコンポーネントライブラリを使って作業します。  

UXPin Mergeのようなツールは、デザインと開発の間の繋がりを促し、各部門が単一のコンポーネントライブラリにアクセスできるようにします。デザインチームが視覚的なUIコンポーネントを使う一方で、エンジニアはその背後にあるコードを見るというように、同じ要素を異なる視点から見ることができます。   

2. デザインの一貫性

  この信頼できる唯一の情報源（Single source of truth）は、デザインと開発全体の一貫性の維持に優れており、インタラクティブ機能とスタイリングが組み込まれているため、デザイナーはUIコンポーネントを組み合わせてUIを作成することだけを考えればよく、色、タイポグラフィー、サイズ、境界線の半径、正しいアイコンの使い方などのバリエーションといったよくある問題を排除することができます。  

また、デザインの一貫性は、複数のチームが同じ製品に取り組む際に重要な、承認され統一されたコンポーネントやUIを受け取るエンジニアにも利点があります。

3. 共有可能

  デザインチーム間でコンポーネントを共有することで、デザインの一貫性を維持しながら、UXワークフローとデザイナーの連携を効率化することができます。  

静的なUIキットで、デザイナーはUI要素の共有ができますが、そのようなキットは忠実性と機能性に欠けています。そうなると、デザイナーが自らセットアップしなければならず、それがインタラクションデザインの矛盾やドリフトにつながります。  

そこでコンポーネントライブラリを共有すれば、デザイナーはビジュアル要素、インタラクション、スタイリング、その他デザインシステムが設定するあらゆる制約を受けることができます。  

4. よりスムーズなデザインハンドオフ

  デザインハンドオフは、デザイナーとエンジニアにとって、本来はストレスの多い、虚構に満ちたプロセスであり、デザイナーは、ツールやビデオ、ドキュメントや静的なデザインを使って、プロトタイプが「何をするはずなのか」を示します。  

UXPin Mergeでデザインハンドオフを行うと、エンジニアが同じコンポーネントを使うため、不確実性がなくなり、文書化を減らすことができます。デザイナーは、各コンポーネントのインタラクションやスタイリングのプロパティで技術的な制約を受けないようにできるので、エンジニアが再現できないデザインを目にすることはほとんどありません。  

5. 有意義なフィードバック

  ユーザビリティの参加者やステークホルダーも、コンポーネント駆動型のプロトタイプの恩恵を受けます。完全にインタラクティブなプロトタイプは、最終的な製品とその能力について、誰もが現実的に期待することができ、デザインチームは、より高い忠実度と機能性により、ステークホルダーとエンドユーザーから有意義で実用的なフィードバックを得ることができるのです。

6. より高速なイテレーション

コンポーネント駆動型のプロトタイプのワークフローにより、デザイナーはテストやステークホルダーからのフィードバックに対して、より速やかにイテレーションを行うことができます。ドラッグ＆ドロップによるデザインプロセスと簡単にできるプロパティへのアクセスにより、デザイナーはその場で変更を加えることができるのです。ちなみにPayPalは、UXPin Mergeに切り替えた後、以下のようにその効率性の向上を実感しました：

「忠実度の高いプロトタイプをより早く作り、セッション後にすぐにフィードバックが得られます。すぐに修正できることがあれば、次の参加者の前にその変更を行い、以前よりずっと早くフィードバックを得ることができます。」- PayPal, UXシニアマネージャー、エリカ・ライダー氏

UXPin Merge のユーザーはPatternのようなツールの恩恵を受け、デザインチームは1つのコンポーネントが持つ複数のバージョンを共有のパターンライブラリに保存することができます。そしてデザイナーは、UXPinのPropaties Panel（プロパティパネル）を使う代わりに、UI要素とパターンを切り替えて、より速くイテレーションを行うのです。  

7. レスポンシブデザイン機能

  レスポンシブデザインは、デザイナーにとって時間のかかる作業です。1つの画面に対して複数のレイアウトの作成が必要があり、それによってデザインプロジェクトに多大な時間が費やされることになります。そこで、レスポンシブコンポーネントを開発することで、デザイナーはプロトタイプを１つ作成するだけで、すべてのレイアウトに対応できるようになります。  

Merge のコンポーネント駆動型のプロトタイプのソリューションでは、デザイン システムチームはコンポーネントをiFrameでラッピングして、複数のビューポートに対応させることができ、デザイナーはデザインをプレビューする際に、ドロップダウンを使ってこのようなレイアウトを切り替えることができます。  

8. デザインの拡張性

  コンポーネント駆動型のプロトタイプのドラッグ＆ドロップの特性とは、非デザイナーが、画像ベースのデザインツールを使う熟練のUXデザイナーよりも、高い忠実度と機能性でプロトタイプを構築することができるということです。  

PayPalが2019年にUXPin Mergeを使い始めた際に、製品チームをトレーニングすることでデザインプロジェクトの90%を完了させることができました。UXデザイナーは製品チームを指導し、複雑なユーザビリティの問題をサポートすることで、UX専門家を増やす必要性が下がるとともに、ハイレベルなUXの取り組みに集中できるようになりました。  

コンポーネント駆動のワークフローは、学習曲線を大幅に短縮し、プロトタイプを高速化することで、非デザイナーにもデザインプロセスがより身近なものになっているのです。  

コンポーネント駆動型のプロトタイプのワークフローを導入している会社

  PayPalとTeamPasswordは、コンポーネント駆動型のプロトタイプを使って不整合を排除し、顧客にポジティブなユーザー体験を提供しています。  

PayPalが巨大な多国籍企業であるのに対し、TeamPasswordは小規模なチームで運営されていることから、今回この２社を例に選びました。  

両社とも、UXPin Mergeに切り替え、コンポーネント駆動型のプロトタイプのワークフローを採用することで、大きなメリットを得られました。  

PayPal

  PayPalは、コンポーネント駆動型のプロトタイプのとてもいい成功例です。同社はUXPin Mergeに切り替えた後、画像ベースのデザインツールを使っていたときよりも8倍速くデザインプロジェクトを完成させました。  

「PayPalで使っている別のデザインツールで、1ページのベクターベースのデザインを行い、その後、UXPinでMergeコンポーネント ライブラリを使って全く同じプロトタイプを作成しました。Merge だと、デザイナーは約 8分間でできますが、他のデザインツールでは1時間以上かかりました。」

「社内でよくある問題は、製品チームがUXデザインをボトルネックと捉えていることです。まずはそのボトルネックを取り除き、製品チームが自分たちでデザインを行えるようにする戦略を実行しました。」 – Paypal、エリカ・ライダー氏  

PayPalのコンポーネント駆動型のワークフローでは、製品開発に関わるすべての人がUXに責任を持つようになります。最も大きな影響として、コンポーネント駆動型のプロトタイプによって、PayPalの製品チームはより多くのデザイン責任を担うことができるようになった点です。  

Teampassword

  パスワード管理は、組織が顧客の確保および維持のために信頼を勝ち得なければならない、競争の激しい業界であり、デザインは、ブランドの強化や、顧客の信頼とロイヤルティを獲得する一貫したユーザー体験を生み出す上で、重要な役割を担っています。  

「お客様は私たちに「ログイン記録」という重要な情報を託しています。矛盾や時代遅れのデザインは、当社がその情報を安全に保つのに十分な最先端の技術を備えているかどうか、一部のお客様に疑念を抱かせてしまうことになります。フロントエンド開発は、バックエンドのパフォーマンスに対する信頼と自信を築くのです。」トニー・カッチャーボ氏、TeamPasswordオペレーションディレクター  

TeamPasswordはゼロからデザインする代わりにオープンソースのコンポーネント ライブラリを使い、プロトタイプとテストのためのデザイン チームは設けられてません。その代わりに、TeamPasswordのフロントエンドのデベロッパーは UXPin Merge を使って新しいUIや機能のプロトタイプとテストを行っています。  

このコンポーネント駆動ワークフローによって、TeamPasswordは製品のデザイン、テストなどが高い整合性で行うことができ、市場競争の中での運営において欠かせないものとなっています。  

コンポーネント駆動型のプロトタイプの始め方

  デザインと開発の間に信頼できる唯一の情報源（Single source of truth）を作成することはこれまで以上に簡単になります。UXPin Mergeでを使用することで、組織はコンポーネント ライブラリをインポートでき、デザイナーとエンジニアは同じ UI 要素を使えるようになります。  

コンポーネントの取り込み

  デザイナーは、UXPinのNPM統合を使ってオープンソースのコンポーネントライブラリをインポートしたり、エンジニアの協力を得て、MergeのGitまたはStorybookの統合を使って製品のデザインシステムを同期させたりすることができます。

プロトタイプ

どの方法でUXPinとコンポーネントを同期させても、デザインの流れは同じです。

• MergeのUI 要素をキャンバスにドラッグして、プロパティパネルで変更する。また、より大きく、より複雑なコンポーネントを作成するのにUXPin Pattern（パターン機能）を使って要素を組み合わせることも可能。
• コンポーネントを接続してプロトタイプを作成し、ユーザビリティテストやステークホルダーへのプレゼンテーションを行う。
• 完璧なソリューションを見つけるまで、テストとイテレーション行う。UXPinでは、【プレビューと共有】を使ったブラウザでのテストや、【UXPin Mirror】を使ったモバイルでのテストが可能。
• プロジェクトに【ドキュメンテーション】を追加し、デザインハンドオフの時にコメント機能を使ってエンジニアと共同作業を行う。

Mergeの信頼できる唯一の情報源（Single source of truth）

UXPin Mergeは組織全体での「信頼できる唯一の情報源（Single source of truth）」として機能し、それによって製品のデザインシステムの管理および拡張のお手伝いをします。さらに、コンポーネントライブラリのレポジトリに変更があると、UXPinのデザインエディタに自動的に同期され、チームに更新が通知されます。

UXPin Mergeのバージョンコントロール機能で、リリースの追跡や、デザイナーによる以前のバージョンへの切り替えができるため、アップデートを完全にコントロールすることができます。

UXPin Mergeが提供するコンポーネント駆動型のプロトタイピングを試してみませんか？詳細とこの革新的なテクノロジーへのアクセス権のリクエスト法については、Mergeのページをぜひご覧ください。

The post コンポーネント駆動型 プロトタイプとは？ appeared first on Studio by UXPin.

デザインシステム、パターンライブラリ、コンポーネントライブラリ、スタイルガイドという言葉は、よく同じ意味で使われているのを見かけます。これら４つの概念は関連していますが、同じものではありません。

また、デザインシステムとコンポーネントライブラリの違いについてもわかりづらいと思う方も多いかもしれません。デザインシステムにはコンポーネントライブラリがありますが、コンポーネントライブラリもまた、独立したエコシステムです。（例：MUIやReact-Bootstrapなど）

上記の違いが現時点でわからないという方も、ご安心ください！この記事では、これらの４つの用語を定義しながら違いをわかりやすく説明していきます。また、デザインシステムとコンポーネントライブラリの各メリットや、デザイナーと開発者がこれらをどのように使い分けるかについても解説してきます。

世界で最も種類が豊富であるコンポーネントライブラリの MUI を活用し、コード同様（code-like）な機能性を持つプロトタイプを作成することができます。こちらから無料トライアルにサインアップして、コードは1行も書かずにMUIのReactコンポーネントを使って、実際にプロトタイピングを始めましょう！

デザインシステムとは？

デザインシステムとは、UIパターン、UXデザインの原則、コンポーネントを含む、UIツールキットに関連するデザインの”基準”（スタイルガイド）とドキュメントの一式のことをいいます。この概念でデザインシステムをみたとき、デザイナーと開発者がデジタル製品を構築し、拡張するために必要なものすべてが組み込まれていることがわかりますね。

デザインシステムには、他にも以下のようなものがあります。：

• ブランドガイドライン
• アクセシビリティ・ガイドライン
• UIデザイン・ガイドライン
• ガバナンス
• ベストプラクティス
• デザインシステムのロードマップとリリース
• コードスニペット
• CSS変数とデザイントークン
• UIキット（デザインシステムにあるコンポーネントの画像ベース版）
• ダウンロード可能なアセット

パターンライブラリとコンポーネントライブラリの違いとは？

分かりにくさのもう一つの大きな原因は、「パターンライブラリとコンポーネントライブラリの違い」です。これらの用語を同じ意味で使っている人もいるかもしれません。ある意味では間違ってはいませんが、これらが全くの同じものでないということは覚えておきましょう。

各ライブラリの違いとしては、Brad Frost氏のAtomic Design方法論を使って、以下で説明していきます。：

• Atoms（アトム）： これ以上分解することができない基本的なデザイン要素。例えば、ボタン、アイコン、フォームなど。
• Molecules（分子）： ページネーションやパンくずなど。より大きなUIコンポーネントやパターンを作成するために、原子を組み合わせて作成する。
• Organisms（生物）： 原子と分子からなる複雑なUIパターン。カード、ナビゲーションバー、ロゴ、検索フィールドなどでユーザーインターフェースを形作る。
• Templates（テンプレート）： アトム、分子、有機体を含む完全なレイアウトとワイヤーフレーム。テンプレートはWebページやモバイルアプリケーションの一部に似ている。
• Page（ページ）： すべてを1つの画面にまとめたもの。

アトミックデザインを使うと、以下のようにパターンとコンポーネントを定義可能です：

• コンポーネントライブラリ（Atoms）： コンポーネントとは再利用可能なコードのブロック。単独でも複数のUIパターンの一部を構成することも可能。デザインシステム内のUIコンポーネントのコレクション。
• パターンライブラリ（Molecules & Organisms）： デザイナーがユーザビリティの問題を解決するために使用するコンポーネントのグループ。（例：ロゴ、リンク、検索フォーム、CTAボタンを備えたナビゲーターなど）。デザインシステム内のUIパターンのコレクション。

スタイルガイドとは？

スタイルガイドとは、デザインシステムのパターンや構成要素（例：色のHEXコード、タイポグラフィの尺度、使い方、注意点など）について、説明や指示を提供するドキュメントの一部です。

デザインシステムかコンポーネントライブラリどちらを選ぶべきか

MUIやReact-Bootstrapなどのコンポーネントライブラリについて話されると、余計混乱しますよね。「結局、それってデザインシステムではないのか？」と…。

これらのコンポーネントライブラリには豊富なドキュメントやガイドラインがありますが、これらはデザインシステムではありません。デザイナーやエンジニアは、これらのオープンソースのコンポーネントライブラリを好きなように使うことができます。

制限なしでライブラリのコンポーネントを（オリジナルと見分けがつかないように）編集したり、新しいパターンを構築したり、他のライブラリと組み合わせたり、カスタムでコンポーネントを作成したりすることができます。

しかし、デザインシステムではそれが異なります。デザイナーやエンジニアは、コンポーネントを構成要素として使わなければなりません。一貫性のあるUIをデザインするには、デザインシステムが持つガイドライン、スタイルガイド、方針、その他のドキュメントに従わなければなりません。

チームメンバーがコンポーネントに変更を加えたり、新しいパターンを取り入れたいなどの場合は、デザインシステムのガバナンス手続きに従わなければなりません。場合によっては、その新しいコンポーネントの構築方法について、デザインシステムチームが最終決定権を持つこともあります。

実践的な意味でのデザインシステム

デザインシステムは制約が多いように見えるかもしれませんが、これらのプロセスやプロトコルにはきちんとした理由があります。例えば、Atlassianではグローバルなユーザーベースを持つビジネスツール群を持っています。

Atlassianの最大の売りは、カスタマーサポートから営業、デザイン、開発まで、全社で一貫した一貫したエクスペリエンスを提供するために、Atlassianの製品スイートを使用し、同期できることです。

デザイナー、プロダクトチーム、エンジニアで構成されるグローバルチームでは、レベルの一貫性を実現することは困難です。そこで、Atlassianのデザインシステムでは、シームレスなユーザーエクスペリエンスのために、チームが製品をどのようにデザインしなければならないかを規定しています。

もう一つの例として、Shopifyがあります。Shopifyはサードパーティのアプリケーション、テーマ、その他連携を許可しています。これらのアドオンは、世界中のフリーランサーや代理店から提供されており、Atlassian以上に結束と一貫性を維持するのが難しくなります。

そこでShopifyは一貫したユーザーエクスペリエンスを提供するためにデザインシステムである「Polaris」を開発しました。このデザインシステムには、デザイナー向けのUI キットとエンジニア向けのReactコンポーネントライブラリが含まれています。

この場合、Polarisとは、原則、文書化されたコンテンツ、視覚的特性、および構成要素からなる完全なデザインシステムのことです。スタイルガイドは、単にデザインシステムの使用方法を説明するPolarisウェブサイト上の静的な文書です。パターンライブラリは、Polarisデザインシステムの「コンポーネント」の一部です。

この違いは微妙ですが、製品開発を改善するという点では紛れもなく重要です。スタイルガイド単体では、ドキュメントのメンテナンスが必要なため、すぐに古くなってしまいます。パターンライブラリには、一貫性のある実装のための指示と原則がありません。

デザインシステムは、すべてを結びつけるものです。

デザインシステム の構築

さて、これらの用語の意味と仕組みを理解したところで、デザインシステムの構築方法を簡単に確認しましょう。ここでは、50ページにわたる電子書籍 Creating a Design System: The 100-Point Process Checklistから、その手順を簡単にご紹介します。

1.  UIインベントリを作成するまず、現在のインターフェースで使用されているデザインパターンをすべてリストアップして説明し、そこにある矛盾点を指摘します。
2. 組織のサポートを得る: 調査結果を発表し、共通のデザイン言語の有用性を全員に説明します。Evangelizing Design Systems templates のテンプレートで説明されているように、冗長な作業で無駄になっているデザインとエンジニアリングの時間数を見積もり、製品の一貫性がNPSスコアをどのように向上させるかを説明します。
3. デザイン原則を確立する：実践方法を明確にする。ここから初めてデザインシステムのスタイルガイドに着手できます。
4. カラーパレットの構築: UIインベントリーを構築する際に、116種類のグレーの色合いを整理する必要があることがわかりました。パレットとその命名規則を作成します。
5. タイポグラフィースケールを作成する: 既存のスタイルに合わせてスケールを最適化することもできますし、黄金比や長秒針を使って調和のとれたスケールを構築することもできます。スケールを構築する際には、フォントのサイズだけでなく、ウェイトやラインハイトなどのプロパティも設定することを忘れないでください。
6. アイコンライブラリやその他のスタイルを実装する: UIインベントリーからどのアイコンをデザインシステムの一部とするかを決定し、実装を標準化 します。
7. 最初のパターンを作り始める: これは永遠に終わらない作業です。パターンは常に、製品の真実を反映したものか、近い将来の製品の理想的な状態を反映したものでなければなりません。

デザインシステムについてさらに詳しく

デザインシステム、スタイル・ガイド、パターン・ライブラリという用語を定義し、階層構造にまとめてきました。また、自社や独自のデザインシステムを構築する方法についてもここまでで簡潔に説明しました。

デザインシステムを構築するためのステップバイステップのガイドについては、50ページの電子書籍 Creating a Design System: The 100-Point Process Checklist をダウンロードしてください。すべてのアドバイスは、Marcin Treder氏が社内のデザインシステムを構築した経験に基づいています。

デザインシステムを構築した後も、上手く活用して成功するためにやるべきことがあります。そこで、デザインシステムをリリースした後に、組織で行うべきことのチェックリストはこちら。

コンポーネントライブラリの使用について

コンポーネントライブラリは、デザインチームやエンジニアリングチームに、デジタル製品デザインのためのUI要素やコンポーネントの総合的なコレクションを提供します。

コンポーネントライブラリは、デザインチームやエンジニアリングチームに、デジタル製品デザインのためのUI要素やコンポーネントの総合的なコレクションを提供します。

最も大きなメリットとして、チームはゼロから作成する必要がなく、検証済みのコンポーネントライブラリを使用して、すぐにプロトタイピングとテストを開始することができます。

世界で最も包括的で広く使用されているコンポーネントライブラリの1つであるMUI（GoogleのMaterial Design UIをベース）は、テーマによるカスタマイズも可能です。

コンポーネントライブラリはカスタマイズ可能である一方、デザインと開発の間に信頼できる唯一の情報源を提供するものであり、特に製品ライフサイクルの初期段階では難しいものです。

エンジニアと同じコンポーネントを使用することで、デザイナーはドリフトを最小限に抑えることができます。デザインのハンドオフ時に、エンジニアはコンポーネントライブラリにあるコンポーネントをコピーし、デザイナーのモックアップやプロトタイプに従って変更を加えるだけです。

コンポーネントライブラリのもう1つの大きな利点は、フリーランスのエンジニアや新興企業が製品やプロトタイプを構築する際に、プロフェッショナルなスタイルのUI要素を提供し、市場への参入や競争を容易にすることです。

デザイナーとエンジニアはデザインシステムをどのように活用できるか？

デザイナーとエンジニアは同じデザイン原則に従いますが、ガイドラインやドキュメントは異なります。

例えば、Polarisでは、デザイナーとエンジニアは、Shopify製品をデザインするための原則、ブランド要件、アプローチを理解するために、FoundationsとExperiencesに従わなければなりません。この知識は、デザインやコーディングを始める前に知っておく必要があります。

Polarisには、UIキット、Polarisツール（アイコンセット）、Polaris GitHubページ、Shopifyのブログへのリンク、追加の開発者向けドキュメント、フォーラム/コミュニティなどのリソースセクションもあります。

Polarisのコンテンツとデザインは、Shopify製品をデザインするためのデザイナー専用のドキュメントです。デザインセクションには、Polarisのデザイン言語、カラー、タイポグラフィ、イラスト、サウンド、アイコン、ステート、スペーシング、データビジュアライゼーションなどのスタイルガイドが含まれています。

開発者は、デザイン決定の背景を理解し、それに従ってレイアウトを構築するうえでPolarisのデザインドキュメントに熟知している必要があります。（特に一人で開発する場合）Componentsでは各ドキュメントを設けています。

Componentsセクションには、コードスニペットとCodeSandboxで開くためのリンクが付いたインタラクティブなコンポーネントサンプルがあります。開発者は各コンポーネントを探索し、Shopify製品を開発するためのスターターコードとしてスニペットを使用することができます。

UXPin Mergeでコンポーネントライブラリとデザインシステムを使用する

UXPin Mergeを使用すると、リポジトリにホストされているデザインシステムやコンポーネントライブラリをUXPinのエディタに同期できます。デザイナーは、UIキットを使用する代わりに、完全に機能するコードコンポーネントを使用してモックアップやプロトタイプを作成できます。

デザインシステムチームは、Git統合（React用）またはArgとMergeのStorybook統合（Vue、Ember、Angularなど）を使用して、コンポーネントのpropsを介して制約を設定し、柔軟性を提供することができます。デザインシステムチームがリポジトリを更新すると、自動的にエディタに同期され、UXPinが変更箇所を通知で知らせます。

デザイナーはUXPinのプロパティパネルでコンポーネントの調整や、JSXに切り替えてコードを直接編集することもできます。デザインのハンドオフ時には、エンジニアが各コンポーネントのJSXプロパティをコピーして最終製品を開発します。

UXPinは、コードで生成されたインタラクティブなコンポーネントによって自動でデザインシステムも生成可能です。また、スタイルガイドなどのドキュメントも含めることができ、デザイン言語全体を一か所で管理できます。デザインチームは、アセットやコンポーネントをダウンロードしてインポートする代わりに、Design Libraries Panelから必要なものをドラッグアンドドロップでレイアウトを作成できます。

こちらから無料トライアルをぜひお試しください。

The post デザインシステム、パターンライブラリ、スタイルガイド、コンポーネントライブラリの違い appeared first on Studio by UXPin.

組織がデザインプロセスを効率化し、連携を強化しようと努力する中で、DesignOpsは『デザイン目標』と『ビジネス目標』を一致させるための基盤としての役割を果たします。

UXPinは最近、３人の DesignOps エキスパートによるウェビナー「Strategies for Building Resilient DesignOps Practice（レジリエントな DesignOpsプラクティス構築のための戦略）」を開催し、そこでは貴重なインサイトと戦略が得られました。

ウェビナーでは、以下の３人の業界専門家によるパネルディスカッションが行われました：

• Salomé Mortazavi氏：SiriusXM社の DesignOpsおよびデザインシステム担当シニアディレクター
• Meredith Black氏：豊富な経験を持つDesignOpsコンサルタント
• Adam Fry-Pierce氏：Google社のUXリーダーシップ担当チーフスタッフ

知識が豊富なこの三方からユニークな視点と経験がもたらされ、DesignOpsにおける課題と機会について議論されました。

UXPinの「信頼できる唯一の情報源（Singoe source of truth）」で、効率的なタスク管理とワークフローを実現します。アクセス方法については、Merge のページをぜひご覧ください。

デザインチームの真のニーズを突き止める

レジリエントな DesignOps のプラクティスを構築するには、デザインチームの真のニーズを理解し、それに対処することが非常に重要です。デザインチームが直面する基本的な課題の１つに、デザインと全体的なビジネス戦略との整合性の欠如があり、この不整合はデザインプロセスを阻害するような、非効率性やコミュニケーションのギャップ、そしてリソース制約につながってしまいます。

共通のビジョン作り

デザインチームのニーズに対応するための極めて重要なステップは、共通のビジョンの作成であり、このビジョンの共有には、デザインチームの目標をビジネスの幅広い目標と一致させることが含まれます。組織内でのデザインの役割について共通の理解を確立することで、チームはより結束して効果的に働くことができるのです。

デザインチームのビジョンのステートメントの作成についてはこちら。

ワークフローの効率化

デザインチームをサポートするもうひとつの重要な側面は、ワークフローの効率化です。デザインチームは、断片化されたプロセスによるボトルネックや非効率によく遭遇します。そこで DesignOps が、ワークフローを効率化することで効率性を上げ、連携しやすい環境を促進することで、デザインチームがこのような課題を克服できるよう支援します。

デザインシステムの導入

デザインシステムの導入は、コミュニケーションギャップやリソースの制約に対処する効果的な方法です。デザインシステムは、さまざまなデザインプロジェクト間で一貫性を保つことができるような一連の基準とガイドラインを提供し、それによってチームメンバー間のより良い連絡と連携が促進されます。

ロードマップと成熟度モデルの整合性

ロードマップを成熟度モデルと整合させることは、デザインプラクティスの現状評価や改善領域の特定などのデザイン計画のプロセスにおいて有益です。デザインチームは、ロードマップを成熟度モデルと整合させることで具体的なマイルストーンと目標の達成に焦点を当てた取り組みを行うことができますからね。

こちらもチェック： UXPin Merge 顧客事例『Iress』：デザインツールの再想像

DesignOps のプラクティスを適切なサイズにする

DesignOpsのロードマップを組織の成熟度モデルと整合させるなど、デザインチームの特定のニーズと成熟度に合わせて運用を調整するには、DesignOps のプラクティスを適切なサイズに調整することが非常に重要です。

成熟度モデルの使用

効果的なアプローチの１つは、デザインリーダーシップチームが集まって定性的な課題やニーズ、目標について議論することによって、成熟度モデルを中心にDesignOpsロードマップを調整することです。成熟度モデルで、重点領域の概要や、テーマの特定および優先順位付けができるようになります。この調整によって、確実にDesignOpsが組織の成熟度に沿った具体的なマイルストーンと目標の達成に重点的に取り組めるようになります。

記事を読む：DesignOps の成熟度確認のためのチェックリスト

企画におけるインクルーシブデザインの提唱

もうひとつの重要な側面は、組織の企画（プランニング）のプロセスにおけるインクルーシブデザインの提唱です。デザインが主要な企画要素として認識されていないことがあるため、この認識を変えるにはデザインチームによる提唱が必要です。デザインを提唱してその価値を示すことで、DesignOps が組織の企画と意思決定プロセスにおいて、確実にデザインが重要な考慮事項となるようにすることができるのです。

内部統制とチームの成長

組織の目標に合わせるだけでなく、デザインチームのニーズに社内で焦点を合わせることが重要となります。この連携には、チームがどのように成長できるかの評価やデザイナーに開発の見通しを示す方法が含まれます。また、デザイナーが同じタイプのプロジェクトで行き詰まることもあり、彼らの成長と発展に貢献する多様な機会を提供することは非常に重要です。

デザインチームワークに関する電子書籍を読む： DesignOps First Pillar: How We Work Together.（DesignOps の第一の柱：協働の方法）

重要な部門横断的パートナーシップの特定と確立

DesignOps がうまくいくには、重要な部門横断的パートナーシップの確立が不可欠です。このようなパートナーシップによって、デザイン業務は確実に組織内の他のチームや部門の目標やインセンティブと一致できるようになります。

目標と動機の理解

部門横断的パートナーシップを確立するための重要な側面のひとつは、パートナーの『目標』と『動機』を理解することであり、さまざまなチームや部門には、それぞれの行動の原動力となる明確な目標と動機があることを認識することが非常に重要です。

この「目標」と「動機」を理解することで、DesignOps は他のチームの取り組みと連携し、共通の組織目標に向かって取り組むことができます。そしてこの連携は、DesignOps が確実により広範な組織目標と統合して、単独で運営されることがないようにするのに欠かせません。

緊急性と重要性のバランス

部門横断的なパートナーシップを確立する上でもうひとつ重要なことは、緊急性と重要性のバランスをとることです。文化を構築し、デザイナーをつなげることに力を注ぐのは重要ですが、緊急性が優先されることが多いことを認識しておくことも極めて重要です。DesignOps は、効率性を確保しながら、デザイン組織の価値を上げることに重点を置かないといけないのです。

DesignOps の規模および範囲

機能横断的なパートナーシップを確立する際には、さまざまなチームの固有のニーズを評価し、そのニーズを満たすための DesignOps の適切な規模と範囲を決定するなど、DesignOps の規模と範囲の考慮も不可欠です。

出だしに余裕を持ってチームや組織のニュアンスを理解することで、どのような種類のサポートやリソースが必要かを特定することができます。この体系的なアプローチによって、DesignOps は組織固有のニーズに合わせて確実に調整されるのです。

測定とインパクト：DesignOps のROIを説明する方法

インパクトを測り、DesignOps の ROI （投資収益率）を示すことは、組織内でその役割を説明し、デザインと部門横断チームに価値をもたらす重要な側面に焦点を当てるのに非常に重要です。

インパクトへの焦点

DesignOps を測る上で欠かせない側面の１つは、インパクトへの焦点です。DesignOps の実践者は、すべてをやり遂げたいという衝動を抑え、代わりに最も重要なことに集中しないといけません。DesignOps チームの規模とインパクトは必ずしも一致しないことを認識しておくことが重要であるため、低コストでも見返りの大きい取り組みに集中することが非常に重要です。

土台作り

DesignOps にレイヤーを追加する前に、デザインと部門横断チームの価値を促進する本質的な側面に焦点を当てることによる、強固な基盤構築が必要です。この土台を築いて組織からの賛同が得られたら、DesignOps が提供する中核的な価値を損なわないように注意しながら、追加のレイヤーを追加し始めることができるのです。

内部拡張と乗数

緊縮財政の時代には、創意工夫を凝らして取り組みの規模を拡大することが極めて重要です。これは必ずしも人員を増やす必要はありませんが、DesignOps に関心のあるマネージャーやリーダーとの提携が必要になる場合があります。また、同様にこれらに関心のあるデザインリードの機会を引き出すことにもつながるかもしれません。このような内部乗数は、必ずコストを増やすというわけではなく、取り組みを強化させることができるのです。

デザイナーの DesignOps 参加

DesignOps を拡張するもう１つのアプローチとして、デザイナーの DesignOps への参加があります。多くのデザイナーは、気づかないうちにすでにDesignOps 活動を行っているかもしれません。このようなデザイナーにDesignOps での役割を割り当てることで、組織はデザインへの理解を通して、 DesignOps の価値を上げることができます。

スコープの影響：コストセンターと収益源 – 管理範囲内のメトリクス

DesignOps の影響をスコープする際には、コストセンター（原価中心点）と収益源を通してビジネスニーズに焦点を当てることが不可欠であり、このスコープには、機能横断的な強固なパートナーシップの確立や、DesignOps の管理範囲内のメトリクスへの注力が含まれます。

ビジネスニーズへの焦点

ビジネスに価値をもたらす重要な側面を特定し、その側面に取り組みを集中させることは、影響範囲に不可欠です。DesignOps にできることがたくさんある一方で、ビジネスに最も大きな影響を与えるものに集中することが、最も大きな価値と ROI を生み出すということを認識しておくことが重要です。

部門を超えたパートナーシップの確立

強力な部門横断的パートナーシップを確立するということは、エンジニアリング、製品、技術プログラムマネージャなど、組織内の他の部門や機能との関係を築くということです。このようなパートナーシップにより、DesignOps は組織の広範なゴールと連携で、達成につながることができるのです。

投資としての人間関係

機能横断的なパートナーと個人的な関係を構築することで、DesignOps は他部門や機能の目標やニーズをよりよく理解できるようになり、DesignOps の管理範囲内のメトリクスに焦点を当てながら、調整して取り組むことができます。

時代の変化への対応

DesignOps は、たとえ緊縮財政の時代であっても、回復力性（ レジリエント ）があり、成長と発展の機会を模索することで、変化に機敏に適応できないといけません。柔軟で、回復力があることでDesignOps は世の中が変化しても、ビジネスに価値をもたらし続けることができるのです。

DesignOps × ChatGPT含む生成系AI

DesignOps のコンテクストでは、AI（人工知能）や ChatGPT のような生成系モデルは、デザインプロセスを大幅に効率化し、生産性を上げてくれます。その方法を以下に挙げてみましょう：

ルーティンタスクの自動化

AI はデザインプロセスにおけるルーティンワークや繰り返し作業を自動化し、それによってデザイナーはより複雑でクリエイティブな作業に集中できるようになります。例えば、DesignOps の実務者は、AI を使って、事前に確定されたルールやガイドラインに基づいて、デザインアセット生成、UI（ユーザーインターフェース）コンポーネント、さらにはレイアウト全体を自動化することができます。

迅速なプロトタイプ

生成系 AI モデルは、特定の入力に基づいてデザインコンセプトを生成することで、迅速なプロトタイプを支援することができます。AI を活用することで、デザインのアイデア出しやコンセプト開発の段階のスピードが大幅上がり、デザイナーはより短時間で幅広いアイデアを検討することができるのです。

ユーザー調査とデータ分析

AI は、ユーザー調査やデータ分析の支援もします。例えば、AI はユーザーの行動データを分析してパターンや傾向を特定し、デザインの意思決定に有益で貴重なインサイトを提供することができます。また、DesignOps は 、ユーザーテストを実施してフィードバックを集めることでユーザーの反応を集めて分析するような、時間のかかるプロセスを AI を使って自動化することもできます。

連携の強化

ChatGPT のような AI モデルは、アイデアを生み出し、フィードバックを提供し、様々なタスクを支援する仮想チームメンバーとして機能することで、連携を改善することができます。そしてこの AI アシスタントは、特に遠隔地や分散した作業環境において、デザインチームの効率性と生産性を上げることができます。

UXPin Merge テクノロジーでデザインワークフローのギャップを埋め、デザイナーとデベロッパーの連携を強化してみませんか？組織全体で「信頼できる唯一の情報源（Single source of truth」）を持ち、ドリフト排除、市場投入までの時間短縮、１つのツールで負債の最小化を実現しましょう。詳細は こちらのページをご覧ください。

The post レジリエント な DesignOps – 実践のためのヒント appeared first on Studio by UXPin.

新しいプロジェクトの開始時に企業が考えることの一つとして、「コンポーネントライブラリを採用するか、ゼロから始めるか 」というのがあります。メリット・デメリットの比較検討が必要であり、プロジェクトの範囲と優先順位の考慮も必要です。 その際に最も人気のあるコンポーネントライブラリの1つがMUIで、GoogleのMaterial Design UIを最初にモデル化された包括的なReact UIライブラリです。

今回はMUIについてみていきましょう、なぜMUIを使いたいのか、他のコンポーネントライブラリとの違いは何か、そして次のプロジェクトのデザインの始め方ついてお話します。 コードでデザインってどんな感じだろう、と思ったことはありませんか？

UXPin Mergeは、コードコンポーネントをレポジトリからUXPinのエディタに同期させる画期的な技術です。この強力なツールにより、デザイナーは一行のコードも書かずに、きちんと機能するコードベースのプロトタイプを作成することができます。Merge の詳細と、次のプロジェクトのためのアクセス要求方法についてご覧ください。

また、UXPinのトライアルでは、コードコンポーネントを使ったデザインがどんな感じか試すことができ、トライアル中にMUI 5キットを用意していますので、MUIを間近で体験することができます。14日間の無料トライアルに登録して、MUIをぜひご利用ください。

MUI とは

MUIは、デザイナーやデベロッパーがReactアプリケーションを構築するのに使えるUIコンポーネントの巨大なライブラリです。このオープンソースプロジェクトは、コンポーネント作成のためのGoogleのガイドラインに従っており、基礎的なUI要素と高度なUI要素のカスタマイズ可能なライブラリが備わってます。 また、MUIはReactのテンプレートやツールを販売しており、プロジェクトに合わせて微調整できる既成のユーザーインターフェースがあります。

MUI のような コンポーネントライブラリ を使う理由

デザイナーは、新製品の開発や既存プロジェクトの機能追加にUIキットを使用することがよくありますが、これらのライブラリにより、デザイナーは必要なコンポーネントをドラッグ＆ドロップして、さっとインターフェースのデザインができます。

MUIコンポーネントライブラリを使用する7つの理由を探ってみましょう。

1. 市場投入までの時間を短縮

競争の激しい今日のテク環境において、市場投入までの時間は、企業が常に最適化を求めるメトリクスとなっています。コンポーネントライブラリを利用することで、デザイナーやデベロッパーは、すぐに使える徹底的にテストされたUI要素で、大きな幸先のいいスタートを切ることができます。

デザイナーは、要素をドラッグ＆ドロップしてユーザーインターフェースを構築し、製品やブランドの要件に合わせてコンポーネントをカスタマイズすることができます。

デザインチームは、UIコンポーネントをゼロから構築してテストすることに煩わされることなく、優れたカスタマーエクスペリエンスのデザインにより多くの時間を費やすことができ、市場投入までの時間が大幅に短縮されます。

デザイナーがプロトタイプの作成、テスト、反復を速くできるため、ユーザビリティテストはずっと速くなります。テスト中にユーザーインターフェースがうまく機能しない場合は、膨大なライブラリからその場で変更を加え、参加者やステークホルダーから即座にフィードバックを得ることができます。

デザインハンドオフでは、エンジニアはコンポーネントライブラリをインストールし、プロトタイプやスタイルガイドからの変更をコピー＆ペーストすることで、ゼロから始めることなく製品を開発することができます。

2. 信頼できる唯一の情報源（Single source of truth）

信頼できる唯一の情報源（Single source of truth）の維持は、デザインシステムのガバナンスにおける最大の課題の1つです。製品チーム、UXデザイナー、およびデベロッパーが、同期していないデザインシステムを使用していることは珍しいことではなく、その結果、エラーや再作業が発生し、DesignOpsは大きな課題に頭を抱えることになります。

MUIのコンポーネントライブラリを使用することで、デザインと開発の間に信頼できる唯一の情報源（Single source of truth）を作成しながら、こういった課題を大幅に減らすことができます。デザイナーとエンジニアは別々のデザインシステム（デザイナーは画像ベース、エンジニアはコードベース）を持つことになりますが、MUIは彼らに同じスタートブロックを提供します。

UXPinのコードベースエディターでMergeを使用すると、デザイナーとエンジニアは同じデザインシステムのコンポーネントを単一のレポジトリで同期して使用します。レポジトリが更新されると UXPin に同期され、デザイナーに変更点が通知されます。Reactコンポーネント ライブラリにはGitを、その他の一般的なテクノロジーにはStorybookを使用してMergeを接続できます。

3. デザインの一貫性

一貫性は、ユーザーエクスペリエンス、信頼の構築、ブランドロイヤリティには欠かせません。同じUIコンポーネントを使用することで、デザイナーは一貫性を高め、エラーや手戻りを最小限に抑えることができます。

4. 拡張性

拡張性もまた、製品デザインの重要な要素です。ゼロからデザインシステムを構築する場合、デザイナーは製品をスケールアップする前に、新しいコンポーネントのデザイン、プロトタイプの作成、テストが必要です。

MUIの包括的なUIライブラリにより、デザイナーはプロトタイプに必要なコンポーネントを検索して、すぐに拡張することができ、エンジニアは、MUIから同一のReactコンポーネントをコピー＆ペーストし、デザイナーの仕様に合わせてカスタマイズできます。

MUI Xには、データグリッド、日付ピッカー、チャート、ページネーション、フィルタリングなど、複雑な製品をより速く拡張するためにチームが使用できる高度なReactコンポーネントのライブラリが含まれています。

5. 容易なメンテナンス

MUIのようなコンポーネントライブラリには、コンポーネントのインストール、使用、更新、カスタマイズのための詳細なドキュメントが付属しています。デザイナーやエンジニアは、このフレームワークを使って企業のデザインシステムの維持ができ、ガバナンスシステムやプロトコルを簡単に確立することができます。

また、MUIには、あるバージョンから次のバージョンへの移行のためのハウツーガイドもあるので、企業はMUIがアップデートをリリースするたびに、最新のUIスタイル、テクノロジー、トレンドを利用できます。

6. アクセシビリティ

デザインシステムを設定した経験のある方は、すべてのコンポーネントがアクセシビリティ基準をクリアするのに必要な時間と費用をご存知でしょう。MUIのデザイナーは、WCAD 2.0のアクセシビリティ・ガイドラインを満たすようにコンポーネントをデザインすることに細心の注意を払い、研究者やデザイナーの負担を軽減しています。

ただし、アクセシブルなコンポーネントを用いてインターフェースをデザインする場合でも、ナビゲーションやユーザーフローをテストして、製品全体がアクセシビリティの基準を満たしていることの確認が必要であることに留意することが重要です。

7. スキルの強化

MUIのオープンソースコンポーネントUIライブラリは、スタートアップ企業や若い起業家が新製品を開発する際に、特に教育、指導、技能伝授を受けられない発展途上国において、その能力が発揮されるようにします。

また、チャリティ団体、非営利団体、NGOなど、製品やツールを開発したいがデザインシステムに投資する予算がない場合にも、このライブラリーは非常に有益です。 誰でもMUIの優秀なデザイナーやデベロッパーのスキルを活用し、フォーチュン500社で使用されているのと同じコンポーネントライブラリを使用して、洗練されたデジタル製品を開発し、グローバル市場で競争することができます。

MUIが他の コンポーネントライブラリ と異なる点

GoogleのMaterial Design UIは、間違いなく世界で最も優れた、最も包括的なデザインライブラリの1つであり、MUIは、Material Designの上に構築することで、それに匹敵するReactコンポーネントライブラリを提供します。

MUIはTheming機能で簡単にカスタマイズでき、ライブラリのドキュメントも充実しているため、多国籍企業や製品アイデアを持つ一人のデベロッパーでも製品の構築が可能です。 MUIは非常に広く使われているため、デザイナー、研究者、デベロッパーからなる大規模なグローバルコミュニティが存在し、指導やサポートを受けることができます。

Reactが最も人気のあるフロントエンドフレームワークの1つであるという事実も加わり、MUIは魅力的なコンポーネントライブラリとなっています。

興味深い事実と数字

ここでは、MUIの興味深い事実と数字をご紹介します。 注：MUIの統計は上昇を続けており、これは、2022年1月時点のものです。

• MUIは、Googleと差別化するために名称を変更することにして、2014年にMaterial UIとしてスタートしましたが、多くの人がMaterial UIはGoogleの製品だと思い込んでいるようでした。
• MUIには2,200人以上のオープンソースの貢献者がいます。
• GitHubで73,700スター以上獲得しています
• MUIが実施した2020年調査の回答者1,488人のうち、35％のデベロッパーが従業員5人以下の企業で働いていました。
• 調査では、27％のデベロッパーがエンタープライズ・アプリケーションにMUIを使用し、20％が管理者用ダッシュボードにライブラリを使用しています。

UXPinのMUI5キット

UXPin MergeのMUI統合で、UI Reactコンポーネントでプロトタイピングの力が発揮されます。 MUIは、きちんと機能するコードコンポーネントでのデザイン作成をサポートします。信頼できる唯一の情報源（Single source of truth）により、デザイナー、デベロッパー、製品チームなどは、エラーや摩擦を減らし、より効果的にコラボレーションを行うことができます。 忠実度が高いほど、参加者とステークホルダーから有意義なフィードバックを得られるような、より良いユーザビリティ・テストとなります。

その結果、全体的なユーザー体験が向上し、ビジネス価値が高まります。 UXPinのMUIキットの詳細と、この画期的なコードベースのデザイン技術へのアクセスをリクエストするための申し込み方法についてご覧ください：UXPinのMUIライブラリ：より速くデザインする。

UXPin Mergeによるコンポーネントライブラリの同期

UXPin Mergeで、Gitレポジトリ、Storybook、またはMUIからコードコンポーネントを同期し、実際のコードで完全に機能する高忠実度のプロトタイプの構築ができます。 メニュー、フォーム、タブ、データテーブル、日付ピッカー、アコーディオンなどの複雑なUIコンポーネントは、UXPinのコードベースエディタに機能が搭載されており、デザイナーは、ユーザーインターフェースの構築に必要なMUIコンポーネントをドラッグ＆ドロップします。

標準的な画像ベースのデザインツールと同じように、コンポーネントのプロパティパネルを調整することができます。 UXPin Mergeの優れた点は、デザイナーがコードベースのコンポーネントを使用してデザインするのに、新しいスキルセットを学んだり、コードの書き方を知る必要がないことです。

ワークフローは変わりませんが、プロトタイプの忠実度と機能性が大幅に向上します! デザイナーが Merge を使用せずに UXPin を使用する場合でも、ステート、Javascriptのようなインタラクション（条件付きインタラクションを含む）、変数、エクスプレッション、オートレイアウトなど、コードベースの高度な機能を利用できます。

The post MUI とは？MUIについて何を把握すべき？ appeared first on Studio by UXPin.

最初に

複数のツールにまたがって開発を効率的に行うには、コンポーネントライブラリの利用を検討するのが賢明です。

プロダクションレディで、カスタマイズ性があり、再利用可能なコードコンポーネント（例：ボタン、アコーディオンなど）にアクセスできるオープンソースリポジトリがあることで、UI／UXデザイナーは開発の高速化と成長を実現できます。

主なポイント（概要）

• コンポーネントライブラリは、事前に構築・検証済みの十分に文書化されたUIコンポーネントのセットであり、製品のUI全体で簡単に再利用できる。

• コンポーネントライブラリにより、製品の一貫した LnF（ルック＆フィール）が保証され、効率性と拡張性が促進される。

• コンポーネントライブラリを使うことで、デザイナーと開発者は全体的なデザインの一貫性を保ち、新しい機能やページを素早く追加できる。

デザイナーとエンジニア間で「信頼できる唯一の情報源（Single source of truth）」を作成しましょう。

UXPin Mergeを使って、コンポーネントライブラリをデザインツールに取り込んでみましょう。

インポートした要素を使用することで、インタラクティブなプロトタイプが簡単に構築可能です。

UXPin Mergeについての詳細はこちらより。

コンポーネントライブラリとは

UIコンポーネントライブラリは、Webサイトやアプリケーションなどのデジタル製品向けに、統一感を持たせるために使用される、デザインおよび事前構築済みの ユーザーインターフェースの要素のコレクションです。

ライブラリには、様々なUI要素（例：ボタンやフォーム、ナビゲーションメニュー、アイコンなど）があらかじめ備わっており、各要素は一貫したルック＆フィールでデザインされています。

また、UIコンポーネントライブラリは、チームメンバー間で「信頼できる唯一の情報源（Single source of truth）」を確実に使うことができます。

これによって、最終製品がプロフェッショナルで洗練された外観を確実に維持できることから、協働デザインおよび開発環境において有益です。

コンポーネントライブラリ には「信頼できる唯一の情報源（Single source of truth）」がある

コンポーネントライブラリによって、仕上がりのばらつきや、さまざまなコンポーネントが色々な場所に配置されてしまうというリスクが下がります。

コンポーネントライブラリでは、UI要素のソースコードを扱い、通常はCSSとJavaScriptを使用します。

Reactは、よく使われているオープンソースのフレームワークの代表例であり、Facebookによって「コンポーネントライブラリ」として開発されました。

それ以来、アプリ、静的サイト、デスクトップアプリケーションを作成するための大規模なエコシステムに成長しました。

コンポーネントライブラリ を使う利点

アクセシビリティ

コンポーネントライブラリは、既製の再利用可能なコンポーネントを格納する単一のレポジトリとして、あらゆる開発者やデザイナーに迅速なアクセスを提供する。

チームを超えて働く開発者やデザイナー間の連携や連絡が改善される。

重複コードを削減

さまざまなデザインやプロジェクトで重複コード（コードクローン）がよく起きるが、コンポーネントライブラリを使うことでピクセルを全てコードに変換する必要はなくなる。

代わりとして、すでにコード化されたコンポーネントを使うことができる。

一貫性

コンポーネントライブラリを使うことで、「信頼できる唯一の情報源（Single source of truth）」が促進され、プロジェクト全体で一貫したUI／UXを可能にし、統一性を出しやすくなる。

全体的な作業の高速化、効率化につながる。

スピード

ボトムアップ型手法での構築を避けることで、チームの時間が節約される。

UIの作り直しやデザインする代わりに、すでにあるUIを使うことができる。

既製のコンポーネントを使用することで、これまで時間を要した意思決定のプロセスを省略できる。

互換性

フロントエンドデベロッパーは、クロスブラウザやクロスデバイスの互換性の確保が大変な時があるが、コンポーネントライブラリを使用して標準化することによって非互換性の回避が可能。

コンポーネントライブラリを使うベストタイミング

コンポーネントライブラリでプロジェクトに測定可能な価値が加わる特別な状況がいくつかあります。

では、それがどのようなものか見てみましょう。

コード優先のプロトタイプ

ビジュアルデザインよりも機能性を重視するプロジェクトは、コンポーネントライブラリの恩恵を受けやすく、さらに、コードによるプロトタイプは、画像から始めてコードに変換するよりも効率的です。

なので、デベロッパーが画像ベースのデザインを解釈してコードを作成するのを期待するのではなく、既製のデザインからコードコンポーネントを取り入れるだけでいいのです。

これにより、デベロッパーはデザインスキルの不足を心配することなく、事前に構築されたコンポーネントを使ってデザインできる機会も広がります。

自分で作る技術や経験がない場合

独自のコンポーネントライブラリの作成や、独自のエンタープライズデザインシステムの一部としてのコンポーネントライブラリの開発を夢見ているかもしれませんが、再利用可能なUI コンポーネントの構築の経験がチームになかったり、プロジェクトの締め切りが厳しかったりすると、これは現実的ではないかもしれません。

その代わりに、統合されたコンポーネントライブラリだと、デザイナーやデベロッパーがデジタル製品に変換する前に、機能性、使いやすさ、デザインをテストするのに必要なコードコンポーネントをすべて得られます。

小規模な企業やチームの場合

スタートアップ企業や中小企業では、資金繰りにもっと慎重になる必要があるかもしれません。また、効果的で汎用性の高いオープンソースのコンポーネントライブラリが幅広く存在するため、中小企業でも一歩ずつ規模を拡大することができます。

結局のところ、業界の巨大勢力が一夜にしてそこに到達したわけではなく、その多くは、その進化を通して、オリジナルのコンポーネントライブラリにこだわり続けているのです。

拡張に役立つ優れたツール

もし、コンポーネントライブラリがどのようなメリットをもたらすのかがまだハッキリしないのであれば、以下のポイントを考えてみてください：

• デベロッパーがプロジェクトごとに同じコンポーネントを、多少の違いはあるものの構築しているのを見るか。
• インターフェースでどのUIやUX規約を使うべきかを迷っているデベロッパーはいるか。
• アップデートや変更の迅速なリリースが必要か。
• 多くのカスタマイズが必要か。
• デザインシステムとコンポーネントライブラリの組み合わせを探しているか。

上記質問のいずれかに当てはまるものがあれば、以下のツールのいずれかをご検討ください。

１．Mergeコンポーネントマネージャー

Merge コンポーネントマネージャーは、UXPin で React の UI コンポーネントを管理するためのデザイン操作ツールであり、独自のコンポーネントライブラリを持ち込んで、コンポーネントマネージャーを使ってコンポーネントのプロパティを管理することができます。

これはアクティブな開発サポートが不足している場合に最適です。

UI コンポーネントをアップロードすると、それを使って UXPin で UI をデザインできます。

コンポーネントは React でコーディングされているため、UXPin で完全なインタラクティブ性が発揮されます。

２．npm統合

コンポーネントライブラリから UXPin に UI コンポーネントを取り込む方法の1つに、NPM パッケージの統合があります。

コンポーネントのインポートに必要なのは、ライブラリ名だけです。

その後は、Merge のコンポーネントマネージャーを使って プロップ を設定し、説明などを記述します。

npm 統合についての詳細はこちらをご覧ください。

３．Storybook統合

Storybook は、１５のさまざまなフレームワークで UI コンポーネントを開発するためのオープンソースのツールです。

中でもReact、Vue、Angularは最もよく使われているフレームワークです。

これはコード化されたデザインシステムとコンポーネントライブラリを組み合わせたもので、効果的なコンポーネントとページの開発、テスト、ドキュメンテーションのためのサンドボックスとして機能します。

そしてデベロッパーは、視覚的なアプローチよりも効果的なコンポーネント駆動型のアプローチを取ることができます。

また、Storybook はデベロッパーが使うものであることから、デザインにも役立つ UXPin との統合があります。

UXPin Merge の技術があれば、Storybook を UXPin エディタと同期して、コードコンポーネントでデザインすることができ、すぐにアクセスできるように、完全に機能する要素はUXPinでのUIライブラリの１つとして表示されます。

４．MUI統合

MUI（Material UI）コンポーネントを使用し、デザインからハンドオフ、及び開発プロセス全体の流れの最後まで一貫性を確保します。

CSSユーティリティでReactフレームワークを簡単にカスタマイズし、求めるデザインを追及できます。

革新的なMerge技術を使って、コードでデザインする１番手になろう

コンポーネントライブラリで、開発の標準化やコードの重複の減少、チーム間の連携の改善およびスケーラビリティ推進のチャンスがもたらされます。

また、プロジェクトの成果物やチームのモチベーションに大きな影響を与えるため、ニーズに合ったソリューションを選択することが重要です。

ただ、デザインの一貫性と開発生産性の向上を目指している場合、UXPin の Mergeの技術には、Storybook統合の独自のポイントだけでなく、デザイン内のコンポーネントを管理するための独自のツールである Mergeコンポーネントマネージャーもあります。

こちらから UXPin Merge の詳細をぜひご覧ください。

The post コンポーネントライブラリ とは？なぜUI開発に使う必要がある？ appeared first on Studio by UXPin.