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.

MUI（Material-UI）は、Googleのマテリアルデザイン原則に基づいて構築された多くの人に使用されているReact UIフレームワークです。カスタマイズ可能なコンポーネントとスタイルで、ブランド標準に沿った組織運営が実現します。

そこで本記事では、  MUI for Figma の機能と制限について深く掘り下げます。また、MUI を UXPin Mergeと統合するという別のアプローチもご紹介します。あるスタートアップ企業がデザインプロセスで MUIのReactコンポーネントを使って製品をリデザインした実例を交えてお話しします。

主なポイント

• MUI（Material-UI）は、GoogleのマテリアルデザインがベースのReact UIフレームワークであり、ブランドガイドラインに合わせたカスタマイズが可能。
• MUI for Figmaにはデザインキットがあるが、MUIではReactライブラリのインタラクティブ機能がないため、デザインに矛盾が生じる可能性がある。
• サイズが大きく、Token Studioなどのプラグインに依存するため、パフォーマンスの問題につながることもある。
• UXPin Mergeは代替手段を提供。デザイナーがReactコンポーネントを使ってプロトタイプを作成できることで、デザインと開発のギャップを埋めることができる。
• TeamPasswordは、UXPin MergeとMUIを活用したことで製品開発ワークフローを強化し、「Code-to-Design（コードからデザイン）」アプローチによって効率性が向上したことを実証した。

UXPin Mergeにより、使い慣れたデザインツールの中でMUIのReactライブラリを使用したプロトタイプ作成とテストが可能です。詳細とアクセスリクエストはこちらのページをご覧ください。

MUI とは

MUI（Material-UI）は、Google のマテリアルデザインに基づいたコンポーネントとスタイルのセットを提供する人気のReact UIフレームワークであり、組織は、MUIのテーマ機能を使って、製品やブランドの仕様に合わせて UIライブラリをカスタマイズすることができます。

MUI を使う理由

MUIを使うことでゼロからデザインすることなく製品を構築するための包括的なデザインシステムを活用することができます。わずかな調整や修正を行うだけで、カスタムデザインシステムを構築することができるため、研究開発にかかる時間の節約につながるでしょう。

また、MUIの使用は新製品の開発にも便利です。プロダクトチームやスタートアップ企業は、テーマを変更することなくMaterial UIのライブラリを使って、テスト用のMVP（実用最小限の製品）を構築することができます。デザインシステムを活用することで、UX（ユーザーエクスペリエンス）とアクセシビリティのために最適化された包括的なライブラリを使うことができ、製品を速やかにデザインすることができるのです。

 MUI for Figma のコスト

無料のコミュニティである MUI for Figmaのライブラリがありますが、提供されているコンポーネントは限られており、サポートもありません。また、UIライブラリ全体が必要な場合は、MUIのWebサイトでMUI for Figmaのライセンスの購入が必要です。ちなみに２０２３年１０月現在、エディター１名分のライセンスは７９ドルです。大規模なチームであれば、すぐに料金がかさむ上に、毎年のライセンス更新が必要です。

このような追加料金を回避するためにも、UXPinで完全に機能するMUIのReactコンポーネントを使ってプロトタイプを作成することをおすすめします。MUIはUXPinに組み込まれているデザインライブラリの１つで、UXPin Mergeでのすべてのプランに備えられています。UXPin MergeでのMUIを使ったデザインについては、こちらをご覧ください。

Figmaでマテリアル UIを統合する方法

コミュニティページからファイルを開き、無料のFigma MUIライブラリを使うことができます。新しいプロジェクトでMUIを使い始めるには、Open in Figma ボタンをクリックしてください。

フルライブラリを使用する場合は、以下をご参考ください。

MUI for Figma のインポート法

• Figma の下書きまたは組織に移動する
• Import ボタンをクリックして、MUI ファイルをインポートする

 MUI for Figma の使用法

FigmaでMUIライブラリを扱うには、次の２つの方法があります：

１．MUIファイルで直接デザインする：この方法は無料版では問題ありませんが、フルライブラリではファイルサイズが大きくなるため、MUIはこの方法を推奨していません。

２．MUIファイルをライブラリとして使う： FigmaでMUIを使う際の好ましい方法です。これをするには以下を行います：

• Figmaのアセットパネルに移動する
• ライブラリのアイコンをクリックする
• MUIファイルをライブラリとして公開する

FigmaでMUIライブラリをカスタマイズする方法

MUI ライブラリの色をカスタマイズするには、以下の２つの方法があります：

1. Token Studioプラグイン： この方法は高速で、合成が可能。つまり、ある色を使って別の色を生成することができる。
2. Figmaのネイティブトークン： サードパーティのプラグインを使用したくない場合は、Figma のネイティブ・トークンを使って色の変更が可能。

Token Studioでグローバル設定を変更する方法

Token Studioプラグインを使うと、Border‐radiusやフォントファミリなど、コンポーネントのグローバル設定を全て簡単に変更できます。例えば以下のような感じです：

• グローバルのborder‐radiusを変更するには、プラグインを開き、［Border radius］のグループに移動して値を編集する。
• フォントファミリーを変更するには、プラグインの［Typography］のグループに移動してフォント設定を調整する。

Figma MUIのダークモードを有効にする方法

Token Studioを使って、MUIライブラリ全体のダークモードを有効にするには以下を行います：

• Token Studio のプラグインを開く
• ダークモードなど、有効にしたいグループのボックスにチェック（✓）を入れる
• Figma のカラーモードをダークモードに変更して、変更を確認するというオプションもある

Figma MUIの課題と限界

MUIのFigmaライブラリは、UIデザインや静的プロトタイプには優れていますが、正確なテストを行うためのインタラクティブ性には欠けています。ここでは、デザイナーが FigmaのMUIライブラリを使う際のよくある問題を見ていきましょう。

 MUI for Figma は、UIデザインキットであり、インタラクティブなデザインシステムではない

Figma MUIライブラリで、ゼロからデザインする時間が何時間も節約されますが、MUIのインタラクションを提供するものではありません。そのため、デザイナーはプロジェクトごとに Figmaでインタラクションを設定しなければいけません。

また、Figmaのコンポーネントのインタラクティブ性を追加することは、デベロッパーが使うMUIのReactライブラリと一致しません。コンポーネントの見た目は似ていますが、デザイナーは 正しいアクション、ステート、アニメーションを確実に実装すべく、MUI のドキュメントに忠実に従わないといけません。

編集可能なコンポーネント

デザインシステムチームは、メインのライブラリのファイルからMUIコンポーネントを管理し、不正な変更を防ぐことができます。一方で、デザイナーはインスタンスを切り離したり、UI要素を調整したりすることができるため、デザインドリフトや不整合が生じてしまいます。

プラグインへの依存

MUI for Figmaを正しく機能させるには、Token Studioのようなプラグインが必要です。しかし、プラグインは複雑さと潜在的な互換性の問題を別のレイヤーにもたらす可能性がある上で、Token Studioはプレミアム機能であることから月々のコストがかさみます。

チュートリアルの 「Getting Started」で、MUIは、Token StudioプラグインとFigmaのネイティブ・トークンとの同期に問題がある可能性があり、適切に管理されないと不整合が生じる可能性があることを記載しています。

パフォーマンスの問題

MUIではFigmaのファイルサイズが大きいため、デザインチームは、特にライブラリファイル内で直接作業する場合、パフォーマンスに問題が生じる可能性があります。

 MUI for Figma の代替案

MUIライブラリを使った最適なデザイン方法として、UXPin Mergeを使って、エディタ内でReactコンポーネントを使用したプロトタイプの作成という方法があります。

UXPinで MUIを使うには以下の２つの方法があります：

1. 内蔵されたMUIライブラリの使用
2. カスタムMUIライブラリの連携

UXPinでのMUIライブラリの使い方

UXPinには、MUI、Fluent UI、Ant Design、MUI、Material UI、UXPin Boilerplateなど、Mergeではいくつかのビルトインライブラリが用意されています。それらはすべて、GitHubのレポジトリからのインタラクティブコンポーネントを備えたReactライブラリです。

UXPinでMUIライブラリを使用する利点は、スタイリングインタラクティブ機能が各コンポーネントに「組み込まれている」ため、デザイナーがそれを設定する必要がないことです。また、マスターインスタンスからコンポーネントをデタッチして変更することもできないため、レポジトリで定義されたデザインシステムを使わないといけません。

デザインライブラリのサイドバーからUI要素をキャンバスにドラッグし、プロパティパネルで再定義されたReactのプロップを調整するだけです。

このようなビルトインライブラリでは、デザイナーはUI（ユーザーインターフェース）の構築と、スタイリング、変数、ステート、ナビゲーションなどの定義済みの MUIプロパティの調整だけに集中することができます。

また、ブランドカラーやスタイリングでカスタムMUIデザインシステムを使いたい場合は、Mergeで他の統合の使用をおすすめします。

カスタムの MUIライブラリを UXPinに同期する方法

UXPin Mergeは、以下２つの統合機能により、テーマ別の MUI ライブラリなどのあらゆるデザインシステムをインポートすることができます：

• Git 統合（Reactのみ）：Reactのライブラリの統合によって、 パターン、バージョン管理、および JSXのプリセットを含むなどすべてのMerge機能にアクセスできる。
• Storybook統合： React、Vue、Angular、Ember、その他のフロントエンド技術など、あらゆるStorybookで動作する。

この２つの統合のセットアップには技術的な入力が必要ですが、一度設定すると、Mergeは自動的にUXPinにアップデートを同期します。デザイナーとエンジニアは常に同じコンポーネントライブラリを使って、組織全体で「信頼できる唯一の情報源（Single source of truth）」を作成することができます。

UXPinでMUIコンポーネントを使用する方法

UXPinのビルトインライブラリを使おうが、カスタムの MUIデザインシステムを使おうが、ワークフローは同じであり、ライブラリは、キャンバスの左側にあるDesign System Libraries（デザインシステム ライブラリ）の下にあります。

Mergeのデザインシステムを選択すると、ライブラリのコンポーネント、カラー、タイポグラフィ、アセットが左サイドバーに表示されます。UI要素をクリックまたはキャンバス上にドラッグして、簡単にUIを構築します。

Mergeが非デザイナーにとってデザインをより身近なものにする

デザインツールは非デザイナーにとっては大変なものです。多くのデベロッパーは学習曲線をマスターするヒマはなく、そうなると彼らは、大体慣れ親しんだもの、つまり「コードを書くこと」に戻ります。

ただ、コードのプロトタイプはテストには最適ですが、時間とコストがかかり、デベロッパーは結局、ユーザビリティの問題やその他の矛盾を抱えた製品や機能をリリースすることになります。

TeamPasswordがMergeとMUIを使って再デザインと高速拡張を実現した方法

パスワード管理ツールを提供するTeamPasswordは、UXPinに切り替える前にこの課題に直面しました。２名構成の開発チームにはデザインスキルがなく、速やかに進めるために最小限のテストしか行わずにアップデートをプッシュしていました。また、時代遅れの技術スタックを使っていましたが、リソースが限られていたため、製品をゼロから作り直すことはできませんでした。

また、TeamPasswordにはUXデザイナーがいないため、エンジニアがデザイン、プロトタイプ作成、テスト、プログラミング、QA、出荷のすべてを自分たちで行わないといけません。

製品の再デザインのために MUIとReactに切り替えることにしました。彼らは、毎回コードを書いたり編集したりすることなく、Reactのコンポーネントを使ってプロトタイプを作成してテストするソリューションを求めており、シンプルなデザインワークフローを提供するツールが必要でした。

そこで、UXPinのMergeテクノロジーが選択肢として挙がり、TeamPasswordのデベロッパーは、製品固有のパターン、テンプレート、UIなどのカスタムのReact MUIライブラリを、Git統合でUXPinに同期し、インタラクティブなプロトタイプを使って新製品をテストできるようにしました。

MergeとMUIを使うことで、TeamPasswordsの製品開発ワークフローに革命がもたらし、２名構成の開発チームは、デザインから最終製品に至るまで非常に効率的かつ効果的になったのです。

MUI を使ったプロトタイプに「Code-to-Design（コードからデザイン）」が適している理由

Figmaのデザインシステムは、UIデザインや基本的なプロトタイプ作成には最適ですが、正確なテストを行うためのインタラクティブなプロトタイプを作成するには、外部ツールやプラグインに頼らないといけません。この時代遅れの「デザインからコード」へのワークフローは、時間もコストもかかるので、非効率的です。

そこでUXPinの「Code-toDesidn（コードからデザイン）」のワークフローだと、MUIのReact コンポーネントをデザインプロセスに取り入れ、プロダクトチームに以下のような多くのメリットをもたらします：

• コードによって定義された「信頼できる唯一の情報源（Single source of truth）」によって、デザインと開発のギャップを埋める。
• より少ない文書と説明によるシームレスなハンドオフ。
• デザインシステムのレポジトリにプロパティを確定することで、ドリフトや不整合がなくなる。
• ゼロからのデザインやプログラミングが不要なため、市場投入までの時間が短縮され、組織の競争力が強まる。
• 一元化されたデザインシステム管理は、少ないリソースで多くの運用負担を軽減し、それによって運用チームがより効果的になる。

Mergeのテクノロジーでインタラクティブプロトタイプさっそく作ってみましょう！詳細およびアクセスリクエスト方法については、こちらのページをぜひご覧ください。

The post MUI for Figma はデザイナーに最適なソリューションか？[代替案] 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.

UXPin Mergeのコンポーネント駆動型のプロトタイプにより、デザイナーは最終製品とそっくりなレプリカを作成することが可能になりました。UXPinは静的なグラフィックをレンダリングする他のデザインツールとは違い、コードによって駆動するためデザイナーは忠実度の高いプロトタイプを作成できるのです。

UXPinのnpm統合により、デザイナーはオープンソースのデザインシステムからコンポーネントやパターンを自由にインポートできます。既存のデザインシステム用の新しいパターンを作成するために単一のUI要素が必要な場合もあれば、デザインスプリント中に完全に機能する MVP （実用最小限のプロダクト）を構築するためにnpm統合を使用する場合もあります。

UXPin Mergeがどのようにコンポーネント駆動型のプロトタイプによってデザインを強化できるか体験してみませんか。アクセスのリクエスト方法は こちらのページでご確認ください。

 npm のコンポーネントを使ったプロトタイプについて

 UXPinの npm 統合と、プロトタイプにインポートできるパッケージについて説明する前に、まずは npmライブラリを使ったコンポーネント駆動型プロトタイプを実現する技術「Merge」についての理解が必要です。  

企業はMergeにより、デザイナーがエンジニアと同じコンポーネントライブラリを使ってプロトタイプを作成することができるようになります。それと同じように、リポジトリにホストされたデザインシステムをUXPinのデザインエディタと同期させることもできます。  

このような「既製」の UI 要素には、デザインシステムのコードによって確定されたプロパティとインタラクティブ機能が含まれています。Mergeのコンポーネントは完全なレプリカであるため、最終製品と同じ見た目であり、機能性を持ちます。

デザイナーは Mergeコンポーネントをビルディングブロックのように使い、ドラッグ＆ドロップで簡単に新しいUIや完全に機能するプロトタイプを構築します。また、Pattern（パターン）を使って UI要素を組み合わせたり、新しいコンポーネントを構築することもできます。

また、Mergeの最も魅力的な機能は「デザインと開発を同期させる機能」であり、デザインシステムのリポジトリを経由して、組織全体で使うことができる「信頼できる唯一の情報源（Single source of truth）」を作成します。さらに、リポジトリへの変更は自動的にUXPinに同期され、製品チームにも通知されます。

１．Ant Design

  Ant Designは、中国の巨大テック企業である Ant Groupによって開発および維持されているオープンソースのデザインシステムです。コンポーネントライブラリは、React、Angular、Vue で利用可能で、クロスプラットフォームやモバイルアプリケーションを構築するための Ant Design Mobile も含まれます。

Ant Designは、B2C製品、エンタープライズアプリケーション、Webサイト、クロスプラットフォームアプリのためのコンポーネントを備えた「オールラウンダー」であり、アイコンセット、ダークモード、アニメーション、インタラクティブ機能も備えています。

Ant Design npm のパッケージをインポートする

  以下は、Ant Designの npm 統合での ライブラリ設定です：

• ライブラリ名：Ant Design NPM – ライブラリ名はインポートに影響しない。
• パッケージの詳細：antd – Ant Designの npm レジストリに対応していないといけない。
• アセットの場所：antd/dist/antd.css – Ant Design React のプロップのスタイリングに必要。

  その他はすべてデフォルトのままにして、「Save Changes （変更を保存）」をクリックします。

さらに読む： 中国初の Ant Design とは？UXPin連携方法と npm 統合徹底ガイド

２．Bootstrap

  Bootstrapは、最も古くて大規模なレスポンシブ対応なフロントエンドのフレームワークの１つです。エンジニアは、Webサイトや Webアプリケーションのプロトタイプを作成する際に、基本的な CSSスタイリングやJavascript機能でBootstrapをよく使います。

UXPinの npm 統合では React Boostrap が使われており、オリジナルのBootstrapと同じアウトオブボックス機能と特徴が備わっています。ちなみに、レスポンシブ WebサイトやWebアプリケーションのプロトタイプには、React Bootstrapがオススメです。

React Bootstrap の npm パッケージをインポートする

  以下は、React Bootstrapの npm 統合でのライブラリ設定です：

• ライブラリ名：Bootstrap NPM Integration – ライブラリ名はインポートに影響しない。
• パッケージの詳細：react-bootstrap – React Bootstrapの npm レジストリに対応していないといけない。
• Dependency package の名前：bootstrap – React BoostrapをUXPinで動作させるには、Bootstrapのdependency パッケージが必要。
• アセットの場所：bootstrap/dist/css/bootstrap.min.css – React Boostrapのプロップのスタイリングに必要。

  その他はすべてデフォルトのままにして、「Save Changes（変更を保存）」をクリックします。

さらに読む： BootstrapコンポーネントをUXPinに追加する方法 – npm統合ガイド

３．MUI

MUI は、GoogleのマテリアルデザインUI に基づいて構築された Reactライブラリです。この包括的なデザインシステムには、さまざまなデジタル製品を開発するのに必要なものが全てあり、その上に２,０００以上のマテリアルデザインのアイコンが用意されています。

MUIはその包括的なコンポーネントライブラリにより、エンタープライズ製品、クロスプラットフォームアプリケーション、MVPによく選ばれています。

MUIの npm パッケージをインポートする

  以下は、MUIの npm 統合でのライブラリ設定です：

• ライブラリ名：MUI NPM – ライブラリ名はインポートには影響しない。
• パッケージの詳細：＠mui/material – MUIの npm レジストリに対応していないといけない。

MUIは 、React Boostrap や Ant Design とは違ってUXPinで動作するために依存関係やアセットを必要としません。他のすべてをデフォルトのままにして、[Save Changes（変更を保存）]をクリックします。

さらに読む： npm統合 – MUIコンポーネントのUXPinへ導入のご案内

４．Semantic UI

  Semantic UIはBootstrapに代わる優れたフレームワークです。Semantic UI Reactのフレームワークには、よりモダンな美しさ、シンプルな機能、高度にカスタマイズ可能なコンポーネントがあります。また、Semantic UIには、世界で最も広範なアイコンライブラリである FontAwesome ￥が組み込まれています。

Bootstrapのように、Semantic UIはWebサイトや Web アプリケーションのプロトタイプに最適です。

Semantic UI Reactの npm パッケージをインポートする

  以下は、Semantic UI React の npm 統合 でのライブラリ設定です：

• ライブラリ名：Semantic UI – ライブラリ名はインポートには影響しない。
• パッケージ詳細：semantic-ui-react – Semantic UI React の npmレジストリに対応していないといけない。
• Dependency package の名前：semantic-ui-css – Semantic UI React が UXPin で動作するには、Semantic UI CSSのdependency が必要。
• アセットの場所：https://cdn.jsdelivr.net/npm/semantic-ui@2/dist/semantic.min.css – Semantic UI の React props のスタイリングに必要。

  その他はすべてデフォルトのままにして、「Save Changes（変更を保存）」をクリックします。

さらに読む： ライブラリ設定は React Bootstrapに似ています。Bootstrap のチュートリアルのステップバイステップのガイドに従い、Semantic UI Reactのドキュメントを使って、ライブラリとコンポーネントの設定を適宜置き換えてください。

５．Carbon Design System

  Carbonは IBMが開発および維持するデザインシステムで、React、Angular、Vueのバージョンがあります。このシンプルかつ包括的なデザインシステムには、大規模なコンポーネントとパターンライブラリ、アイコンセット、ピクトグラム、モーション、テーマ設定の指示が含まれています。

Carbon は、B2Bやエンタープライズ製品のデザインに最適なデザインシステムであり、Carbon のデータ可視化ドキュメントは、ダッシュボードやレポートのUI を開発する製品チームに最適です。  

Carbon Design Systemの npm パッケージをインポートする

  以下は、Carbon Design System React の npm 統合での ライブラリ設定です：

• ライブラリ名：Carbon NPM – ライブラリ名はインポートに影響しない。
• パッケージの詳細：carbon/react – Carbon Design Systemの npm レジストリに対応していないといけない。
• アセットの場所：https://unpkg.com/carbon-components/css/carbon-components.css – Carbon Design System の React のスタイリングに必要。

その他はすべてデフォルトのままにして、「Save Changes（変更を保存）」をクリックします。

６．Grommet

  Grommet は React ベースのフレームワークで、アクセシブルでレスポンシブなモバイル主導型のプロトタイプを作るのに適しています。このデザインシステムは、Netflix、Uber、Hewlett Packard で使用されており、簡単にテーマ設定ができるので、ぜひ試してみてください。

Grommet の npm パッケージをインポートする

  以下は、Grommetの npm 統合での ライブラリ設定です：  

• ライブラリ名：Grommet NPM
• パッケージ詳細：grommet – Grommet の npm レジストリに対応していないといけない
• アセットの場所：https://v2.grommet.io/components　

  その他はすべてデフォルトのままにして、「Save Changes（変更を保存）」をクリックします。  

Semantic UIのボタンをキャンバスに追加して選択すると、同じプロパティが UXPinのプロパティパネルに表示され、そのプロパティを調整することで、ボタンのスタイルを即座に変更することができます。

npm コンポーネントをUXPinにインポートする方法

  Mergeでの npm 統合により、エンジニアのサポートがなくても、デザインチームは Reactコンポーネントをインポートおよび管理するために必要なコントロールと柔軟性をUXPinで得ることができます。

MCM（Merge コンポーネントマネージャー）を使って、デザイナーはライブラリの npm パッケージを介して各コンポーネントとプロパティをインポートできます。コードは不要で、セットアップも数分で完了します。  

デザイナーは、このオープンソースのコンポーネントを使い、自社デザインシステムの新しいパターンを構築したり、完全に機能するUI要素を使ってMVP（最小実行可能製品）を作成したりすることができます。

MCM（Mergeコンポーネント マネージャー）の使用

  MCM（Merge コンポーネントマネージャー）は、デザイナーが npm でインポートしたコンポーネントライブラリを管理する場所です。

コンポーネントをインポートするときは、ライブラリのドキュメントと命名規則に従う必要があります。UXPinでの npm 統合は、リポジトリの命名規則を使ってコンポーネントとそのプロパティを見つける必要がありますが、React propsを間違って参照してしまうと、MCMではそれを見つけることができません。

Semantic UIのボタンを使って、コンポーネントをインポートするときに React propsを参照する方法を見てみましょう。このReact propsは、デザインシステムのドキュメントで見つけることができます。

なお、コンポーネントのプロパティをインポートする場合、MCMのプロパティ名はドキュメントにある React prop名と一致していないといけません。

この場合、Semantic UIのボタンにラベルを与える 子プロップをインポートしています。

デザイナーが UXPinのプロパティパネルで目にするのが表示名になります。

このスクリーンショットで見ることができるように、children（子）、circular（円形）、color inverted（反転色）、 secondary（セカンダリ）、size（サイズ）、type（タイプ）をインポートしました。

このようなMCMでのプロパティ名は、以下の２つのスクリーンショットにあるSemantic UIのドキュメントに対応しています。

npm コンポーネントの選択ルール

• デザイナーがnpm統合を使用できるのは、Reactコンポーネントライブラリがあるデザインシステムをインポートする場合のみで、npm パッケージを持っている必要があるため注意しましょう。
  
  
• デザインシステムは、製品のニーズに応えるものでないといけません。B2Bの製品をデザインしているのか、Web、モバイル、クロスプラットフォームのアプリケーションのプロトタイプなのか、既存のデザインシステムを補完したいのか、それともゼロから作りたいのかなどありますよね。例えば、WebサイトやWebアプリケーションを構築するのであれば、BootstrapやSemantic UIは優れた選択ですが、モバイルやクロスプラットフォームのデジタル製品には Ant Designが適しているでしょう。
  
  
• ライブラリに必要なUI要素があることを確認するために、オープンソースのデザインシステムを調査する価値はあります。また、ライブラリには、セットアップ手順や利用可能な React の propsのリストが記載されたドキュメントが必要です。これらのpropsによって、コンポーネントの色、形、インタラクティブ性、サイズ、アイコンなどのプロパティを変更できるようになります。

UXPinで npm のコンポーネントを使ってデザインしよう

ここでは、UXPin Mergeで試せる6 つの npm コンポーネントライブラリをご紹介しました。npm 統合でパッケージをテストし、コンポーネント駆動型プロトタイプがもたらすものメリットをぜひご体験ください。14日間の無料トライアルはこちらより。

The post コンポーネント駆動型 プロトタイプのための npm パッケージ６選 appeared first on Studio by UXPin.

日付ピッカーは、Web サイト、アプリケーション、ゲーム、企業向けソフトウェア、OSなどで使われる、デジタル製品のデザインにおいて最も馴染みのあるUIパターンの１つです。

そしてデザイナーは、日付ピッカーがスクリーンサイズ、OS、デバイスなどでどのように機能するかを理解し、製品の美観、機能性、全体的なUX（ユーザーエクスペリエンス）への影響をテストしないといけません。

UXデザイナーは、従来の画像ベースのデザインツールで日付ピッカーは作成できませんが、UXPin Mergeでは可能です。UXPin Mergeの技術によって、完全に機能する日付ピッカーをGitレポジトリやnpmパッケージ、さらにStorybookからインポートすることができるのです。  

UXPinに同期された日付ピッカーは、最終製品のように機能します。アートボードをリンクしてインタラクションを作成する必要はありません！Mergeへのアクセスリクエストはこちらのリンクから。

 日付ピッカー とは

  日付ピッカーは、ユーザーが特定の日付、時間、またはその両方の組み合わせを選択できるようにする UIパターンであり、フォーマットの一貫性を確保しながら、日付の取得を効率化することを目的としています。

 日付ピッカー が必要な理由

  世界では、例えば米国だと「mm/dd/yyyy（月/日/年）」のように「日」の前に「月」を置くのに対し、英国では「日、月、年」の形式を使うというように、日付の表示形式が異なります。

これは微妙な違いに見えますが、データベースはユーザーが米国形式を使っているのか、英国形式を使っているかを区別することはできません。データベースは、どちらか一方の形式でしか日付を正しく読み取ることができないのです。例えば『２０２２年１０月１日』を数字で見てみましょう：

• 米国：10/01/2022 （英国だと 10日1月2022年）
• 英国：01/10/2022 （米国だと1月10日2022年）

  この例では、データベースは各エントリーを「１０月」ではなく「１月」として解釈しています。 また、ユーザーは同じ日付を複数の方法で入力し、異なるセパレーターを使用することもできます。以下に例を挙げましょう：

• Oct 1, 2022 
• Oct 1, 22
• 1 Oct 2022
• 1 Oct 22
• 10-01-22 / 01.01.2022 / 10/01/22 
• 22/10/01 / 2022/10/01

  日付ピッカーによって、ユーザーが日、月、年を個別に選択し、あいまいさをなくし、システムが一貫した正確なフォーマットを提供できるようにします。 

モバイルとデスクトップにおける 日付ピッカー の UIデザイン

モバイルの 日付ピッカー 

デザイナーは、iOSやAndroidのようなモバイルのオペレーティングシステムがユーザーにどのように日付ピッカーを表示するかを認識することが重要です。ちなみに、 iOS のネイティブピッカーでは無限スクロールのUIが使われ、Androidアプリケーションでは月全体を表示するカレンダービューが使われています。

また、iOSでは親指でのスクロールができますが、Androidでは親指タップに最適化されたUIとなっています。

デザインシステムからカスタムの日付ピッカーを使うこともできますが、ネイティブのオプションを使うことで、親しみやすさが生まれ、製品の学習曲線が短くなります。ただし、モバイルアプリにネイティブの日付ピッカーを使う場合は、iOSのUIで述べたようなユーザビリティの問題が生じないように注意しましょう。

デスクトップの 日付ピッカー 

  大抵のデスクトップのWebサイトやアプリケーションは、カレンダーの日付ピッカーが使われており、余分なスペースとマウスを使うことで、ユーザーは数回のクリックだけで簡単に日付を選択できます。また、多くの製品では、ユーザーが手動で日付を入力するための入力フィールドが提供されています。

日付の数値の入力フィールドは、デスクトップでもうまく機能します。UXデザイナーは、ユーザーを正しいフォーマットに導くべく、プレースホルダーや有益なエラーメッセージを含めないといけません。

 日付ピッカー の UIデザイン５種

数値の入力フィールド

  最も基本的な日付ピッカーは、数値入力またはテキスト入力フィールドです。このようなフィールドには、日付ピッカーを備えたモーダルポップアップが含まれる場合があるか、ユーザーは区切り文字を使って日付を入力する必要があります。

製品によっては、US Web Design Systemsのこの例のように、ユーザーが日付を入力するか、モーダルを使うかを選択できるものもあります。

プレースホルダーは、「MM/DD/YYYY（月/日/年）」といった日付のフォーマット方法をユーザーに示す必要があります。UXデザイナーは、ユーザーが「月」と「日」を入力するとセパレーターが表示される日付のオートフォーマットを適用することで、これをさらに推し進めることができます。また、デザイナーは、ユーザーがフォームに記入する方法を知ることができるように、ヘルパーテキストを下に追加することもできます。こちらの例をご覧ください。

ドロップダウン日付セレクタ

  デザイナーは、Webサイトやデスクトップのアプリケーションで、大体はドロップダウンの日付セレクタを使用します。ただこのような日付ピッカーはマウスではうまく機能しますが、オプション間のスペースが少ないため、モバイルデバイスのユーザー、特に大きな指や親指を持つユーザーには難しいかもしれません。

ドロップダウンセレクタは、カレンダーモーダルで単一の入力フィールドを使うよりも多くのスペースを占有し、ユーザーが「日」、「月」、「年」を個別に選択する必要があるため、入力に時間がかかります。

なので、ドロップダウンセレクタは、デスクトップアプリケーションやWebサイトには最適ですが、オンボーディングフォームではボトルネックになるかもしれません。

スクロール 日付ピッカー 

  スクロール日付ピッカーは、ユーザーが日、月、年を別々に選択するため、ドロップダウンと同様に機能します。このようなスクローラーは、ユーザーが親指を使って日、月、年をスクロールできるモバイルデバイスで最も便利です。

ただ、多くのユーザーは、スクロール式の日付ピッカーが遠い未来や過去の日付には適していないとの不満を抱いています。何十年もスクロールするのは時間がかかり、特に手や指に障がいのあるユーザーにとっては大変です。

ちなみに、iOSのデフォルトの日付ピッカーは、スクロール式の日付ピッカーの最も一般的な例ですが、Appleでは、はるか過去や未来の日付にカレンダーピッカーがよく使われています。

カレンダー 日付ピッカー 

  カレンダーUIは、最もよく使用される日付ピッカーであり、カレンダー日付ピッカーは、OS、デバイス、画面サイズに関係なくうまく機能します。

物理的なカレンダーやデジタル形式のカレンダーは誰でも見慣れたものであるため、ユーザーはこのような日付ピッカーで慣れ親しみ、それによって認知的な負荷や製品の学習曲線が軽減します。

カレンダーのUIは、日付範囲のピッカーに特に有益で、それによってユーザーは自分の選択を視覚化してサッと調整することができます。  

タイムラインピッカー

タイムラインピッカーは、１週間までの短い日付範囲や数時間の時間枠を選択するのに適しています。タイムラインのUIは、ユーザーが［開始日］と［終了日］を選択するためにインジケータをドラッグすることができるので、モバイルデバイスで特に便利です。

タイムラインピッカーは日付にも使えますが、タイムウィンドウの選択に最適です。

 日付ピッカー のUIとUXのベストプラクティス

日付ピッカー のアクセシビリティ

  デザイン性の低い日付ピッカーだと、障がいのあるユーザーやスクリーンリーダーを使うユーザーはイライラしてしまう可能性があります。全ユーザーが日付の選択にアクセスできるようにするには、物事をシンプルに保つことが非常に重要です。

以下は、日付ピッカーにアクセスしやすくするための推奨事項です：

• 日付フィールドには明確なラベルを使いましょう。例えば、誰かが予約をしている場合、スクリーンリーダーや認知障がいのユーザーが必要な日付を知ることができるように、フィールドに「予約日」または「予約日を選択してください」というラベルを付けます。
  
  
• プレースホルダーと入力フィールドの上または下にフォーマットのヒントを含めましょう。このバリデーションで、明確な指示によって全ユーザーに利益がもたらされると同時に、日付ピケットがより利用しやすくなります。
  
  
• ユーザーは、タッチ、マウス、スクリーンリーダー、キーボードを使って日付ピッカーを使えないといけません。UX デザイナーは、全ユーザーとデバイスが 確実にUIを操作して簡単に日付を選択できるようにするために、日付ピッカーをテストしないといけません。
  
  
• 日、月、年のフィールドを分けることで、スクリーンリーダーやキーボードユーザーが日付を入力しやすくなります。UX デザイナーは、ユーザーがカレンダーを使って選択を完了できるように、ボタンまたはカレンダーのアイコンを含めるのもいいでしょう。（USWDSの日付ピッカーの例を参照）。

以下は、日付ピッカーのアクセシビリティリソースです：

• Collecting dates in an accessible way by Hassell Inclusion
• Date picker by US Web Design System
• General accessibility guidance for forms by US Web Design System

現在の日付を表示

  カレンダーピッカーでは、ユーザーに［現在の日付］と［選択内容］の表示が重要です。現在の日付を強調表示することで、ユーザーが選択する際の基準となり、特に旅行や予約の際に重要です。

「現在の日付」と「ユーザーが選択した日付」の区別は、混乱を避けるために非常に重要です。マテリアルUI では、現在の日付にはアウトラインを、選択された日付には陰影のある背景を使用することで、これをハッキリと区別しています。

空いてない日をブロックする

日付を選択しても、その日が利用できないことが判明するのは、最もイライラするユーザー体験のひとつであり、それでユーザーは選択をやり直して、空きを見つけるまで試さないといけません。そこで、空いてない日付をブロックすることで、ユーザーはカレンダーに戻ることなく選択することができます。

追加の重要な意思決定データを提供する

Booking.com や Airbnb などの多くの旅行予約アプリは、ユーザーが最良の料金を見つけることができるように、各日付の下に１泊あたりの料金を表示しています。この情報でユーザーはお金を節約できるため、ポジティブなユーザー体験が生み出されます。

不要なデータの削減

カレンダーのUIは、ごちゃごちゃして煩わしい場合があります。デザイナーは、カレンダーを読みやすくしてタスクを完了しやすくするために、UI要素、線、その他のコンテンツをできるだけ減らさなないといけません。例えば、ユーザーは「生年月日」を選択する際に「曜日」を見る必要はありませんよね。

また、UXデザイナーは、カレンダーの背後にあるコンテンツを遮断するために、モーダルオーバーレイに無地の背景を使わないといけません。

UXPinで 日付ピッカー をデザインする方法

UXPinは、インタラクティブで動的な忠実度の高いプロトタイプを作成するための高度なプロトタイピングツールです。大抵のプロトタイピングツールでは、１つのインタラクションをプロトタイプ化するために複数のアートボードを作成する必要がありますが、UXPinではステート、Variables（変数）、条件を使って完全に機能するページを作成できます。

UXPin に日付ピッカーを挿入するには、まず垂直ツールバーの「Search All Assets（すべてのアセットを検索）」の検索アイコン（command + F / Ctrl + F）をクリックします。

次に、入力フィールドで「date（日付）」または「calendar（カレンダー）」を検索します。

オプションは［Components（コンポーネント）］ の見出しの下に用意されるものもあり、タッチユーザーに最適なものもあれば、キーボードユーザーに最適なものもあるでしょう。ただし、「Input calendar（カレンダー入力）」は、タッチユーザーにはカレンダーを提供し、キーボードユーザーには入力フィールドを提供します。

 日付ピッカー コンポーネントのスタイリング

UXPin のコンポーネントはすでに優れたUXを提供するようにデザインされていますが、皆さんはブランドが持つビジュアルアイデンティティやアプリ/ Web サイトの美的感覚に合うようにスタイリングしたいと思うでしょう。そのためには、右側のプロパティパネルを使いましょう。

UXPinのデザインシステムライブラリ（特にテキストスタイルとカラースタイル）を使っている場合は、すでに確立されているスタイルを活用することで、日付ピッカー コンポーネントとデザインの他の部分の視覚的な一貫性をある程度維持できます。

コンポーネントをカスタマイズするには、スタイルを設定したいレイヤーを選択し、「デザインシステムライブラリ」の アイコン（⌥ + 2 / alt + 2）をクリックして UXPinのデザインシステムライブラリに移動し、レイヤーに適用したいスタイルを選択します。

実際のコンポーネントで代用

デザイナーは、同じコンポーネントを何度も挿入したりスタイリングしたりして毎回最初からいちいち作るのではなく、デベロッパーによってすでに構築されたリリース可能なコンポーネントを使用できます。コーディングなしで Git、Storybook、または NPM からコンポーネントを取り込むことができ、見た目も機能も本物と同じです。これを実現できるUXPinが持つテクノロジーについてご覧になりませんか。こちらからぜひアクセスをリクエストしてください。

The post UI を魅力的にする 日付ピッカー のデザイン 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.

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.

忠実度とは、プロトタイプやデザインの「精度」や「リアルさ」のレベルを指し、ビジュアルデザインやインタラクション、機能性において、プロトタイプが最終製品にどれだけ近いかを表します。 高忠実度 なプロトタイプは再現性が高く、最終的なUX（ユーザーエクスペリエンス）を可能な限り近い形でシミュレーションすることを目的としています。

 高忠実度 プロトタイプ（Hi-Fiプロトタイプ）には、色、タイポグラフィ、インタラクション、アニメーション、イメージなど、実際の製品が持つUI（ユーザーインターフェース）に沿ったビジュアルおよびインタラクティブな要素が含まれます。このようなプロトタイプによって、ユーザーやステークホルダーに没入感のある体験が提供されるため、最終製品のイメージが理解しやすくなります。

そして、デザイナーはデザインプロセスの後期段階で、コンセプトのテストおよび検証、ユーザーフィードバックの収集、UX改良のために忠実度の高いプロトタイプを作成します。そして作成されたプロトタイプで、インターフェースの使いやすさや効果性の評価、潜在的な問題や改善点の特定し、情報に基づいた製品デザインの決定をすることができます。

UXPinのMergeテクノロジーで完全にインタラクティブなプロトタイプを作成して、より良いデザインを決定しましょう。詳細とアクセスリクエスト方法については、こちらのページをぜひご覧ください。

高忠実度（Hi-Fi）と低忠実度（Lo-Fi）プロトタイプ

デザイナーは、さまざまな目的と目標のために、デザインプロセスの各段階で高忠実度または低忠実度なプロトタイプを使用します。

低忠実度（Lo-Fi）プロトタイプとは、一般的に簡単なスケッチやワイヤーフレーム、または基本的なデジタルモックアップを使って作成される、シンプル化されたデザインコンセプトのことです。デザイナーは、デザインプロセスの早い段階でこの低忠実度プロトタイプを作成し、多くのアイデアを共同作業で可能な限り速やかにに反復します。

また、低忠実度プロトタイプは、デザインの核となる構造、情報アーキテクチャ、機能性に焦点を当てており、簡単に作成できるため、デザイナーは時間とリソースを過剰に費やすことなく、デザイン案を複数検討し、反復することができます。

一方、高忠実度プロトタイプでは、最終的なデザインのより正確でリアル感があり、ビジュアルデザイン要素、インタラクティブ機能、実際のコンテンツを取り入れ、最終製品のイメージ通りのデザインや機能とほぼ同一のように完成します。デザインチームは、デザインプロセスの後半で高忠実度プロトタイプを作成し、デザインハンドオフの前にコンセプトを確定します。

 高忠実度 プロトタイプのプランニング

デザイナーは、デザインプロセスの初期段階でほとんどのリサーチとプランニングを完了します。そのため、このステップでは高忠実度プロトタイピングを導くために、調査結果を統合し、レビューします。

プロトタイプの目的と目標の設定

デザインのどの側面をテスト、評価、またはステークホルダーに見せたいかを決定することで、高忠実度で達成したい具体的な目標を設定します。

例えば、ECのWebサイトをデザインする場合だと以下のようになります：

• 目標：カートに商品を追加し、チェックアウトプロセスを完了するまでのユーザーフローをテストする。
• 目的：ユーザビリティの問題特定およびコンバージョン率の最適化。

UXリサーチからのユーザーゴールの設定

デザイナーがプロトタイピングツールを使い始める前に、何を作って、誰のために作るのかがわかるように、徹底したUXリサーチが必要です。ユーザーゴールを理解することで、ターゲットオーディエンスのニーズや好みに合わせて忠実度の高いプロトタイプを調整することができるのです。

例えば、フィットネス愛好家向けのモバイルアプリをデザインしている場合、ターゲットとなるユーザーは、ワークアウトや進捗情報の追跡に興味がある可能性があります。となるとこのユーザーグループの目標には、フィットネス目標の設定、消費カロリーの追跡、ワークアウト統計の分析などが含まれます。このようなリサーチを利用することで、デザイナーはそれに応じて機能やインタラクションを計画することができますよね。

主な機能とインタラクションの概要

上記の目標と目的を達成しながら、適切なUXを実現させるためにプロトタイプに必要な中核となる要素を決定します。そのような主要な機能性を特定することで、デザイン作業に優先順位をつけ、プロトタイプに必要不可欠なインタラクションとユーザーフローを確実に捉えることができるのです。

例えば、フライト予約のモバイルアプリをデザインする場合、主な機能として以下が挙げられます：

• フライトの検索
• 検索結果の絞り込み
• フライト詳細の表示
• 座席の選択
• 支払いと予約確認
• 予約内容の確認

視覚的要素のデザイン

デザイナーは、リサーチ、スケッチ、ワイヤーフレームを基礎として、高忠実度のプロトタイプの視覚的要素をデザインします。また、視覚的要素をデザインする際は、タイポグラフィ、色、イコノグラフィー（図像）、イメージなどのさまざまな側面を考慮します。

製品のタイポグラフィと色は、ブランドアイデンティティと調和され、読みやすさを上げるものでないといけません。そして、製品のイコノグラフィーは、親しみやすく直感的なシンボルを使ってアクションや機能を表します。イラストや写真などのイメージは、UXの質を向上させて、適切なメッセージを伝えてくれます。

また、デザイナーは、このようなデザイン要素が、色のコントラスト、読みやすさ、支援技術などのアクセシビリティにどのような影響を与えるかも考慮しないといけません。

オープンソースのコンポーネントライブラリの活用

デザイナーは、MUI、Ant Design、Fluent UI などのオープンソースのコンポーネントライブラリを使うことで、ビジュアルデザインのプロセスを加速することができます。ボタン、フォーム、ナビゲーションバーなどの既製要素を活用することで、デザインに必要な時間と労力が削減され、 高忠実度 のプロトタイプ全体で一貫したビジュアル言語を維持することができるのです。

UXPinには、UIデザインのプロセスを簡素化するツールや機能を提供しています。UXPinにあるMergeライブラリによって、UI要素をドラッグ＆ドロップするだけで画面やレイアウトが構築可能となります。これらのコンポーネントはデフォルトでインタラクティブで、デザインシステムによって定められたプロパティを含んでいるため、より速く、効率的で、一貫性のあるUIデザインが可能になります。

この段階が完了すれば、デザイナーはインタラクティブなプロトタイプを作るための、 高忠実度 なモックアップが作成可能です。

コンポーネントのインタラクションとアニメーションの追加

デザイナーは、ユーザーと要素とのインタラクションを反映するために、ホバー、アクティブ、無効などのさまざまなステートを確定します。また、最終製品の動的な動作をシミュレーションして、たとえば「ユーザーがフォームで入力必須箇所の欄を入力するまでボタンを無効状態にする」など、よりリアルなUXを提供するために、コンポーネント間の遷移も作成します。

さらに、デザイナーは マイクロインタラクションとアニメーションを取り入れます。マイクロインタラクションとは、フィードバックを提供し、プロトタイプとのインタラクションを通してユーザーをナビゲートする、小さくて、繊細で、意図的なアニメーションのことです。プロトタイプをより魅力的でインタラクティブなものにするだけでなく、ユーザーに重要な情報を伝えて、インターフェースをより直感的に誘導してくれます。

Mergeのインタラクティブなコンポーネントを活用

UXPinのMergeテクノロジーによって、デザイナーはレポジトリからコードコンポーネントをデザインプロセスに取り込むことができ、そのUI要素には、デザインシステムによって規定されたインタラクションなどのプロパティが含まれています。

この『Code-to-Design』の手法により、デザイナーはスタイリングやインタラクションなどのコンポーネントプロパティの設定に悩まされることはありません。また、各コンポーネントのバリアントは、デザイナーが選択できるように、例えば「コンポーネントのステート選択」などが UXPinのプロパティパネルに表示されます。

さらにデザイナーは、キーボードやスマホ用のトリガーやアクションなどを含むUXPinのインタラクション機能を使って、マイクロインタラクションを追加することもできます。

ユーザーフローのシミュレーション

ユーザーフローとナビゲーションパスのマッピング

デザイナーは、画面の論理的な順序を確定し、ユーザーの［入口］や［出口］、およびタスク達成のために取ることができるさまざまな［経路］を特定するなど、デジタル製品を通じて「ユーザージャーニー」を定めます。そのユーザージャーニーマップで、ユーザーにとって使いやすくて直感的なナビゲーション体験が保証されます。

インタラクションの設定

デザイナーは、ユーザージャーニーマップに従って、ボタンやリンクなどのインタラクティブな要素を使って、画面間のつなぎを設定します。そしてユーザーは、設定したつなぎによって、さまざまなスクリーンをナビゲートし、製品内で起きるトランジションやインタラクションのシミュレーションができます。

トランジションへの対応

デザイナーは、アニメーション、トランジション、インタラクティブな要素を使って、例えば、「ボタンをクリックするとモーダルが表示される」や、「スクロールすると追加コンテンツが表示される」など、ユーザーがプロトタイプとどのように操作するかをシミュレーションします。

このプロセスが終わる頃には、デザイナーはエンドユーザーと 高忠実度 のプロトタイプをテストする準備が整います。

テストおよびイテレーション（反復）

テストとは、デザイナーがユーザーからのフィードバックを取り入れ、より効果的でユーザーに優しいソリューションを生み出すためにデザインを改良することで、高忠実度のプロトタイプを継続的に改善していく反復的なプロセスです。

以下は、高忠実度プロトタイプのプロセスにおける概要です：

• ユーザーによるユーザビリティテストのセッションを実施し、高忠実度のプロトタイプを評価して、そのユーザビリティに関する貴重なフィードバックを収集する。
• プロトタイプをステークホルダーに提示し、ビジネス価値のフィードバックを得る。
• プロトタイプを使ったユーザーとステークホルダーの対話、理解、全体的な経験に関するフィードバックとインサイトを収集および分析する。
• 改善点を特定し、受け取ったフィードバックに基づいてプロトタイプに変更を加える。
• ユーザビリティの問題に対処し、全体的なUXを向上させるためにデザインを改良する。
• プロトタイプが確実にユーザーのニーズを満たし、デザイン目標に合致していることを確認するために改良の反復プロセスを繰り返します。

UXPin でのプロトタイプの共有と連携

プロトタイプを共有し、フィードバックとレビューを受ける

UXPin のプレビューと共有機能により、デザイナーはチームメンバーやステークホルダーとデザインやプロトタイプを共有でき、その際、サイトマップ、コメント、スペックモード、ドキュメントなど、デザイナーが共有したいものを選択できます。

UXPin の共有リンクはオープンな Web 上で利用可能です。つまり、リンクがあれば誰でもプロジェクトにアクセスできます。その際デザイナーは、チームメンバーやステークホルダーだけがアクセスできるように、プロジェクトをパスワードで保護することができます。

チームメンバーやステークホルダーとの連携

UXPinのコメント機能で、オブジェクト上で直接コメントしたり、メンバーのタグ付け、コメントの割り当て、適切なアクション後に解決できることから、メンバーやステークホルダー間の連携強化されました。また、Team（チーム）コメントとPublic（公開）コメントの機能を使えば、UXPinのアカウントを持っていない人でもフィードバックに参加してもらうことができます。

より円滑な連携とデザインハンドオフ

デザイナーとエンジニアはUXPinのMergeテクノロジーを通して同じ言語で会話できることから、コードコンポーネントで 高忠実度 のプロトタイプを構築すると、デザインと開発プロセスの間のギャップを埋めることができます。

デザイナーとエンジニアは、まったく同じコンポーネントをそれぞれのレンズを通して見ています。例えばデザイナーはUXPinでビジュアル要素を確認し、エンジニアはIDE（統合開発環境）でコードを確認しますが、デザイナーとエンジニアが同じ制約の中で作業するため、この「信頼できる唯一の情報源（Single source of truth）」によって摩擦は軽減されます。また、これらの制約は、デザインドリフトや技術的負債、不整合を防ぐことから、より調和のとれた製品開発プロセスを生み出すのです。

ユーザーテストを強化し、ステークホルダーの連携を効率化するために、より優れた高忠実度のプロトタイプをより速く、よりインタラクティブに構築しませんか。

UXPin Merge を使った高忠実度のプロトタイプについての詳細はこちらをご覧ください。

The post UXPinでできる 高忠実度 なプロトタイピング appeared first on Studio by UXPin.

ユーザビリティテスト参加者やステークホルダーに実際のユーザー体験に近いものを提供する上で、インタラクション機能は欠かせない存在です。しかし、インタラクティブなコンポーネントの作成には時間が掛かってしまい、ほとんどのデザインツールでは上手くいかないことから、多くのデザイナーを悩ませているでしょう。

UXPin Mergeを使用したコンポーネント駆動型プロトタイピング技術と、インタラクティブコンポーネントを使うことで、完全に機能するプロトタイプを構築できます。機能横断的なコラボレーションとユーザーテストを強化するための詳細については、こちらのページをご覧ください。

 インタラクティブコンポーネント とは？

 インタラクティブコンポーネント （またはインタラクティブ要素）は、デザインシステムから再利用可能なUI要素と、デフォルトでインタラクティブ機能を含んでいます。普段からUIキットを使い、プロジェクトごとにインタラクションを追加しなければならないデザイナーにとってこれは画期的と言えるのではないでしょうか。

デザインチームは、インタラクション、ステート、その他のアニメーションを設定して、最終製品を正確に表現する没入型のプロトタイプを作成できます。

インタラクティブコンポーネント のメリット

インタラクティブコンポーネント のメリットをいくつかご紹介します。

1. 少ないアートボード

従来、デザインツールを使ってインタラクションを作成するには、基本的な機能を実装するだけでも複数のアートボードが必要でした。デザイナーは、 インタラクティブコンポーネント を使うことで、1つのアートボードで同じ得ることができます。

2. 市場投入までの時間を短縮

インタラクティブなコンポーネントは再利用可能なので、デザイナーはインタラクションを一度設定するだけで、デザインプロセスでの時間を大幅に節約できます。

エンジニアが承認されたコンポーネントに慣れ親しめば、デザインのハンドオフはより簡単になり、プロジェクトの納期をさらに短縮することができます。

これらの時間節約の結果、市場投入までの時間が短縮されます。

3. 一貫性の向上

UIキットはデザインの一貫性を高めますが、インタラクションに関してはあいまいさを残します。デザイナーはこれらのインタラクションを自分で設定しなければならず、エラーや一貫性の欠如につながってしまいます。

インタラクティブなコンポーネントには、インタラクティブ性がすでに備わっているので、誰もが同じステート、マイクロインタラクション、アニメーションを持ちます。これによって、一貫性を高めるだけではなく、デザイナーが修正するセットアップタスクやエラーが少なくなるため、効率性を高めます。

4. より良いテストとフィードバック

ユーザーやステークホルダーからのフィードバックは、デザインプロジェクトにとって非常に重要です。また、ビジネスゴールに沿ったユーザー中心の製品を提供するための意思決定の原動力となります。

ほとんどのデザインツールでは、エンジニアが数行のコードで実装する単純なインタラクションを実装するための忠実さと機能性に欠けています。 インタラクティブコンポーネント を使用すると、コードの機能を簡単に再現できるため、ユーザビリティテストやステークホルダーのために実物に近いプロトタイプを作成できます。

5. デザインシステムの普及を促進する

デザインシステムチームの仕事の1つとして、デザインシステムを普及を促進させることです。 これにおいても、インタラクティブコンポーネント は製品開発チームの効率的なワークフローを作成できる強力なツールとなります。

6. デザインの拡張

UXPinでは、コンポーネント駆動型のプロトタイピングとインタラクティブコンポーネントがデザインのスケーリングにどのように役立つかを見てきました。１つの例として、PayPalが新しく人材を雇用せずデザインプロセスを拡張したUXPin Merge活用方法をこちらで紹介しています。

リポジトリにホストされているインタラクティブコンポーネントにMergeを統合することで、PayPalのプロダクトチーム（UX/デザインツールの経験はほぼ無いに等しい）は、経験豊富なUXデザイナーが以前行っていたよりも8倍速くデザインプロジェクトの90％を完了することができました。

 インタラクティブなコンポーネント により、学習曲線が大幅に短縮されたことでデザイナーでない人にとってもデザインプロセスがより身近なものになりました。

PayPalのUXチームは、レイアウトやテンプレートを含むインタラクティブコンポーネントライブラリを構築し、React propsを使用してデザインシステムの制約を設定しました。製品チームは、ユーザビリティテストとデザインハンドオフのためのプロトタイプを、ドラッグ＆ドロップで簡単に構築できます。

インタラクティブコンポーネントは、プロダクトチーム（または別のUXPin MergeユーザーであるTeamPasswordの場合はエンジニア）のような非デザイナーに、より多くのUXに関する仕事を与えることができます。

すでに構築済みのコンポーネントにクリック、ホバーなどの条件に応じてインタラクションを作成することも可能です。

UXPinプロトタイプにインタラクティブ・コンポーネントを組み込むには？

インタラクティブコンポーネントを製品のプロトタイプに組み込むには、多くのステップを踏む必要があります。フォームが実際に入力できること、ボックスがチェックできること、リンクがクリックできることを確認します。

このようにすることで、ユーザーが製品を使おうとする経験を持つことができ、製品がどのように機能し、人々がどのように使用する（または使用したい）のかについての洞察を得ることができます。

1. UXPinでの インタラクティブコンポーネント の使用

10年以上前のUXPinの最初のリリース以来、インタラクティブコンポーネントはUXPinのデザインツールの中核であり、最終的な製品体験を正確に再現するプロトタイプを作成するソリューションをデザイナーに提供してきました。

UXPinには、インタラクティブコンポーネントを作成するための4つの強力な機能があります：

• ステート（状態）： 1つのコンポーネントに対して、それぞれ異なるプロパティとインタラクションを持つ複数のステートバリアントを作成できます。
• バリアブル（変数）： ユーザーの入力データをキャプチャし、パーソナライズされた動的なユーザー体験を作成するために使用します。
• Expression（式）： Javascriptのような関数で、複雑なコンポーネントや高度な機能を作成できます！
• 条件付きインタラクション： ユーザーのインタラクションに基づいてif-thenやif-elseの条件を設定し、複数の結果を持つ動的なプロトタイプを作成して、最終的な製品体験を正確に再現します。

UXPinのプラットフォームで簡単にドラッグ＆ドロップできる、ビルド済みのコンポーネント（UXPinでは「フォーム」と呼びます）を使用するのも1つの方法です。(ゼロから設計する必要はありません！）

UXPinのサンプルページにあるインタラクティブなコンポーネントの例をいくつかご紹介します。

ここで、ステート、バリアブル、Expression、条件ロジックで何ができるか見てみましょう。

例１. ボタン

例２. インプットとテキストエリア 

例３. ラジオボタン

例４. インタラクティブなサインアップフォーム

→ このサンプルをダウンロードして使いたい場合は、こちらから。

ドキュメントはこちらをご覧ください。

2. UXPin Mergeの インタラクティブコンポーネント 

Mergeは、コンポーネント駆動型のプロトタイピングとインタラクティブコンポーネントをさらに進化させます。デザイナーが UXPin でコンポーネントを作成する代わりに、Merge はリポジトリからデザイン システム ライブラリをインポートします。

これらの MergeのUI要素の背後には React、Vue、Angular などのフロントエンドフレームワークのコードがあるため、真にインタラクティブなコンポーネントとなります。組織のデザインシステムをインポートすることも、オープンソースのライブラリを使用することもできます。

デザイナーは Mergeコンポーネントを使用するためにコードを見たり書いたりする必要はありません。また、UXPinのプロパティパネルからコンポーネントのプロパティにアクセスし、デザインシステムの制約内で変更を加えることができます。

Mergeについての詳細やアクセスはこちらをご覧ください。

Mergeのインタラクティブコンポーネントを使ってデザインする

ステップ 1: デザインシステムからコンポーネントを取り込む

Mergeを使用してインタラクティブ コンポーネントを UXPin にインポートするには、3 つの方法があります：

• Git統合： React コンポーネント ライブラリを UXPin に直接接続する
• Storybook統合： Vue、Angular、HTML、Ember、Web Components などのフロントエンドフレームワークを同期します。
• npm統合： Node Package Manager（npm）からオープンソースのライブラリをインポートできます。npm Integration とその動作方法の詳細をご覧ください。

インポートされたMergeコンポーネントは左サイドバーのUXPinのデザインシステムライブラリに表示されます。デザイナーはサイドバーから必要なUI要素をクリックまたはドラッグしてキャンバスに表示することができます。

また、複数のデザインシステムとUXPin要素を使用したり、それらを組み合わせて新しいコンポーネントを作成し、パターンとして保存することもできます。

UXPin Mergeでプロトタイピングを始める方法

Mergeを使用して UXPinのコンポーネント駆動型プロトタイピングを始める準備はできましたか？始めるにあたって2 つの方法があります：

• オープンソースライブラリ： オープンソースライブラリは、アクティブな開発サポートがないチームや、コンポーネントに取り組む前にどのように作業できるかの基礎的な情報を把握したいチームに最適です。
• プライベートなデザインシステム： 製品のプライベートデザインシステムをUXPinと同期させたい場合は、Mergeページでアクセスをリクエストしてください。

UXPinの無料トライアルを14日間無料でお試しいただけますので、ぜひご利用ください。

The post プロトタイプに命を吹き込む インタラクティブコンポーネント appeared first on Studio by UXPin.

コンポーネント駆動プロトタイプは、ユーザーテストを大幅に改善すると同時に、ステークホルダーに現実的な製品デザインの期待値を提供しますが、UXPinの npm統合 で、デザインチームは、完全に機能する高忠実度のプロトタイプのデザインに、オープンソースのコンポーネントライブラリを使うことができます。

UXPinのMergeテクノロジーと npm統合 で、コードベースのデザイン革命に乗り出しましょう。 デザインシステムを最大限に活用し、デザインハンドオフを改善し、デザインを大幅に拡張するコンポーネント駆動型プロトタイプの詳細をぜひご覧ください。

UIコンポーネントは、Gitレポ、Storybook、または最新の npm統合 によって提供されます。最後のオプションについては、ぜひこちらをご覧ください。

UXPin Mergeとは

UXPin Merge は、レポジトリ、Storybook、または npm パッケージとしてホストされているコンポーネントライブラリをUXPinのデザインエディタに同期できる、コードベースの技術であり、デザイナーは、このような UIコンポーネントを使って、最終製品のような外観と機能を持つプロトタイプを構築できます。

エンジニアやデザイン システム チームがレポジトリ内の機能コンポーネントに加えた変更は、自動的にUXPinに同期され、デザイン チームに更新が通知されます。Mergeにはバージョン管理が含まれており、チームメンバーは必要に応じて古いデザインシステム バージョンに切り替えることができます。

この『信頼できる唯一の情報源（Single source of truth）』は連携を強化し、「デザインツール」と「コード」という２つのデザインシステムを管理するDesignOpsとDSチームの負担を軽減します。

UXPinの npm 統合 とは

これまでUXPin Mergeは、セットアップ全般にはエンジニアリングの専門知識を必要としていましたが、セットアップのための貴重なエンジニアリングリソースがどのチームにもあるわけではないので、npmコンポーネントをUXPinに統合する方法を考え出しました。

Merge の npm 統合により、デザイナーは npm パッケージとして利用可能なオープンソースのコンポーネントライブラリのインストールと管理を完全に制御することができます。また、直感的なインターフェースを使って、プロトタイプのニーズに合わせてコンポーネントをインポートおよびカスタマイズすることができます。ちなみに、全設定においてコーディングスキルは不要です。

デザイナー向けのnpmについて学びたい方は、入門ガイドをお読みください：NPMと言うのは？把握しよう！

 Ant Design とは

Ant Designは、Alipay、華北、優慧宝など、中国に拠点を置くハイテク/金融企業のコングロマリットである Ant GROUPから生まれた製品です。

Ant Designは、B2B、B2C、エンタープライズ製品など、数多くのアプリケーションの構築に利用されており、この包括的なデザインシステムには、React、Angular、Vueのコンポーネントライブラリと、それを補完するアイコンセットが含まれています。また、ネイティブアプリケーションの構築に、Ant Design モバイルも入手できます。

UXPin Mergeを使った Ant Design の npm 統合方法

Ant DesignのReactコンポーネントライブラリは、 npm パッケージ（antd）として提供されており、デザイナーは、UXPinの  npm 統合を使った Ant React コンポーネントをインポートし、Mergeのコンポーネント管理でプロパティをカスタマイズすることができます。

デザインチームが Ant Design を他のデザインツールと併用する場合、 Ant Design の静的ベクターベースの UI キットをいずれか使う必要がありますが、UXPinの npm 統合 により、デザイナーはエンジニアが使う同じコンポーネントへのアクセスが可能です。

Ant Designのコンポーネント駆動型プロトタイプは、デザイナーとエンジニアの間に『信頼できる唯一の情報源（Single source of truth）』を作成し、UXチームと製品チームの間に最高の一貫性を確保します。

UXPinの  npm 統合 では、インポートする Ant DesignのReactpropsを色、サイズ、アイコン、ステートなど自由に選択することができます。

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

  npm 統合 には、各 Ant Designのコンポーネントプロパティをインポートおよび管理するための一元管理である『Merge コンポーネントマネージャ』が含まれています。

UXPinの npm 統合はReactコンポーネントで動作するので、 Ant Design のReactドキュメントに従って、どのpropsをインポートするかを参照できます。これらを Merge のコンポーネントマネージャ で設定すると、コンポーネントのプロパティが UXPin のプロパティパネルに表示されます。

例えば、Ant のボタンには以下のように６つのタイプまたはバリエーションがあります：

• プライマリー
• ゴースト
• ダッシュ
• リンク
• テキスト
• デフォルト

これらのボタンタイプ（および他のすべてのプロパティ）は、デザイナーが選択できるようにプロパティパネルにドロップダウンとして表示されます。プロップは、コンポーネントによって、テキストフィールド、チェックボックス、コードエディタなどとして表示されます。

UXPinとAnt Designの npm パッケージの連携

ステップ１

UXPinのダッシュボードに移動し、【New Project（新規プロジェクト） 】をクリックします。

ステップ２

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

ステップ３

【New prototype（新規プロトタイプ）】をクリックし、UXPinのデザインキャンバスにプロジェクトを開きます。

ステップ４

左サイドバーのDesign System Libraries（デザインシステム・ライブラリ）タブの下部にあるドロップダウンをクリックし、【New library （新規ライブラリ）】をクリックします。

お使いのサイドバーや利用可能なライブラリは、例と異なる場合があります。

ステップ５

【Import React Components （React コンポーネントをインポートする）】を選択し、【Next （次へ）】をクリックします。

ステップ６

ライブラリに名前を付けます。この名前は純粋にあなたの参考のためであり、インポートに影響を与えることはありません。

また、Ant Design のnpmページの「Install（インストール）」にある、npmパッケージのレポジトリ名を取得する必要があります。npmからインストール内容をコピーして、「Library Package name （ライブラリパッケージ名）」欄に貼り付けます（antdより前は削除）。

コンポーネントのスタイリングプロパティをインポートするために、Merge は Ant Design の CSS (antd/dist/antd.css) へのパスを要求します。これは、Ant Design の React インストール手順の 【Usage（使用） 】 に記載されています。

Ant Design コンポーネントをインポート

npm の統合が完了すると、UXPinは自動的にキャンバスにリダイレクトします。では、インポートしたいAnt Design のコンポーネントを選択してみましょう。

ステップ１

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

Merge のコンポーネントマネージャが新しいタブで表示されます。

ステップ２

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

ステップ３

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

正しい命名規則は、Ant Design のドキュメントの コンポーネント API にあります。Ant Designのコンポーネントは、例えば、「Date Picker」 は 「DatePicker」 となるように、スペースなしのキャメルケースを使い、常に最初の文字を大文字にします。

このチュートリアルでは、最初のコンポーネントとしてAnt Design のボタンをインポートし、「General」という新しいカテゴリに追加します。その際、Ant Design のドキュメントと同じカテゴリを使うことをお勧めします。そうすることでデザイナーとエンジニアが同じリファレンスポイントを持つことができますからね。

一度のインポートで複数の部品を追加できるので、手順の「２」と「３」を繰り返す手間が省けます。

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

ステップ４

右上の【Publish Changes（変更を公開する）」をクリックすると、インポート処理が初期化されます。

新しい部品に対して初めて行う場合は、１～２分かかるかもしれません。

ステップ５

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

この手順を順を追って見ていくと、左サイドバーにカテゴリ【（General（一般）】と最初のコンポーネント（ボタン）があるのが見えます。

ステップ６

そのボタンをクリックして、プロパティの追加を開始します。このような Reactプロップは、Ant Design のドキュメントで、Components > General > ButtonのAPI で見ることができます。

Merge のコンポーネントマネージャを使ったコンポーネント プロパティの追加

ドキュメントにあるReact propsを使って、Ant Designのボタンのプロパティをいくつか追加してみましょう。

ボタンの種類：ステップ1

Reactのボタン型プロップは、Ant Designのボタンスタイル６種をインポートします。

• プロパティ名：「type 」と入力（propsは必ず小文字を使用）。
• 表示名：デザイナーとエンジニアの両方が使う説明的なもの（これは参照用であり、わかりやすように「Type」が使用されている）。
• 説明文：デザイナー向けの簡単な説明または指示を追加。今回は「ボタンの種類」を使用。
• プロパティの種類：「列挙型（enum）」 − スタイル６種を表示するドロップダウンを作成することができる。
• プロパティコントロール：「セレクト」
• オプション：Ant Design の API ドキュメントにあるオプションである「primary（プライマリ）」、「ghost （ゴースト）」、「dashed（破線）」、「 link （リンク）」、「 text （文字）」、「default （デフォルト）」 を追加。
• デフォルト値：お好みで。ここでは Ant Designのドキュメントにあるように「default （デフォルト）」とする。

プロフィールを完成させると、コンポーネントのプレビューが表示され、お好みに応じて変化することがわかります。

ボタンの種類：ステップ２

項目を全て入力したら、【Add property（プロパティを追加） 】をクリックします。

その後、【Save changes（変更を保存） 】します。

最後に、【Publish library changes（ライブラリの変更を公開）】します。

UXPinによるコンポーネント駆動プロトタイピング

Ant Designの必要なコンポーネントとプロパティをインポートすれば、UXPinでのプロトタイプは、ドラッグ＆ドロップでレイアウトを構築するのと同じくらい簡単です。３つのAnt Designのコンポーネントを用いて、以下のシンプルなメール登録フォームを１分足らずで作成しました。

Ant Designコンポーネントを選択すると、Mergeのコンポートマネージャ で作成したプロパティが右側のプロパティパネルに表示されます。

UXPinの npm 統合でAnt Designのプロトタイプを構築してみませんか。コンポーネント駆動のプロトタイプが、どのように製品開発のワークフローを改善し、より良いユーザー体験を顧客に提供するかぜひご体験ください。

The post 中国初の Ant Design とは？UXPin連携方法と npm 統合徹底ガイド appeared first on Studio by UXPin.

UXPin Mergeは、デザイン協働者（デベロッパー、UXデザイナー、プロダクトチーム）や関係者に、ReactJS コンポーネントを使ったプロトタイプ・テストを行うための直感的な UI （ユーザーインターフェース）を提供します。この機能性によりワークフローは、デザイナーでなくてもデザインツールのスキルを持たない人でも、React の ラピッドプロトタイピング を行うのに最適な環境です。

大手決済会社の PayPal とスタートアップの TeamPassword では、デザイナー以外の社員が UXPin でプロトタイプの構築とテストを行っています。PayPal のプロダクトチームはデザインプロジェクトの９０％をこなし、TeamPassword の２名からなる開発チームは、会社のプロトタイプとユーザーテストをすべて行っています。

そこで本記事では、「ラピッドプロトタイピング」について解説し、エンジニアがUXPin Mergeを使って開発プロセスにおける、より速い反復や、UIの不整合の減少を実現する方法をご紹介します。

UXPin MergeでReactの ラピッドプロトタイピング のワークフローを効率化しませんか。詳細とアクセス権のリクエスト方法については、Merge ページをぜひご覧ください。

ラピッドプロトタイピング とは

 ラピッドプロトタイピング とは、デザイナーが最善策を見つけるために、たくさんの実験を速やかに行うプロトタイプのプロセスであり、チームメンバーは「あったらいいな」の機能を無視して、UX（ユーザーエクスペリエンス）のための UI の最適化のみに集中します。

デザイナーは、新製品のプロトタイプを作るために、デザインシステムやオープンソースのコンポーネントライブラリを使います。既存のライブラリを使うことで、デザインチームはゼロからデザインする必要がなく、紙のスケッチからHi-Fi（高忠実度）プロトタイプとテストをサッと行うことができます。

React ラピッドプロトタイピング

React  ラピッドプロトタイピング は、エンジニアがコンポーネントライブラリを使ってMVP（最小実行可能製品）を構築するのと同様の方法論を採用しています。React のライブラリを使うことで、エンジニアは最小限のフロントエンドプログラミングで UI をゼロから開発することができ、それによってより速いテストと反復が可能になります。

コードでのプロトタイピングの課題

コードによるプロトタイピングの最大の課題は、ドラッグ＆ドロップのデザインツールを使い、あらかじめ用意されたコンポーネントでプロトタイプを作成するワークフローに比べ、時間がかかるということです。小さな変更であっても、望ましい結果を得るには、何らかのコードやスタイリングの調整が必要です。

また、コードでプロトタイピングを行うと、エンジニアはコードの記述、ドキュメントの参照、UI デザインなど、複数のタスクに集中しないといけません。プロトタイプが複雑になればなるほど、変更と反復に必要な時間と集中力が必要となり、 ラピッドプロトタイピング には程遠くなってしまいます。

TeamPassword がReactを使って ラピッドプロトタイピング の課題を克服した方法

パスワードマネージャのスタートアップ企業である TeamPasswordは、市場投入のスピードと UIの不整合に悩まされていました。小さなチームにはデザイナーがおらず、リリースのデザイン、プロトタイプ、テストはエンジニアがコードを使って行っていました。

そこで TeamPassword は、MUIのオープンソースの Reactライブラリに切り替え、ブランドや製品の要件に合わせてカスタマイズし、プライベートのレポジトリでホスティングしました。

UXPin Mergeを使ったプロトタイピングとテスト

また、TeamPassword は新製品のプロトタイピングとテストを行うためのより良い方法も必要でした。この小さなスタートアップには UX デザイナーを雇うリソースがなかったため、「デベロッパーに優しい」デザインツールを探すことにし、いくつか検討した後、TeamPassword のデベロッパーは UXPin Mergeを見つけました。

Mergeにより、TeamPasswordはMUIデザインシステムのレポジトリを UXPinのデザインエディターに同期させ、エンジニアにドラッグ＆ドロップでプロトタイプの環境を提供することができたのです。

そして今、プロトタイプの段階を終えたら、デザインシステムをプロジェクトにインポートしてコンポーネントを追加し、UXPinか JSX コンポーネントプロップをコピーするだけで最終製品を開発することができます。

この Merge の製品開発ワークフローでは、TeamPasswordの UI の一貫性は排除され、デベロッパーはプロトタイプ、テスト、反復を大幅に短縮することができるようになりました。また、Merge のバージョン管理は、デザインシステムの変更を UXPin に自動的に同期させ、デザインと開発の間に「信頼できる唯一の情報源（Single source of truth）」を作成することができます。

UXPin Mergeを使ったReact ラピッドプロトタイピング 

ベクタ形式を生成する画像ベースのデザインツールと違って、UXPinはHTML、CSS、Javascriptをレンダリングし、それによって完全にインタラクティブなReact コンポーネントのインポートが可能になります。

TeamPassword のケーススタディには、デベロッパーがデザインツールの複雑さを学ぶことなく、Reactコンポーネントを使ってより速くプロトタイプを作成する方法が示されています。以下にそれをご紹介しましょう：

デザインシステムの選択

デザインシステムがない場合は、オープンソースのライブラリを使いましょう。ちなみに筆者のオススメは、MUI、React-Bootstrap、Ant Design、Semantic UIなどです。このデザインシステムはテーマ設定が可能で、デスクトップやモバイルの UI 要素などの膨大なコンポーネントライブラリが用意されています。

UXPin のドキュメントに従って、レポジトリを正しくセットアップしましょう。また、Merge へのアクセスのリクエストもできます。テクニカルサポートチームがそのプロセスをお手伝いします。

デザインシステムのカスタマイズ

コンポーネントライブラリのドキュメントに従ってデザインシステムをテーマ設定するか、そのままの状態ですぐにプロトタイプを開始します。デザインシステムをプライベートレポジトリに保存して、UXPinと同期させましょう。

カスタム コンポーネントやテンプレートの追加など、レポに変更を加えると、Merge が自動的にそれを UXPin に同期してくれます。また、バージョン管理により、プロジェクトを更新するタイミングを選択でき、デザインシステムの以前のバージョンにいつでも切り替えることができます。

統合の選択

以下の３つの統合機能のうちの１つから、コンポーネントをUXPinに取り込むことができます：

• Git 統合：Reactライブラリにのみ利用可能な Git レポジトリに直接接続する。
• Storybook 統合：React、Vue、Angular、Ember などのフロントエンドフレームワークで利用可能なパブリックまたはプライベートな Storybook に接続する。
• npm 統合：UXPin への npm リンクを貼り付け、使いたいコンポーネントをインポートする。

統合の初期設定が完了すると、MergeはUXPinのレポジトリの変更を自動的に更新し、チームのメンバー全員に新しいバージョンを通知します。

Git 統合は、UXPinと正しく同期するための何らかの設定が必要ですが、UXPinはダウンロードできる Merge boilerplateを提供しており、ルートディレクトリで npm install を実行すると、ボイラープレート レポジトリからコードを実行するのに必要な依存関係がインストールされます（React、Webpack、Babel などのものです）。

また、Git 統合では、バージョン管理、パターン、Merge コンポーネント マネージャーなどの Merge の全機能を利用できます。

Storybookは、デザインシステムのコンポーネントを分離して開発するための直感的なダッシュボードを提供します。デベロッパーは GitHub レポジトリにディストリビューションする前に、コンポーネントを文書化してテストするといいでしょう。また、Storybook には連携、QA（品質保証）、承認機能があり、チームはデザインシステムのあらゆる側面を管理し、ガバナンス手順に従うことができます。

プロパティパネルの設定

各コンポーネントの React props は、UXPinのプロパティパネルに表示され、色、サイズ、ステート、タイポグラフィなど、デザインシステムで確定された変更を行うことができます。

注：React propsは Git 統合でのみ表示されます。Storybookを使っている場合は、Args を使って UXPin のプロパティパネルを設定する必要があります。

作業開始

コンポーネントを UXPin にインポートしたら、いよいよプロトタイプ開始です。デザインシステムのライブラリから UI エレメントをキャンバスにドラッグして、UI を構築しましょう。

UXPin のパターンでは、新しいパターンやテンプレートを作成し、それを個人のパターンライブラリに保存することができます。その UI コンポーネントはすでにレポジトリに存在しているため、開発中にそれを組み合わせてプロトタイプを再現することができます。

また、Webサイト や Webアプリ ではブラウザ上でプロトタイプをテストでき、モバイルアプリのテストには UXPin Mirror を使います（Android と iOS で利用できます）。

そして、開発の準備に納得がいくまで、UXPin のプロトタイプでテストを反復をします。

React のアプリ制作

最後のステップは、UXPin MergeのプロトタイプをReactアプリケーションへの変換作業です。ちなみに YouTuberのCoderOne は、UXPinのプロトタイプから開発への移行に関する優れたチュートリアルを公開しています。

プロトタイプのコピーに最適な方法は、UXPinのPreview（プレビュー）とShare（共有）モードです。ここでは、製品のサイトマップ、アダプティブバージョン、仕様、各コンポーネントのプロップなどを見ることができ、UXPinでは、コンポーネントのドキュメントへのリンクも提供されます。

スペックモードでは、UXPinは各コンポーネントとその相対的なプロップを JSX で表示します。デベロッパーは、このproduction-ready のコードをコピー/ペーストして、React のプロジェクトでプロトタイプを複製できます。

UXPin Mergeに切り替えて、プロトタイピングツールの利便性とコードの魅力を活用しませんか。より良いUXを作りながら、プロトタイピング、テスト、イテレーションをより速くやってみましょう。詳しくは、Merge のページをぜひご覧ください。

The post React ラピッドプロトタイピング – 速く作成する方法とは？ appeared first on Studio by UXPin.

プロトタイプが完成しましたか？それでは、作成したデザインを開発チームに送ってコードに変換してもらいましょう！

…しかし、ここで疑問が浮かびます。そもそも、「デザインからコード（Design to Code）」という流れで行うのは、本当にベストな手順なのでしょうか？

これについて考える前に、もう一つの方法として「コードをデザイン（Code to Design）」に反映させ、コード化されたUIコンポーネントで作業する方法もあります。

本記事では、「Design-to-Code（デザインからコード）」と「Code to Design（コードからデザイン）」のワークフローについてメリット、デメリットを含めて説明し、実際に企業が実践しているユースケースをいくつかご紹介していきます。

「Code to Design」のテクノロジーを体験してみませんか？UXPin Mergeで、デザインと開発での「信頼できる唯一の情報源（Single source of turth）」を活用しましょう。UXPin Mergeについて詳しく見る。

Design-to-Code

「Design-to-Code」は、典型的な製品開発プロセスを表しています。デザイナーはデザインツールやプロトタイピングツールを使ってUI（ユーザーインターフェース） をデザインし、デベロッパーに渡してコード化してもらいます。

長年にわたり、「Design-to-Code」のプロセスは進化してきましたが、「デザイン」と「開発」の間には、まだ大きなギャップがあります。デザイナーは今でも静的なUIを作成し、エンジニアはそれをコードに変換しないといけないのです。

静的なUIは忠実度や機能性に欠けるため、デザインチームはデザインやプロトタイプが何をするものなのか、ドキュメントや注釈、説明を含めないといけません。

ツールにインタラクティブ性がなく、多大な時間とリソースが必要なことから、多くのデザイナーがアニメーションやトランジションのデモにGIFやビデオを使っています。それによって、デザインファイルやドキュメントを断片化し、デベロッパーやステークホルダーにとってわかりにくいものとなってしまいます。

詳しくは、「デザインツールはイメージベースからコードベースへ」の記事でご覧ください。

「Design-to-Code」の利点

デザイナーとエンジニアにとって「Design-to-Code」のプロセスは、それぞれが使い慣れたツールやワークフローを使って馴染みのある言葉を用いて作業することができることから、両者にとって。

デザインツールは、使いやすさとスピードを重視して作られており、経験豊富なデザイナーは、画像ベースのデザインツールを使って、画面モックアップを本当に速く作成することができます。

「Design-to-Code」の限界

残念ながら、「Design-to-Code」は実際のところ、利点よりも制限の方が多いため、多くの企業がデザインプロセスの改善に模索しています。

デザインと開発間のズレ

現在の「Design-to-Code」でのワークフローでは、忠実度と機能性が大きな制約となっていることから、画像ベースのプロトタイプでは最終製品のように見えたり機能はしません。デザイナーは、プロトタイプを説明する文書や注釈、会議を行ったとしても、エンジニアが期待に応えてくれないと不満を抱いてしまうかもしれません。逆に、エンジニアはデザイナーに技術的な制約をうまく伝えづらいため、そこに摩擦が生じてしまいます。

デザインシステムの課題

高品質のデザインシステムであっても、「Design-to-Code」は、ハンドオフ、スケーラビリティ、成熟度の面で課題が生じてしまい、デザインシステムチームは、以下の２つのデザインシステムの管理が必要です：

• デザイナー向けのUIキット
• デベロッパー向けのコンポーネントライブラリ

さらに、両方のシステムに関するドキュメントの維持が必須です。

このワークフローを「信頼できる唯一の情報源（Single source of truth）」として表現するのは誤りです。これについて、ドイツに本拠を置くソフトウェア開発会社のdotSourceがこちらの記事（英語の記事です）で以下のように指摘しています：

「デザインシステムのリリースの多くは、少なくとも以下の３か所のアップデートが必要になるでしょう：

• デザインシステムのコードベース（コンポーネントライブラリ）
• デザインチームのUIキット(デザインツール)
• デザインシステムのドキュメント

各 UIコンポーネントに対して、「信頼できる唯一の情報源（Single source of truth）」が「３つの 信頼できる情報源」になると、直感に反しているように見え、エラーを増加させてしまいます。デザインシステムの更新プロセスと技術が一致していないと、1つの変更に3箇所の更新が必要になるため、チームは冗長な作業で行き詰まることになってしまいます。”

重複作業

エンジニアは、デザインの最終版を手に入れたら、それをコードに変換させなければいけないため、デザインをコードに反映させる必要がない場合よりも、はるかに長い時間がかかってしまいます。

Code to Design

「Code to Design」は、UXPinがMergeの技術を使って独自に開発したワークフローです。

デザイナーは、使い慣れたUIや機能のあるデザインツールを引き続き使いますが、デザインはベクターグラフィックスではなく、本番環境へリリースする前のコードをレンダリングします。

多くのデザインツールはプラグインや拡張機能でこのシステムを再現しようとしていますが、エンジニアがそのコードを使えることはほとんどありません。MergeはデザインシステムのリポジトリからUXPinにコンポーネントを同期させるので、コードはエンジニアが自分で書いたものなのでそのまま使うことができます。

そしてデザイナーは、エンジニアが開発時に使うのと同じコンポーネントライブラリをデザインプロセスで使います。

「Code to Design」の利点

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

「Code to Design」は製品開発の多くの問題を解決しますが、最も大きな利点は、「真の 信頼できる唯一の情報源（Single source of truth）」、つまり全員が同じレポジトリから同じコンポーネントライブラリを使う点です。レポジトリに変更があると、自動的にUXPinに同期され、デザインチームに更新が通知されます。

Mergeのバージョン管理により、デザインチームは以前のリリースに変更し、選択したときに既存のプロジェクトの更新のみをすることができます。

デベロッパーは、UXPinの Storybook統合を使っていたら、リリースごとにドキュメントを同時更新します。この「信頼できる唯一の情報源（Single source of truth）」は、DesignOpsでの多くの課題を解決し、それによってチームメンバーが重要なタスクに集中することができます。

「Code to Design」のワークフローのもうひとつの大きなメリットは、そのデザインハンドオフのしやすさです。エンジニアはコンポーネントライブラリのパッケージをインポートしてコンポーネントを追加し、UXPinからJSX コードをコピーし、開発を完成させます。

コンポーネント駆動型のプロトタイピング

Mergeコンポーネントは、レポジトリと同じプロパティとインタラクティブ機能でUXPinに表示されます。各コンポーネントのプロップ（Storybookでは Args）はUXPinキャンバス上のプロパティパネル（Propaties Panel）に表示されるため、デザイナーは色、ステート、サイズなどを含むデザインシステムに従って変更を加えることができます。

このような既製のUI要素を用いて、デザイナーがコンポーネントとパターンをドラッグ＆ドロップするだけで、完全に機能するプロトタイプを構築するコンポーネント駆動型の迅速なプロトタイピングが実現するのです。

デザインドリフトがない「究極の一貫性」

既成のコンポーネントによって、誰でも同じ制限および制約のある同じUIライブラリを使うため、矛盾がなくなります。

デザイナーは、UXPinのプロパティパネルで利用可能なプロパティによってのみ要素を変更することができます。オーバーライドがないため、変更の可能性がないことから、結果としてドリフトが発生しません。

ガバナンスの向上

この制限により、ガバナンスとデザインシステムの整合性が上がります。デザインシステムチームはレポジトリを絶対的に管理していることから、新しいパターンやコンポーネントを普及させるためには、誰もが正しい手順を踏まなければなりません。

拡張性と成熟度

Merge は、チームメンバー全員が同じコンポーネントライブラリを使い、ゼロからのデザインや開発を行わずに製品をリリースすることで、最高のデザインシステム成熟度を提供します。この技術を使うことで、組織は「Design to Code」のワークフローに従うよりも、大幅に早くこのレベルの成熟度を達成することができるのです。

全員が単一のコードベースを使用することで、技術や市場の変化に応じたデザインシステムの拡張がしやすくなります。また、デザインシステムチームが新しいコンポーネント、パターン、テンプレートをレポジトリに追加すると、製品開発チーム全体ですぐに利用できるようになります。

検証の質を向上

「より良いプロトタイプ」は、「より良い検証」ということであり、デザイナーは、最終的な製品体験を正確に表現するプロトタイプによって、デザインプロセスにおいてより多くの問題を解決し、より良い機会を見出すことができます。

ユーザビリティ調査の参加者やステークホルダーは、最終製品と同じようにそのようなプロトタイプを操作することができ、それによって有意義なフィードバックやデータに基づく実用的なインサイトに繋がります。

制限事項

「Code to Design」にはコンポーネントライブラリが必要

「Code to Design」は、コンポーネントライブラリでのみ機能します。組織内でデザインシステムがない場合は、オープンソースのUIライブラリの活用も可能です。たとえば、PayPal の社内製品開発チームではカスタマイズされた MicrosoftのFluent UIデザインシステムを使用しました。

デザイナーはMergeの npm統合を使って、npmレジストリで利用可能なオープソースライブラリからコンポーネントをインポートすることもできます。この方法には技術的なスキルは必要なく、その代わり、デザイナーは Merge コンポーネントマネージャー機能 を使って UI要素をインポートまたは管理を行うことができます。

デザイナーとエンジニアの連携

「Code to Design」では、デザイナーとエンジニアのより密接に連携する必要がありますね。ほとんどの組織には、デザインシステム専門のチームがあるので、これは標準的なガバナンスの手順とあまり変わらないでしょう。

柔軟性が低い

コードベースのデザインシステムは、デザイナーが素早く組み立てられるUIキットに比べると柔軟性に欠けてしまいます。デザイナーは、一度デザインツールにアップロードされたコンポーネントの変更や操作が制限されている、もしくは全くできません。この柔軟性の低さは、デザインシステムのガバナンスと整合性のうえでは必要ですが、革新性と創造性を制限してしまうという意見もあるかもしれません。

UXPinは他のデザインツールと同様に機能するため、デザイナーは新しいアイデアやパターンを開発し、チームメンバーに提案することができます。UXPin のパターン（Patterns）機能では、既存のデザインシステム要素を組み合わせたり、オープンソースライブラリをインポートして、新しいコンポーネントや、パターン、テンプレートを作成することができます。

このように、「Code to Design」は、デザイナーがオープンソースのライブラリの良い部分を活用して新しいパターンを開発できるため、創造性と革新の機会が増えるでしょう。

「Code to Design」を採用している企業

UXPinの「Code to Design」ワークフローは世界の様々な規模の企業に採用されています。ここでは、実際に「Code to Design」を実践しているユースケースを３つご紹介します。

PayPal

PayPalでのUXチームは、「Code to Design」のワークフローへの切り替えで、製品開発プロセスに革命を起こしました。２０１９年に切り替えて以来、PayPalの製品チームは、デザインドリフトや不整合もなく、８倍速くリリースを提供できるようになりました。さらにPayPalの新しい製品開発プロセスでは、部門外のコラボレーションも改善され、全員がUXに責任感を持つようになりました。

また、Mergeで PayPalのプロトタイプと検証の質も改善され、ユーザビリティテスト参加者とステークホルダーからのフィードバックもより良いものになりました。

「UXPin Mergeの大きな影響の1つは、高忠実度のプロトタイプを作成できるようになったことです。最終製品がどのように見えるか、UXやインタラクティブ性に関して、デザイナー、経営陣、ディレクター、デベロッパーを含む全員がより確信を持てるようになり、ステークホルダーからより質の高いフィードバックを得られるようになりました。」- Paypal 社 UX Lead EPX、エリカ・ライダー氏

TeamPassword

TeamPasswordは、競争の激しいパスワード管理市場で事業を展開する、５名からなる（２０２３年２月現在）スタートアップ企業です。TeamPasswordにはUXチームがなく、エンジニアが新しいリリースのプロトタイプとテストを行う必要があります。

Mergeに切り替える前は、TeamPasswordのエンジニアが各プロトタイプを開発していたこともあり、リソースが限られた企業にとっては時間のかかるプロセスでした。そこで２０２２ 年、TeamPasswordはUXPin Mergeに変更し、カスタムMUIのデザインシステムを同期させました。

「Code to Design」のワークフローに変えてからは、TeamPasswordの市場投入スピードは劇的に改善され、製品に使い勝手の問題や矛盾がなくなり、それによって企業の競争力が高まりました。

革新的な「Code to Design」のソリューションで「Design-to-Code」のワークフローを改善しませんか？詳細はMerge のページをぜひご覧ください。

The post 「Code to Design」か「Design to Code」どっちがいい？ appeared first on Studio by UXPin.

Ant Design は、エンタープライズ製品開発のためのよく使われているデザインシステムであり、その包括的なコンポーネントライブラリには、製品チームが最新の B2B デザインの問題を解決するのに必要なものがすべて備わっています。

主なポイント：

• Ant Design は、ボタン、フォーム、ナビゲーションメニュー、データテーブル、モーダルなど、幅広いユースケースをカバーする高品質な UI コンポーネントが集まったものである。
• Ant Design は、一貫性とユーザビリティを促進するデザイン原則とガイドラインの遵守で知られている。
• Ant Design は「Ant Design 言語」の原則に従い、それが明快さ、効率性、シンプルさを重視したデザインとなっている。
• Ant Design には、デザイナーとデベロッパーの強力で活発なコミュニティがあり、それが継続的な開発とサポートに貢献している。

UXPin Merge で、デザインチームは Ant Design の UI コンポーネントをインポートして、完全に機能するプロトタイプを作成することができます。そこで本記事では、Ant Design で作業する利点、その膨大なコンポーネントライブラリ、そして最終製品のように見える Ant Design プロトタイプを構築する方法について概説していきます。

UXPin Merge で、デザインと開発の間に「信頼できる唯一の情報源（Single source of truth）」を作成しませんか。詳細およびこの高度なプロトタイプ技術へのアクセス方法については、Merge のページをぜひご覧ください。

Ant Design （AntD）とは

Ant Design は、アリババ、アリペイ、Huabei、MYbank などの親会社である Ant グループによって開発されたオープンソースのデザインシステムであり、そのコンポーネントライブラリは、React、Vue、Angular のフロントエンドフレームワークに対応しています。

Ant Design には、レイアウト、アイコン、タイポグラフィ、ナビゲーション、データ入力/フォーム、データビジュアライゼーションなどが含まれ、デザイントークンで、組織は製品要件に合わせてコンポーネント ライブラリをカスタマイズできます。

Ant Design の主な利点

製品開発者が Ant Design を選ぶ主な理由の一つに、その包括的なコンポーネントライブラリと機能があります。データビジュアライゼーションなどの、あらゆるタイプの UI パターンを見つけることができることから、エンタープライズ製品に最適です。

以下に、ソフトウェア開発者から学んだ Ant Design の利点を挙げてみましょう：

• 行き届いたメンテナンス： Ant Design のチームは、頻繁にアップデートを行い、デザインシステムの改善に継続的に取り組んでいる。バグはほとんど発見されいないとのエンジニアからの報告もある。
• 包括的なライブラリ： Ant Design には、あらゆるデザイン問題を解決するコンポーネント、パターン、アイコンがある。さらに、各要素には複数のバージョンがあり、どのようなシナリオにも対応できる。
• ネイティブライブラリ： Ant Design Mobile には、クロスプラットフォームのネイティブアプリケーションを構築するための広範なライブラリがある。
• アニメーションライブラリ： Ant Motion は、ネイティブと Webコンポーネントライブラリを補完するために、一般的なパターンとマイクロインタラクションのアニメーションを提供する。
• サードパーティライブラリ： Ant Design のサードパーティの React ライブラリには、デザインシステムの機能を上げるデータビジュアライゼーション、無限スクロール、マップ、メディアクエリなどが含まれる。
• 国際化対応： Ant Design の国際化機能は、世界中の言語に対応しており、デベロッパーは言語を追加することもできる。
• フォーム：優れたフォーム処理機能を備えた広範なフォームライブラリ。
• Scaffold： ダッシュボード、レポート、テーブル、管理者 UI、チャット、ログインなど、１００以上のテンプレートプロジェクト。
•  

• タイプスクリプトの互換性

マテリアルデザインと Ant Design

マテリアルデザインと Ant Design は、相違点よりも類似点の方が多くあります。

どちらにも、クロスプラットフォームのアプリケーションを構築するための包括的なデザインシステムがあり、優れたドキュメントと大規模なグローバルコミュニティが備わっています。

テーマ設定

マテリアルデザインとAnt Designでは、テーマ設定にデザイントークンが使われています。そのため、デベロッパーはUIコンポーネントやパターンを簡単にカスタマイズできるようなります。

アクセシビリティ

アクセシビリティは、両デザインシステムの最も大きな違いの１つです。マテリアルデザインには、原則とベストプラクティスが各コンポーネントに「組み込まれている」アクセシビリティが備わっているのに対し、Ant Designではこれをデベロッパーに任せています。

技術スタックの互換性

マテリアルデザインは、クロスプラットフォームの Flutterのアプリケーションを開発するための最善策であり、デベロッパーは数行のコードでコンポーネントを呼び出し、UI（ユーザーインターフェース）を簡単に構築できます。また、マテリアルデザインはMUIを通じて Reactアプリでも利用できます。

対する Ant Designは、React、Vue、Angular のフレームワークに対応していることから、より多くのソフトウェアデベロッパーがデザインシステムにアクセスできるようになります。

Ant Design と Bootstrap

Bootstrap は、レスポンシブ Webサイトや Webアプリケーションを構築するための、最も古いフロントエンドの CSS フレームワークの１つです。フレームワークの CSS と Javascript のライブラリを活用して、少ない労力で Webサイトや Webアプリケーションを開発できるため、多くのエンジニアがプロトタイプに Bootstrap を使っています。

Ant Design と同様に、Bootstrap は React、Vue、Angular に対応していますが、Bootstrap がフレームワークであるのに対し、Ant Design はデザインシステムである点が両者の最大の違いです。

プロトタイプと Webサイト構築には、Bootstrap を選ぶ方がいいですが、Ant Design には、Web とネイティブのクロスプラットフォームアプリケーションを構築するのにより多くの機能があります。

Ant Designで構築できるもの

Ant Design のコンポーネント、パターン、テンプレート、アイコンの膨大なライブラリで、B2B や B2C のデジタル製品の開発が実現します。そして、このデザインシステムのフォームとデータ可視化パターンは、エンタープライズアプリケーションのための一般的な選択肢となっています。

以下は、Ant Designを採用している企業です：

• Yuque（语雀）：ナレッジマネジメントのプラットフォーム
• アリババ：世界最大のオンラインマーケットプレイス
• バイドゥ：中国の Google に相当し、Ant Design を実行する複数の製品がある世界最大級の AI・インターネット企業。
• Fielda：フィールド調査用のモバイルデータ収集アプリケーショ
• Moment：プロジェクト管理ソフトウェア
• Videsk: ビデオベースのカスタマーサービス・プラットフォーム
• Solvvy：Zoomのチャットボット・ソフトウェア
• Ant Financial：中国有数の FinTech企業

Ant Designのデザイン言語

１．デザイン言語

Ant Design のデザインバリューには、多くのユーザビリティの問題を解決するための原則とパターンが含まれており、そのデザインシステムには以下の４つの価値があります：

1. 自然：認知的負荷を最小限にするため、製品や UI は直感的でないといけない。
2. 一定：デザイナーは、連携を強化し、一貫したユーザー体験を提供するために、コンポーネントとパターンを一貫して使用しないといけない。
3. 有意義：製品には明確な目標があり、ユーザーを支援するために各アクションに対して即座にフィードバックを提供しないといけない。また、デザイナーは、ユーザーが気が散ることなくタスクに集中できるような体験を作らないといけない。
4. 成長：デザイナーは、人間とコンピュータのインタラクションの共生を考慮し、スケーラビリティを考慮したデザインをしないといけない。

２．動作の原理

Ant Design には以下の３つの動作の原理があります：

1. 自然：デザイナーは、スムーズで直感的なアニメーションとトランジションで、自然の法則に基づいた動きをしないといけない。
2. パフォーマンス：アニメーションは遷移時間が短く、製品のパフォーマンスに影響を与えてはいけない。
3. 簡潔：デザイナーは、UX（ユーザーエクスペリエンス）に付加価値を与えない過剰なアニメーションを避けながら、正当で有意義なインタラクションを作成しないといけない。

３．グローバルスタイル

Ant Design のドキュメントの「Global Styles（グローバルスタイル）」のセクションには、色、レイアウト、フォント、アイコン、ダークモードのガイドラインが含まれています。

Ant Design のパレット生成ツールでは、製品の原色に基づいて１０色のパレットが生成されますが、Material Theme Builder や他のパレット生成ツールに比べると、やや原始的なツールです。

フォントのスケールと行の高さは、平均的な距離の５０cm（２０インチ）、角度０.３度で計算されたユーザーの読書効率に基づいて、有益なガイドラインを提供します。ちなみに、ベースフォントは１４px、行の高さは２２pxです。

Ant Design のアイコンは、アウトライン、塗りつぶし、ツートンの３種類があります。また、デザインシステムのイコノグラフィーの原則に準拠したカスタムアイコンを作成するための説明書もあることから、カスタマイズの一貫性が最大限に確保されます。

Ant Design のコンポーネント

Ant Designのコンポーネントライブラリの概要と主な機能は以下の通りです。

一般的なコンポーネント

ボタン、アイコン、タイポグラフィなどがあります。また、ボタンの種類は以下の５つになります：

1. プライマリ：メインCTA（Call to Action）
2. デフォルト：セカンダリ（二次的）CTA
3. 破線
4. テキストボタン
5. リンクボタン

さらに、以下の４つのボタンのプロパティがあります：

1. 危険：削除のようなリスクの高い操作
2. ゴースト：アウトラインボタンとも呼ばれる
3. 無効：アクションが利用できない場合
4. 読み込み中：スピナーを追加し、コントローラを無効にして複数投稿を防ぐ

レイアウト

Ant Design のレイアウトには、仕切り、グリッド、スペース（配置、方向、サイズなど）が含まれます。

ナビゲーション

ナビゲーションのパターンには、affix、パンくずリスト、ドロップダウン、メニュー、ページヘッダー、ページネーション、ステップなどがあります。

データ入力

Ant Design のデータ入力コンポーネントにより、そのデザイン システムはエンタープライズ アプリケーション開発に最適な選択肢となるでしょう。

プロダクトチームは、Ant Designのすぐに使用できるパターンを使って、以下のようなエンタープライズ UIを簡単に構築できます：

• オートコンプリート入力フィールド
• カスケードのドロップダウンメニュー
• チェックボックス
• 日付ピッカー
• フォーム
• 入力（テキストと数値のみ）
• メンション（ユーザーへのタグ付け）
• ラジオ
• レーティング（アイコンと絵文字）
• セレクトメニュー
• スライダー
• スイッチ
• タイムピッカー
• 転送セレクトボックス
• ツリーセレクター
• アップロード

データ表示

データ入力にはデータ表示が関係しており、以下のようにデータを視覚化してユーザーに提示します。

• アバター
• バッジ
• カレンダー
• カード
• カルーセル
• 折りたたみ（アコーディオン）
• コメント（ユーザーディスカッション）
• 説明（注文、取引、レコードなどのテーブル）
• 空（空のコンポーネントのプレースホルダー）
• 画像
• リスト
• ポップオーバー
• セグメント
• 統計（ダッシュボード用の数値コンポーネント）
• テーブル
• タブ
• タグ
• タイムライン
• ツールチップ
• ツリー

フィードバック

デザイナーは、以下の Ant Design のフィードバックのコンポーネントを使って、ユーザーとコミュニケーションをとります。

• アラート
• 引き出し
• メッセージ（画面上部にシステムフィードバックを表示）
• モーダル
• 通知
• ポップコンファーム
• 進行状況
• 結果（成功、失敗、エラーなど）
• スケルトン（遅延ロード・プレースホルダー）
• スピン（スピナー）

その他

最後のカテゴリーには、アンカー（目次）とバックトップ（トップに戻る）があり、基本的にはナビゲーション・コンポーネントです。また、デベロッパーがコンポーネントをグループ化できるコンフィグプロバイダーもあります。

Ant DesignのReactコンポーネントをUXPinにインポートする

どのようなデザインシステムでも、「信頼できる唯一の情報源（Single source ofn truth）」があるにもかかわらず、デザイナーとエンジニアで、デザイナーは画像ベースの UI キットを使い、エンジニアは React、Vue、Angularなど、コードベースのコンポーネントライブラリを使うというように、異なる UI 要素が使われていることが課題となります。

UXPin Merge は、真の「信頼できる唯一の情報源（Single source of truth）」を作成します。ソフトウェアのデベロッパーは、製品のデザインシステムやAnt Design などのオープンソースのコンポーネントライブラリを UXPin に取り込むことができるため、デザイナーは、エンジニアが最終製品の開発に使うのと同じ UI 要素をプロトタイプに使うことができます。

Merge のコンポーネントはコードによって駆動されることから、デザイナーは完全なインタラクティブ性とデザインシステムによって確定されたプロパティを得られます。例えば、この Ant Design ボタンには、UXPin で何も変更しなくても、デフォルトでホバーとクリックのインタラクションが含まれています！

また、デザイナーは、（色、サイズ、タイプ、コンテンツなど）デザインシステムで確定されたコンポーネントのプロパティにプロパティパネルからアクセスして、変更を加えることができます。

UXPinはそれを JSXとしてレンダリングするため、エンジニアはSpecモードからコピー＆ペーストして開発を始めることができることから、ドリフトがなく、常に100％の一貫性を保つことができるのです！

Ant Design の npm統合

UXPin の npm統合により、デザイナーは Ant Design などの npm レジストリにホストされているオープンソースのコンポーネントライブラリから UI 要素をインポートすることができます。

デザイナーは Merge のコンポーネントマネージャーを使って、以下の Ant Design の npm の詳細を追加するだけです。

• パッケージ名：antd
• アセット位置：antd/dist/antd.css

そして、UXPinは npm経由でAnt DesignのGitHub のレポジトリに接続します。 デザイナーは、Ant Design のドキュメントを使って、プロトタイプに必要なコンポーネントとプロパティを選択できます。

Ant Design のコンポーネントを UXPin にインポートするには、このステップバイステップ ガイドをご覧ください。

また、セットアップと基本的なプロトタイプの構築を説明する CoderOne の YouTube のチュートリアルを見るのもいいでしょう。

ユーザーテスト中に有意義な結果を生み出す、完全に機能する Ant Design プロトタイプを構築しませんか。 より多くの機会を特定しながら、デザインプロセス中により多くの問題を解決することで、デザインチームの価値を高めましょう。 詳細とアクセスのリクエスト法については、Merge のページをぜひご覧ください。

The post Ant Design – デザインシステム入門【エンタープライズ向け】 appeared first on Studio by UXPin.

デジタル製品を成功させるためには、多くの努力が必要です。しかし、努力したからといって、ユーザーが自分の製品を選んでくれるとは限りません。

実際のところ、リリース前に製品を十分にテストをしなかったことで、ユーザーは製品から離れてしまうことがあります。  高度で完全な機能を持つプロトタイプを作らず、忠実度の低いプロトタイプに決めてから開発段階に入った場合、信頼できるユーザビリティテストを行う余地はありません。

今になってようやく、数え切れないほどの時間を費やして作った製品が、期待よりも成功を収めていないことに気づいたのです。

ここでは、 ユーザビリティテスト の重要性と、テストで正確な結果を得るために機能プロトタイプが必要な理由を詳しく見て、この仮説的な失敗から学んでみましょう。

ほとんどのデジタル製品は失敗する

成功する確率は高くありません。それは悲観的な見方ではなく、あくまで数字での話です。

 アプリの成功率は実はたったの0.5%程度です。つまり200個のアプリを作って、そのうち1個だけが成功するという統計です。では、残りのアプリはどうなるのでしょう？

• 67.8%は1,000ダウンロードに到達しません。
• 17.9%は1,000人のアクティブユーザーを獲得できません。
• 5.8%はユーザーを維持できず、おそらく削除され、忘れ去られてしまうでしょう。
• 5.8%は収益を得られません。せっかく作ったのに、何の見返りもないのです。
• 1.4%は収益を上げていますが、利益は出ていません。

計算を否定することはできませんが、発売に踏み切る前に製品をテストすることはできます。

このような現実を目の当たりにすると、「なぜユーザーテストが重要なのか」と思うかもしれませんが、200個のアプリのうち1個は成功していることは覚えておきましょう。

完全な機能性のあるプロトタイプはビジョンをもたらす

ここで、プロトタイプやユーザーテストを行うことのメリットを考えてみましょう。

多くの企業はアプリの開発とテストに十分な時間をかけていません。appinventivによると、開発者の24％は、発売前の製品開発に3カ月以下しか費やしていません。その中には、1ヵ月以内にアプリを発売した企業もあります。市場を調査し、製品を設計し、製品を開発し、品質保証のためのテストを行い、1ヶ月以内に発売することは実現可能でしょうか？可能性は低いと思います。

第三に、これが問題の核心につながるのですが、インタラクティブ機能がある完全に機能するプロトタイプと実際のデータを使ったユーザーテストの恩恵を受けているデザイナーはほとんどいません。

機能性のあるプロトタイプで、モックアップでは得られない視点を得ることができます。

早期の ユーザビリティテスト で時間とコストを削減

例えば、あなたはプロジェクトマネージャーで、チームに2人のデザイナーと3人の開発者がいたとします。1年間で、デザイナーには約53,400ドル、開発者には約114,300ドルを支払うことになります。この小さなチームで年間449,700ドルと手当がかかります。（これは米国での給与の中央値です。）

当然のことながら、あなたはスタッフからできるだけ生産性を高めてほしいと思っている一方、開発の最後でテストを実施していては生産性の向上につながりません。ユーザビリティテストの段階に入って、誰も使いたがらない機能を追加するのに1週間も費やしていたことに気づきたくないですよね。

デザイン段階で ユーザビリティテスト を行うことで、開発プロセスを効率的に、スピードアップすることができます。完全な機能性のあるプロトタイプで、実際の操作性や、ユーザーに人気のあるレイアウトに気づくことができるかもしれません。

このようなことは、常にプロセスの早い段階で知れるほうがよいでしょう。ユーザビリティテストの結果、ひどいコンセプトであることがわかったら、そのコンセプトにお金をかける前に、やり直しましょう。もっといいアイデアがあるはずです。

プロトタイプの中に、状態、条件、インタラクションを持つインタラクティブコンポーネントを作ることで、テスト前に開発者が機能を作ることに頼る必要はありません。

また、自分のプロトタイプを誰にでも送ることができます。UXPinのアカウントは必要ありません。プロジェクトのリンクを持っている人であれば、プロトタイプを操作してコメントを残すことができます。

製品のユーザビリティを向上させる方法がわからない場合は まずはユーザーエクスペリエンスの5つの原則を参考にしてみてください。最初から正しい方法で作業ができることほど効果的なことはありません。

プロトタイプはデザイナーと開発者の間にある壁を解消する

プロトタイプが機能的に見えても、最終製品と同じように正確に動作しないのではないかと心配になるかもしれません。

Mergeでは、各コンポーネントが完全にコード化されているため、そのような心配はありません。コードの書き方がわからなくても大丈夫です。デザイナーはインタラクティブなUIを見て、開発者は同じコンポーネントの製品化可能なコードを見るだけなので、簡単です。1 つの要素に 2 つの視点があります。

Merge のコードベースのデザインアプローチは、開発者が既存のコンポーネントから新しい製品を作ることができることも意味します。機能がどのように動作するかをすでに知っているので、独創的な方法でそれらを組み合わせて、ユーザーに新しいツールを提供することができます。React コンポーネントや Storybook のライブラリがあれば、それらを簡単に組み合わせることができ、それらがどのように作用するかを知ることができます。

Mergeを使って完全な機能を持つプロトタイプをテストする

Mergeは、最終製品の模造品を提供するだけのプロトタイピング ツールではありません。すぐにテストを開始可能な完全に機能的プロトタイプが得られます。最も重要なことは、テストをするためにHi-Fiプロトタイプの構築に10倍の時間を短縮できるということです。

最終製品と同じように動作するプロトタイプで ユーザビリティテスト を向上させることができれば、デジタル製品は簡単で、より早く市場投入することができます。今すぐMergeを使い始めてみましょう。

The post ユーザビリティテスト を向上させるプロトタイプの作成方法 appeared first on Studio by UXPin.

UIコードコンポーネントをUXPinのエディターにインポートするための、デザイナーに便利な方法が発表されました。エンジニアの積極的なサポートがないチームでも Mergeにアクセスできるようにするための、新しい “npm 統合” です。

UXPin Mergeでデザインプロセスに革命を起こす

UXPinとMergeテクノロジーにより、プロトタイプでの新しいレベルの忠実度とインタラクション性を生み出し、スムーズなデザインハンドオフ、デザイナーとデベロッパーの作業の信頼できる唯一の情報源（Single source of truth）での統合が可能になります。まさに、製品開発プロセスを効率化するものです。

静的なデザインから完全にインタラクティブなデザインへ

静的なプロトタイプの時代は終わり、今は特にデザイン成熟度が高い企業で、より効率的なプロトタイピングの方法を探しています。動きのないアートボードをリンクさせ、不完全なツールでデザインをコードに変換し、ニュアンスの異なるインタラクションを何度も文書化することは、仕事を増やし、成長の妨げにもなるのです。

そこでMergeの出番です。この技術があれば、真の機能を持つ要素を組み込んだプロトタイプの作成ができるのです。Mergeは、PayPalのチームが行ったように、デザインをスケールアップさせます。

デザインと開発間の連携の効率化

Mergeでは、デザインチームと開発チームが、制作プロセス全体を通して同じインタラクティブなコンポーネントを使用して作業します。デザイナーはUIコンポーネントを使用し、一方、開発者は全く同じデザインから作成されたコードをコピーします。

デザインからコードへの変換はもう完了です。信頼できる唯一の情報源（Singe source of truth）を最大限に活かすことで、デザインとエンジニアリングが一体となり、デザインのハンドオフ段階がシンプルになります。つまり、デザイナーもデベロッパーもハッピーで、行ったり来たりのやりとりで時間を無駄にすることもありません。

デザインの一貫性を保証する正確なUIコンポーネントの使用

デザインプロセスで使用されるコード化されたUIコンポーネントは、プロトタイプを最初から最後まで一貫したものにします。デザイナーが意図したとおりに製品が作られていくのです。何よりも、デザイナーがコードを扱う必要ないことが1番ですね。

その結果、Mergeの技術ない場合、デザインと最終製品の外観や感触の間にずれがないため、非常に時間とエネルギーを消耗する結果になります。

UXPin MergeへのUIコンポーネントの新たなインポート方法

コンポーネントを使ってデザインする前に、コンポーネントのライブラリへのインポートが必要ですが、今までコード化されたコンポーネントをUXPin Mergeに取り込むには、2つの方法がありました。

• Gitの統合：デベロッパーはソースコードとその履歴をホストするためにGitを使いますが、コードコンポーネントをUXPinにインポートするには技術的なサポートが必要です。
• Storybookの統合： Storybookには、UXPinに持ち込むことができる公私でのコンポーネントライブラリが保存されています。

今回、UIコンポーネントをインポートする3つめの方法として、デザイナーにとって自由度が高いnpm統合機能が追加されました。

Merge npm統合で得られるもの

デベロッパーからの積極的なサポートがない場合、多くのデザインチームが大変な思いをしてMerge Git 統合をすることになります。そこで、本来Mergeが持つ威力を発揮するために、UXPinにコンポーネントライブラリをインポートする、デザイナーにとっても使いやすく新しい方法がリリースされました。

npm統合の使い方って？

では、npmの統合をどのように使うか見てみましょう。まずは、その方法を以下で文章でご説明します。

npmコンポーネントをUXPinにインポートする

npmは、プロジェクトで使用するためにダウンロードできる既製の開発要素を持つ、パッケージのレジストリです。最も使われるオープンソースのデザインシステムの一部は、この方法で配布されています。

Adele (UXPin のデザインシステムレポジトリ) を使って、どのデザインシステムが npm パッケージに含まれているかを調べることができ、最終列までスクロールすると、配布方法が表示されます。 または、独自のReactベースのコンポーネント ライブラリをnpmにアップロードして、UXPinで使用することもできます。

npmデザインシステムをUXPinに取り込む手順は次のとおりです。

1. 新しいライブラリをUXPin Mergeに追加する

どの React ベースのデザイン システムを使用するかがわかったら、それを UXPin Merge と同期します。そして UXPin ダッシュボードの【Merge】タブに移動し、npm パッケージを介してライブラリを追加します。 npm パッケージ名と使用するバージョンを指定する必要があり、 ドキュメントで必要な場合は、「assets location（アセットの場所）」のフィールドにスタイルを追加します。

2. UI コンポーネントを構成する

Merge Component Managerを開き、インポートするコンポーネントを指定しますが、必要に応じてコンポーネントを分類できます。 コンポーネントを作成した後、そのプロパティを管理し、インポートするものを確定します。 ライブラリの文書にアクセスして、プロパティの名前とタイプを確認しましょう。

3. 完全にインタラクティブなプロトタイプの作成を開始

最初のデザインを作成する時が来ました。デザインエディタ（design editor）に移動し、コンポーネントをキャンバスに置きます。 使用するコンポーネントのプロパティを簡単に変更できることをご覧ください。コンポーネントのインタラクティブ性（動きなど）を確認するには、【Preview（プレビュー）】モードに移動します。

プロトタイプは完成しましたか？ これで、プロジェクトのリンクを仲間のデベロッパーに渡すだけで、デザインからコードをコピーしてスペックをチェックできるようになります。

それでは実際にやってみましょう！

1. 統合の使用方法を説明するビデオをご視聴ください。

Youtubeで統合の流れについて一通り説明してくれるビデオをご用意しました。 npmデザイン システムをUXPinにインポートする方法については、この動画をご覧ください。

2. npmコンポーネントをMUI からUXPinにインポートする

MUIをUXPinにインポートしますか? 以下のブログ記事では、一連のプロセスについて説明しています。

MUIのコンポーネントをUXPinにインポートするには？

3. Ant DesignからUXPinにnpmコンポーネントをインポートする

Ant Designは、最も人気のあるライブラリの1つです。 UXPinにログインすると、npm を介してインポートした Ant Design コンポーネントの一部が表示されます。 すぐに使用できるので、 下の記事でUXPinへのインポート方法を確認してください。

 中国初の Ant Design とは？UXPin連携方法と npm 統合徹底ガイド

npm統合 + Patternsを使う

必要なものをすべてインポートし、変更を保存したら、基本的なものからより複雑なコンポーネントを作ったり、同じ手順を何度も繰り返さないように、コンポーネントをプロパティで保存したりすることができます。つまり、パターンを作るのです。

詳しく読む： Patterns（パターン）の使い方

npm統合を試してみよう

npmの統合により、コード化されたUI要素をUXPinに取り込むのにデベロッパーの手助けは必要なく、デザイナーはUIコンポーネントをUXPinに取り込み、好きな方法で自分で管理することができます。

npmの統合でUIコンポーネントを導入しましょう。デザインチームと開発チームを信頼できる唯一の情報源（Single source of truth）でつなぎ、組織のサイロを解消しましょう。14日間のトライアルにサインアップして、ぜひ統合をテストしてみてください。

The post UXPin Mergeで npm 統合するには？ appeared first on Studio by UXPin.

製品とそのデザインシステムは、常に進化し続けるプロジェクトです。製品の規模が大きくなるにつれ、デザイナーはユーザビリティの課題を解決しながら、ビジネス目標やユーザーニーズを満たすために、新しい UI パターンやコンポーネントを作成しないといけません。

デザイナーは新しいパターンを普及させる前に、まずはそれを作らないといけないんです！さらに、大抵の組織では、デザインシステムのガバナンスの手順に従っているため、新しいパターンがライブラリで利用できるようになるまでに時間がかかる可能性があります。

UXPinのPatterns（パターン）では、デザインチームが「既存のMergeコンポーネント」と「標準的なUI 要素」を組み合わせて新しいUIパターンを作成し、UXPinライブラリに保存することができます。

そこで本記事では、UXPin のPatterns（パターン）機能の使い方などをご紹介し、製品やデザインシステムをスケールアップするためどのように活用することができるかをみていきます。

UXPin Merge で完全に統合されたデザインシステムを構築し、製品開発チームに「信頼できる唯一の情報源（Singl source of truth）」を提供しませんか。この革新的なコードベースのデザインテクノロジーの詳細とリクエスト方法については、ぜひ Mergeのページをご覧ください。

UXPin Mergeとは、その仕組み

Merge によって、Gitレポジトリ、Storybook、npmパッケージでホストされているコンポーネントライブラリの要素を UXPin のデザインエディターにインポートして、チーム全体が同じデザインシステムを使えるようになります。そして、デザイナーはその要素を使って、最終製品と完全に一致するプロトタイプを作成することができます。

従来、多くのデザインシステムでは、以下の２つの UI ライブラリが搭載されています：

• デザインチームは静的なUIキットを使用
• エンジニアはコード化されたコンポーネントライブラリを使用

多くの組織は、この二重のシステムが「信頼できる唯一の情報源（Single source of truth）」であると主張していますが、その実現には多くの時間とリソースが必要です。

UXPin Merge は、コンポーネントライブラリが１つしかないため、純粋にそれが「信頼できる唯一の情報源」になり、デザイナーとエンジニアは、同じレポジトリから同じ UI 要素やパターンを使います。

また、Vue、Ember、Web Components、Angularなど、他の一般的なフロントエンド技術については、Merge for Git や UXPin の Storybook 統合を使ってReactコンポーネントを同期することができます。

さらに、デザイナーは Merge の npm 統合を通じて、MUI、Bootstrap、Ant Design、Lightning などのオープンソースのコンポーネントライブラリの npm パッケージをインポートして、完全に機能するプロトタイプまたは最小実行製品（MVP）を構築することもできます。

UXPin パターン（Patterns）とは

パターンとは、デザインチームが Merge コンポーネントと標準的な UXPin UI  要素を組み合わせて、より複雑な UI パターンを構築することができる Merge 独自の機能です。

ブラッド・フロスト氏の「アトミックデザイン」のコンテクストでは、デザイナーはパターンによって、基礎となる UI 要素やコンポーネントである原子や分子を使って、カード、フォーム、ナビゲーション、ヘッダー、フッターなど、有機体やテンプレートなどの大規模で複雑なデザインを構築できます。

UXPin パターンの代表的な使用例として、以下のようなものがあります：

• 現在のライブラリにはない高度なコンポーネントの作成
• よく使うコンポーネントのバリアントのプロパティの保存
• グループ化と保存 要素の大きなUIパターンへの統合
• 一貫性を上げるための新しい UI パターンのデザインチームとの共有
• エンジニアがコンポーネントライブラリに追加するための新しいパターンの推進

デザイナーは、複数のコンポーネントライブラリや UXPin の基本的なコンポーネントの UI 要素を組み合わせて、新しいパターンを作成することができます。この柔軟性は、新しい UI パターンに必要なパーツがデザインシステムにない場合に有益です。

例えば、ドロップダウン メニューを使ったヘッダー ナビゲーションを構築したいけど、現在のデザイン システムにはドロップダウン メニューがないとします。その場合は UXPin の npm 統合を使って、MUI（または他のオープンソースライブラリ）からドロップダウン メニューをインポートし、それを使って新しいナビゲーションのパターンを構築することができます。エンジニアは、MUIのドキュメントを読み、JSXコードを見ることで、新しいパターンのコーディング方法がわかり、それをデザインシステムに追加することができます。

UXPin Patterns（パターン）の３つのメリット

パターンは製品開発およびデザインシステムチームに対して 主に３つの利点があり、この３つは、Merge レポジトリに必要なものがない場合に、パターンが同等の代替手段を提供してくれる点が共通しています。

１．UI 要素を入れ子にして複雑なコンポーネントを構築できる

包括的なデザインシステムがあっても、デザイナーは製品の進化に伴って新しいコンポーネントやパターンを作らないといけないことがよくありますが、多くの場合、そのパターンはデザインシステムには存在しないため、デザイナーは毎回ゼロから構築しないといけません。

特にグラフやデータテーブルのようなものを作る場合、ゼロからデザインすると、貴重な時間がその作業に費やされることになります。その代わりに、このような複雑なパターンを一度作成し、UXPin のパターンライブラリに保存しておくといいでしょう。また、このパターンを他のデザイナーと共有することで、チームで作業が被ったり、矛盾が生じたりすることがなくなります。

多くのデザインツールがこの機能を提供していますが、コードコンポーネントを操作して組み合わせることができるものはありません。これがパターンだと、デザイナーはデザイナーとエンジニアのハイブリッドな役割を担い、１行のコードも書かずに、完全に機能する複雑なUIを構築することができます。

２．同じコンポーネントのプロパティを再利用できる

デザイナーは Merge によって、プロトタイプを画像ベースのデザインツールよりずっと速く構築できますが、より効率的に作成する余地は常に存在します。

例えば、デフォルト、エラー、警告、成功など、さまざまな Merge フォームの入力やボタンの状態についてパターンを保存したいと思うかもしれません。パターンだと、それを一度設定してパターンライブラリに保存し、次の UI（ユーザー インターフェース）のためにドラッグ ＆ ドロップする準備ができます。

このような構築済みのパターンは、デザインスプリントや、ステークホルダーとのミーティングやユーザーテスト中でのちょっとした変更がしたい場合に特に便利です。UXPin のプロパティパネルでプロパティを操作する代わりに、目的のパターンをキャンバスにドラッグするだけですぐに使えますよ！

３．新しいデザインシステムの UI 要素の推進とテストができる

新しい UI 要素は、デザインシステムで魔法のように現れるわけではなく、DSチームは、リリース前にこのパターンを構築してテストする必要があります。UXPin パターンを使えば、DSチームは既存のコンポーネントを 基本的な UXPin やオープンソースのライブラリと組み合わせて、より高い忠実度と機能性でテストおよびイテレーションを行うことができます。

また、UXPin Mergeとパターンを使ったコンポーネント駆動型のプロトタイプによって、デザイナーはエンジニアからのより少ないインプットでイテレーションを行い、エンジニアは最終コンポーネントの開発とデザインシステムのテクニカルバックログの処理に集中することができます。

パターンがあれば、デザインチームはエンジニアが新しいコンポーネントを開発するのを待つ必要がなく、DSチームが作成したプロトタイプのパターンを使うことで、忠実性や機能性を損なうことなく、デザインとテストのプロセスを継続できるのです。

UXPin パターンは、１回こっきりの UI コンポーネントやほとんど使われない UI コンポーネントを作成するのに素晴らしいツールです。このようなパターンは、デザインシステムに昇格するほどには使われていませんが、デザインチームはまだそこへのアクセスが必要な時がありますからね。

それを UXPin パターン ライブラリに保存すると、デザイン システムのレポジトリに追加されることなく、完全に機能する Merge コンポーネントの利点を得られ、エンジニアは、そのコンポーネントを別のレポジトリに保存して、必要なときに使えます。

UXPin Merge Patterns（パターン）の使い方

では、UXPinで新しいMerge パターンを作成するのがいかに簡単であるかをみてみましょう。MUI npm のチュートリアルでインポートしたものと同じコンポーネントを使用しているので、そちらもぜひご覧ください。

以下のパターンは、Merge の npm 統合 を使ってインポートした MUI コンポーネント３つと、UXPin の基本的な テキスト要素 ２つが使われています（デザイン賞はもらえないでしょうけど！）

でもこのようなシンプルなパターンでも設定が必要なので、再利用可能なパターンを作ることで、その繰り返しの作業をなくすことができたらいいですね。

ステップ１

パターンに必要なコンポーネントを追加して配置します。複数のコンポーネントライブラリや UXPin の基本的な要素を組み合わせることができることを忘れずに。

ステップ２

Merge コンポーネントのプロパティを設定します。

• アクセシビリティのために、プレースホルダーとヘルプテキストを備えたメール入力フィールドを作成しました。また、ユーザーが入力しないといけないことがわかるように、このフィールドは「必須項目」としました。
  
  
• 次に、MUIチェックボックスを追加しました。これはユーザーが当社からのメールを受信するためにチェックする必要があります。
• 最後に、ユーザーがメールフィールドとチェックボックスを完了した後にクリックしなければならない場所が明確になるように、MUIボタンを選択し、プライマリに設定しました。

以下は、メールコンポーネントのプロパティパネルの例です。

ステップ３

コンポーネントライブラリの上にある左サイドバーの「Patterns（パターン）」タブに切り替えます。

ステップ４

パターンとして保存したい UI 要素のグループまたは単一のコンポーネントを選択します。左サイドバーの大きな白い「＋Add（追加）」のボタンをクリックすると、新しいパターンが表示されます。

ステップ５

パターンの名前をクリックして、より分かりやすいものに変更したり、デザインシステムの命名規則と一致させます。複数のパターンを用意したら、UXPin の検索機能🔍を使って、必要なものを絞り込むといいでしょう。

パターンの削除

また、下の鉛筆のアイコン（「Enter edit mode（編集モードに入る）」）をクリックすると、古いパターンを削除できます。

削除したいパターンを選択して【Delete（削除）】をクリックします。

複数のステートの作成

デフォルトのパターンができたので、ワークフローをさらに最適化するために、追加のステートを作成したいと思うかもしれません。

例えば、ユーザーがメールアドレスを入力しなかったときに発生するエラーステートのパターンを設定するといいでしょう。

また、ユーザーが有効なメールアドレスを入力し、入力を確認した場合にのみ、ボタンが有効になるような無効ステートを作るのもいいですね。

これで、プロトタイプを始めるのに３つのニュースレターパターンの準備ができました。デザイナーは、プロパティの設定やパターンからの個々のコンポーネントの切り替えを気にすることなく、ドラッグ＆ドロップで簡単に変更することができます。

UXPin MergeとPatternsでワークフローを効率化する準備はできましたか？Merge へのアクセス権をリクエストして、さっそく使ってみましょう。

The post UXPin Merge Patterns（ パターン ）の使い方・チュートリアル appeared first on Studio by UXPin.

 

アトミックデザインは、以下の５つの要素で構成され、それらが互いに積み重なっています：

• 原子：化学の世界と同じように、アトミックデザインでは「原子」は情報を全て伝えるための基本要素です。Webアプリケーションの世界では、『HTMLタグ』、『フォント』、『アニメーション』、『カラーパレット』などの基礎的な要素が【原子】にあたりますが、Webデザインの【原子】は、例えば、『ボタン』や『フォーム』など、あまり具体的でない場合もあります。
  
  
• 分子：分子は、その次に大きな構成要素です。異なる原子の結合によって作られる分子は、もともと複雑なものですが、さまざまな原子の集合体であるため、概念的には、よりわかりやすい UI 要素への分解が可能です。例えば、フォームラベルや入力欄など、大きなデザインシステムの骨格となるものがWebデザインの分子となります。
  
  
• 有機体：「原子」が結合して「分子」を形成し、「分子」の集まりが「有機体」を形成します。アトミックデザインの世界では、有機体は Webサイトの外観と機能の両方を形成する UI 要素であり、UI（ユーザーインターフェース）に影響を与え始める要素でもありますが、デベロッパーが分子をどのように配置するかによって、サイト体験や完成品の複雑さが変わってきます。有機体の例としては、ロゴ、検索フィールド、およびメイン ナビゲーションが挙げられ、これらが一緒になってヘッダー有機体を形成する場合があります。
  
  
• テンプレート：アトミックデザインのこの段階では、化学的な意味合いと結びつけることから離れ、フロントエンド開発全体の辞書にシフトしていくことになります。テンプレートは、ページレベル、あるいはそれ以上のレベルでつながった「有機体」であり、原子、有機体、分子と同様に、非常に具体的なものです。また、より抽象的な部品を適合させるための固定されたコンテクストを提供し、サイトを最終形態に似たものにまとめ上げる役割を果たします。テンプレートの良例としては、HTMLのワイヤーフレームが挙げられます。
  
  
• ページ：ページとは、アトミックデザインの最終的な要素であり、フロスト氏自身は、「ページとはテンプレートの具体例である」としています。ページは最も具体的な要素であり、ユーザーが最も多くの時間を費やす場所です。また、アトミックデザインの中でも最も重要なフェーズであり、ページの最終的なイテレーションは、デザインシステム全体が有効か否かをデベロッパーが確認する場でもあります。つまり、ページの最終的な外観によって、製品デザインが発売できる状態にあるか、デベロッパーが立ち戻って以前の UI デザイン要素に変更を加える必要があるかどうかが決まります。

アトミックデザインの利点

アトミックデザインの基本的な UI コンポーネントを説明したところで、このようなコンポーネントが有益な理由や、デザインシステムを構成するのによく使われるアプローチとして登場した理由について深掘りしてみましょう。

「ミックス＆マッチ」の実現

アトミックデザインの手法では、デベロッパーはUI 要素を１つのブロックとして動かすのではなく、独立したものとして捉えることができ、それによって、アトミックコンポーネントを再利用、再目的化、または他の要素との組み合わせで、新しい、より複雑なコンポーネントを形成することができます。

わかりやすいレイアウトの生成

これは、デベロッパーにとっても最終ユーザーにとっても同じことです。デベロッパーにとっては、アトミックデザインで作成されたサイトのコードは読みやすく理解しやすいものになり、ユーザーにとっては、アトミックデザインのサイトはナビゲートしやすく、より直感的になります。また、デベロッパーがサイト内のコンテンツ構造を変更する際も、アトミックデザインなら各要素が何を表しているのかが一目瞭然で、それに応じた変更が可能です。

全体的にシンプルな UX デザインを作成

アトミックデザインの基本は複雑に聞こえるかもしれませんが、実はアトミックデザインで作られたサイトは、全体的に UI コンポーネントの数が少ないのです。

その理由は以下の通りです：

デベロッパーが UI の構築に取り掛かる前に、原子、分子、有機体などの基本的な構成要素のリストがあれば、無駄に新しい UI 要素を作るよりも、既存のインフラを利用する方がいいでしょう。

その結果、部品点数が少なくなり、無駄のない使いやすいサイトが実現するのです。

UI コンポーネントの強化

顧客のレベルが上がって目が肥えてくるにつれて、Web開発もそれに対応する必要があることから、Web デザインの世界では、今 UI が重視されていますが、幸い、アトミックデザインはそれを簡単に実現してくれます。複雑なウェブ開発の見通しをシンプルにすることで、デベロッパーのワークフローが効率化され、エンドユーザーにはより良い UI がもたらされます。

UXPin で再利用可能なコンポーネントを使ってデザインしませんか。Reactコンポーネントをプロダクトデザインに持ち込み、プロトタイプでアトミックデザインの原則に従ってみましょう。UXPin Merge の詳細はコチラ。

The post アトミックデザイン における５つの UI コンポーネント appeared first on Studio by UXPin.

オープンソースのデザインシステムには、高品質の製品を急ピッチで開発する機会があり、組織はユーザビリティとアクセシビリティの基礎的な課題を解決することで、製品開発と問題解決を重点的に行うことができます。  

 Fluent UIは、エンタープライズ製品を開発する企業で支持されているオープンソースのデザインシステムです。包括的なコンポーネントライブラリを使うことで、マイクロソフトのエコシステムに対応したアプリケーションを構築できるとともに、あらゆる製品のテーマ設定による完全なカスタマイズと柔軟性を実現します。  

革新的なMergeテクノロジーを使ってFluent UIデザインシステムをUXPinにインポートして、デザインと開発の間に信頼できる唯一の情報源（Single source of truth）を作成しませんか。詳細とアクセスリクエスト方法については、Merge ページをご覧ください。  

 Fluent Design Systemとは

  Fluent UIは、マイクロソフトが構築・保守するデザインシステムです。オープンソースのデザインシステムで、以下の2つの機能があります：  

1. LightningがSalesforce向けにするような、Microsoft 365製品を開発するためのデザイン言語とコンポーネントライブラリ。
2. Microsoftのエコシステムの外でエンタープライズアプリケーションを構築するためのテーマ別コンポーネントライブラリ

  包括的なデザイン システムには、Web、Windows、iOS、Android、および macOS 用のプラットフォーム固有の UI 要素を含む、クロスプラットフォーム アプリケーションを構築するためのコンポーネントとパターンが含まれています。  

コンポーネントとパターンには、それぞれクロスプラットフォームの製品開発における凝集性と一貫性を高めるための基本的なステートとインタラクティビティが含まれています。このような機能により、企業はゼロからデザイン、プロトタイプ、テスト、イテレーションを行うのではなく、製品とUX（ユーザーエクスペリエンス）に注力することができます。  

 Fluent Design Systemの利点

  大抵のオープンソースのコンポーネントライブラリから得られる凝集性と一貫性とは別に、Fluent UIはB2B（企業間取引）やエンタープライズ製品のデベロッパーにとって多くの利点があります。  

シームレスなMicrosoft 365の製品体験

もし会社でメール、Excel、Word、TeamsなどのためにMicrosoft 365が使われていたら、Fluent UIは、たとえMicrosoft 365と同期していなくても、社内製品用の素晴らしいデザインシステムになります。  

受信トレイやスプレッドシートから、倉庫の在庫システムやデータの可視化まで、シームレスなUIデザインを作成することで、従業員はどのワークスペースでも馴染みのあるユーザー体験を得ることができ、それによって学習曲線が短縮されて、最終的に連携と生産性が上がります。  

企業向け製品開発

  企業のUIは、B2C（企業消費者間取引）アプリケーションに比べて、より複雑なアーキテクチャ、レイヤー、データを持つことが多いため、ゼロから設計すると、最終製品の開発・保守の負担や複雑さに加え、多大なリソースが必要となります。  

 Fluent UIのようなオープンソースのライブラリで、何百（もしかしたら何千）時間もかけてコンポーネントをゼロから作ってテストする作業が省かれ、その代わり、製品チームは Fluent UIのコンポーネントをドラッグ＆ドロップすることで効率的に新製品を開発することができます。  

 Fluent UIには、基本的な入力から、日付ピッカー、リストUI、ナビゲーションコンポーネント、通知、モーダルなどのより複雑なパターンまで、包括的なライブラリーが含まれています。また、デザインシステムはテーマ化が可能で、他の製品との統合やブランド要件に合わせたライブラリの適用が簡単です。  

さらに、Fluent UIチームがデザインシステムを成熟させ、製品が基本的なユーザビリティとアクセシビリティの要件を満たすようにするため、組織は無料でメンテナンスを受けられるという利点もあります。  

 Fluent UIによるコンポーネント駆動型プロトタイプ

  コンポーネント駆動型のプロトタイプは、ゼロからデザインするのではなく、デザインプロセス中に既製のUI要素を用いてプロトタイプを構築します。  

このプロトタイプの手法は、デザインチームがスケッチやペーパープロトタイプから、そのままHi-fiプロトタイプに移行でき、時間のかかる新しいUI要素をデザインするプロセスを省けるという利点があります。  

例えば、ゼロから表をデザインするのは特に厄介で、時間がかかりますよね。その点Fluent UIには、実装方法とベストプラクティスを記載したリストUIが多数付いています。  

デザイナーは、プロジェクトに適したリストを選び、関連するコンテンツを追加して、すぐにテストを始めることができます。例えば、このドキュメントライブラリーのUIは、デザイン、テスト、イテレーションに何時間もかかりますが、Fluent UIはそのような作業を省き、デザイナーは線、円、四角などを描くのではなく、ユーザーニーズのコア部分の解決に集中することができるのです。  

Fluent UIには多くの利点がありますが、従来のデザインツールでプロトタイプを作成すると、入力や日付選択などのユーザーコントロールが機能しないなど、テストが制限される制約があります。  

UXPin Mergeがあれば、デザイナーはコードのような忠実性と機能性を実現できます。  

コードベースのデザインツールとして、UXPin Mergeはコンポーネント駆動型のプロトタイピングを可能にし、そこでデザイナーは一行のコードも書かずに最終製品の正確なレプリカを作成することができるのです。  

UXPin Mergeによる高度なコンポーネント駆動型プロトタイプ

  UXPin Mergeでは、組織がレポジトリからコンポーネントライブラリを同期できるため、デザイナーはエンジニアと同じUI要素を使うことができます。Fluent UIのUIキットのいずれかを使う代わりに、UXPinのデザインエディタでデザインシステムのReactのコンポーネントを使うのです。  

このような Merge のコンポーネントには、色、サイズ、インタラクティブ性、ステート、機能性など、デザイン システムによって定められた Fluent UI の React プロップが含まれており、そのプロップは UXPin のプロパティパネルに表示されるため、デザイナーは製品の要件に合わせてコンポーネントを調整することができます。  

PayPal「Fluent UIとUXPin Merge」の使用例

  PayPalがUXPin Mergeに切り替える前は、同社の社内製品は一貫性がなく、使い勝手の問題が多くありました。  

PayPalでのデベロッパーツールおよびプラットフォームエクスペリエンスのUX担当シニアマネージャー であるエリカ・ライダー氏は、UXPinのインタビューで「PayPalの製品チームには、経験豊富なUX担当者やUIデベロッパーはいませんでした。その結果、さまざまなユーザビリティとデザインの一貫性の問題、つまり、2つの製品が同じに見えないという問題が生じたのです！」 と述べています。  

そこでエリカは、Fluent UIを次のような理由で採用することにしたと述べています：「マイクロソフトのFluentデザインシステムとUIコントロールは、より企業向けに特化しており、社内のUIに適しているため、社内ツールの開発に採用することにしました。」  

Fluent UIで、PayPalにUIコントロールと一貫性がもたらされ、コンポーネントの構築と管理よりも製品開発に集中できるようになりました。また、ゼロからデザインする必要性を最小限に抑えるカスタムコンポーネントやUIのテンプレートなどのテーマ別のFluent UIライブラリをホストするのに、同社はGitHubのプライベートレポを使っています。  

レポジトリ内のコードによって設定された制約のもと、PayPalのプロダクトチームがデザインプロジェクトの90％を完成させ、UXデザイナーは「UX（ユーザーエクスペリエンス）の指導者」として、複雑なユーザビリティの問題や継続的なコーチングをサポートします。  

Fluent UIとUXPin Mergeに切り替えてから、PayPalの製品チームは、経験豊富なUXデザイナーが画像ベースのツールを使っていたときよりも8倍速く製品を提供できるようになりました。  

信頼できる唯一の情報源（Single Source of Truth）

  Fluent UIやMergeのようなデザインシステムを使う最も大きな利点は、すべての製品開発チームにわたって信頼できる唯一の情報源（Single source of truth）を作成することです。  

Fluent UIのコンポーネントはすべて1つのレポジトリから提供されるため、デザイナーとエンジニアは同じ制限と制約の中で作業でき、レポジトリに変更があると自動的にUXPinに同期されて、デザインチームに更新が通知されます。さらに、デザイナーはUXPinのバージョンコントロールを使って、いつでもどのプロジェクトでも、どのバージョンのデザインシステムにも切り替えることができます。  

迅速な製品の成熟度

  製品やデザインシステムを成熟させるには、かなりの時間とリソースが必要ですが、Fluent UIを使えば、スタートアップ企業が何年もかけて行ってきた研究開発を、最初のリリースでFortune500のソフトウェア企業と肩を並べるまで早めることができます。  

Fluent UIユーザーは、コンポーネントの開発に悩まされることなく、製品のイノベーションと問題解決に集中することができ、デザインシステムには、ゼロからデザインやプログラミングをすることなく、プロダクトをスケールアップするためのUI要素がすべて揃っています。

Fluent UIのコンポーネントをUXPinにインポートする方法

  Fluent UI の Reactのコンポーネントライブラリをインポートする場合、デザイナーには 2 つの選択肢がありますが、どちらを選ぶにしても、ファイル構造とレポジトリの正しい設定のためにエンジニアの協力が必要です。  

Git統合

  UXPinのGit統合は、Reactのコンポーネントでのみ動作してレポジトリに直接接続し、エンジニアは、すべてをセットアップするのにUXPinのボイラープレート・レポをテンプレートとして使うことができます。そしてUXPinのテクニカルサポートは、このプロセスを通じて企業を指導し、デザインシステムが確実に正しく同期されるようにします。  

始めの接続が完了すれば、UXPinはどんな変更点でも自動的に同期してデザイナーにその更新情報を通知します。  

Storybook統合

  UXPinのStorybook統合もReactで動作しますが、組織のFluent UIのVue、Angular、Emberのライブラリとの同期も可能です。  

Storybookは、UIのコンポーネントを単独で開発・管理するための素晴らしいツールであり、UXPinのStorybookのベストプラクティスで、組織が確実にStorybookとMergeを最大限に活用できるようにします。  

UXPinでStorybookのコンポーネントを使う

Storybookのセットアップが完了すると、左サイドバーの「デザインシステムライブラリ」にコンポーネントライブラリが表示され、以下のマテリアルUIの例のように、ライブラリ名の横にStorybookのアイコンが表示されます（MUIライブラリのGit 統合のアイコンは違うことに注意しましょう）。

デザイナーは、ライブラリからコンポーネントをドラッグ＆ドロップして、UIを構築しますが、UXPin Patternを使って、このようなStorybookのコンポーネントや他のライブラリの要素を組み合わせることもできます。  

UXPin Patternには、以下のように大きなメリットが２つあります：  

• デザインシステムを拡張するための新しいUIのコンポーネントとテンプレートの作成（デザイナーは、エンジニアがレポジトリに追加するのを待つ間、これらを共有・使用し、プロトタイプを継続できる）
• プロトタイプやテスト時の速やかな変更のための、コンポーネントの複数のステートやバージョンの保存。

Argsとプロップの使用

  組織は、Reactのプロップ や StorybookのArgs を使って、UXPin のプロパティパネルに表示されるコンポーネントのプロパティを設定することができ、そのプロップやArgsで、デザイナーは色、タイポグラフィー、ステート、影、その他の重要な値など、スタイリングのためのデザインシステムのガイドラインに確実に準拠できます。  

デザイナーは、毎回最小限の労力でブランドらしい仕上がりを実現するのに、ドロップダウンやチェックボックス、テキストフィールドなどを使ってさまざまなプロパティを適用できます。  

このようなプロパティには、すでにレポジトリにコンポーネントとスタイリングがあり、それによってリリースごとに絶対的な凝集力と一貫性を保証されることから、エンジニアは最終製品をより速く開発できるようになるのです。  

Merge と Fluent UI で早速デザインを始めよう！

  UXPin Merge と Fluent UI のパワーをうまく使って、顧客の期待を上回る高品質のUXを実現するエンタープライズ製品を開発しましょう。詳しい情報およびデザインシステムやオープン ソースのコンポーネント ライブラリを同期するためのアクセスのリクエスト方法については、Mergeのページをぜひご覧ください。

The post Fluent Design System とは？UXPinのStorybookに取り込む方法 appeared first on Studio by UXPin.

『Design-to-Code（デザインからコード）』とは、デザインツールを使ってデザイナーがプロトタイプを作成し、デベロッパーがそれをコード化するという、一般的な製品開発の流れを簡略化したものです。

UXPin Mergeは、このプロセスをひっくり返す画期的な『 Code-to-Design （コードからデザイン）』のワークフローを採用しています。

本記事では、FinTechの大手であるPayPalを含む４つのケーススタディとともに、「 Code-to-Design 」の利点や課題について述べ、製品開発プロセスをどのように強化できるのかについて説明していきます。UXPin Mergeの詳細についてはぜひこちらのページをご覧ください。

『 Code-to-Design 』とは？

『 Code-to-Design 』は、UXPinがMergeの技術を使って開発したUXワークフローです。Mergeを使うことで、デザイナーはUXPinのデザインエディターにレポジトリからUIコンポーネントをインポートし、それらを使って「コンポーネント駆動型プロトタイピング」と呼ばれるプロセスで、完全にインタラクティブなプロトタイプを作成することができます。

このコンポーネント駆動型プロトタイピングの手法によって、デザイナーはプログラミング言語を書いたり学んだりする必要がなく、コードの利点をすべて活用できます。

「 Code-to-Design 」のワークフローは、UXデザイナー、ステークホルダー、プロダクトチームに次のようなメリットをもたらします：

1. デザイナーはリリース可能なプロトタイプを作り、それによってデザインプロセスでのテスト範囲を拡大する。
2. 既製のコードコンポーネントを使うことで、デザイナーはゼロからデザインする必要がなくなった。これによって、プロトタイプの品質、忠実度、機能性を高めながら、市場投入までの時間を短縮することができる。
3. Mergeのプロトタイプは最終製品のように見えることから、ステークホルダーはデザインのビジョンをより繊細にイメージすることができる。
4. デザイナーとエンジニアが同じ言葉を話し、同じソースを使うことで、デザインハンドオフがよりスムーズになり、摩擦が少なくなる。
5. Mergeはコンポーネントライブラリを製品開発のワークフローに統合するため、デザインシステムの導入が増加する。
6. ドラッグ＆ドロップの簡単なワークフローにより、デザイナーでなくてもプロダクトデザインがもっと身近になる。

『Design-to-Code』か『 Code-to-Design 』どっちがいいの？

「Design-to-Code」の課題

「Design-to-Code」は、従来のUXのワークフローであり、デザインチームは、標準的な画像ベースのデザインツールを使ってモックアップやプロトタイプを作成し、デベロッパーはそれをコードに変換します。

「Design-to-Code」のワークフローの最大の課題は、デザイナーとエンジニアの間にギャップが生じることです。デザイナーはそのギャップを埋めるべく、複数ツールの使用や詳細なドキュメント作成、さらにデベロッパーと直接プロトタイプやインタラクションでの機能についての説明をしなけいといけません。

このような手厚い作業や説明をしても、最終的な製品がデザイナーの仕様や期待に応えられないことはよくあることです。それでデザイナーとエンジニアは、責任をなすりつけ合いますが、本当の問題は言葉の壁です。デザイナーはベクターグラフィックツールを使う一方で、エンジニアはコードで仕事をするからなのです。

「 Code-to-Design 」でのソリューション

「 Code-to-Design 」のワークフローは、デザイナーとエンジニアの間のギャップを埋めるものです。両者は異なる言語を使いますが、Mergeのようなテクノロジーによって、デザインと開発の間のコミュニケーションが簡単になります。

デザインチームは視覚的なUI要素に取り組み、エンジニアはそれらを支えるコードに取り組むという、同じコンポーネントを２つの視点から見ていると思います。

そこで、デザインシステムで作業しているチームは、この「Code-to-Design」でのワークフローが最も有益です。

「Design-to-Code」のワークフローでは、チームは以下の２つのバージョンのデザインシステムで作業します：

• デザインツール用の画像ベースUIキット
• プログラミング用のUIコンポーネントライブラリ

「Code-to-Design」は、デザインチームとエンジニアが同じレポジトリから同じコンポーネントライブラリを使うため、このような分離をなくすことから、真の「信頼できる唯一の情報源（Single source of truth）」を作り出します。

「Code-to-Design」と「Design-to-Code」についてさらに読む。

「 Code-to-Design 」のユースケース

「Code-to-Design」が素晴らしいことはわかりましたが、実際の製品開発にはどのように反映されるのか？と思っているかもしれません。

ここでは実際に、企業が製品開発で『Code-to-Design」でのユースケースを４つご紹介します。

Paypal

２０１９年、PayPalは UXPin Mergeを使って社内の製品開発プロセスを完全に再デザインしました。PayPal内のUXチームは、６０以上の製品を管理する１０００人以上のエンジニアに対して５人のデザイナーという独自の課題を抱えており、どの製品も同じようには見えず、それぞれにユーザビリティやデザインの一貫性の問題がありました。

PayPalのUXリードEPXであるエリカ・ライダー氏は、この問題の解決するよう言われました。さらに大変なことに、彼女はPayPalのプロダクトチームが製品をデザイン、テスト、提供できるようなワークフローを作る必要がありました。しかしながら、プロダクトチームはデザインスキルに乏しい上に、デザインツールの経験もほとんどなかったのです。

従来の画像ベースのツールを使ったソリューションをいくつか試した後、ライダー氏は UXPin Mergeと出会いました。そこでPayPalのUXチームはMergeを使って、カスタマイズしたFluent UIのデザインシステムをUXPinに同期させました。

PayPalのステークホルダーは、この新しい「Code-to-Design」への投資の有効性を検証したいと思っていたので、ライダー氏は、１ページのプロトタイプの２つのバージョンを作成する実験を行いました。１つは画像ベースのツールで、もう１つは UXPin Mergeを使い、すると結果は以下のようになり予想以上でした：

• 画像ベースのツール：所要時間１時間以上
• UXPin Merge：所要時間 ８分

Mergeのプロトタイプは、忠実度と機能性がはるかに優れており、Paypalのプロダクトチームも指導を受けることで、同じ結果を得ることができたのです。

Paypalのケーススタディについて全文を読む

Iress

ソフトウェア開発会社の Iress は、下の画像のようにシステムの成熟度をデザインするために４つのプロセスを踏んでいました。

• ステップ１：PDF のスタイルガイド
• ステップ２：CSSによる HTMLパターンライブラリ
• ステップ３：UIキットとコンポーネントライブラリ
• ステップ４：完全に統合された「信頼できる唯一の情報源（Single source of truth）」で、リリースに必要なデザインやコードがない

Iressはステップ３の時点で、デザインと開発のギャップをどう埋めれば最終的なゴールにたどり着けるかわからず、行き詰まっていました。

当時のIressにとって、このワークフローは、以下の条件をすべて満たすものでした：

• デザイナーやエンジニアが製品を作り、リリースするのに必要なコンポーネントを提供する単一のリポジトリである。
• シームレスなデザインハンドオフによって、デザイナーとエンジニアのよりよい連携が行われる。
• デザインやフロントエンドのプログラミングをゼロからする必要がない。
• デザインドリフトや組織間の不整合がない。
• リアルでインタラクティブなプロトタイプが、ユーザビリティテストの参加者やステークホルダーに最終製品の正確な表現を提供する。
• ダークモードやマルチブランドのデザインシステムなど、テーマの切り替えを試す機会がある。

Iressの事例を全文読む

TeamPassword

上の２つのユースケースは、大規模企業の製品でしたが、スタートアップや小規模なチームに対して、「 Code-to-Design 」でどんなことができるのでしょうか。

TeamPasswordは、競争の激しいパスワード管理市場で事業を展開しているスタートアップで、「UXデザイナー不在」は最大の課題でした。

パスワードや機密データを預かるスタートアップ企業にとって、ユーザビリティの問題やデザインの矛盾は会社の信頼を失い、評判が落ち、さらには解約につながってしまうのです。

TeamPasswordのエンジニアは、コードでのプロトタイプを使って設計とユーザーテストを全て行いました。このようなプロトタイプは製品の機能とUX（ユーザーエクスペリエンス）を正確に表現していますが、アイデアを構築して反復するのは時間を食うものでした。

２０２２年、TeamPassword はMUIデザインシステムに切り替え、Merge を使って UXPinに同期させました。そこでエンジニアは、プロトタイプの開発の代わりに、UXPinでカスタムMUI Reactライブラリを使いました。そしてこの「 Code-to-Design 」のワークフローにより、市場投入までの時間が大幅に短縮され、ユーザビリティの問題やデザインドリフトが解消されたのです。

TeamPasswordのデベロッパーがデザインシステムのレポジトリを更新すると、その変更箇所が自動的にUXPinに同期されるため、常に最新バージョンの状態になります。また、Mergeのバージョンコントロール機能によって、チームは変更の追跡や、テスト中にバージョンを切り替えることができるようになりました。

TeamPasswordのケーススタディを全文読む

dotSource

dotSourceは、ドイツに拠点を置くデジタル製品のコンサルティングと開発を行う会社であり、複数のデザインシステムを用いて、製品やソリューションをクライアントに提供しています。

dotSourceでは、「デザイン用のUI キット」と「開発用のコンポーネントライブラリ」の２つのデザインシステムを持っているためプロセスや作業が重複してしまうことが、製品を提供する上での最大の問題点でした。また、デザインシステムのドキュメントは、「デザイン用のUIキット」と「開発用のコンポーネントライブラリ」につづき、チームが維持しなければならない３つ目のピースとなっていました。

つまり、dotSourceの「信頼できる唯一の情報源（Single source of truth）」は、実は「唯一」ではなく「３つの情報源」だったのです。そしてこれは、多くの企業が抱えるデザインシステムに関する問題でもあります。

dotSource は、「信頼できる唯一の情報源（Single source of truth）」をコードベースにする必要があると認識していましたが、UXPin Mergeと出会うまでは、従来の画像ベースのデザインツールでこのワークフローを実現する方法を知りませんでした。

dotSourceは現在、MergeのStorybook 統合を使って、デザインシステムをUXPinに同期させており、そうすることで、リリースごとにデザインシステムのレポジトリ、ドキュメント、UXPinのコンポーネントがStorybookによって更新されます。

「コードベースのデザインワークフローに切り替えることが、このような画像ベースの制限を回避する唯一の方法です。UXPinのようなコードベースのプロトタイピングツールとMergeテクノロジーによって、ベクターグラフィックスではなくブラウザのようにコードをレンダリングすることでこのワークフローが実現します。UXPinでは、UIコンポーネントがデベロッパーと同じように見え、動作するため、デザインと開発の間のギャップを効果的に埋めることができます。これが真の「信頼できる唯一の情報源（Single source of truth）」ですね。」 – dotSource

dotSourceの事例を全文読む（英文）

UXPinが提供する「 Code-to-Design 」ソリューション

製品チームは、コードコンポーネントをUXPinにインポートする際、以下のように選択肢が２つあります：

• 製品のデザインシステムを取り込む
• オープンソースのUIライブラリ（MUI、Bootstrap、Ant Designなど）を取り込む

そして、このようなライブラリをUXPinに取り込むには、以下の３つの方法があります：

• Git 統合：レポジトリから UXPinにReactコンポーネントライブラリを同期させる
• Storybook 統合：React、Vue、Angular、Web Components、Emberなど、多くのフロントエンドフレームワークをチームで同期できるようにする。（Storybookのドキュメントの全リストはこちら）
• npm 統合：デザイナーが、MCM（Merge コンポーネントマネージャー）を使って、npmレジストリからのオープンソースライブラリからUIコンポーネントをインポートできる。

npm統合とコンポーネントマネージャーを使うためのチュートリアルは以下の３つになります：

• React-Bootstrap
• Ant Design
• MUI

GitとStorybookの統合はもう少し複雑になってしまいますが、UXPinのテクニカルサポートチームと共に Mergeのセットアップを完了するには技術的なスキルが必要です。

UXPinのPattern機能を使ったコンポーネントの組み合わせ

UXPinのPatterns（パターン）機能を使えば、デザイナーはUI コンポーネントを組み合わせて新しいUIパターンやテンプレートを作成することができます。これは、デザインシステムに特定の要素がない場合で特に便利です。

例えば、製品に分析ダッシュボードを追加する必要があるのに、デザインシステムにはチャートがないとします。npmレジストリでオープンソースのUIライブラリを見つけ、MCMを使ってパッケージをインポートし、チャートのコンポーネントを追加すれば、同じ忠実度と機能を維持しながら新しいパターンを作成することができます。そしてチームは、このパターンのデザインシステムに組み込むことも、一度だけの使用もできます。

UXPinパターンについてのチュートリアルをさらに読む。（英文）

「 Code-to-Design 」を始めませんか？今回紹介した革命的なコードベーステクノロジーへのアクセス方法は、こちらのページからぜひリクエストください。

The post Code-to-Design 完全ガイド（２０２３年版） appeared first on Studio by UXPin.

デザインシステムは、再利用可能な コンポーネント ライブラリなしには存在し得ません。そのデザインシステムの コンポーネント は、デザインと開発におけるワークフローと UI （ユーザーインターフェース）の一貫性を作り出し、ドリフトを最小限に抑え、ハンドオフを効率化するものなのです。

ただ、その UI コンポーネントは単に表示されるわけではなく、デザインシステムチームは、まずデザイン言語（デザイン原則）や、一貫してまとまったコンポーネントライブラリを構築するためのチームをまとめるガイドラインなど、そのような UI 要素が存在するための基盤作りをしないといけません。

Merge のテクノロジーで、レポジトリにホストされているデザインシステムのコンポーネントを UXPin に同期させ、製品開発チーム全体で『信頼できる唯一の情報源（Single source of truth）』を確認することができます。詳細およびアクセス要求方法については、Merge のページをご覧ください。

デザインシステムの コンポーネント とは？

UIコンポーネントは、あらゆるデザインシステムの基礎となるものであり、フロントエンドのデベロッパーは、このコードコンポーネントを使って、UI やデジタル製品を構築します。

UI コンポーネントには以下のように２つの側面があります：

• 視覚的なデザイン要素
• コンポーネントにスタイルとインタラクティビティを与えるコードスニペット

大抵のデザインシステムには、以下の UI ライブラリの２バージョンがあります：

• デザイナー向けの画像ベースの UI キットやスタイルガイド
• デベロッパー向けのコードコンポーネント（UI コンポーネント）ライブラリ

UI コンポーネントのプロパティについての理解

コンポーネントにはそれぞれ、色、間隔、タイポグラフィ、ステートなど、インタラクティブで美的な特性を与えるプロパティがあり、デザインシステムのデザイン言語と UI ガイドラインが、そのプロパティを確定します。

多くのデザインシステムで React が使われているので、そのフレームワークを例にコンポーネントのプロパティの仕組みをご説明します。

Reactでは、プロパティを 「プロップ 」と呼んでおり、プロップには、スタイリング、インタラクティビティ、コンテンツが含まれます。以下の例では、MUI ボタンの React プロップスを示しています。

• 「children prop（子プロップ）」はボタンの内容を確定し、通常は 「今すぐ購入」 や 「送信」 などのラベルを指定します。
• 「color prop （カラープロップ）」は、ボタンの色を確定します。「inherit（継承）」、「primary（主）」、「secondary（副）」 などの各タイプは、デザインシステムのテーマの色を表し、エンジニアは、ライブラリのCSSファイル内のデザイントークンまたは変数を使ってこれらを確定します。
• 「disabled prop（無効プロップ）」 はブール（ブーリアン）で、「True（正）」か「False（誤）」のどちらかです。このプロパティを使うことで、エンジニアはユーザーがタスクやアクションを完了するまでボタンを無効にすることができます。

この３例からわかるように、コンポーネントのプロパティは多くの特性、機能、コンテンツを確定できます。

コンポーネントライブラリ と パターンライブラリ

UIコンポーネントは、効果的な UI を作成するためのビルディングブロックを提供します。例えば、「ユーザー」はボタンのアクションの起動やページ間の移動など、「メニュー」はオプションの表示や追加機能へのアクセスの提供など、デザイナーは UI コンポーネントを使って、アプリケーションのニーズに応じてさまざまなレイアウトやデザインを作成します。

一方 UI パターンは、このようなコンポーネントがどのように相互作用すべきかの構造と構成を提供し、デザインパターンで、ユーザーは必要なものを簡単に見つけられ、製品の使い方を理解できるようになります。一般的な UI パターンには、ナビゲーションバー、検索ボックス、ドロップダウンメニューなどがあり、デザイナーは、確立されたパターンに従って、すべてのプラットフォームで一貫した LnF（ルック＆フィール）を持つアプリケーションを作成することができます。

さらに読む： デザインシステム、パターンライブラリ、スタイルガイドの違い.

UIコンポーネントの構造とアトミックデザイン

UI コンポーネントとデザインパターンは、複数の小さな UI 要素で構成されています。ブラッド・フロスト氏のアトミックデザインは、その構造と、この小さな部分がどのように組み合わされて、私たちが見たり操作したりする部品を形成するかを説明するのに一番いい方法です。

Atom（原子）

Atom（原子） はデザインシステムの基礎となる要素で、これ以上分解することはできません。デザインシステムチームは、この Atom を組み合わせて、UIコンポーネントやデザインパターンを作成します。

Atom の例としては、以下のようなものがあります：

• ラベル
• 入力欄
• ボタン
• カラーパレット
• フォント
• アイコン
• アニメーション
• デザイントークン

Molecule（分子）

Molecule（分子）とは、複数の原子から構成される UI のコンポーネントやパターンのことであり、検索バー、ロゴ、ナビゲーションリンクなど、UI に必要な機能を提供します。

Organism（有機体）

Organism（有機体）とは、デザイナーがテンプレートや UI の構成要素として用いる UI パターンのことであり、例えば、ナビゲーションバー、画像カルーセル、フッター、サイドバーなどがあります。

アトミックデザインの構造は、テンプレートやページにも受け継がれています。詳しくはこちらの記事でお話しています。

デザインシステム１０大コンポーネント

このデザインシステムのコンポーネントのリストは、決して網羅的なものではありませんが、我々が選んだ１０個のコンポーネントのユース ケースと、それらがデザインシステムのエコシステムにどのように適合するかを以下で見ていきましょう。

１．ボタン

ボタンは、デザインシステムにおいて最も重要なコンポーネントの一つであり、フォームの送信、新しいページへの移動、ショッピングカートへの商品の追加など、ユーザーが UI と対話してアクションを完了するための手段を提供します。

デザインシステムを構築する前に製品チームが製品を監査する際、多くのボタンのバリエーションが見つかり、それが最終的にフラストレーションと混乱の原因となることがよくあります。なのでボタンの一貫性が保たれれば、ユーザーはアクションを起こしたり情報を探したりするための正しい UI 要素をすばやく特定することができます。

２．文字入力

テキストフィールドもまた、一般的なデザインシステムのコンポーネントです。このような入力要素により、ユーザーはテキストまたは個人情報などの数値コンテンツを共有し、検索にアクセスすることができます。テキストフィールドは通常、以下の主要なプロパティ３つを備えています；

• ラベル
• ヘルパーテキスト（アクセシビリティ用）
• プレースホルダー

また、デザイナーは、入力をより分かりやすくするために接頭辞や接尾辞を使います。例えば、米ドルを表す接頭辞として記号の「＄」、重量を表す接尾辞として「lbs（ポンド）」や「kg」があります。この２例では、（単位があることから）ユーザーは文字ではなく数字を入れることが分かります。

３．チェックボックスとラジオボタン

チェックボックスは複数選択型の UI パターンで、ラジオボタンは複数の選択肢の中から一つを選択する UI パターンで使われます。

４．トグル（スイッチ）

トグルコンポーネントは、ユーザーが異なる状態やオプションをサッと簡単に切り替えるためのシンプルで直感的な方法を提供し、それによって UI をナビゲートしてタスクを完了する時間が短縮されます。

５．ドロップダウンメニュー

ドロップダウンメニューは、UI の混乱を減らし、ユーザーが自分に関連するオプションだけを選択できるようにします。ユーザーが必要とするまで長いオプションのリストを隠しておくことで、より整理されたユーザーに優しいエクスペリエンスを実現します。

６．カード

デザイナーは、視覚的に魅力的でユーザーに優しい方法で情報を整理して提示するためにカードを使います。カードがあれば、ユーザーはコンテンツをすばやく読み取ることができ、必要なものを簡単に見つけることができます。また、カードはプラットフォーム間で一貫した LnF を提供し、統一されたクロスプラットフォームの UX を実現します。

７．ダイアログボックス

ダイアログは、何かの削除のような重要な、あるいは不可逆的なアクションを確認するための摩擦の瞬間を作り出すモーダルです。このダイアログは、プラットフォームによってビジュアルが異なるため、デザイナーは iOS、Android、Web、Windowsなど、複数のバージョンの作成が必要になります。

８．進捗バー

進捗バーは、複数のステップからなるタスクの進行状況をユーザーに知らせるために、デザイナーが使う重要なフィードバックコンポーネントです。このフィードバックで、ユーザーの期待値はコントロールされ、「あとどれくらいかかるんだ！」というフラストレーションが抑えられます。

９．ツールチップ

ツールチップは、ページ上の機能または要素に関する追加情報をユーザーに提供するもので、デザイナーは、ボタンやリンクなどの UI 要素の目的の説明や、使い方のヒントの提供のために、ツールチップを使います。

ツールチップは、製品やユーザーインターフェースがより複雑なエンタープライズ向けデザインシステムで特に有用であり、ユーザーが UI を離れて製品のドキュメントを確認することなく、ツールチップで機能を説明することができます。

１０．アラート＆スナックバー

アラートとスナックバーは、重要な情報を簡潔かつユーザーに優しく実用的なメッセージでユーザーに提供します。アラートは「エラー」や「警告」、「完了」などを知らせるために、スナックバーはアクションに関するコンテクストの情報を提供するために使われます。

デザインシステムのコンポーネントの例

ここでは、代表的なデザインシステムとそのコンポーネントライブラリの良例をご紹介します：

• Shopify Polaris
• Salesforce Lightning
• Atlassian Design System
• Google’s Material Design
• IBM Carbon Design System
• Microsoft Fluent Design System

このような例はデザインシステムベスト8の事例の記事に載っています。

UXPin Mergeによるコンポーネント駆動型プロトタイプ

デザイナーは、UIキットに含まれるデザインシステムのコンポーネントを使って、視覚的に魅力的な UI を作成することができますが、このような画像ベースのツールの問題は、機能を持たないUIコンポーネントのベクター表現をレンダリングする点にあります。

UXPin Mergeでは、デザイナーはコンポーネント駆動型開発と同様のコンポーネント駆動型プロトタイプ手法を使用して、最終製品のような外観と機能を持つ完全なプロトタイプを作成します。

Merge の仕組み

Mergeは、レポジトリ（GitHub）にホストされているデザインシステムの UI ライブラリとUXPinのデザインエディタを同期させます。デザイナーは、エンジニアが開発で使うのと同じコンポーネントをデザインプロセスで使うため、コンセプトから最終的なリリースまで、『信頼できる唯一の情報源（Single source of truth）』を作成することができます。

Merge をデザイン システムのレポジトリに同期させると、コンポーネントへの変更が UXPin のエディターに自動的に同期され、デザイナーに更新が通知されます。Merge のバージョン コントロールにより、デザイン チームは更新のタイミングを選択でき、古いプロジェクトで作業しているときなど、デザイン システムの以前のバージョンに切り替えることもできます。

ジョンソンエンドジョンソンのコンポーネント駆動型プロトタイピングへの移行

UXPin Mergeに切り替える前、ジョンソンエンドジョンソン（J&J）のデザインチームは画像ベースの UI キットを使用し、PDFと印刷物のスタイルガイドを別々に作成していました。何が問題でしょうか？

「…スタイルガイドをその企業の現在の標準に合うように全部更新したかどうかは、わかり得ないのです。可能な限りたくさんの会議を開いても、時代遅れのスタイルガイドは誰かの机の引き出しに入ったまま佇み、それであなたは１、２年後にもっと大変な思いをすることになるのです。」ジョンソン・エンド・ジョンソン社 エクスペリエンスデザインエキスパート サービスリーダー 、ベン・シェクトマン氏

J&J では、デザインシステムの開発管理に Storybook が、デザイナーには UXPin Merge が使われています。Merge の Storybook 統合により、J&J では２つの技術を同期させ、デザイナーとエンジニアが同じレポジトリから同じUIライブラリを使用できるようになりました。

「このようなコンポーネントは、インタラクティブ性を全て維持しながら、リリース可能な状態であるため、多くのハンドオフトラブルを回避することができ、デジタル製品の構築、デザインと開発の両プロセスをスピードアップしてくれます。」ジョンソン・エンド・ジョンソン社 エクスペリエンスデザインエキスパートサービスリーダー 、ベン・シェクトマン氏

完全な機能を持つプロトタイプを数分で作成

２０２１年のUXPinによるウェビナーで、J&J 社のベン・シェクトマン氏とジル・ジェラード氏は、Mergeによってデザインチームが古い UI の完全機能のプロトタイプを１０分もかからず構築できたことを述べました。

PayPal は Merge に切り替えた後、同様の結果を経験しました。製品デザイナーは 1 ページで完全に機能する新しい UI を １０ 分もかからず構築しますが、これは、経験豊富な UI デザイナーが限られたインタラクティブ機能を持つ画像ベースのツールで １時間以上かかっていたプロセスです。

もし Merge がこのような多国籍企業の巨大な製品開発プロセスをシンプルにできるなら、あなたのビジネスだったら何ができるか想像してみてください。

詳細およびアクセスのリクエスト法については、Merge のページをぜひご覧ください。

The post デザインシステムの１０大 コンポーネント とは？ appeared first on Studio by UXPin.