グローバルデザインシステムのコミュニティである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.

Reactのデザインシステムをゼロから構築するには、慎重な計画と配慮が必要です。

組織とエンドユーザーに役立つコンポーネントライブラリを作成するには、複数の部門と利害関係者からの意見が重要になります。

そこで本記事では、Reactデザインシステムについての基礎について解説し、コンポーネント開発、ドキュメント、ガバナンス、デザインツールなどのアプローチ方法について見ていきます。

また、デザインシステムの構築において覚えておくべきポイントを１２項目にまとめたデザインシステム構築のステップバイステップガイドの内容も含めてご紹介します。

主なポイント

• Reactデザインシステムは、ReactJSを使用して構築された、再利用可能なコード化されたコンポーネント、開発ガイドライン、アセットのコレクションのことを言う。
• Reactデザインシステムのコンポーネントには、あらかじめビルドされたボタン、フォーム、ナビゲーションメニュー、カード、その他のユーザーインターフェイスが含まれる。
• Reactデザインシステムを始めるにあたり、オープンソース（例：MUIやFluent UI）のReactコンポーネントを使用するか、ゼロから構築できる。
• プロトタイピングでReactデザインシステムを使用するためのベストなツールの1つとしてUXPin Mergeがある。

UIコンポーネントをUXPinに取り込み、Reactデザインシステムをベースにデザイン性の高いプロトタイプを作成することができます。アプリ制作が10倍速くなり、開発フローをスピードアップしましょう。

詳しくは、Mergeのページをご覧ください。

Reactデザインシステムとは？

Reactデザインシステムは、Reactアプリを構築するための再利用可能なReactコンポーネントとデザインガイドラインの集まりです。一貫性があり、スケーラブルで、メンテナンスしやすいユーザーインターフェースの作成と維持に役立ちます。

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

React デザインシステムの使用や構築には、多くの利点があります。

React のコンポーネント駆動型の開発手法は、デザインシステムに最適なモジュール形式の UIライブラリとなっており、フロントエンジニアは、React のコンポーネントを原子まで分解して、それを組み合わせて新しいUI要素やパターン、テンプレートを作成することができます。

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

• 質問や問題解決ができる、エンジニアの大きなコミュニティ
• 豊富な Javascript ツールや統合機能
• インスピレーションの源となる、多くの定評のあるデザインシステム

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

以下は、デザインシステムに React を採用している企業の一部です：

• Instacart – Snacks
• Shopify Polaris
• Atlassian – デザインシステム
• Salesforce Lightning
• IBM – Carbon Design System
• Microsoft – Fluent UI
• Google のマテリアルデザインに構築された MUI (Material UI)

コンポーネントのシンタックス、ドキュメント、ガイドラインなど、デザインシステムの要素を学ぶために、このようなデザインシステムをチェックすることをお勧めします。

デザインシステムのアイデアの参考として、Adeleをチェックしてみてください。

公開されているデザインシステムとパターンライブラリのレポジトリであり、ダウンロードや分析ができる GitHub レポへのリンクがあります。

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

アトミックデザインの原理についての理解

アトミックデザインとは、ブラッド・フロスト氏が考案したシステムであり、UI要素を以下５つのカテゴリーに分類します。：

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

React デザインシステムでアトミックデザインが重要な理由

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

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

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

React コンポーネントは、UI やアプリの一貫性、再利用性、保守性を確保するための構成要素であり、このような UI要素は、以下のような多くの重要な役割を果たします：

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

デザイントークンの重要性

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

デザイントークンは、複数のプラットフォーム用に多くの値を含むことができます。

例えば、UXPinのホームページでは、CTAに黄色を使用していますが、この黄色のヘックスコードは#FCC821で、以下のような方法で表現できます：

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

UXPinでは、上記4つの値すべてを1つのデザイントークンにカプセル化できます：

• cta-background-primary

つまり、この色をプラットフォームで実装する場合は、コードの代わりにトークンを使います。

また、「あるチームはHEXを参照、別のチームはRGBを参照、別のチームが8進数を参照する」というような、ミスや混乱を招くようなものではなく、全員が同じ言語を使用することから、デザイントークンの使用によって部門間連携が強化します。

デザイントークンで、デザインシステムチームは、トークンファイルのプロパティを変更するだけで製品全体の変更を実施できるようになります。

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

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

表面的には、デザインシステムはシンプルに見えますが、実際には、これらのUIライブラリは、多くの構成要素を持つ複雑な構造なのです。

ここでは、Reactのデザインシステムを作成する上で考慮すべき点をいくつか紹介します。

その要素は、デザインシステムガバナンスのプロトコルと手順の基礎となるものであるため、この初期の意思決定プロセスの全段階を文書化することが重要です。

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

デザインシステムの React コンポーネントライブラリを単一のレポジトリ（モノレポ）にするか、複数のリポジトリ（ポリレポ）にするかを決めましょう。

モノレポは依存関係の管理をシンプルにし、複数のパッケージの同時作業をしやすくします。

一方、ポリレポは、パッケージ間のモジュール性と分離性を高め、個々のコンポーネントを独立して維持や使用しやすくします。

Accenture では、モノレポ と ポリレポ の使い分けの メリットとデメリットが紹介されています（英語）。

コンポーネントの整理

コンポーネントライブラリは、製品やチームにとって最も便利な方法で整理しましょう。

例えば、機能別、ドメイン別、アトミックデザイン別などで分けられますね。

ちなみに MUIでは、以下のような機能別に UI ライブラリを整理できます：

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

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

デザイントークンの管理

デザイントークンの管理は、デザインシステムチームが管理する専用のフォルダやパッケージに一元化されます。

この集中管理により、変更と更新をシンプルにしながら、より良いメンテナンスとガバナンスを促すことができます。

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

デザインシステムのテーマ設定とカスタマイズは、現代の製品開発には不可欠であり、通常、「ライトモード」と「ダークモード」の少なくとも２つのテーマが必要です。

マルチブランドのデザインシステムでは、より高いカスタマイズ性と柔軟性が求められるため、開発前にこのような要素を検討する必要があります。

React ライブラリのテーマ設定方法については、CSS Tricksの「Theming and Theme Switching with React and styled-components（Reactによるテーマ設定およびテーマ変更とスタイルコンポーネント）」で詳しく解説されているので、ぜひチェックしてみてください。

ドキュメント

デザインシステムのドキュメントは、採用の成功と一貫した実装に不可欠です。

ドキュメントには、デザイン言語、ガイドライン（コンテンツ、デザイン、コード、アクセシビリティなど）、スタイルガイド、使用事例、コード例、ツール、その他の重要な情報が含まれてないといけません。

Storybook のようなツールによって、デザインシステムのドキュメントの管理と更新を一元化できます。

Merge を使って Storybook を UXPin に同期させて、デザインと開発にわたる「信頼できる唯一の情報源（Single source of truth）」を作るといいでしょう。

テスト

コンポーネントテストを管理・整理するための構造を計画することも、Storybook を検討するもう一つの理由です。

Storybookは、ビジュアル、インタラクション、アクセシビリティ、スナップショットなど、複数のバグ防止テストを含むコンポーネントテストの自動化が内蔵されています。

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

確実にデザインシステムの更新と製品との互換性を維持できるようにするために、React ライブラリのバージョン管理戦略とリリース管理プロセスを確立しましょう。

デザインツール

デザイナーは、プロトタイプとテストのために、React デザインシステムへのアクセスが必要です。

一般的な戦略として、ベクターベースのツールの使用がありますが、これは React デザインシステムの以下の２つのフォーマットを更新および維持するということです：

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

UXPin Merge があれば、Reactライブラリを UXPinのデザインエディタにインポートできるので、デザイナーとエンジニアは同じUIコンポーネントを使用することができます。

React コンポーネントを使ったプロトタイプの試してみませんか？

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

UXPin Mergeを使用すると、ReactライブラリをUXPinのデザインエディタにインポートできるので、デザイナーとエンジニアはまったく同じUIコンポーネントを使用できます。コードコンポーネントの同期にはいくつかのオプションがあります。

UXPin Mergeについての詳細はこちらから。

The post Reactデザインシステム – どこから作り始めるべき？ 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.

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

ここでは、１０年以上にわたってデザインツールに携わる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.

多くのプログラミング言語では、ウェブサイト、ソフトウェア、その他のデジタル製品の構築、拡張のためにパッケージが使われ、こういったパッケージにより、エンジニアは追加のコードを書いたり維持したりすることなく、プロジェクトの機能を拡張できます。

もしあなたの会社で Node.js が使われていたら、エンジニアが NPM、Node.js パッケージ、またはパッケージマネージャについて話しているのを聞いたことがあるかもしれません。本記事では、パッケージがどのように機能し、なぜエンジニアがそれを使用するのかについての基本理解のために、デザイナーの視点でこれらの用語について説明します。

UXPin Mergeは、デザイナーが完全に機能するコードコンポーネントでUIデザインができる画期的なツールを提供しています。UXPin Mergeのトライアルはこちらより。

NPM(Node Package Manager)とは

NPM（Node Package Manager）は、エンジニアがアプリケーションやWebサイトの開発に使うツールのオープンソースレポジトリです。

NPMは2種類あります：

1. オープンソースプロジェクトを公開するためのレポジトリ。簡略版：デジタル記録及び検索機能
2. レポジトリとインタラクトするためのCLI（コマンドラインインターフェース）。簡略版：ストレージ機能と通信するためのツール

パッケージマネージャ とは？

NPMを説明する前に、パッケージマネージャの基本を理解しておきましょう。パッケージマネージャはデベロッパーのためのツールキットだと考えてください。

例えば、支払いにStripeを使用するアプリケーションを構築するとします。パッケージマネージャは、あなたの製品がStripeと通信して支払い処理をするのに必要なコードをすべてインストールします。

エンジニアは、コードを書いたりStripeのドキュメントからのコピー＆ペーストの代わりに、コマンドの入力だけで、パッケージマネージャがStripeから必要なコードの依存関係をインストールします。

検索機能、API、決済、認証ツール、地図、アイコン、ホスティングなど、アプリケーション開発のためにに思いつくあらゆる機能を備えたパッケージが何百万と存在します。

NPMなどの、誰でもパッケージをアップロードしてインストールできるオープンソースのレポジトリと、アクセスが制限されたプライベートなパッケージレポジトリがあります。

コマンドラインインターフェースとは？

CLI（コマンドラインインターフェース）とは、デベロッパーがコンピュータープログラムの操作に使うテキストインターフェースのことです。このCLIを使用すると、コマンドを実行して、ソフトウェア開発に必要なバックグラウンド操作を実行できます。

NPMの場合、例えば、エンジニアはnpm installのようなコマンドにパッケージ名を続けて指定したパッケージをインストールすることができるように、CLIによってパッケージレジストリの対話ができます。

NPMレジストリ

NPMのウェブサイトは、エンジニアがパッケージについて検索したり学んだりする場所ですが、このウェブサイトは単なるレジストリであり、パッケージをホストしているわけではありません。代わりに、エンジニアはGitHub、Packagecloud、AWS CodeArtifactなどのプラットフォームを使って、パッケージをホストし配布しています。

例えば、NPM上のUXPin Merge CLIを見ると、レポジトリと関連リンクとしてGitHubが表示されています。その上に、UXPin Merge CLIとその依存関係を【 npm i @uxpin/merge-cli】とインストールするコマンドがあります。 NPM の後の “i” は “install” の省略形なので、【npm install @uxpin/merge-cli 】と入力しても、同じ結果になります。

依存関係とは？

パッケージは、エンジニアが【依存関係】と呼ぶ他のパッケージで構成されています。ちょっとわかりにくいですよね。この「依存関係」とは、プロジェクト内で異なるタスクを実行するコードのパッケージのことです。

例えば、UXPin Merge CLI は Typescript を使用しており、Typescript は UXPin Merge CLI が必要とする 41 の依存関係のうちの 1 つに過ぎませんが、依存関係として typescript パッケージが必要です。

開発依存とは？

UXPin Merge CLI の依存関係を見ると、41の依存関係と41の開発依存 (devDependenciesとも呼ばれる) があります。

• 依存関係：あるソフトウェア実行（本番）に必要なパッケージ
• 開発依存：開発段階で必要なパッケージのみ

依存関係と開発依存はnode_modulesという別のフォルダに存在するので、packages.jsonファイルとプロジェクトのコードはそれらがどこにあるのかがわかります。

package.jsonファイルとは？

そのメタデータと依存関係を提供する package.json ファイルがあります。コンピュータにプロジェクトをインストールするとき、NPM は 、依存関係と 開発依存 をインストールするのにpackage.json ファイルを参照します。

それぞれの依存関係を個別にインストールする代わりに、コマンドラインでnpm installと入力するだけです。

ホスティングプロバイダーもpackage.jsonファイルを使用して、そのサーバー上でプロジェクトの実行に必要な依存関係（開発依存を除く）をインストールします。

package-lock.jsonとは？

package-lock.jsonは、プロジェクトのビルドに使用されたパッケージの正確なバージョンを特定します。このファイルによって依存関係がロックされ、プロジェクトがインストールされるときに、最新のリリースではなく、開発中に使用されたバージョンが参照されるようになります。

エンジニアは定期的にパッケージを更新しますが、多くの場合、パッケージの動作方法が変更されます。それにより、依存関係のロックによって、プロジェクトが意図したとおりに確実に動作するようになります。

NPMの使用方法

ここでは、一般的なNPMのコマンドとその機能について説明します。

• npm init：プロジェクト用のpackage.jsonファイルが作成されます。アプリケーションを一から構築する場合、npm initはプロジェクトの重要な情報を含めるために使用する最初のコマンドの1つになり、NPMは、パッケージをインストールまたは削除するたびに、package.jsonファイルを自動更新します。
• npminstall：プロジェクトの依存関係をすべてpackage.json ファイルにインストールします。
• npminstall <package-name>：たとえば、npminstall @uxpin/merge-cli とすると、Merge CLI がインストールされるように、 NPMレジストリから特定のパッケージをインストールし、node_modules フォルダに保存します。
• npminstall <package-name> –save：NPMパッケージをインストールし、package.jsonファイルの依存関係に追加します。
• npminstall <package-name> –save-dev：NPMパッケージをインストールし、開発依存に追加します。
• npmuninstall <package-name>：プロジェクトから特定のパッケージをアンインストールします。
• npmdoctor：npmのインストールを診断し、パッケージの管理に必要なものがすべて揃っているかどうかを確認します
• npmupdate <package-name>：特定のパッケージを最新バージョンに更新します。

これらは、最も一般的なNPMコマンドのほんの一部であり、すべてのリストはNPMのドキュメントでご覧になれます。

デザイナーとしてのNPMの理解

NPMは、デザインツールのプラグインやアプリの拡張機能に匹敵する、ツールキットです。パッケージがどのように作られるのか、その裏側を知る必要はありませんが、一つや二つ知っておくと便利かもしれません。

まず、MUIやAnt Designなど、コードコンポーネントライブラリの一部は、NPMパッケージとして共有されています。

NPMパッケージとして配布されているコンポーネントライブラリはどのように探すのでしょうか。UXPinが公開しているデザインシステムのライブラリAdeleから、UXPinに取り込めるコンポーネントライブラリを探したとします。そこでShopifyのPolarisを選び、それがNPMで配布されていることがわかります。 そこで、NPMのサイトに行って、ShopifyのPolarisを探し、見つけるのです。

UXPinはMerge技術により、NPMパッケージを介してコンポーネントライブラリからUI要素をインポートすることができ、それらの要素を使って、完全に機能するプロトタイプを組み立てることができます。

UXPin Mergeは通常、デベロッパーによってセットアップされますが、開発サポートが不足している場合はMerge Component Managerを使って、コンポーネントを自分で管理することができます。

もし、デベロッパーとの連携を強化するためにプログラミングの知識を高めたいのであれば、HTML、CSS、Javascriptなどの基本的なコードの原則やコンポーネントライブラリについて学ぶ方が、デザイナーにとってはるかに有益だと思います。

UXPin Mergeで連携の強化

Mergeは、デザイナーとエンジニアが同じコンポーネントライブラリを使用することで、デザインと開発の連携を促します。

Mergeは、デザイナー用のUIキットとデベロッパー用のコードを用意する代わりに、レポジトリをUXPinのエディタに同期させ、デザインチームがコードコンポーネントを使用して完全に機能するプロトタイプを構築できるようにしています。

自社デザインシステムやMUIなどのコンポーネントライブラリを同期させることで、デザイナーはUI要素をドラッグ＆ドロップするだけでインターフェースやプロトタイプの構築ができます。UXPin Mergeをトライアルしてみたい方はこちらまで。

The post NPMと言うのは？把握しよう！ 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.

 Material UI は、MUI によって開発および維持されている、Googleのマテリアルデザインのガイドラインを実装した人気のReactコンポーネントライブラリです。ボタン、カード、メニュー、フォーム要素、決まったスタイル、テーマなどを含む再利用またはカスタマイズが可能なコンポーネントの総合的なセットを提供しています。

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

UXPinが提供するMergeテクノロジーを使って、プロトタイピングやテストにMaterial UIのReact コンポーネントを使ってみませんか。詳細については、こちらのページをぜひご覧ください。

１． Ant Design

（Webアプリケーション、クロスプラットフォームアプリケーション、ネイティブアプリケーションに最適）

Ant Designライブラリは、高品質なアプリケーションを構築するための、再利用可能で文書化された幅広いコンポーネントを提供しています。Ant Designによって開発された包括的なコンポーネントライブラリであり、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の原則に従い、明快さ、コンテンツの優先順位付け、スムーズなアニメーションを重視しています。

また、さまざまなプラットフォームやデバイス間で一貫したまとまりのあるエクスペリエンスを提供するため、多くのクロスプラットフォームやモバイルプロジェクトに適しています。

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

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

４．Carbonデザインシステム

（Webアプリケーション、iOS & Androidアプリケーション、ネイティブアプリケーション、クロスプラットフォームアプリケーションに最適）

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

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

５．Tailwind CSS

（Webアプリケーションに最適）

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

また、このライブラリはReact、Vue、HTMLに対応しています。デベロッパーは、そのユーティリティクラスをHTML要素に簡単に適用することができ、コンポーネントの見た目や動作をきめ細かく設定できるようになります。

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

６．Semantic UI

（Webアプリケーションに最適）

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

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

Semantic 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 など複数のフレームワークに対応しています。

これはナイジェリアのSegun Adebayo氏によって設立され、アフリカから生まれた最も著名なオープンソースのコンポーネントライブラリのひとつとなっています。

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

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

９．Bulma

（Webアプリケーション、ランディングページに最適）

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

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

１０．Styled Components

（Webアプリケーション、ランディングページに最適）

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

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

１１．PrimeReact

（Webアプリケーション、ランディングページに最適）

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

PrimeReactはレスポンシブデザインを採用しており、それによってコンポーネントがさまざまな画面サイズやデバイスにきちんと適応することが保証されます。また、このライブラリはデータバインディング、フィルタリング、ソート（並べ替え）、ページネーションなどの強力な機能を備えており、データ集約的なアプリケーションの構築に適しています。

また、PrimeReactに内蔵されたコンポーネントと機能を活用することで、デベロッパーは時間と労力を節約でき、それが開発サイクルの短縮やUX（ユーザーエクスペリエンス）の向上に繋がります。ライブラリは定期的に更新され、それによって最新のReactバージョンとの互換性は保証され、継続的なサポートとバグ修正が提供されます。

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

UXPin Mergeが提供する技術によって、プロダクトチームはオープンソースのデザインシステムをUXPinのデザインエディターにインポートでき、デザイナーはコードコンポーネントを使ってプロトタイプやテストを行うことができます。

「Code-to-Design」のワークフローは、エンジニアが最終製品の開発段階で使うものと同じコンポーネントをデザイナーが使うため、プロトタイピングやテストが強化されます。そして、デザイナーはユーザーテストやステークホルダーに没入型のプロトタイプ体験を構築でき、コンセプトを反復・改善するための有意義なフィードバックがもたらされます。

Mergeは、製品開発環境全体で「信頼できる唯一の情報源（Single source of truth）」を提供するため、デザインと開発間の摩擦は減り、デザインハンドオフがスムーズになります。また、Mergeのプロトタイプでは、デベロッパーがすでに同じレポジトリから取得したまったく同じコンポーネントライブラリがあるため、最小限の補足ドキュメントと説明しか必要ありません。

UXPinのMerge技術により、ユーザビリティの問題の解決、ビジネスチャンスの拡大、時間のかかるガバナンス手順の自動化、「信頼できる唯一の情報源（Single source of turht）」の作成が実現します。詳細とアクセスリクエスト方法については、Mergeページをぜひご覧ください。

The post Material UI の代替案１１選 appeared first on Studio by UXPin.

デザインシステムとは、製品の一貫性がありブランドイメージに合ったインターフェイスを構築するために使用されるコンポーネント、ルール、スタイルガイド、ドキュメンテーションの集合体です。企業の多くは独自にデザインシステムを構築しています。

今回は、UXPinが選ぶ 参考にしたい8つの デザインシステム をご紹介していきます。デザインシステムの導入検討の方のみではなく、デザインについて学習中の方もぜひ最後までご覧ください。以下で紹介するデザインシステム以外にも、Adeleというデザインシステムのリポジトリがあります。

UXPin Mergeでデザインシステムの導入とガバナンスを強化しましょう。デザインシステムからすべてのインタラクティブ性のあるコンポーネントをエディターに取り込み、最終製品と同じ操作・機能性を持つインタラクティブなプロトタイプを作成し、デザインの一貫性を保ちましょう。UXPin Mergeについての詳細を読む。

デザインシステムとは

デザインシステムとは、プロダクトチームがアプリ、ウェブサイト、eコマースストア、その他開発する必要のあるUIデザインを構築するために使用するすべてのデザインリソースをまとめたものをいいます。

デザインシステムはデザイナーのためだけのものではなく、フロントエンドのコードとドキュメント、デザインガイドライン、関連プラグイン、デザインパターン、スタイルガイド、再利用可能なコンポーネント、ルールとガイドライン、その他ウェブデザインと開発のワークフローに役立つすべてのビルディングブロックを含むすべてのコードスニペットと開発リソースが含まれることから、開発者にとっても役に立ちます。

これらのデザインシステムは、オンラインのウェブサイトとしてホストされ、一般に公開されることもあれば（オープンソースのデザインシステム）、企業内だけで利用されることもある。

デザインシステムは、応用できる説明書や例、スタイルガイドやコーディングガイドラインを含む貴重なドキュメントとして機能する膨大なデータライブラリであり、同時にUIキットの一部であると考えることができます。

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

Googleマテリアルデザインシステム

Googleは、Microsoft、Apple、Amazonと並ぶBig4テクノロジー企業のひとつであり、オンライン広告、検索エンジン、クラウドコンピューティング、ソフトウェアなどのウェブサービスや製品に注力している有名なハイテク企業です。

GoogleはMaterial Design Systemを作成し、公開しています。Material Design Systemでは、デザインとデザイン原則に関するすべての事柄について、非常に詳細に説明しています。UXPinユーザーは、UXPinライブラリの一つであるマテリアルデザインコンポーネントを簡単に使用することができます。

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

さらに、Material Designによって、他のブランドや個人が、アトミックデザイン、業界のイノベーション、独自のブランド表現に対する独自のアプローチを行う際に、土台となる強固な基盤を持つことができます。

GoogleのMaterial Design Systemの主な機能は以下の通りです：

• Starter Kits
• Design Source Files
• Material Theming
• Layout
• Typography
• Color
• Components
• Mobile Guidelines

GoogleのMaterial Design Systemは非常に洗練されているように見えますね。多くのデザインガイドラインがありますが、開発で使用されるコンポーネントに関するドキュメントも含まれており、コンポーネントがデザインでも使うことができます。UXPinのMergeテクノロジーで、開発者のコンポーネントをデザインに取り込みましょう。UXPin Mergeへのアクセスはこちら。

Apple ヒューマンインターフェースガイドライン

Apple Human Interface Guidelinesは、ウェブデザインのエッセンスやパターンライブラリが、ダウンロード可能なテンプレートのための膨大でむしろ貴重なデザインシステムのリソースを提示しています。iOSのUIキットライブラリもUXPinのアカウントで利用できます。

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

• 細部にまで気を配り、正確に作る
• ユーザーエクスペリエンスを重視し、ユーザーとのつながりを大切にする
• より大きなスケールで本当に重要なことに集中する
• 具体的なデザイン言語と手法により、ユーザーの求める反応を生み出す
• 初心者から上級者まで、ハイテクの親しみやすさを活用する
• すべてをシンプルに

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

以下のデザインシステムに関するドキュメントも含みます：

• Menus
• Buttons
• Icons and Images
• Fields and Labels
• Window and View
• Touch Bar
• Indicators
• Selectors
• Extensions
• Visual Design
• Visual Index
• App Architecture
• System Capabilities
• User Interaction
• Themes

Atlassian デザインシステム

Atlassian Design Systemは、世界中のチームのコラボレーションをシームレスかつ容易にすることで、価値ある支援を提供することに重点を置いています。また、Atlassianデザインガイドラインは、UXPinのライブラリコレクションの一部です。

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

Atlassian Design System は、アジャイルプラクティスと、プロジェクト内のすべてのステップを効率的に追跡することを特徴としており、最終的に製品の納品と開発の面で価値ある結果をもたらします：

Atlassian Design System

• UI components
• brand values
• UI kit
• UI patterns
• design tokens
• illustration library
• content guidelines

Uber デザインシステム

Uberによれば、移動が機会に火をつけるといいます。

Uberのサービスは、ライドハイリング、ピアツーピアのライドシェアリング、フードデリバリー、スクーターや電動バイクを使ったマイクロモビリティなど、移動を基本としています。

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

Uber Design Systemの主な機能は以下の通り：

• Brand Architecture
• Composition
• Tone of Voice
• Motion
• Illustration
• Photography
• Iconography
• Color
• Logo
• Typography

Shopify デザインシステム Polaris

ShopifyはグローバルなEコマースプラットフォームで、ブランドがビジネスを運営・成長させるために必要なものをすべて提供しています。

Shopifyのデザイン方針が、より良い、よりアクセスしやすいコマース体験の創造に焦点を当てているのも不思議ではありません。

ShopifyのPolarisと呼ばれるパブリックデザインシステムは、同社のコアバリューを包括しています：

• ユーザーへの思いやりと配慮を忘れない
• ユーザーがやりたいことを実現するための適切なツールを提供する。
• ブランドイメージに合った最高レベルのクラフトマンシップを享受すること
• 正確で迅速な解決策を提供し、手間を省く
• ユーザーからの信頼を得ること
• ユーザーが安心して製品を使用できるようにする

Polaris Design Systemは、Shopifyプラットフォーム用のデザインのための、わかりやすく実用的なスタイルガイドを提供します。これは、より良いユーザーエクスペリエンスと製品を作成するためのUIコンポーネント、視覚的要素、コンテンツ、デザイン言語を活用するための広大な知識ベースを提供します。Polarisのコンポーネントは、UXPin管理の一部でもあります。

Shopify Design System Polarisには、上記のプラクティスに忠実に従った主な機能が含まれています：

• Data Visualization
• Accessibility
• Interaction States
• Colors
• Typography
• Icons
• Illustrations
• Spacing
• Sounds
• Resources

IBM Carbon デザインシステム

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

そのサービスは、ビジネス・コンサルティングやファイナンス、ソフトウェア開発、ITホスティング/管理、ソフトウェア・ハードウェア製品など多岐にわたっています。

そのサービスは、ビジネス・コンサルティングやファイナンス、ソフトウェア開発、ITホスティング/管理、ソフトウェア・ハードウェア製品など多岐にわたっています。

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

Carbon Design Systemは、Adobe、Axure、Sketchなどのデザイナーや開発者のために、豊富なツールとビジュアルリソースを提供しているのが大きな特徴です：

• Data Visualization
• Patterns
• Components
• Guidelines
• Tutorials

UXPinユーザーは、Carbonで必要なすべてのものをアカウントで簡単に見つけることができます。

Mailchimp デザインシステム

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

Mailchimpの明確な目標は、中小企業が自社のブランドアイデンティティやイメージに忠実でありながら成長できるよう支援することです。

Mailchimp Design Systemを開発した背景には、創造的な表現、より良いユーザーエクスペリエンス、最高の品質に焦点を当てた主な機能があるのもそのためです：

• Data Visualization
• Grid System
• Color
• Typography
• Components

Salesforce Lightningデザインシステム

セールスフォースは、統合されたクラウドベースのCRMソフトウェアを通じて、ユーザーにパーソナライズされた体験を提供するために、それ以上の努力をしています。

Salesforce CRMの目的は、マーケティング、商取引、IT、サービス、販売の取り組みを改善することであり、ユーザーがユーザーと同じことができるようにすることです。

セールスフォースのデザイン哲学は、ハワイ語で家族を意味するOhana（オハナ）に反映されており、4つのコアバリューが企業活動と文化全体を推進しています：

• 革新
• 平等
• 信頼
• カスタマーサクセス

そのため、Salesforceは独自のLightning Design Systemを発表しており、コンテンツ管理システムに携わるすべての人がその主な機能を学び、恩恵を受けることができるようになっています：

• Design Guidelines
• Platforms
• Accessibility
• Components (and a lot of them)

なぜデザインシステムを作るのか必要があるのか

開発者、デザイナー、プロダクトマネージャーなど、会社のプロダクトチーム全員が集まり、フォントやカラーパレットからUXライティングのルールやCSSコードなど、今あるデジタルプロダクト資産のすべてを話し合い、マッピングします。

表現の仕方（どのようにデザイン、コード化されるべきか）などについての基本的な方針を共同で作成します。

そうすることで、すべてのチームが視覚的な参照情報、ツール、記事、パターン、データライブラリなどの完全な証拠となる情報源（業界でデザインシステムが信頼できる唯一の情報源と呼ばれるのには理由があります）を手に入れることができます。これにより、作業の一貫性と統一性を保ちながらメンバー全員が同じページを確認することができます。これはデザインシステムの最終的な目標です。

デザインシステムの活用と導入

デザインシステムの実装と開発に関して言えば、開発者は、再利用可能なコンポーネントやライブラリから必要なものがすべてコピーできるようになっていれば、繰り返しのコードスニペットに時間を費やす必要はありません。

同様に、デザイナーは色、ロゴ、ヘッダー、フッターなどの標準的なデザインやUI要素のライブラリがあれば、新しいランディングページをゼロから作成する必要はなく、デザインプロセスをスピードアップすることができます。

また、Webマーケティング担当者にとっては、必要なものがすべてシステム内にあれば、ニュースレターの色合いやテンプレートを何度も作り直す必要はありません。

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

デザインシステムの大半は、わりと一般的な設定パターンに従っています。

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

これらのメインカテゴリには、より詳細な情報を提供するサブカテゴリがあり、原子レベルのデザイン構造を最大限に活用しています。例えば、「タイポグラフィ」「カラー」「フォーム」「バナー」などのサブカテゴリです。

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

他の人やブランドにとってのメリットは？

多くの企業がオンラインで公開しているデザインシステムの優れた点は、他の人々もそこから学び、さらには自分のアトミックデザインの例として使用することができることです。

Shopify社のショッピングデザインシステムは、ウェブ上で公開されています。つまり、Eコマースサイトをデザインしようとする人は、すべてのデザイン要素について、その基準、デザインコンポーネント、デザイン言語、パターンライブラリを使用することができ、自分が素晴らしい仕事をしていることを100％確信できるのです。

それでは、多くのことを学ぶことができる（そして、必要に応じて盗むことができる）最高のデザインシステムの例をいくつか見てみましょう。

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

包括的なデザインシステムを導入することで、企業はチームワークと規律を大幅に改善することができます。

デザインシステムの最も重要な利点の一つは、リソース、要素、データの収集により、デザイナーと開発者間のコミュニケーションの問題を最小限に抑え、UXデザインのバグが発生する可能性を最小限に抑えることができることです。

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

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

デザインシステムは、デザイナーと開発者の間の断絶を最小限にする素晴らしい方法ですが、それだけではまだ理想的なソリューションとは言えません。Mergeが持つ技術によって、製品チームのメンバーは開発ツールを簡単に活用し、DesignOpsでのワークフロープロセスを改善することができます。これは、開発者とデザイナーの両方が 1 つのソースから同じUI要素を使うことができることを意味します。

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

企業がデザインシステムを構築しようとしても、特にすべての要素、ドキュメント、コードを維持する際には、具体的な問題や一貫性の断絶が起こり得ます。

デザインシステムの課題と解決策について、デザインのトップリーダーの一人であるジョンソン・エンド・ジョンソンからご紹介します。ウェビナーでは、J&Jチームが彼らのベストプラクティスをすべて共有しました。

UXPin Mergeでデザインシステムを最大限に活用する方法

Mergeが持つ技術は、デザインチームと開発チームの間にコミュニケーションのギャップがある場合に起こりがちな課題に対するソリューションとして開発されました。そのため、さまざまなUIコンポーネントやコーディング、ドキュメントの不整合が生じ、製品の効率やメンテナンスに影響を及ぼす可能性があります。

必要なコンポーネントをすべてまとめたデザインシステムをはじめ、MergeはすべてのUI要素をデザインエディターに取り込みます。

イメージ通りに仕上がるのはもちろん、不整合を避けることができるので製品開発での時間と費用の節約にもつながります。

Mergeは、コードコンポーネントをデザインに変換することに重点を置いています。そのため、デザイナーは最終製品の外観だけに基づいてプロトタイプを作成するのではなく、すでにコード化されたコンポーネントを使ってプロトタイプのイメージをデザインすることができます。

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

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

理想なデザインシステムは見つかりましたか？

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

しかし、デザインシステムのメンテナンスや実装が不十分であれば、デザインシステムは、不便で混乱を招くコードスニペット、ライブラリ、コンポーネントになってしまいます。

デザインシステムは、チームメンバーを迅速に教育し、一貫性を促進すると同時に、デザイナーがより複雑なUXの問題に対処できるようにします。そして、革新的なMergeのテクノロジーをミックスに加えれば、デザインシステムを次のレベルに引き上げることができます。

１４日間の無料トライアルで今すぐコードベースデザインご体験ください。

The post デザインシステムベスト8の事例 appeared first on Studio by UXPin.

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

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

UXPin Mergeでデザインシステムのコンポーネントやオープンソースのコンポーネントライブラリをインポートして、組織全体で「信頼できる唯一の情報源（Single source of truth）」を作成しませんか。Mergeの詳細および、この画期的なデザインテクノロジーへのアクセスのリクエストについては、せひこちらをご覧ください。  

 デザイントークン とは

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

クロスプラットフォームの製品開発では、OS でそれぞれ異なるスタイルプロパティとフォーマットが使われているという点が課題になります。例えば、UXPinのウェブサイトでは、CTAに黄色が使われていますが、その黄色のヘックスコードは#FCC821 で、以下のように何通りかの方法で表現することができます：

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

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

組織では、カラーパレット、サイズ、スペース、アセット、ドロップシャドウなど、多くのスタイルプロパティにこのようなデザイントークンが使われます。

 デザイントークン の由来

  Salesforceは、”デザイントークンのパイオニア “として広く知られています。Salesforce Designer に掲載された２０１４年の記事で、Salesforce UX VPのシェーンケ・ローデ氏は、同社がデザイントークンを使って、複数のプラットフォームやソフトウェアに同じデザイン原則を適用する方法について次のように説明しています。

「Salesfrorce では、このような課題に直面し、”デザインを一カ所で確定し、それをすべてのプラットフォームにカスケードダウンするシステムを使う。” という解決策を考え出しました。私たちはこれを『信頼できる唯一の情報源（Single Source of Truth）』と呼び、基本的に、デザイントークンを記述する名前と値のペアが含まれているJSONファイルのセットになります。」  – シェーンケ・ローデ氏著「Living Design System」からの抜粋。

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

 デザイントークンは自分が求めているものか

  Googleのマテリアルデザイン３のドキュメントには、以下のようにデザイントークンが最も役立つシナリオのリストが掲載されています：

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

  また、マテリアルデザインは、デザイントークンが “あまり役に立たない “と思われる事例も以下のように２つ挙げています：

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

 デザイントークン の利点

デザイントークンの使用には、主に３つのメリットがあります：

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

デザイントークンが「信頼できる唯一の情報源（Single source of truth）」の作成に最も有益であり、それが Salesforce がデザイントークンを使い始めた原動力となりました。複数のプロダクトチーム、エンジニア、UXデザイナーが同じ製品に取り組む場合、みんなに同じデザイン言語が使われないといけません。  

デザイントークンによって、チームは役割、プラットフォーム、プログラミング言語、担当業務に関係なく、同じ言語で話すことができるようになるのです。

UI の一貫性

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

そこでデザイントークンが、デザイナーがそれぞれ同じスタイルとプロパティを使用できるようにこのような矛盾を解消します。これも「信頼できる唯一の情報源（Single source of truth）」の利点です。

スケールアップへの柔軟性

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

例えば、Android では、HEX や RGB ではなく、８進数のカラーコードが使われていますが、デザインシステムをAndroid に対応するために、DSチームは各デザイントークンに８進数のコードを追加し、「信頼できる唯一の情報源（Single source of truth）」を維持できます。

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

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

 デザイントークン の構造

デザイントークンの構造を確定するルールはありませんが、Amazon のスタイルディクショナリーにあるこの例が一番わかりやすく、多くの組織では、デザイントークンに同様の形式が使われています。

スタイルディクショナリーは、以下のように階層的なデザイントークン構造を採用しています：

1. カテゴリー（色、時間、ラインハイト（行ボックスの高さ）、サイズ、アセット、コンテンツ、など）
2. タイプ
3. 項目
4. サブ項目
5. ステート

  この構造を使ってプライマリ・アクティブ・ボタンのデザイン・トークンを作成する場合、color_background_button_primary_active のようになるか、あるいは color-bg-btn-primary-active と短縮されるかもしれません。そしてこのトークンは、クロスプラットフォームの実装に必要なあらゆるタイプのカラーコードを含むことになります。

デザイントークン構造の鍵は『一貫性』であり、ユーザーがトークンを見つけやすく、システムを拡張できるように、予測可能な命名規則を使わなければいけません。

トークンのアーキテクチャ

  UXのエキスパートであり、eightshapesの創設者であるネイサン・カーティス氏が、トークンのアーキテクチャについて素晴らしい記事を書いています。彼は、最初のステップとして、デザイントークンを【オプション（または選択肢）】と【意思決定】に分けることを挙げています。

• オプション：ベースとなるトークン値の作成。トークンは、スタイル ディクショナリが上記で色、時間、アセット、コンテンツなどのカテゴリーとして説明しているものを確定する。
• 意思決定：意思決定はオプションを使用して、例えばインタラクティブカラー、バックグラウンドカラー、テキストカラーなどのコンポーネントのプロパティを作成する。

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

ネイサンの方法論では、オプションを使って意思決定を増やすだけなので、拡張も簡単です。トークンのアーキテクチャーに関する詳しい説明は、こちらの記事をお読みください。

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

  ルイ・シェネー氏は、「Design Tokens for Dummies」という参考記事の中で、デザイントークンの有無による典型的なデザイン変更のワークフローを概説しています。  

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

1. デザイナーによる、デザインツールでのスタイル更新
2. デザイナーによる、デザインハンドオフのための変更点の文書化
3. エンジニアによるコンポーネントのプロパティ（CSS、LESS、SASSなど）の更新
4. デザインチームによるQA（品質保証）時の変更点確認

このワークフローには、以下のように問題点がいくつかあります：

• デザインハンドオフの際に、より多くの作業と注意点が生じる
• エラーや伝達の行き違いが起こりやすくなる
• より多くのチケット（実施するべき作業や課題）が生じてしまい、技術的負債が増加する
• 変更作業や対応するエラーの修正に無駄な時間とコストがかかってしまう

デザイントークンのやり方

1. デザイナーがデザインツールでスタイルを更新する
2. デザイントークンジェネレーターが、プラットフォーム固有のファイル（JSON／YAML）を作成する集中型レポジトリを更新する
3. エンジニアが新しいレポを引き出し、新しいトークンを追加して、プロジェクトのスタイルを自動的に更新する

デザイントークンを使うことで、デザインハンドオフのためのドキュメント軽減や、エンジニアのプログラミング時間の短縮が実現します。この自動化されたシステムで、ヒューマンエラーが大幅に減り、開発とQAプロセスが効率化されるのです。

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

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

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

Merge コンポーネントには、レポジトリにあるものと同じ忠実度と機能性があり、デザインシステムチームは、React props（またはStorybook統合のためのArgs）を使って、変更の制限や、デザイナーへのデザイン決定のための柔軟性の提供ができます。

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

MergeのNPM統合

  これまでのMergeでは、セットアップにはすべてエンジニアのサポートが必要でしたが、２０２２年に UXPin は NPM 統合を開始したことから、デザイナーはエンジニアの助けを借りずにオープンソースのコンポーネントライブラリを同期できるようになりました。

新しいNPM統合により、デザイナーはコードを一行も書くことなく、直感的な UI を通じてNPM レポジトリからコンポーネントを読み込むことができます。また、コンポーネントにpropを追加して、完全にコントロールやカスタマイズすることもできます。

Merge には以下の３つのオプションが用意されています：  

• Git 統合：Reactコンポーネントライブラリの直接統合
• Storybook 統合：Angular、Vue、Ember、HTML、Web Componentsなど、よく使われているフロントエンドフレームワークを接続可能
• NPM 統合：直感的なダッシュボードでオープンソースのコンポーネントライブラリを同期

  UXPin Mergeで、製品開発を新たな高みへと導き、『信頼できる唯一の情報源（Single source of truth）』を作成しましょう。詳しい情報とアクセスリクエストの詳細については、Mergeのページをぜひご覧ください。

The post デザイントークン とは？覚えておきたいポイントとメリット 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.

顧客とのつながりやプロセスの効率化に役立つデジタル製品を導入する企業が増えるにつれ、デザインオペレーションマネージャーの重要性が高まっています。デザインチームのメンバーが複数のプロジェクトを同時に進めている場合、デザイナーや開発者の管理方法を熟知した人材を導入することは理にかなっています。

比較的新しい職種であるデザインオペレーションマネージャーは、多くの仕事を兼任することが多いです。さらに、職務内容も様々なので、特定のタスクを果たすためにポジションをカスタマイズすることもできます。しかし、どのように定義したとしても、デザインオペレーションマネージャーは製品開発プロセスを改善することができます。

プロジェクトのワークフローを改善する

デジタル製品を成功させるには、時間とお金が必要です。現在では、ほとんどのチームは、コラボレーションによるアジャイルプロジェクトマネジメントが最高の結果を生むと考えています。おそらくそれは正しいでしょう。しかし、成功する製品を効率的に作るためには、どのアプローチが最適なのかを知るには、プロジェクトのガイドラインを見直したり、他のコンセプトを試したりする必要があります。

知識豊富なデザインオペレーションマネージャーは、スクラムやカンバンなどのオプションを検討し、プロジェクトのワークフローを改善できるかどうかを判断することができます。

UXPin Mergeのようなコードベースのデザインツールを使用しているデザイン・開発チームは、独自のワークフローを作成することで最良の結果を得られるかもしれません。例えば、PayPalはデザインとDevOpsを1つのフローに統合したシステムを使用しています。

デザイン業務担当者には、ワークフロー改善の機会を探るように促してください。今はまだ時間がかかるかもしれませんが、その努力は長期的にはチームの時間と労力を節約することになるでしょう。

プロジェクトに特化したスキルを持つ専門家のチームを作る

 デザインオペレーションマネージャー は、プロジェクトの要件を検討し、目標を達成するために必要な特定のスキルを持つ専門家のチームを構築する方法を知っている必要があります。例えば、あなたのチームが作っているのは非常にシンプルな製品なので、必要なのは1人のデザイナーと2、3人の開発者だけかもしれません。しかし、よりインタラクティブで表現力豊かなデジタル製品を作るには、新たな人材が必要になるかもしれません。デザインオペレーションマネージャーは、採用するために応募者を審査する方法を知っている必要があります。

• アニメーション・デザイナー
• プロジェクトマネージャー
• ブランドマネージャー
• アートディレクター
• コンテンツクリエイター
• UI/UXテスター

製品が高度化すればするほど、プロジェクトを完成させるために必要なスキルも増えていきます。デザインオペレーションマネージャーは、適切な人材を確保することができます。

最適な規模のチームを維持することでコストを削減（必要に応じて規模を拡大

あなたのチームは、ユーザーフレンドリーなデザインを作成し、プロトタイプを作成し、市場で通用する製品を作るために協力し合っていますか？

チームの人数が少なすぎると、マイルストーンを達成するのに苦労し、競合他社に追いつくことができません。従業員が多すぎると、潜在的な貢献者がチャレンジ精神に欠け、コストを浪費してしまいます。経験豊富なデザインオペレーションマネージャーは、チームを監査して、メンバーの数が必要かどうかを判断し、製品デザインチームの新しいメンバーの導入を進めることができます。

多くの企業がそうであるように、時折、追加の支援を必要とするプロジェクトがあるでしょう。デザインオペレーションマネージャーは、チームを過剰に拡大するのではなく、信頼できるフリーランスのデザイナーや開発者に連絡を取り、共同作業を支援することで、迅速に規模を拡大することができます。

また、デザインプロセスの拡張を容易にするツールやプロセスを知っている必要があります。例えば、UIパターンを定義し、一貫性を確立し、デザイン作業を容易にするために承認されたアセットへのアクセスを提供するデザインシステムがすでにあれば、チームはより迅速に作業を進めることができます。

 デザインオペレーションマネージャー による品質保証

あなたは、従業員、マネージャー、ステークホルダーにとって魅力的なデジタル製品を作っています。しかし、品質保証のために製品をテストするという特別なステップを踏んでいますか？

品質保証テストの最適な方法は、目的によって異なります。デザインオペレーションプログラムのマネージャーがその目標を明確に把握していれば、ターゲットとなる市場が製品に価値を見出すことができるようにテストを管理することができます。

社内製品の中には、大規模なテストを必要としないものもあります。試作品を数人の同僚に送り、フィードバックを求めるだけでいいかもしれません。

しかし、収益を生み出す市場向けの製品には、綿密なテストが必要です。デザインオペレーションマネージャーは、テストとフィードバックをしてくれるユーザーを募集するかもしれません。A/Bテストでは、あるバージョンのアプリが他のバージョンよりも優れているかどうかという疑問を解決することができます。これを機に、AIをユーザビリティテストに参加させてみてはいかがでしょうか。

買ってもらえなかったり、クレームや悪い評価を受けたりするような商品は出したくない。当たり前のことですが、リスクを伴い、テストされていない製品は、あなたの会社に損害を与えます。製品を改善し、失敗を避けるために、品質保証の方法を知っているデザイン担当者を雇いましょう。

製品をリリースする前に、チームがすべてのタスクを完了していることを確認する

理想的なのは、プロジェクトのタスクが完了したことを示すチェックリストを管理することです。例えば、従業員Aがアプリのナビゲーションをデザインしているとします。従業員Bは、アプリがすべてのデバイスで完璧に見えるようにコードを調整していますので、その仕事が完了したら報告します。

この方法は通常、うまくいきます。しかし、タスクが時間通りに正しい順序で完了するように、誰かがチェックリストを監督しているでしょうか？これはプロジェクトマネージャーが行うことができますが、その人はデザインチームの中でどのアプローチがプロジェクトのタイプに最適かを知っているでしょうか？

ここにもデザインオペレーションマネージャーが介入し、製品開発プロセスを改善するチャンスがあります。タスクを割り当て、完了を監視するためのアプリケーションは数多く存在します。これらのツールを使いこなしている人は、プロジェクトごとに最適なオプションを選ぶことができます。プロジェクトマネージャーは進捗を監視するかもしれませんが、その進捗をどのように測定し、保証するかを決めるには、より広い視野を持った人が必要です。

UXPin Mergeでデザインオペレーションマネージャーの仕事が楽になる

デジタル製品を構築するほとんどすべての設計・開発チームは、デザインオペレーションマネージャーの洞察力から恩恵を受けることができます。

しかし、新しいマネージャーに過度の負担をかけてはいけません。ストレスの多い職場環境は、人間関係を悪化させ、仕事の進展を困難にするでしょう。

UXPin Mergeへのアクセスをリクエストすることで、チャレンジを容易にすることができます。Mergeは、デザインにコードベースのアプローチを取ることで、開発プロセスを合理化します。デザイナーはGitやStorybookのような開発者のライブラリからインポートされたインタラクティブなコンポーネントを使用するので、デザインプロセスの時間が短縮されます。さらに、デザインを開発チームに送る前に、完全に機能するプロトタイプをテストすることができます。

Mergeにアクセスして、デザインオペレーションマネージャーの仕事を容易にし、製品開発プロセスを改善することができます。

The post デザインオペレーションマネージャー は必要ですか？ 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開発を効率化し、失敗しないようにすることができます。（なぜUI開発に使う必要がある？）コンポーネントライブラリを作るメリットには以下のようなものがあります：

• 現在のガイドラインに沿った信頼できる唯一の情報源を作ることができる。
• 重要なマイルストーンやリリース日に間に合わせる必要がある場合、迅速にスケールアップすることができる。
• 製品チームのコラボレーションとコミュニケーションを向上させる。
• コードの重複を減らす。
• 複数のデバイスで動作するデジタル製品の構築。

UXPinがStorybookの統合を提供している今、アクセスできるStorybookのフレームワークについて学んでみましょう。Storybookが普及しているということは、あなたの開発チームのメンバーは、すでにこれらの一般的なフレームワークを使った経験があるということです。もしそうでなければ、Storybookのフレームワークの長所と短所を知る機会を与えてあげましょう。

Storybook for React

Reactは、たくさんの利点を持つJavaScriptライブラリです。私たちは、以下のようなReactの機能に対する評価を投稿してきました：

• コンポーネントの再利用性。
• 不具合を修正するための簡単なオプションを備えた安定したコード。
• 特にJavaScriptに慣れている人にとっては、学習曲線が短い。
• ライブラリを動かし続ける信頼できるエンジニアリングチーム。
• JSX拡張での条件文。

Reactは、UIライブラリの他のコンポーネントに影響を与えずに個々のコンポーネントを変更する方法をすでに提供しているため、Storybookに自然にフィットします。Storybookでは、コンポーネントを分離することで、この機能をさらに効果的にしています。サンドボックスでは、技術的な詳細に立ち入ることなく、UI全体を構築することができます。

また、React Storybookフレームワークは、コンポーネントを文書化することで再利用をこれまで以上に容易にし、コンポーネントを視覚的にテストすることでバグのあるコードを避けることができます。

StorybookでのReactの使用についてもっと知りたい方は、StorybookのReactの紹介を読み、ウェブサイト「Component Driven User Interfaces」をご覧ください。

Vue

Vue Storybookフレームワークでは、Storybook for Reactで得られるエッセンスをすべて提供しています。Vueフレームワーク用のStorybookとReactフレームワーク用のStorybookの最大の違いは、GraphQLアドオンを取得できないことで、これにより他のツールとの統合が若干難しくなります。

多くの開発者がVueを気に入っているのは、サイズが小さくてもパフォーマンスに妥協がないからだ。Vueは、強固なツールエコシステム、リアクティブな双方向データバインディング、仮想DOMレンダリングを提供します。

Angular

Storybook Angularフレームワークは、Reactで得られるエッセンスやアドオンをすべて提供しています。

少人数の開発チームで、シンプルなJavaScriptでHTMLの機能を拡張することに集中したい場合、Angularを選択するのは理にかなっています。基本的なJavaScriptのコーディングスキルがあれば誰でもこのフレームワークを使うことができ、コスト削減、開発時間の短縮、ミスの回避に役立ちます。

Angularがシンプルだからといって、弱いわけではありません。ディレクティブ、再利用可能なコンポーネント、データバインディング、ローカリゼーションなど、優れた機能を備えています。

コミュニティStorybookフレームワーク

コミュニティフレームワークは、大規模なコミュニティが存在しないため、ReactやVueなどの主要な  Storybookフレームワーク のように頻繁に更新されない傾向があります。

これらはStorybookの最良の選択肢ではありませんが、オープンソースのツールはまだ動作します：

• Ember
• HTML
• Mithril
• Marko
• Svelte
• Riot
• Preact
• Rax

これらのStorybookのフレームワークを使うと、いくつかの機能が失われることを覚えておいてください。Ember on Storybookだけが、必要なもの(Actions, Backgrounds, Docs, Viewport, Controls)をすべて備えています。コミュニティフレームワークの中には、GraphQLをサポートしているものはありません。また、他にも数多くのアドオンがないため、プロジェクトを迅速に終わらせるのが難しくなるかもしれません。

しかし、Storybookの柔軟性はこれらのフレームワークにも及びます。完璧ではありませんが、きっとうまくいくでしょう。

Storybook のDIYフレームワーク

Storybookは非常に柔軟なツールで、自分のチームのために特別に新しいフレームワークを足場にすることができます。Storybookは常にユーザーの成功を支援する優れた仕事をしているので、ウェブサイトにStorybookの新しいフレームワークを使用するための包括的なチュートリアルがあることは驚くことではありません。

Storybook とUXPinを統合して、製品をより効率的に作りましょう!

Storybookで コンポーネントライブラリ を作成したら、それをUXPinに簡単にインポートすることができます。1分程度で完了するほど簡単です。

UXPinとStorybookを統合すると、Storybookの中でUIコンポーネントライブラリを管理できるようになります。変更を加えると、UXPinのライブラリにも自動的に反映されます。このようにして、Storybookで信頼できる唯一の情報源を維持し、Mergeテクノロジーを使用してUXPinで完全に機能するプロトタイプを作成することができます。

StorybookとMergeは、コードベースのデザインの力を誰もが使えるようにすることで、開発プロセスをより効率的かつ効果的にします。あなたは効率性を求めていますよね？今すぐStorybookとの統合を行い、その効果を実感してください。

The post コンポーネントライブラリを構築するためのStorybookフレームワーク appeared first on Studio by UXPin.

デザインシステムが、高品質な製品を効率的に提供するのに必要なツール、ガイダンス、コンポーネント、サポートを確実に提供できるようにする上で、「テスト」は不可欠です。組織の基準や期待に確実に応えるために、コンポーネントライブラリ、ドキュメント、シンタックス、アクセシビリティなどのあらゆる側面を査定するものとして「デザインシステムテスト」というがあります。

本記事では、デザインシステムテスト、実施するタイミング、役割と責任、手順、使用できるツールについて見ていきます。

UXPin MergeのCode-to-Design（コードからデザイン）のワークフローによって、デザインシステムで「信頼できる唯一の情報源（Single source of truth）」を構築し、運用負荷を軽減してエラーを最小限に抑えましょう。詳しくは、Merge のページをぜひご覧ください。

デザインシステムテストとは

デザインシステムテスト（またはデザインシステム監査）はデザインシステムの機能性、使いやすさ、ドキュメント、品質、および一貫性を評価します。この評価によって、デザインシステムがユーザーやステークホルダーの要請や期待を満たしているかの確認を目的としています。

一般的なデザインシステムテストプロセスには、以下のようなものがあります：

• コンポーネントテスト： 個々の部品についての、視覚的な整合性や期待通りの機能であるかの評価。
• パターンテスト： UI（ユーザーインターフェース）やユースケースにおいて、パターンが一貫性があるかの確認。
• デザインファイルテスト： デザインファイルとレポジトリのコンポーネントの比較による、デザイナーとエンジニアが同じUIエレメントやパターンを共有しているかの確認。
• アクセシビリティテスト： コンポーネント、パターン、テンプレートがデザインシステムのアクセシビリティ の標準とガイドラインに適合しているかの検証。
• クロスプラットフォームおよびクロスブラウザテスト： 様々なデバイス、プラットフォーム、OS、ブラウザ間で、デザインシステムとコンポーネントが一貫して動作するかの確認。
• 性能テスト： 読み込み時間や応答性など、デザインシステムが製品全体の性能に与える影響の測定。
• ユーザビリティテスト： ユーザーリサーチの分析やインタビューの実施による、デザインシステムがポジティブなUX（ユーザーエクスペリエンス）に対応しているかの確認。
• ドキュメントのテスト： ブランド、コンテンツ、コード、デザインなどのガイドラインを含めたデザインシステムのドキュメントをレビューすることによる、それが包括的でユーザーに適切なサポートを提供するかの確認。

デザインシステムテストが重要な理由

デザインシステムテストは、UIライブラリと製品の整合性を保つうえで不可欠です。エラーや矛盾を放置しておくと、製品チームやエンドユーザーにとってすぐに大きな問題に発展してしまいますからね。

また、デザインシステムは「信頼できる唯一の情報源（Single source of truth)」として機能することを主な目的としています。デザインシステムが侵害されると、製品の一貫性と整合性を保つための信頼できるソースとしての役割を果たせなくなってしまいます。

デザインシステムテストを行う頻度

デザインシステムテストの頻度は、以下のような要因次第です：

• デザインシステムの規模や複雑さ
• デザインシステムの成熟度
• 人材、時間、資金などの利用可能なリソース
• 製品エコシステム
• アップデート頻度

ここでは、組織がデザインシステムテストを検討する場面とその間隔をご紹介します。

定期的な間隔でのテスト

デザインシステム（DS）チームは、毎月、四半期、隔年など、定期的なテストのスケジュールを作成するでしょう。そして、固定されたテストプログラムにより、DSチームはステークホルダーやユーザーの期待を考慮して計画を立てることができます。

大幅なアップデートや追加を行った後

デザインシステムチームは、大きなアップデートの後や新しいコンポーネント、パターン、ガイドラインを導入する際に、デザインシステムを監査するのが一般的です。この監査により、UIの一貫性と整合性の高い基準を維持しながら、変更点が確実に期待通りに機能するようにします。

ユーザビリティ、アクセシビリティ、性能に関する問題への対応

製品チームがユーザビリティ、アクセシビリティ、または性能の問題を発見した場合、デザインシステム全体を監査することが極めて重要です。監査によって、問題の深さと適切な是正措置が査定されます。

問題が発生するまで待つのは、デザインシステムテストにとって良い戦略ではないので注意しましょう。テストを定期的または随時で行うなど、より予防的なアプローチを採用する方が問題の早期発見や修正においても有効的です。

アジャイル開発

アジャイル開発を実践している組織では、開発プロセスに定期的なテストを組み込んでいる場合があります。このアジャイルアプローチは、テストがより頻繁に行われ、場合によってはスプリントやリリースサイクルに統合される可能性があるということです。

デザインシステム監査の責任者

全体的なデザインシステム監査には、さまざまな専門知識を備えた部門を超えたチームが必要である一方、小規模なテストより特定のテストの場合、１人または２人の専門家だけで済む場合もあります。

規模や範囲にもよりますが、デザインシステムテストで必要な役割リストをご紹介します。また、企業によっては、以下に挙げる複数の仕事を一人で担っている場合もあります。例えば、UXデザイナーはデザイン、アクセシビリティ、コンテンツを評価し、エンジニアはコンポーネントとQAを担当することがあります。

• UX/UIデザイナー：コンポーネントやパターンの視覚的な一貫性、使いやすさ、全体的な UXを評価する。デザイン関連のドキュメンテーションやツール、UIキットをチェックする。
• デベロッパー：フロントエンドとバックエンドのデベロッパーは、コンポーネントの機能、シンタックス、性能、実装を評価する。プラットフォームやブラウザを問わず、ライブラリのテストも行う。
• アクセシビリティの専門家：アクセシビリティの基準やガイドラインに関する最新の専門知識を持つチームメンバーであり、デザインシステムを組織や地域のアクセシビリティ要件に適合させるためのテストを行う。
• QA（品質保証）エンジニア： デザインシステムの品質基準に従ってテストを作成し、実行する。
• プロダクト/プロジェクト マネージャー：多くの企業では、テストをプロジェクトのように扱い、タイムラインの設定、リソースの配分、目的・優先順位の確認など、プロセスの調整と監督を行うチームメンバーを必要としている。また、このポジションは調査結果をまとめ、次のステップを含む最終報告書を作成することもある。
• コンテンツデザイナー/コピーライター：デザインシステムのドキュメント、コンテンツガイドライン、メッセージング、トーン、ボイスなどをレビューし、コンポーネントやパターン間の一貫性と正確さを確認する。

デザインシステムテストのワークフロー

ここでは、デザインシステム監査を実行するために推奨する手順をご紹介します。

1. 目的・目標の設定： 矛盾の特定、アクセシビリティの評価、性能の査定など、デザインシステムテストの目的と目標を設定する。
2. プランの作成： テスト計画は、監査の範囲、方法、リソース、スケジュール、成功基準を概説するものであり、効果的なテスト計画には、テストの指針、役割分担、チームメンバーの連携が必要。
3. テストケースとシナリオの特定： デザインシステムのさまざまな部分を評価するために、チームメンバーが使わないといけない具体的なテストケースとシナリオを決定する。それは、KPI（重要業績評価指標）と性能を長期的に測定できるようにするために、各テストに対して一貫性がないといけない。
4. ツールやリソースの準備：テストフレームワーク、アクセシビリティチェッカー、性能分析ツール、ユーザビリティテスト手法など、チームメンバーが作業を完了するのに必要なツールやリソースを収集する。
5. テストの実行： 計画に従ってテストを実施し、その結果や問題点を文書化する。
6. テスト結果の分析： テストをレビューし、パターン、傾向、懸念事項を特定する。問題の重大性を判断して修正に優先順位をつけ、UXまたは技術バックログに追加する。
7. 報告書の所見および推奨事項： デザインシステムのユーザーやステークホルダー向けに、テスト結果、所見、推奨事項を記載した包括的な報告書を作成する。
8. 問題の修正および改善の実施： デザインシステムチームは、報告書に従って、コンポーネント、パターン、ガイドライン、ドキュメントを必要に応じて更新や変更を実施しないといけない。
9. モニタリング、再テスト、反復の実施： 問題を適切に解決していることを確認すべくリリースをテストする。変更をモニタリングして効果を評価し、望ましい結果が得られるまでテストと反復を繰り返す。

デザインシステムテストのためのツール

デザインシステムのさまざまな側面をテストするのに利用できるツールはたくさんあります。ここでは、UXPinが推奨するツールをカテゴリー別でご紹介します。

視覚的整合性のテスト

• Percy： コンポーネントやレイアウト間の視覚的な変化や不整合を検出できる、視覚的なテストのツール。
• Chromatic： UIのフィードバック収集、ビジュアルテスト、ドキュメントの作成を自動化する。
• SauceLabs Sauce Visual Testing：開発ライフサイクルの早い段階で、全ブラウザと解像度で視覚的なエラーや不整合を発見および修正する。

機能テストと統合テスト

• Jest：React、Vue、Angular などのJavaScriptライブラリやフレームワークのコンポーネントテストや統合テストに対応する JavaScriptのテストフレームワーク。
• Cypress：ブラウザベースの Webアプリケーションをテストするためのエンドツーエンドのテストツール。

アクセシビリティテスト

• axe：Webアプリケーションのアクセシビリティ問題の特定および解決のためのアクセシビリティテストのツール。
• Lighthouse：Google が提供するオープンソースツールで、アクセシビリティ、性能、その他のベストプラクティスの自動監査を提供する。
• WAVE：アクセシビリティの問題を特定し、解決するための Web アクセシビリティ評価ツール。
• UXPin：カラーコントラストチェッカーや色覚異常シミュレーターが内蔵されており、デザイナーはその場で UI をテスト行うことができる。

クロスプラットフォーム および クロスブラウザテスト

• BrowserStack：Web アプリケーションをさまざまな環境でテストするために、さまざまなブラウザやデバイスへのアクセスを提供するプラットフォーム。
• Sauce Labs：ブラウザ、プラットフォーム、デバイスにまたがる自動テストと手動テストのための、クラウドベースのプラットフォーム。

性能テスト

• WebPageTest：読み込み時間、レンダリング速度、最適化の推奨など、Webページの性能を測るためのオープンソースツール。
• Google PageSpeed Insights（グーグル・ページスピード・インサイト）： Web ページの性能を分析し、改善のための提案を行う無料ツール。
• Digital.ai Continuous Testing：様々なメーカーの OS を搭載したデバイスやブラウザで、機能、性能、アクセシビリティのシナリオを継続的にテストする。

ユーザビリティテスト

• UserTesting：リモートでユーザビリティテストを実際のユーザーと実施し、そのフィードバックやインタラクションを取得するためのプラットフォーム。
• Ethnio:：インターセプトを使って、製品や機能を使用する参加者をスカウトするためのリサーチオプスプラットフォーム。特定のコンポーネントやパターンと相互作用するユーザーからのフィードバックを得るのに有効。
• Optimal Workshop：カードソーティング、ツリーテスト、ファーストクリックテストなどの、ユーザビリティテストツール群。
• UXPin Merge：正確な高忠実度ユーザビリティテストのために、デザインシステムのコンポーネントを使ってプロトタイプを構築するためのツール

デザインシステムのドキュメントと連携

• Storybook：UIコンポーネントを構築・整理するためのオープンソースツールで、これによってデザインシステムテストが協調的かつ身近なものになる。また、Storybookは UXPinと統合され、デザインと開発のギャップを埋めることができる。
• UXPinデザインシステム：ドキュメント、アセット、スタイルガイドを共有したデザインシステムを構築、管理、拡張するためのツール。

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

特にデザインと開発の間に「信頼できる唯一の情報源」がない場合、メンテナンスとガバナンスはデザインシステムで最大の課題になります。

UXPin Mergeでは、デザインシステムのレポジトリとUXPinのデザインエディタを同期させ、デザインとエンジニアリングチームが同じコンポーネントライブラリを使用することで、デザインと開発のギャップを埋め、組織全体で「信頼できる唯一の情報源」を作成します。

UXPin Mergeのコードからデザインワークフローについての詳細と、メンテナンス、連携、ガバナンスの向上など、デザインシステムにどのようなメリットをもたらすかについてぜひご体験下さい。詳しくはMergeのページをご覧ください。

The post デザインシステムテストとは？定義、メリット、プロセス紹介 appeared first on Studio by UXPin.

UXPinのnpm統合により、デザインチームはより忠実でコード同様の機能でプロトタイプが作成できるようになりました。これまではエンジニアにコーディング依頼が必要だったところを、UXPinが持つコンポーネント駆動型プロトタイピング機能によって、デザイナーでも高忠実度なプロトタイプ作成の実現が可能です。

npm統合で、簡単にコンポーネントライブラリをUXPinのデザインツールにインポートできます。これには、技術面での複雑な設定は不要で、共有コンポーネントのインタラクティブ性を最大限に活かすことができるのです。今回は、Mergeを使ってコンポーネントの統合が実際にいかに速く行えるのか見ていきましょう。

さっそくGitレポジトリ、Storybook、または最新のnpmからUXPinにコンポーネントを統合させてみましょう。UXPin Mergeテクノロジーついての詳細は、こちらのページをぜひご覧ください。

UXPin Merge とは

npmについてお話しする前に、UXPin Mergeの概要を説明します。UXPin Mergeはコンポーネント駆動型プロトタイプを実現するコードベースのテクノロジーです。デザイナーはゼロからデザインする代わりに、レポジトリからProduction ReadyなUI要素を使用して、高忠実度で完全に機能するプロトタイプを構築することができます。

デザイナーはビジュアル要素、エンジニアはその背後にあるコードに取り組むことで、製品開発チーム全体で「信頼できる唯一の情報源（Single source of turth）」が構築されます。これによって、実際に、UXPin Mergeを導入したPayPalやTeamPasswordのチームは、デザインの品質、スピード、一貫性向上に成功しました。

UXPin で「npm統合」って何？

UXPin Mergeを非公開のデザインシステムで使う場合、同期のためのレポジトリをセットアップする上で技術的な知識が必要になってしまうのですが、オープンソースのコンポーネントライブラリを使う場合だと、デザインチームは直感的なダッシュボードを使用して簡単にnpm統合を完了できます。

また、デザイナーはMergeコンポーネントマネージャー機能を使って、コンポーネントのインポートとプロパティを管理することができます。たとえば、 Bootstrapのコンポーネントライブラリまたは以下９つのVariants（変数）からButtonをインポートできます：

• プライマリー（primary）
• セカンダリー（secondary）
• 成功（success）
• 危険（danger）
• 警告（warning）
• 情報（info）
• 明るい（light）
• 暗い（dark）
• リンク（link）

これらのVariantsはUXPin上の画面右にあるプロパティパネル（Properties Panel）でドロップダウンとして表示されます。Mergeはほとんどのコンポーネントにホバーステートも含んでいるため、デザイナーはこのような詳細を気にせず、プロトタイピングにすぐに取り掛かれることができます。

デザインチームは、React Bootstrapのドキュメントから、インポートするコンポーネントのプロパティを探すことができ、全てのプロパティまたはプロジェクト関連のもののみをインポートすることもできます。

 Bootstrapを使うメリット

 BootstrapはReact、Vue、Angularで利用可能な最も有名なモバイルファーストのフロントエンドフレームワークです。

UXPinのnpm統合では、React Bootstrap のコンポーネントライブラリを使用しますが、VueまたはAngularのバージョンをインポートするにはStorybook統合で可能です。

BootstrapはレスポンシブなWebサイト・Webアプリ開発に最適ですが、モバイルアプリのデザインプロジェクトでもReactライブラリを使うこともできます。Bootstrapには、フォーム要素、レスポンシブテーブル、その他の関連コンポーネントが豊富に揃っているため、Webベースのエンタープライズ向け製品に適しています。

なお、Boostrapは総合的なフロントエンドフレームワークなので、Bootstrapのサンプルページでできることを見ておくことをおすすめします。

UXPin Mergeで Bootstrapの npm 統合

npmパッケージ（react-bootstrap）を使って、BootstrapのコンポーネントをUXPinのデザインエディタにインポートできます。Mergeコンポーネントマネージャーによって、各UI要素と利用可能なプロパティをインポートが可能です。

UXPinのコンポーネント駆動型のプロトタイピングで、要素は同じレポジトリから取り込めることから、デザインチームはエンジニアと同じ忠実度と機能性を手に入れることができます。エンジニアがレポジトリのコンポーネントでできることを、デザイナーも同様にUXPinのプロパティパネルで実現することができます。

また、フレームワークのドキュメンテーションにあるBootstrapのReact propsを使用することでこれらのプロパティを割り当てることができます。

Merge コンポーネントマネージャでプロパティの割り当て

Mergeコンポーネントマネージャーはnpmコンポーネントをインポートおよび管理するためのハブ的存在であり、プロジェクトを完成させるために必要な数だけインポートすることができます。

また、インポートするプロパティ数のコントロールも可能です。例えば、Bootstrap Buttonの［プライマリー］と［セカンダリー］Variantsのみを使いたい場合、全てのプロパティをインポートするのではなく、使いたいプロパティ２つのみをインポートすればいいだけです。

UXPinを React Bootstrapの npm パッケージにつなげる

ステップ１

UXPinのDashboard（ダッシュボード）画面に移動し、［+ New Project（新規プロジェクト ）］をクリックします。

ステップ２

プロジェクトに名前を付け、［Create New Project （プロジェクトの新規作成）］をクリックします。

ステップ３

［Design with Merge components （Mergeコンポーネントでデザインする）］と ［+ Add new Library （ライブラリの追加）］をクリックします。

ステップ４

［Import React Components with npm integration（npm統合でReact Componentsをインポートする）］を選択し、［Next（次へ）］をクリックします

ステップ５

ライブラリに名前を付けます。この名前は参考用のためだけなので、インポートには影響しません。

Mergeを動作させるには、npm統合に 『React Bootstrap（react-bootstrap）』と『 Boostrap（bootstrap）』という２つのBootstrapパッケージが必要です。

最後に、コンポーネントのプロパティをUXPinで動作させるには、BootstrapのCSSファイルへのパスが含まれてないといけません。（パスはReact-Bootstrap のドキュメントのCSSの下にあります。）

• bootstrap/dist/css/bootstrap.min.css

React Bootstrapコンポーネントのインポート

上記の手順を完了すると、UXPinはMergeのコンポーネントマネージャー にリダイレクトします。

ステップ１

左側のサイドバーから、［Open Merge Component Manager （Mergeコンポーネントマネージャーを開く）］をクリックします。

Mergeコンポーネントマネージャーが新規タブで開きます。

ステップ２

［Add new component （新しいコンポーネントの追加）］をクリックします。

ステップ３

インポートするコンポーネントの名前を入力します。

正しい命名規則は、React Bootstrapのドキュメントにあります。

このチュートリアルでは、Bootstrap Buttonをインポートして、［Components （コンポーネント）］という新しいカテゴリーを作成してみます。ここでは、デザイナーとエンジニアが同じ基準点持つためにReact Bootstrapのドキュメントと同じカテゴリを使うことをお勧めします。

１回のインポートで複数のコンポーネントを追加できるので、ステップ２と３の繰り返しは省略されます。

［Import Components（コンポーネントをインポートする） ］をクリックします。

ステップ４

右上の［Publish Changes（変更を公開）］をクリックして、インポート処理を初期化します。

新しいコンポーネントで初めてこの作業を行う際は、少し時間がかかるかもしれません。

ステップ５

インポートが完了したら、［Refresh Library （ライブラリの更新）］をクリックし、プロジェクトライブラリの変更を更新します。

ここまで進めると、左サイドバーのカテゴリーに[Components]、その中に[Button]があります。

ステップ６

［Button］をクリックしてプロパティを追加してみましょう。このReact propsは、React Bootstrapのドキュメントで、Components > ButtonのAPIの下にあります。

Mergeコンポーネントマネージャーでコンポーネントプロパティの追加

React Bootstrap のドキュメントを使って、Buttonプロパティをいくつか追加します。

Buttonラベル

ステップ１

React BootstrapのButtonラベルは、childrenプロパティを使って、次のように設定します：

• プロパティ名：「children」と入力（小文字を使用する）
• 表示名：（これは必須ではないですが）デザイナーとエンジニアの両方が使うわかりやすいものにする（ 統一感があるように 、ここでは『label』とします。）
• 説明：デザイナーに簡単な説明や指示を加える
• プロパティの種類：String（ストリング）型
• プロパティコントロール：『textfield（テキストフィールド）』
• デフォルト値：好みで設定 （ 今回は 『Button』を選択。）

コンポーネントのプロパティを完成させると、コンポーネントのプレビューが表示され設定した通りに変更されます。

ステップ２

すべての項目を入力したら、［Add property （プロパティの追加）］をクリックします。

そして［Save Changes（変更の保存）］

最後に［Publish library changes（ライブラリの変更を公開）］

コンポーネント 駆動型のプロトタイピングをご体験ください

実際にReact Bootstrapコンポーネントとプロパティをインポートしてみると、UXPinでのプロトタイピングはドラッグ＆ドロップでレイアウトを作成するのと同じくらい使いやすいんです。ちなみに、下画像のシンプルなデザインのメール登録フォームだと、３つの Bootstrapコンポーネントを使っただけで、１分もかからずに作成できました。

 Bootstrapコンポーネントを選択すると、Mergeコンポーネントマネージャーで作成したプロパティはUXPinのキャンバス画面右側にあるプロパティパネルで表示されます。

UXPinのnpm統合でコンポーネント駆動型プロトタイピングをさっそく試してみませんか？ Bootstrapのnpmコンポーネントをインポートして、いかに早く製品のアイデア出しから開発までできるかをご体験ください。開発時間を大幅に短縮できますよ。詳しくはMergeのページをご参照ください。

The post BootstrapコンポーネントをUXPinに追加する方法 – npm統合ガイド appeared first on Studio by UXPin.