• AI コンポーネントクリエーターを有効にする

• • Merge AI プランがある場合、または Merge を有効にしている場合は、UXPin の Editor（エディタ）にある［AI Component Creator］に移動する。
  • ［Settings（設定）］タブで OpenAI API キーを入力し、AI 機能を有効にする。
• テキストプロンプトからコンポーネントを生成する
• • AI Component Creator の［Prompt（プロント）］タブを開く。
  • 作成するコンポーネントを説明するプロンプトを記述する。例：「角が丸く、背景が青、テキストが白のプライマリ ボタン コンポーネントを作成する。ボタンは MUI ライブラリを使う。」
  • MUI や Ant Design など、使いたい React ライブラリを選択し、［Generate（生成）］をクリックする。
  • 生成されたコンポーネントを確認し、必要に応じて、UXPin でプロパティやスタイルを直接調整する。

• アップロードされた画像からコンポーネントを作成する

• • コードバックされたコンポーネントにしたいビジュアルデザインがある場合は、AI Component Creator の［Upload Image（画像のアップロード）］オプションを使う。
  • 画像がアップロードされると、AI がそれを解析し、選択した Reactライブラリ（MUI、Ant Design、または React-Bootstrap）を使って完全にコード化されたコンポーネントを生成する。
  • 生成されたコードと構造を確認し、デザインシステムのコンポーネントライブラリに統合する。

• 既存の UXPin コンポーネントを変換する

• • UXPin に既存の静的要素がある場合は、コンポーネントを右クリックして AI 変換オプションを選択し、コードバックされたコンポーネントに変換する。
  • AI が MUI などの適切なライブラリを適用してコードを生成し、コンポーネントを開発可能な状態にする。

ステップ３：AI 駆動型デザインシステムを整える

• UI パターンの作成と文書化を行う

• • ［Design System（デザインシステム）］のインターフェースで、［UI Patterns］ セクションに進む。
  • 類似のコンポーネント（ボタン、フォーム、モーダルなど）をグループ化し、説明を追加して、使用ガイドライン、プロップ、バリエーションを文書化する。
  • AI Component Creator を使って、例えばさまざまな色やアイコンの配置でボタンのバリエーションを作成するなど、テキストプロンプトに基づいてこのコンポーネントのバリエーションを生成する。

• アクセシビリティガイドラインを追加する

• • 例えば色のコントラスト比の最小値を設定したり、インタラクティブな要素のキーボードナビゲーションを確保するなど、説明やガイドラインを追加することで、コンポーネントのアクセシビリティ基準を定める。
  • AI を使って、WCAG 準拠をチェックしたり、アクセシブルなラベルや alt テキストを生成するなど、アクセシビリティ基準に対してコンポーネントをテストする。

• コンポーネントバリアントの設定

• • UXPin で、さまざまなユースケースをカバーするために、ボタンのプライマリ、セカンダリ、無効状態などのコンポーネントのバリアントを作成する。
  • UXPin のインタラクションとブレークポイント設定を使って、コンポーネントのレスポンシブな動作を定める。

ステップ４：UXPin Merge を使ってライブコード統合を作成する

• UXPin Merge でコードコンポーネントをインポートする

• • • UXPin Merge を使って、レポジトリからライブコードコンポーネントをインポートする。Mergeを使うと、デザインシステムとコードコンポーネントを同期させることができ、デザインシステムに最新のコードベースが反映される。

• コードバックコンポーネントの文書化と共有を行う

• • コードバックアップされたコンポーネントをデザインシステムで直接文書化し、コードレポジトリへのリンクやデベロッパー向けの使用ガイドラインを追加する。
  • UXPin のスペックモードを使って、デベロッパーが UXPin 内でコードを検査したり、コンポーネントのプロップを表示したり、ドキュメントにアクセスしたりできるようにする。

ステップ５：AI 駆動デザインシステムの維持と拡張を行う

• AI アシストでコンポーネントをアップデートする

• • デザインシステムの進化に合わせて、AI Component Creator を使ってコンポーネントを更新したり、新しいコンポーネントを生成したりする。AI で、デザインシステムのルールや標準を遵守することで、一貫性を維持することができる。

• AI を使ってデザインシステムの分析および最適化をする

• • UXPin の AI Component Creator のような AI ツールを導入して、デザインシステムの冗長性、矛盾、ギャップを分析する。
  • そのインサイトを使って、デザインシステムの改良や最適化を行うことで、拡張性と適切性を確保する。

• ステークホルダーとの協力と反復を行う

• • AI 駆動型のデザインシステムをステークホルダーと共有し、フィードバックと連携を行う。
  • UXPin のコラボレーション機能を使って、コメントの受け取ったり、デザインシステムのコンポーネントをサッと反復する。

AI駆動型のデザインシステムを試してみませんか

AIはデザイナーを補完し、イノベーションの機会を広げることで、予測的なデザインや個別化されたユーザー体験、効率的なデザインシステム管理を可能にします。デザイナーがAIを活用すれば、次世代の直感的で拡張性のあるデジタル体験を創造できるでしょう。

UXPinでAI駆動型のデザインシステムを構築すると、プロセスが高速化し、開発に対応した一貫性のあるシステムが実現され、繰り返し作業の自動化やデザインと開発の連携が向上します。

AI を活用した独自のデザインシステムを構築してみませんか？UXPinの無料相談およびトライアルはこちらから。

The post AIデザインシステム – 実現可能か？ appeared first on Studio by UXPin.

npmは、開発者がアプリケーションで利用するライブラリやコードのインストール、共有、管理をするためのJavaScriptパッケージマネージャーです。

これにより、ユーティリティ関数から複雑なUIコンポーネントまで、さまざまなパッケージを扱うことができます。

npmはUXPin Mergeを通じてデザインと開発のコラボレーションを促進します。

開発者はReactコンポーネントをパッケージ化してデザイナーに提供し、デザイナーはそれを簡単にデザインに統合することができます。

このプロセスによって、一貫性のある効率的なワークフローが実現し、デザインシステムと最終製品の整合性が保証されます。UXPinの無料相談およびトライアルはこちらから。

NPM とは

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

npm には 以下の２つの特徴があります：

• オープンソース プロジェクトを公開するためのレポジトリ
• 簡易版：デジタル ストレージおよび検索機能
• リポジトリと対話するための CLI（コマンドライン インターフェース）
• 簡易版：ストレージ機能と通信するためのツール

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

npm パッケージとは何かを説明する前に、パッケージマネージャーの考えを理解することが非常に重要です。パッケージマネージャーはデベロッパーのためのツールキットだと考えてください。

パッケージマネージャーの役割と利便性

例えば、決済のためにStripeを使うアプリケーションを作るとします。

パッケージマネージャは、製品がStripeと通信して支払いを処理するのに必要なコードをすべてインストールします。

パッケージの多様性と利用可能なリソース

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

さまざまなタイプの検索機能、API、支払い、認証ツール、地図、アイコン、ホスティングなど、アプリケーションを開発するのに考えられるあらゆるものに対して、何百万ものパッケージがあります。

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

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

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

npmでは、CLIを通じてパッケージレジストリとやりとりでき、エンジニアは npm install コマンドに続けてパッケージ名を入力することで特定のパッケージをインストールできます。

npm レジストリ

npmのWebサイトでは、エンジニアがパッケージを検索し学ぶことができますが、これは単なるレジストリであり、パッケージはホストされていません。

そのため、エンジニアはGitHub、Packagecloud、AWS CodeArtifact などのプラットフォームを使用してパッケージをホストし、配布しています。

たとえば、NPM上の UXPin Merge CLI を見ると、レポジトリと関連リンクとして GitHub が表示されており、その上には、UXPin Merge CLI とその依存関係をインストールするコマンドである npm i @uxpin/merge-cli があります。

ちなみに、npm の後の「i」は「install」の略語なので、npm install @uxpin/merge-cli と入力しても同じ結果になります。

依存関係（Dependency）とは

パッケージは、エンジニアが「依存関係」と呼ぶ他のパッケージで構成されています。

わかりにくいかもしれませんが、この依存関係とは、プロジェクト内でさまざまなタスクを実行するコードのパッケージです。

たとえば、UXPin Merge CLI は Typescript を使うため、依存関係として typescript のパッケージが必要です。

そして Typescript は UXPin Merge CLI に必要な４１の依存関係のうちの１つに過ぎません。

開発依存関係（DevDependencies）とは

UXPin Merge CLI の依存関係を見ると、４１の依存関係と４１の開発依存関係（Dev Dependencies）があります。

依存関係

「依存関係」は、アプリケーションが本番環境で動作するために必要なライブラリやパッケージです。

実行時に必ずインストールされ、アプリの基本機能を支えます。

開発依存関係

「開発依存関係」は、アプリケーションの開発やテスト時にのみ必要なツールです。

本番環境には含まれず、主にコードの品質やビルド、テストを支援します。

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

package.json ファイルとは

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

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

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

package-lock.json とは

package-lock.json は、プロジェクトの構築に使わ れているパッケージの正確なバージョンを指定します。

このファイルは、プロジェクトがインストールされたときに、最新のリリースではなく、開発中に使われたバージョンを参照するように、依存関係をロックします。

エンジニアは定期的にパッケージを更新し、多くの場合はパッケージの動作方法を変更します。

なので、依存関係をロックすることで、プロジェクトが意図したとおりに動作するようになるのです。

npm の使用法

npm init

プロジェクトの package.json ファイルを作成します。

アプリケーションをゼロから構築する場合、npm init はプロジェクトの重要な情報を含めるのに使う最初のコマンドの一つになります。

また、NPM は、パッケージがインストールされたり削除されるたびに、package.json ファイルを自動更新します。

npm install

プロジェクトの依存関係を全て package.json ファイルにインストールします。

npm install <package-name>

NPM レジストリから特定のパッケージをインストールして node_modules フォルダに保存します。

例えば、npm install @uxpin/merge-cli は Merge CLI をインストールします。

npm install <package-name> –save

NPM パッケージをインストールして package.json ファイルの依存関係に追加します。

npm install <package-name> -save-dev

NPM パッケージをインストールして開発依存関係に追加します。

npm uninstall <package-name>

プロジェクトから特定のパッケージをアンインストールします。

npm doctor

npm インストールの診断を実行して、パッケージの管理に必要なものがすべて揃っているかチェックします。

npm update <package-name>

特定のパッケージを最新バージョンに更新します。

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

デザイナーとして npm を理解する

npm は、デザインツールのプラグインやアプリ拡張機能に匹敵するツールキットです。

パッケージがどのように作成されるかを詳しく知る必要はありませんが、１つ２つ知っておくといいかもしれません。

npm パッケージとコンポーネントライブラリ

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

npm パッケージとしてディストリビューションされているコンポーネントライブラリを見つけるにはどうすればいいのでしょうか。

UXPin の公開デザインシステムライブラリである Adele から、UXPin に取り込めるコンポーネントライブラリを探すとします。

Shopify の Polaris を選び、それが npm 経由でディストリビューションされていることがわかります。

それで、NPM サイトにアクセスして Shopify の Polaris を探します。

UXPin と Merge テクノロジーで、NPM パッケージ経由でコンポーネントライブラリから UI 要素をインポートできます。

そして、その要素を使って、完全に機能するプロトタイプを作成することができます。

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

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

npm 統合でできること

npm は一般的にデベロッパーが使うツールですが、シームレスなドラッグ＆ドロップによる UI 構築のために React のコンポーネントを UXPin に取り込むなど、強力なデザインワークフローを実現する上で重要な役割を果たしています。

UXPin Merge のようなツールを使える技術的なデザイナーにとって、以下のような理由から npm が重要になります：

React コンポーネントへのアクセス

デザインシステムが React を使って構築されている場合、npm を使ってそのコンポーネントをパッケージ化し、UXPin Merge のような他のアプリケーションやツールで使えるようにすることができます。

また、npm パッケージとして利用可能な React コンポーネントは、UXPin に直接インポートすることができ、それでデザイナーはコードを記述することなく、実際のコードコンポーネントをデザインにドラッグ＆ドロップすることができます。

アップデートの管理が簡単

npm でバージョン管理をシンプルになります。

デベロッパーがボタンコンポーネントの新バージョンなどパッケージを更新すると、npm は自動的に UXPin Merge で更新を管理することから、デザイナーは常に開発チームの最新コンポーネントを使えるようになります。

これにより、手動で更新することなく、デザインと開発の一貫性が保たれます。

デベロッパーとのシームレスな連携

npm で、技術的なデザイナーとデベロッパーが同じソースから作業できるようになります。

デベロッパーは npm を使って作成したコンポーネントを公開し、デザイナーは Merge を使ってそのコンポーネントを簡単に UXPin にインポートできます。

これにより、デザイナーがプロトタイプに使うコンポーネントと、デベロッパーが最終製品に実装するコンポーネントが完全に同じであることが保証されます。

UXPin Merge で連携の改善

Merge では、デザイナーとエンジニアが同じコンポーネントライブラリを使って作業できるので、デザインと開発の連携が強化されます。

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

UI要素をドラッグ＆ドロップでインターフェースを構築して、会社のデザインシステムや MUIなどのコンポーネントライブラリを同期してみませんか。無料相談およびトライアルはこちらから。

The post npmと言うのは？把握しよう！ appeared first on Studio by UXPin.

ステークホルダーや組織のサポートは、デザインシステム（DS）の継続的な投資と将来的な成功に不可欠です。DSチームは、従業員がデザインシステムを使用し、その投資が利益を生むことを証明しなければなりません。

2022年1月のウェビナー「デザインシステムの保護」で、カローラ・カッサーロ氏は、DSチームが直面する課題として、「私たちは皆、人々の生活を変える製品デザインに取り組んでいますが、その影響を伝えるための適切なフレームワークや語彙が不足している」と述べています。

多くのデザイナーは、デザインシステムの進化や拡張のためのリソースを説明するのに苦労していますが、DSの影響を追跡し、成功と改善点を特定することで、ステークホルダーの支援を得やすくなります。

デザインシステムは通常デザインチームによる取り組みですが、組織全体やフロントエンドの一貫性を確保するためにデベロッパーにも役立ちます。UXPin Mergeのようなツールを使えば、デザインと開発の両方でチームのインタラクティブなUIコンポーネントを簡単に使用できます。

Git、Storybook、または NPM コンポーネントを UXPin にインポートし、デベロッパーにサッと渡せるインタラクティブなプロトタイプを作成しませんか。無料相談およびトライアルはこちらから。  

非デザイナーからのサポートが必要な理由

デザインシステム（DS）の維持と拡張には時間とリソースが必要であり、DSチームはその価値を証明してリソースを確保しなければなりません。

デザインシステムの価値を示すには、チームメンバーがそのシステムを採用することが重要です。そのため、DSチームは組織全体のチームと関わり、使用を促し、改善のためのフィードバックを集める必要があります。

人々がデザインシステムに貢献することで所有感が生まれ、より広く活用されるようになり、それがさらなるリソースとサポートを得るための根拠となります。

デザインシステムの採用を促す方法

多くの組織では、社内ワークショップやトレーニングセッションを通じて、デザインシステムの目的や使用方法、ベストプラクティスを紹介します。全部署から代表者を招き、デザインや開発以外のチームともフィードバックやアイデアを共有する機会を設け、貢献が所有感と採用につながることを意識しましょう。

フィードバックを得るためにワークショップだけでなく、Slack、Asana、Jiraなどのコミュニケーションチャンネルも活用しましょう。デザインシステムがチームに採用され始めたら、組織全体への影響を測定するタイミングです。

デザインシステムのサポートを得る： 注目すべき３分野

デザインシステムチームは、製品や組織への影響を判断するのに、以下の３分野に注目しないといけません：  

• チーム：デザインシステムがどのようにワークフローを改善するのか
• 製品：デザインシステムが製品やビジネス価値にどのような影響を与えるのか
• エンドユーザー：デザインシステムはユーザビリティにどのような影響を与えるか。

  では、その３分野を詳しく見てみましょう。  

チーム

  デザインシステムがチームに与える影響を評価するのに使える主な指標には以下の３が挙げられます：  

• デザインシステムの採用
• リソースの節約
• 市場投入までの時間

デザインシステムの採用状況を評価するには、レポジトリ内の要素の使用率を確認する方法があります。UK Gov DesignがGOVDESIGN 2020で示したこの戦略では、データを定期的に集めて普及状況を追跡し、ワークショップの効果も測定できます。

導入前にタスクの時間やパフォーマンス指標をベースラインとして取得し、それを基にデザインシステムの影響を評価することが重要です。PayPalでは、画像ベースのツールとUXPin Mergeを比較した結果、市場投入までの時間が大幅に短縮されました。これにより、デザインシステムへの投資が少ないリソースで競争優位性を生むことをステークホルダーに示すことができます。

製品

  次に、製品性能におけるデザインシステムの勝敗を見極めたいところです。ここでも、以下の重要な３指標に注目してみましょう：  

• コンポーネントカバレッジ
• 安定性
• ブランド価値との整合性

DSチームは、どのコンポーネントが製品で使われているかをテストし、デザインシステムのカバレッジや製品間の関連性を評価できます。また、製品の安定性やブランド全体への影響を示すため、実装前後の製品欠陥数と重大度を測定し、エラー削減を実証できます。

ブランド親和性の測定は難しいですが、カローラは『Defending Your Design System』で、eBayがデザインシステム導入前後のページデザインを顧客に評価させ、デザインシステムページがより高いブランド親和性スコアを得たことを紹介しました。

エンドユーザー

 あとは、これが一番重要なことですが、デザインシステムは顧客や UX（ユーザーエクスペリエンス）にどのような影響を与えているのでしょうか？デザインシステムに関連するエンドユーザー測定基準には、以下の３つが挙げられます：  

• パフォーマンス
• ユーザビリティ
• 顧客満足度

読み込み時間は製品パフォーマンスの重要な指標で、デザインシステム（DS）の実装により最適化されたコンポーネントで読み込み時間が短縮されます。

DSチームは、タイムオンタスクやコンバージョン率などを使い、ユーザビリティやアクセシビリティへの影響をテストできます。IBMは、DS導入後にユーザーのタスク完了率が3倍に伸びたことを確認しています。

また、アンケートや製品レビュー、インタビューなどのフィードバックを基に、DS導入前後の傾向を追跡し、ユーザビリティの改善や顧客満足度の向上を測ることができます。

デザインシステムをステークホルダーに売り込む

ここでは、デザインシステムを普及させるためのステップを３つ見ていきましょう：  

• デザインシステムの効果検証のためのデータ収集
• 勝因を特定および、説得力のあるストーリーの作成
• 企業が得られるものの予測

ステップ1 – データ収集

  上記の「注目すべき３分野」で説明したようにデータを集めます。何から始めたらいいかわからない場合は、自身の製品や会社に関連する、うまくいったデザインシステムのリソースやユースケースを探してみましょう。  

また、ガイダンスや方向性を示すために、以下のブログからリソースをチェックしてみてください：  

• On Design Systems: An Interview with Dan Mall of Superfriendly（デザインシステムについて：Superfriendlyのダン・モール氏に聞く）

  データの収集と分析には時間と手間がかかりますが、デザインシステムの成功のストーリーを構築するには欠かせない作業です。  

ステップ2 – 勝機を見極め、説得力のあるストーリーを作る

  無料ダウンロードの『Evangelizing a Design System』では、ステークホルダーや経営幹部にプレゼンするためのスライドテンプレートが４０以上紹介されています。  

そこには、自社のケースを強化して将来的な展望を示すべく、Dropbox、IBM、LinkedIn、Atlassian などでの成功事例から得た実際のデータが盛り込まれています。  

プレゼンテーションでは、成功した点を強調し、客観的なテストをどのように使って最終結果に到達したかをストーリーテリングで説明しましょう。  

ステップ3 – 企業が得られるものを予測する

  投資を勝ち取るには、デザインシステムの拡張にリソースを割くことで、企業が何を得ることができるのか、つまり ROI（投資収益率）を示さないといけません。将来予測を、他の成功したデザインシステムのケーススタディと組み合わせて、投資対効果の可能性を示しましょう。  

適切なデザインシステムツールへの投資

  適切なツールに投資することで、先の「注目すべき３分野」で説明した多くのメトリクスを改善することができます。UXPin Merge は、デザイナーが完全に機能するコードコンポーネントを使ってプロトタイプを構築できるように、レポジトリにホストされているデザインシステムを UXPin のエディタに同期できる、コードベースのデザイン ツールです。

この「信頼できる唯一の情報源（Single source of truth）」は、PayPal の場合のように、非デザイナーであっても部門間の採用と連携が上がります。また、PayPal は、市場投入までの大幅な時間の短縮と、以前の画像ベースのデザインツールよりも Merge のプロトタイプと対話できるようになったステークホルダーからのより質の高いフィードバックが得られることに気づきました。

「信頼できる唯一の情報源（Single source of truth）」により、企業はデザインと開発の一貫性を高め、デザインのハンドオフがスムーズになります。デザイナーは生産可能なコンポーネントでプロトタイプを作成し、エンジニアはそのまま開発を開始できます。

さらに、DSチームがデザインシステムに変更を加えると、UXPinで自動的に更新され、チームメンバーに最新リリースが通知されます。

UXPin Mergeのコードベースデザインで、デザインシステムとワークフローを次のレベルに引き上げましょう。無料相談およびトライアルはこちらから。  

The post ノンデザイナーがデザインシステムの利用とサポートをする方法 appeared first on Studio by UXPin.

２０１６年、筆者たちは徹底的なユーザーリサーチキャンペーンを実施し、デザインとエンジニアリングのリーダーたちとの４０回以上のインタビューと、３,１００人以上のデザイナーとデベロッパーを対象とした調査の結果、従来のデザインツールでは現代の製品開発に対応できないという結論に達しました。 ワークフローはあまりにも断片化され、分断され、焦点が定まっていません。デザインシステムツールは、デザインと開発のための完全なハブでないといけないのに。 そこで、UXPin のデザインシステムの最初のリリースでは、調査結果を以下の ３つのシンプルなルールでまとめました。：

• 静的な文書ではなく、動的な環境
• 参照ドキュメントではなく、実行可能なシステム
• 単なるデザインパターンのライブラリではなく、デザインと開発のつながりを促す。

この原則を念頭に置き、２０１７年６月１３日に最初のデザインシステムプラットフォームがリリースされました。

UXPin のデザインシステムライブラリは、デザインシステムの様々な成熟段階に対応しており、最終段階では、デザインと開発を同期して、デザイナーとエンジニアが１つのコンポーネント ライブラリ（信頼できる唯一の情報源 ‐ Single source of truth）を共有する完全に統合されたシステムを作成します。 UXPin Merge では、デザインシステムのレポジトリからコードコンポーネントをビジュアルデザイン要素としてインポートできます。そしてデザイナーはそのコンポーネントを使って、簡単なドラッグ＆ドロップのワークフローでプロトタイプを作成できます。Merge コンポーネントは UXPin のキャンバス上でレポジトリとまったく同じようにレンダリングされるため、デザイナーは最終製品と見分けがつかないほど完全に機能するプロトタイプを作成できるのです。UXPin Merge へのアクセスリクエストはこちら。

UXPin でデザインシステムを作成する方法

まず、UXPin ダッシュボードのトップバーにある Design System（デザインシステム）タブを開きます。ここで、新しいデザインシステムの作成や、既存のデザインシステムの表示ができます。まずは［Create Design System（デザインシステムの作成）］ボタンをクリックしてみましょう。 デザインシステムの構築には以下の２つの方法があります：

• 既存のライブラリを使う：UXPin には、基礎として使える事前構築済みのライブラリがある。
• ゼロから始める：この方法では、［Create from Scratch（ゼロから作成）］をクリックして白紙の状態から始める。

注：ここでの例はすべて UXPin 内で作成されていますが、UXPin のデザインシステムは Sketch と Figma のインポートにも対応しています。

スタイルのライブラリを作成する

しっかりとしたデザインシステムは、最も一般的なデザイン要素であるテキストスタイルとカラーパレットから始まります。UXPin を使うと、デザインプロジェクトからこの要素を直接取得して共有デザインシステムライブラリに保存でき、これは、製品のデザインシステム用の実用的なツールキットとして機能します。

カラーおよびテキストスタイルの追加

カラーやテキストスタイルの追加には、Sketch または UXPin で関連するレイヤーを選択します。UXPin が自動的にスタイルを取得してシステムに追加し、そのスタイルは UXPin または Sketch のライブラリと同期され、システムはダイナミックで最新の状態に保たれます。

• タイポグラフィ：［Editor（エディタ）］から直接テキストスタイルを追加できることから、すべてのデザインで一貫したタイポグラフィシステムが維持されます。
• カラー：HEX コードを入力して「Enter」キーを押すか、Web サイトの URL から色を取り入れるか、CSS ファイルに直接リンクして色を追加できます。これにより、カラーパレットがすべて一元化されて簡単に更新できます。

アセットライブラリの作成

次に、グラフィックデザインアセットを保存し、ロゴや承認済みストックフォト、アイコンライブラリなどのカラーやテキストスタイルと一緒に共有します。このアセットはデザインシステムライブラリに保存できることから、チーム全員が一元化されたデザインツールキットに簡単にアクセスできるようになります。 アセット：SVG などの様々な形式の画像やアイコンをアップロードできます。これにより、さまざまなプロジェクトで再利用できるデザインアセットのライブラリをすべて簡単に管理できるようになります。

実用的なパターンライブラリを作る

デザインパターンは、デザインシステムに非常に重要なコンポーネントおよび要素であり、UXPin では、Sketch からインポートしたものも含め、パターンの作成、保存、共有ができます。また、インタラクティブ機能やアニメーションを追加できるので、デザイナーは新しいプロジェクトごとにゼロから始めることなく、パターンを再利用できます。 UI パターン： UXPin でデザインされてプロトタイプ化された再利用可能なコンポーネントや要素であり、それをデザインシステムに追加して一貫性が確保されることで、デザインプロセスの効率化が実現します。

システムを生成して同期を保つ

共有資産のライブラリを持つのは素晴らしい第一歩ですが、ソフトウェア開発のスケーリングの問題を解決するには十分ではありません。 大抵のソリューションはここで止まってしまい、開発には向かいません。そこで筆者たちは、このまま突き進むことにしました。 UXPin のデザインシステムでは、ワンクリックでどんなカラー、テキストスタイル、アセット、パターンも生きたシステムになります。新しいパターン、テキストスタイル、アセット、カラーを追加すると、UXPin は自動的にデザインシステムを更新してドキュメントを生成します。そしてその変更は、チームメンバーやステークホルダー全員がすぐに利用できます。

デベロッパー向けドキュメントの追加

システムを構築したら、パターンやコンポーネントのコードスニペットなどのドキュメントを追加できます。それでデベロッパーはプロトタイプやモックアップとともにこのドキュメントを閲覧でき、スタイルガイド、アセット、指示が１つのプラットフォームで管理されることで、デザインのハンドオフがより速くスムーズになります。

ドキュメントを実用的にする

デザインシステムのドキュメントは、単なる参考文書でなく、行動が起きる場所、つまりデザインプロジェクトの中身でないといけません。 UXPin だと、デザインシステムのドキュメントはプロジェクトに追従します。 例えば新しいリリースが提供されると、UXPin は製品のデザインシステムからマークアップ、インポート、Javascript コンポーネントの名前などのドキュメントが自動生成されます。

UXPin Merge によるデザインシステムの拡張

UXPin のデザインシステムライブラリで、デザインシステムの成熟度は第１段階から第３段階まで上がります。そして最終段階は、デザインと開発を同期させ、デザイナーとエンジニアが１つのコンポーネントライブラリを共有する、完全に統合されたデザインシステム（信頼できる唯一の情報源 ‐ Single source of truth）の構築になります。 そこで UXPin Merge の出番です。 Merge は、デザイナーが簡単なドラッグ＆ドロップのワークフローを使ってプロトタイプを作成するのに使える視覚的デザイン要素として、コードコンポーネントをデザインシステムのレポジトリからインポートします。 Merge のコンポーネントは、UXPin のキャンバス上でレポジトリとまったく同じようにレンダリングされるため、デザイナーはコードと区別できないような完全に機能するプロトタイプを作成できます。 この高度な忠実度とコードのような機能性により、デザインチームは、ユーザビリティテストや、最終製品と同じようにプロトタイプと対話し関わることができるステークホルダーから、有意義で実用的なフィードバックを得られます。

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

Merge では、デザインシステムの管理と配布が単一のレポジトリから一元化されることで、製品開発プロセスが大幅に強化されます。なので、もう UI キットやコンポーネントライブラリの管理は必要ありません。 レポジトリへの変更は自動的に UXPin に同期され、チームにその更新が通知されます。また、UXPin のバージョン管理により、デザイナーは更新するプロジェクトを選択でき、必要に応じて以前のデザインシステムのリリースに戻すこともできます。 そして チームは、Merge デザインシステムドキュメンテーション または Storybook の Docs（Merge の Storybook 統合用）を使ってチームメンバー全員のドキュメントを管理できることから、最も時間のかかるガバナンスとメンテナンスの手順がシンプルになります。

パターンによるスケーリングと効率化

UXPin のパターンにより、デザインチームは Merge コンポーネントを組み合わせて新しいパターンやテンプレートを作成することができます。また、デザインシステムの要素を使ったり、他のデザインシステムのコンポーネントを組み合わせることもできます。 UXPin のパターンは、コンポーネント、テンプレート、またはスクリーンの複数のバージョンや状態を保存するのにも便利で、それでデザイナーは、テスト中やステークホルダーとのフィードバックセッション中に、さまざまなバリエーションを入れ替えて試すことができます。このような 「その場での」変更により、デザイナーはより速やかに反復し、貴重なテスト時間を最大化することができます。

まとめ

まとめると、UXPin でデザインシステムをセットアップするには、以下が必要です：

• カラー、タイポグラフィ、アセット、UI パターンなどのデザイン要素の作成と整理。
• 説明、コード、リンクで各要素を文書化。
• スペックモードを使って要素を検査し、プロジェクト全体で一貫した実装を確認。
• UXPin Merge を使ってデザインと開発をスケーリングおよび同期し、信頼できる唯一の情報源（Single source of truth）を維持。

このガイドに従うことで、デザインから開発までチームをサポートする総合的なデザインシステムを作成、管理、拡張できるようになります。Merge のページをご覧いただき、UXPin がデザインのワークフローをどのように変革できるかをぜひご確認ください！UXPin Merge へのアクセスリクエストはこちら。

The post UXPin でデザインシステムを構築 – ３分でわかるガイド appeared first on Studio by UXPin.

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

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

デザインシステムとは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１．Ant Design

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

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

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

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

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

２．React-Bootstrap

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

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

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

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

３．Fluent UI

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

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

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

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

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

４．Carbon Design System

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

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

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

５．Tailwind CSS

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

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

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

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

６．Semantic UI

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

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

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

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

７．Foundation

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

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

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

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

８．Chakra UI

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

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

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

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

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

９．Bulma

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

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

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

１０．Styled Components

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

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

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

１１．PrimeReact

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

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

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

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

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

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

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

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

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

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

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

ReactJS とは

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

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

ReactJS の例

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

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

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

React Nativeとは

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

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

Facebookが React Native を作った理由

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

React Nativeの例

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

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

 React NativeとReactJS の違い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ReactとUXPin Mergeでデザインする

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

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

Reactのプロップ

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

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

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

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

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

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

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

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

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

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

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

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

コードを使ったデザイン

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

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

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

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

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

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

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

デザイントークンとは

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

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

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

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

デザイントークンの種類

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

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

デザイントークンの起源

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

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

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

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

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

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

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

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

デザイントークン３例

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

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

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

例２：フォントサイズ

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

例３：行の高さ

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

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

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

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

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

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

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

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

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

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

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

２．UI の一貫性の維持

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デザイントークン方式

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

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

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

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

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

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

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

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

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

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

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

👉 ご参加はこちらから

ウェビナーの内容

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

詳細：

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

👉 ご参加はこちらから

登壇者情報

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

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

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

👉 ご参加はこちらから

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

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

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

主なポイント：

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

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

Reactデザインシステム とは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• cta-background-primary

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

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

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

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

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

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

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

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

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

コンポーネントの構成

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

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

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

デザイントークンの管理

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

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

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

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

ドキュメンテーション

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

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

テスト

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

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

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

デザインツール

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

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

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

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

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

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

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

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

主なポイント：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Figma の「スタイル」とは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

主なポイント：

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

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

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

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

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

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

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

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

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

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

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

DSE の仕事内容

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

DSE に必要なスキル

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

ハードスキル

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

ソフトスキル

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

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

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

インセプション段階

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

デザイン段階

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

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

開発段階

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

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

ローンチ後

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

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

DSEになるには

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

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

DSE としての成長の見込み

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

DSE に必要なもの

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

バージョン管理システム

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

デザインツール

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１．UXPin

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

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

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

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

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

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

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

２．Zeroheight

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

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

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

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

３．Supernova

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

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

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

４．Storybook

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

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

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

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

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

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

５．Pattern Lab

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

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

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

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

６．Adobe XD

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

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

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

７．Design System Manager – InVision

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

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

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

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

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

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

バージョン管理

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

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

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

スタイルガイド

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

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

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

アセットストレージ

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

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

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

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

フィードバック

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１．社内政治

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

６．変化に対する抵抗

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１．使えるものを使う

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

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

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

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

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

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

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

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

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

６．UX および開発テスト

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

７．最終確認

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

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

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

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

１０．品質保証

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

成熟度レベル３

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

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

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

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

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

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

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

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

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

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

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

Merge統合

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

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

ギャップの解消

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

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

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

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

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

Mergeの機能を理解する

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

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

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

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

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

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

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

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

コンポーネント構成

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

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

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

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

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

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

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

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

アクセシビリティと設定

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

データコンポーネント

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

コンポーネント間の通信

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

バージョンコントロール

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

レスポンシブデザイン

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

適応性と拡張性

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

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

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

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

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

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

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

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

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

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

主なポイント：

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

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

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

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

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

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

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

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

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

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

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

コードベース革命

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

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

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

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

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

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

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

それは何？：

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

メリット：

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

デメリット（制限）：

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

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

それは何？：

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

メリット：

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

デメリット（制限）：

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

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

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

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

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

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

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

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

dotSourceのユースケース

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

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

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

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

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

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

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

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

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

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

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

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

静的なプロトタイプ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最初に

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メリット

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

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

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

デメリット

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

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

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

２．アトミックデザイン

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

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

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

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

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

原子

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

分子

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

有機体

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

テンプレート

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

ページ

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

メリット

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

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

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

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

デメリット

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

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

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

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

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

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

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

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

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

メリット

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

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

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

デメリット

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

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

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

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

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

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

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

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

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

• 現在使っているデザインシステムはどのような成熟段階にあるのか

効果的なデザインシステムは、成長と変化に伴う課題に適応することができるダイナミックな存在です。

デザインシステムの本来の価値は、無駄な労力を減らし、連携を促進する能力にあるのです。

UXPin がコードベースのデザインシステムのを好む理由

デザインシステムでコード化されたコンポーネントを使うことで、デザインチームとデベロッパーチームの間での共有が実現します。

それによって、デザインチームと開発チームは、「信頼できる唯一の情報源（Single source of truth）」に依存することができ、より効果的な連携が実現します。

また、組織内の各チームは、デザインやプロトタイプのプロジェクトをすべて同時に管理することができ、それによってより高度な一貫性を保つことができます。

その結果、デベロッパーはデザインパターンのデベロッパー向け言語への翻訳に集中できるようになります。

UXPin Mergeは、コードベースのデザインシステム構造を使って、「信頼できる唯一の情報源」でプロトタイプをデザインします。

これにより、デザイナーはデベロッパーのワークフローと整合性のあるデジタル製品のプロトタイプを作成することができます。

詳しくは、UXPinの Code-to-Designソリューションをぜひご覧ください。

The post デザインシステム 構造 トップ３ appeared first on Studio by UXPin.

デザインシステムは、製品のデザインプロセスを効率化し、チーム間の一貫性と拡張性を確保します。

Figma と UXPin には、それぞれさまざまなニーズに合わせた独自の機能を備えた、強固なソリューションがあります。

そこで本記事では、Figmaのチームライブラリやとその利点、そして潜在的な欠点についてお話します。

また、UXPinのデザインシステムとMergeの技術を使った、チームライブラリの代替案もご紹介します。

主なポイント：

• Figmaのチームライブラリで、デザインシステムの作成と共有がしやすくなり、それによって一貫性が保証される。

• Figmaのデザインシステムは先進的ではあるが、デザイナーとデベロッパー間のギャップを埋めるという点では課題がある。

• UXPin Mergeは、一元管理、究極の一貫性、複数のフロントエンド開発をサポートし、デザインと開発プロセスを統一するという点において、Figmaのプロトタイプ ・ チームライブラリを上回る。

UXPin の Merge技術で、組織・プロトタイプ全体 で「信頼できる唯一の情報源（Single source of truth）」を作成し、製品開発プロセスをシンプルにしませんか。詳しくはUXPin Merge をぜひご覧ください。

Figma でデザインシステムを作成できるのか

チームライブラリ機能により、デザイナーは Figma でデザインシステムを作成することができます。

さまざまなファイルやプロジェクト間で、UIコンポーネントやスタイルを公開し、共有することができます。

デザインの要素が更新されると、その要素が使われている各デザインファイルに一貫性と最新性が保たれ、それによって組織全体は最新リリースが同期された状態が保たれます。

アトミックデザインとは ‐ Figma のデザインシステムに適用するために

Figma は、ブラッド・フロスト氏の「アトミックデザインの原則」に基づき、チームライブラリを設計しました。

アトミックデザインは、UI （ユーザーインターフェース）を以下のように分解します：

• 原子： カラースタイル、ラベル、テキストスタイル、スペーシングなど、Web ページの基本的な構成要素。

• 分子： 例えばボタン、フォーム入力、チェックボックスなど、色のように原子をいくつか組み合わせ、ラベルと形をつけると分子になる。

• 有機体：複数の分子を結合させると有機体になる。サイドバーやヘッダーなど、より複雑な UI 要素になることもある。

• テンプレート： さまざまな生物を組み合わせると、ページ全体のレイアウトを形成するテンプレートができあがる。

Figma のアトミックユニット：コンポーネントとスタイル

コンポーネントとスタイルは、Figma のデザインシステムの原子単位です：

• コンポーネント： ボタンやアイコンのような再利用可能なデザイン要素

• スタイル： 色やタイポグラフィなどのデザイン仕様

この要素は、デザインシステムのチームが作成したオリジナルのファイルに存在しています。

さまざまなファイル間でアクセスできるようにするには、ファイルの所有者がチームライブラリに公開するといいでしょう。

Figma のチームライブラリにアクセスするには？

コンポーネントとスタイルを公開すると、Figma のチームライブラリで見つけることができます：

• デザインファイルを作成するか、開く

• Assets のタブから［Team Library（チームライブラリ）］をクリックして開く

• 目的のチームライブラリを検索または参照する

• ライブラリを有効にして、そのコンポーネントをアセットパネルで利用できるようにする

チームライブラリを有効にすると、デザイナーはそのコンポーネントのインスタンスをデザインファイルに簡単にドラッグ＆ドロップでき、それによってデザインの一貫性が確保されます。

Figma のデザインシステムの主な特徴

• スタイル： コンポーネントの色、文字、エフェクト、レイアウトグリッドを確定する

• 変数（ベータ）： 色値、数値、文字などの再利用可能な値を保存して、コンポーネントを半インタラクティブにしたり、明暗モードを切り替えたりできる

• バリアント： コンポーネントとパターンのバリアントとステートを作成する

• デザイントークン： デザインシステムチームが複数のデザインファイルで共有できる動的なスタイルで、変更と更新を一元管理する

• Storybook：デザイナーは、Figma のデザインをStorybookコンポーネントに埋め込むことができ、関連する Figma コンポーネントとともにストーリーをインポートして参照することができる

• ライブラリー分析： デザインシステムのチームがパターンやコンポーネントの使用状況や採用を監視できるようにする

• バージョン履歴： Figma ファイルのバージョン履歴を表示し、古いバージョンを復元する

Figma のチームライブラリを使うデメリット

Figma のデザインシステムは、デザインをシンプルにするために進化してきましたが、デザイナーとエンジニア間のギャップを埋めることはできません。

デザインシステムチームは、Figma 用とコード用の２つのライブラリを管理が必要になります。

UXPinは、２０２３年に Whitespaceと共同出版し、そこでデザインシステムの課題とその克服方法について、世界的に有名な１９社にインタビューをしたレポートを発表しました。

インタビューを行った企業では、Figma や Sketch のような画像ベースのツール を使用して いました。

筆者たちは、各組織にとっての主要な目標が「信頼できる唯一の情報源（Single source of truth）」であることがわかりました。

企業はこの目標を達成するためにプラグインやカスタムソリューションに依存し、コストを増加させ、フローを複雑にしているのです。

以下に、デザインシステムに画像ベースのツールが使われる場合での、主な問題点を挙げてみましょう：

• デザイナーと開発者は別々のライブラリ (Figma用のUIキットとデベロッパー用のコードコンポーネント) を使用するため、組織が「信頼できる唯一の情報源（Single source of truth）」を得ることはできない。

• 変更の更新には、デザインシステムレポジトリ、Figma、プロトタイピングツール、関連ドキュメントなど、複数の場所の変更が必要。

• 単一のUIライブラリを一元管理しないと、さまざまなバージョンを使っているチーム間でエラーが発生する。

• ハンドオフでは、インタラクションを説明するための長いドキュメントが必要であり、２０２３年のリリースでも、コードに匹敵するインタラクティブ性を実現できない。

• デザイナーは、プロトタイプやテストのために追加のツールやプラグインを使わなければならず、それによってコストや運用の負担、ミスの可能性が増大する。

UXPinのデザインシステムと Figmaのチームライブラリの比較

UXPinは、デザインシステムの成熟度に応じて２つのソリューションを提供しています：

• デザインシステム： コンポーネント、アセット、タイポグラフィ、ドキュメントを含むデザインシステムを作成する。

• Merge技術： レポジトリから UXPin にコードコンポーネントライブラリをインポートして、プロトタイピングとテストを行う。

UXPin のデザインシステム

UXPinのデザインシステムは、Figmaのチームライブラリと同じように機能します。

組織は、デザインシステムを作成し、チームメンバーと共有することができ、デザインシステムチームは、権限のない変更を防ぎ、システムの完全性を確保するために、権限 を設定することができます。

UXPin のビルトインデザインライブラリの活用

組織は、iOS、マテリアルデザイン、Bootstrap、Foundation など、UXPinのビルトインデザインライブラリのいずれかを基盤として使うことで、デザインシステムをサッと構築して拡張することができます。

インタラクティブ性の向上

FigmaとSketchは画像ベースのデザインツールで、デザイナーは最小限の機能しか持たない静的なプロトタイプしか作成できません。

一方、UXPinはコードで動き、ベクターグラフィックスを生成する代わりに、キャンバスは HTML、CSS、Javascript を裏でレンダリングします。

つまり、UXPinのようなコードベースのプラットフォームを使うことは、デザイナーが、完全に機能する入力要素、状態管理、複雑な UI パターンなど、最終製品のコンポーネントを忠実に模倣したインタラクティブ性を実現できるということです。

以下に、UXPinが他のデザインツールと一線を画す４つの特徴を挙げましょう：

• ステート（状態）：デザイナーは、１つのUI要素に対して複数のステートを設定し、ドロップ ダウンメニュー、タブメニュー、ナビゲーショナルドロワー などの複雑なインタラクティブコンポーネントをデザインできる。

• バリアブル：ユーザーの入力からデータを取得し、アプリバーに名前やプロフィール画像に表示され るなど、個別化された動的なユーザー体験を作成する。

• Expression： Javascript のような関数で、複雑なコンポーネントや高度な機能を作成できる

• 条件付きインタラクション：ユーザーのインタラクションに基づいて「if-then」と「if-else」の条件を作成し、複数の結果を持つダイナミックなプロトタイプを作成して、最終的な製品エクスペリエンスを正確に再現する。

UXPinの高度なコードベース機能により、企業はプロトタイプやテストに外部ツールやプラグインを必要とせず、それによってコストや重複したワークフロー、運用タスクが削減されます。

UXPinのデザインシステムは、デザインシステム成熟の初期および中期段階を支援し、Merge の技術により、組織は最終段階である完全に統合された「信頼できる唯一の情報源（Single source of truth）」を達成することができます。

Merge の技術で「信頼できる唯一の情報源（Single source of truth）」を実現する方法

Mergeの技術は、デザイナーとデベロッパーがまったく同じコンポーネントライブラリで作業するという究極の成熟を実現します。

１回の更新で、ドキュメントを含むデザインとエンジニアリングの変更が同期されるのです。

真の 「信頼できる唯一の情報源（Single source of truth）」

Mergeを使うと、組織はレポジトリから UXPinにUIライブラリをインポートできます。

そのため、デザイナーはデザインプロセスで、エンジニアが最終製品を開発するのと同じデザインシステムコンポーネントを使うことができます。

レポジトリへの変更は自動的にUXPinに同期され、最新バージョンがチームに通知されます。

この新しい UXPin Mergeのアプローチにより、より連携しやすく統合的なデザインプロセスが実現します。

デザイン、プロトタイプ、開発を分離するのではなく、UXPinを使うことで、プロセス全体を通してエンジニアリングチームと製品チームを関与させる統合フローを構築することができます。

そしてその結果、製品の最終品質は劇的に上がりました。

ー エリカ・ライダー氏、プロダクト、UX、DesignOps のソートリーダー。

バージョン管理でチームの同期を保つ

デザイナーは UXPinのバージョン管理を使って、最新リリースに切り替えるタイミングを選択し たり、必要に応じて古いバージョンに戻すことができます。デザイナーとエンジニアが同じバージョン管理で同期しているため、混乱や伝達ミスがなく、デザインシステム全体の変更履歴が１つで済みます。

Merge が Figma のチームライブラリより秀でている点

Figmaのチーム ライブラリを使う場合、組織は 2 つのバージョンのデザインシステムを維持する必要があります。

さらにプロトタイプとテストにさまざまなツールを使う場合は、さらに多くのバージョンを維持することもあります。

一方、それがMergeの場合、管理するのはデザインシステムのレポジトリのみです。

一元管理

デザインシステムチームは、デザインチームとエンジニアリングチームのためのレポジトリを一元で管理します。

この一元管理によって、チームはコンポーネントライブラリ、更新、ガバナンス、ドキュメント化、パターンの推進を完全にコントロールできるのです。

究極の一貫性

デザインシステムを一元管理することで、コンポーネントライブラリへの不正な変更を防ぐことができ、インタラクティブ性やスタイリングなどのプロパティは、コンポーネントやパターンに織り込まれます。

デザイナーがコンポーネントを取り外して調整できる Figma とは違って、Merge の要素とそのプロパティは固定されます。

デザイナーは、UXPin のプロパティパネルに表示される、デザインシステムのレポジトリで定義されたプロパティのみを扱うことができます。

デザインシステムチームは、React propsまたはStorybook Argsを使ってコンポーネントのプロパティを確定でき、デザイナーは、プロパティパネルで確認および調整をすることができます。

このような制約は、デザイナーとエンジニアが常に同じパラメータと制限の中で作業するということであり、リリースのたびにピクセルパーフェクトな一貫性がもたらされます。

MergeはUX負債と技術的負債を大幅に削減しながら、ドリフトを排除するのです。

複数のフロントエンド技術に対応

ほとんどの Javascript フロントエンド技術を 以下２つの統合機能を使って UXPin と同期させることができます：

• Git統合： Reactレポジトリに直接接続

• Storybook 統合： React、Vue、Ember、Angular など、あらゆる Storybook ライブラリを同期する

Figmaの Storybookプラグインは、componentとStoryを視覚化させるだけですが、UXPinのStorybook統合は、エディター内で完全にインタラクティブなプロトタイプを構築するためにコンポーネントライブラリをインポートします。

デザイン、プロトタイプ、テストを１つのツールで

Figmaではインタラクティブなエフェクトやアニメーションなどの制限もまだあるため、多くの企業はデザインとプロトタイプに複数のツールを使わないといけません。（例：プロトタイプに Zeplin の使用など）

一方、Mergeテクノロジーの場合、１つのツールだけで完結するので、ワークフローはシンプルになり、同時にコストも削減されるでしょう。

デザインプロセスでコードコンポーネントを使うことは、デザイナーが最終製品のような外観と感触のプロトタイプを作成できるということであり、プロトタイプの幅は広がるため、ステークホルダーやユーザーテスト参加者からのより良いフィードバックの取得に繋がります。

オープンソースのコンポーネントライブラリを使ってプロトタイプを作成して進化させる

UXPinには、Fluent UI、Ant Design、MUI、UXPin BoilerplateなどのMergeライブラリがあります。これらの使用によって、完全に機能する高忠実度なプロトタイプやテストのための MVP（実用最小限の製品）を作成することができます。

また、MergeのGit統合を使っているチームは、上記のライブラリからコンポーネントを組み合わせて、新しいパターンの構築や新しいパターンの検証できるのです。開発者のサポートなしでもデザインシステムの進化が促進されるのです。

UXPinのコードベースのソリューションを使用することで、ワンランク上の製品設計をしてみましょう。

Mergeテクノロジーを使って、「信頼できる唯一の情報源（Single source of truth）」でデザインと開発をつなげましょう。

詳細とアクセス権については、Merge のページをぜひご覧ください。

The post FigmaとUXPin【 デザインシステム 徹底比較】 appeared first on Studio by UXPin.

デザインシステムの開発および維持のための「DevOpsツール」といえば Storybookですね。優れたドキュメントや直感的なUI、さらに内蔵されたテスト、コラボレーション機能は、コンポーネントの構築や市場投入するために最適なツールです。

Storybookの仕組みを理解することで、デザイナーとフロントエンドの連携強化や、プロトタイプやテストへのデザインフロー改善のために内蔵された機能を最大限に活用することができます。

Mergeはドラッグ＆ドロップによってプロトタイプが作成可能な環境を提供します。レポジトリにあるコンポーネントを使ってインタラクティブなプロトタイプを作ってみましょう！詳しくはUXPinのStorybookページをご覧ください。

エンジニアがデザインシステムで Storybook を選ぶ理由

Storybook がデザインシステムの管理に最適なDevOpsツールであるのには、以下のような理由があります。

コンポーネントを切り離して開発およびテストをする

Storybookで、エンジニアは UIコンポーネントを分離して開発できるようになります。この開発ワークフローは、デザインシステムや多くの組織でコンポーネントライブラリに使われているReactのようなコンポーネント駆動型のフロントエンドフレームワークに最適です。

Storybook以前では、エンジニアは CodePenやCodeSandboxのようなサンドボックス（プログラムがシステムの他の部分に悪影響を及ぼすことのないように設計された環境）のプラットフォームを使って、コンポーネントを分離して構築やテストをしていました。Storybookは、このサンドボックス型の開発環境を、エンジニアやステークホルダーが UI 要素を閲覧、テスト、承認するための直感的なユーザーインターフェースで提供します。また、コンポーネントを組み合わせたり、テスト用の小さなプロトタイプパターンの作成もできます。

QA（品質保証）

分離して開発することは、デザインシステムの QA（品質保証）においても多くのメリットがあります。エンジニアは、リリース前にデザイナー、プロダクトマネージャー、その他のステークホルダーに新しい UI要素のテストやフィードバックを依頼することができます。

ドキュメント作成

コンポーネントライブラリにとってドキュメント作成は非常に重要ですが、時間を要するので、誰でも後回しにしたいと考えてしまいますよね。

StorybookのDocsPage は、基本的なドキュメント作成を自動化するzero-config（設定不要）でのデフォルトドキュメントであり、プロダクトチームやエンジニアリングチームは、このドキュメントを活用して、使い方やガイドラインの情報を作成することができます。

信頼できる唯一の情報源（Single source of truth）

クロスプラットフォームアプリケーションのコードベース管理は大変ですが、Storybook だと、一元化された環境から各プラットフォームのコンポーネントやパターンをテストするための「信頼できる唯一の情報源（Single source of truth）」が提供されます。

エンジニアはコンポーネントやパターンを並べて見ることができ、iOS、Web、Androidなど各プラットフォームを担当するエンジニアと連携できるため、一元管理された環境はデザインの一貫性を高めます。

アクセシビリティ

Storybook の A11y Accessibilityアドオンで、エンジニアはアクセシビリティテストを自動化することができます。このアドオンでは、各要素に新しいアクセシビリティタブが作成され、以下の３つのカテゴリーで WCAG （Webコンテンツのアクセシビリティに関するガイドライン）規格が表示されます：

• 違反：解決すべきアクセシビリティの問題がある
• 合格：基準を満たしている
• 未完成： アクセシビリティの ToDoチェックリストに追加

Storybook デザインシステムの活用方法

Storybookのドキュメントには、デザインシステムにおける5ステップのワークフローを紹介します：：

• ビルド
• ドキュメント作成
• レビュー
• テスト
• 分配

１．ビルド

エンジニアは Storybookをセットアップし、GitHubレポジトリに接続すると、各コンポーネントとそのバリエーションの開発を始めます。例えば、ボタンにはステートやサイズ、タイプなどいくつかありますね。

ビルドプロセスにおいて、エンジニアは Storybookのアドオンをインストールすることで、ワークフローの自動化、他のツールとの統合、Storybook 環境の拡張ができます。

２．ドキュメント作成

エンジニアは、ビルドプロセス中にコンポーネントにコメントを追加して、自動生成されるドキュメントを充実させることができます。Storybookのドキュメントにあるこの例では、このようなコメントが StorybookのUIにどのように表示されるかが示されています。

このドキュメントは、フロントエンドエンジニアがデザインをどのように解釈し、それぞれのプロップが何を表しているかをステークホルダーに示すことから、次のステップで非常に重要になります。

３．レビュー

これでコンポーネントはステージングされ、デザインシステムにする準備は整いました。エンジニアは、デザイナー、プロダクトマネージャー、その他のステークホルダーに聞いて、要素のデザインやインタラクティブ性を確認するといいでしょう。

従来は、エンジニアがステージング環境を作ったり、ステークホルダーと会ってコンポーネントをプレゼンする必要がありましたが、Storybook では、Webサイトにアクセスするのと同じくらい簡単に、レビュープロセスをより身近なものにすることができます。

そしてステークホルダーは、好きなタイミングでログインし、コンポーネントに触れ、ドキュメントを読み、フィードバックを残すことができます。

変更点があれば、エンジニアは新しいコンポーネントがステークホルダーの要望に応えるまで、ステップ１から３を繰り返すこともできます。

４．テスト

JestとPlaywright は、Storybook の「フレームワークにとらわれないテスト」を実現します。エンジニアがコンポーネントを作成すると、Storybook は、以下のようなプログラミングエラーが確実にないようにするために、コードをテストします：

• ビジュアルテスト（視覚的回帰テスト）：各コミットのスクリーンショットを作成し、それを比較することで UIの不整合を検出する。
• アクセシビリティテスト：WCAG（Webコンテンツのアクセシビリティに関するガイドライン） 基準に照らしてコードを実行し、問題があれば報告する。
• インタラクションテスト：リンクや機能に問題がないか、インタラクティビティやステートをチェックする。
• テストカバレッジ：条件、論理分岐、関数、変数など、業界標準に照らし合わせてコードを検査する。
• スナップショットテスト：レンダリングされたコードをベースラインと比較することで、マークアップの変更を特定する。

５．分配

最後は、GitHub でのデザインシステムのパッケージの更新です。完了すると、変更内容が自動的に npm に同期され、エンジニアはその更新されたnpmパッケージをインストールすることで、新しいコンポーネントを使えるようになります。

UXPin Mergeでデザインを Storybook と同期させる

デザインチームが UXPin Mergeを使っている場合、このような技術的変更はUXPinのエディター上で最新のデザインシステムのリリース内容がチームメンバーに通知されます。

バージョン管理は、デザイナーがいつでも変更でき、以前のバージョンのデザインシステムに切り替えることもできます。

UXPin Merge とは

UXPin Mergeは、デザインと開発のギャップを埋める（Mergeする）技術です。組織は、デザイナーがエンジニアと同じコンポーネントライブラリを使って、完全に機能するプロトタイプを構築することができるように、レポジトリにホストされているデザインシステムをUXPinのデザインエディターに同期させることができます。

Mergeコンポーネントは完全にインタラクティブであり、色、タイポグラフィ、ステート、サイズなど、デザインシステムで確定された Reactプロップ (StorybookではArgs) を含みます。そのプロップは、デザイナーが絶対的な一貫性と摩擦がない状態を維持しながら、プロトタイプの要件を満たすようにコンポーネントを調整することができるように、UXPinのPropaties Panel（プロパティパネル）に表示されます。

テストとステークホルダーからのフィードバックの強化

Mergeのプロトタイプには、同じコンポーネントが使われるため、最終製品のような見栄えと機能が備わっています。たとえば、Storybookのボタンは、UXPinでもインタラクティブ性やスタイリングを含めてまったく同じようにレンダリングされます。

ユーザビリティテスト参加者やステークホルダーは、このような UI要素やMergeプロトタイプを最終製品と同じように操作することができ、それによってデザインチームに正確で実用的なテストインサイトがもたらされます。

「UXPinを使うことで忠実度の高いプロトタイプを作成できるのでとても助かっています。高忠実度のプロトタイプをより早く作成・修正できて、すぐにフィードバックを得ることができます。」Erica Rider – UX Lead EPX,  PayPal「PayPalがUXPin Mergeでデザインプロセスを拡張した方法」

UXPin Patterns（パターン）によるコンポーネントライブラリの拡張

デザインシステムは、製品の成長や規模に合わせて進化していき、デザインシステムチームは常に新しい変更を加え、新しいUI要素やパターンを推進しています。

Patterns機能で、デザインチームがデザインシステムに対して新しいパターンを作成できます。デザイナーは、分子や原子単位でUI要素を組み合わせて新しいパターンを作成できます。現在のライブラリがニーズに対応していない場合は、npm統合を使用して、オープンソースライブラリからコンポーネントをインポートすることができます。

デザイナーは，このようなパターンを保存して組織全体で共有することができるため、チームは、デザインシステムチームがガバナンスの手順に従って新しいコンポーネントを開発しリリースするのを待つ間、プロトタイプを作成し続けることができます。 上で説明した５つのステップのStorybook開発プロセスに沿った作成ですね。

UXPin Mergeによる第４段階のデザインシステム成熟度

Iress は２０１７年に第３段階のデザインシステム成熟度を達成しました。その後数年間、デザインシステムチームは、最終成熟度である第４段階 – 完全統合に到達するためのデザインツールを探しました：

1. コード又はノーコードでデザインする
2. デザインドリフトがない
3. 一貫性のあるデザイン
4. シームレスなハンドオフ

Mergeは、この４つのデザインシステムの課題を以下で解決します。

• デザイナーは、スタイリングやインタラクティブなプロパティを備えた既製のコンポーネントを使うため、ゼロからデザインする必要がない。UI要素をドラッグ＆ドロップして、新しい製品をデザインすることができる。
• コードでの開発なし。エンジニアはパッケージをインストールし、まったく同じUI ライブラリを使ったプロトタイプをコピーする。UXPinは各コンポーネントのJSX をレンダリングするので、エンジニアはコピー＆ペーストでスタイリングやインタラクティビティを適用できる。
• 全員が同じ制約のもとで同じコンポーネントライブラリ（デザインチームとエンジニアリングチーム）を使用すれば、ドリフトは存在しない。
• 制約を組み込んだ同じコンポーネントを使うことで、デザインチーム間で一貫性を保つ。
• Mergeでは、デザイナーとエンジニアが同じ「信頼できる唯一の情報源」を使うので、シームレスなハンドオフが可能であり、デザイナーは UIを説明したり、プロトタイプを説明するドキュメントを延々と作成したりする必要がない。（すでに最終製品のような見た目と機能を備えているため）

UXPinは、デザインシステムの成熟度を示す４つの段階を、以下のようにわずか２つに短縮します。

1. UXPinのデザインエディタを使ってライブラリをデザイン。
2. デザインをコードコンポーネントに変換してレポジトリに追加し、Mergeを使って UXPinに同期させる。反復して拡張させていく。

デザインシステムに最適な２つのデザインとエンジニアリングツールを融合させることで、製品開発は次のレベルへ上がれます：

UXPin Merge + Storybook = 信頼できる唯一の情報源

ここまでお読みいただきありがとうございます。14日間の無料トライアルはこちらからご体験いただけます。詳細とリクエスト方法については、UXPin MergeでのStorybook連携ページをご覧ください。

The post Storybook をデザインシステム開発で活用するには？ appeared first on Studio by UXPin.

コンポーネント駆動型のプロトタイプは、UXデザインの次なるイテレーションです。デザイナーはもはやゼロからデザインすることはなく、エンジニアが書くコードはより少なくなっています。  

これによってもたらされることは、機能横断的な連携の強化、市場投入までの時間短縮、一貫性、エラーの減少、より良いテスト、ステークホルダーからの有意義なフィードバック、そしてスムーズなデザインのハンドオフが実現します。  

UXPin Mergeを使うことで、これらのメリットがすべて実現可能です。詳しくはこちらのページをご覧ください。  

 コンポーネント駆動型 プロトタイプとは

  コンポーネント駆動型のプロトタイプは、デザイナーが既製のUI（ユーザーインターフェース）要素を使ってUIを構築する製品デザイン手法の１つです。ゼロからデザインするのではなく、インタラクティブなコンポーネントをドラッグ＆ドロップしてプロトタイプを作成します。  

このデザイン手法は、フロントエンドエンジニアがゼロからコーディングするのではなく、既存のコンポーネントライブラリを使ってUIを構築するコンポーネント駆動開発に由来するものです。  

Storybookはこの開発方法でよく使用されるツールであり、エンジニアはコンポーネントを分離して構築・管理することができます。

コンポーネント駆動型プロトタイプも同様に、ゼロからデザインするのではなく、オープンソースのUIライブラリや製品のデザインシステムを使って、既製のコンポーネントでUI構築に集中することができます。  

コンポーネントは通常、色、タイポグラフィー、サイズ、スタイルなどの定められたプロパティで完全にインタラクティブであり、それによってデザイナーはプロトタイプ作成、テスト、イテレーション、デザインプロジェクトの提供をより速く、より正確に行えるようになります。  

 コンポーネント駆動型プロトタイプ の手法

  コンポーネント駆動型のプロトタイプはコンポーネント駆動開発からヒントを得たものですが、ブラッド・フロント氏のアトミックデザイン原則がデザイン手法の基礎となります。  

アトミックデザインにおいては、UI構築の際に最小のUI要素から始めて徐々に規模を拡大していく段階的な取り組み方法を採用しています。ゼロからデザインするのではなく、要素を組み合わせ、より大きなコンポーネントやテンプレート、UI（ページ）を作成します。

アトミックデザインの5つの要素には、以下のようなものがあります：  

1. 原子（Atoms）：HTMLタグ、フォント、アニメーション、カラーパレットなど、UIの基礎となる要素。デザイナーはこれらの要素を分解することはできない。
2. 分子（Molecules）：原子が組み合わさって、フォームのラベルや入力フィールドのような小さなインタラクティブなコンポーネントを作る。
3. 生体（Organisms）：ユーザビリティやアクセシビリティの問題を解決するために、デザイナーが使うインタラクティブ性の高い複雑なUIコンポーネントであり、ロゴ、検索フィールド、プライマリーナビゲーションなどが例として挙げられる。
4. テンプレート：ブログのフィード、カルーセル、導入事例、フッターなど、さまざまなウェブサイトやアプリケーションの部門の構造を定めるものであり、テンプレートには、このような大きな構造を作成するための原子、分子、生体のグループ化が含まれている。
5. ページ：ユーザーのニーズとビジネスゴールを一致させ、まとまりのあるUIを作成するためのテンプレート集を使った完全な画面。

コンポーネント駆動型プロトタイプにおける8つのメリット

1. 信頼できる唯一の情報源（Single source of truth）

  コンポーネント駆動型のプロトタイプの最も大きなメリットは、デザインと開発の連携の強化であり、デザイナーとエンジニアは、レポジトリやnpmパッケージ、Storybookでホストされている同じコンポーネントライブラリを使って作業します。  

UXPin Mergeのようなツールは、デザインと開発の間の繋がりを促し、各部門が単一のコンポーネントライブラリにアクセスできるようにします。デザインチームが視覚的なUIコンポーネントを使う一方で、エンジニアはその背後にあるコードを見るというように、同じ要素を異なる視点から見ることができます。   

2. デザインの一貫性

  この信頼できる唯一の情報源（Single source of truth）は、デザインと開発全体の一貫性の維持に優れており、インタラクティブ機能とスタイリングが組み込まれているため、デザイナーはUIコンポーネントを組み合わせてUIを作成することだけを考えればよく、色、タイポグラフィー、サイズ、境界線の半径、正しいアイコンの使い方などのバリエーションといったよくある問題を排除することができます。  

また、デザインの一貫性は、複数のチームが同じ製品に取り組む際に重要な、承認され統一されたコンポーネントやUIを受け取るエンジニアにも利点があります。

3. 共有可能

  デザインチーム間でコンポーネントを共有することで、デザインの一貫性を維持しながら、UXワークフローとデザイナーの連携を効率化することができます。  

静的なUIキットで、デザイナーはUI要素の共有ができますが、そのようなキットは忠実性と機能性に欠けています。そうなると、デザイナーが自らセットアップしなければならず、それがインタラクションデザインの矛盾やドリフトにつながります。  

そこでコンポーネントライブラリを共有すれば、デザイナーはビジュアル要素、インタラクション、スタイリング、その他デザインシステムが設定するあらゆる制約を受けることができます。  

4. よりスムーズなデザインハンドオフ

  デザインハンドオフは、デザイナーとエンジニアにとって、本来はストレスの多い、虚構に満ちたプロセスであり、デザイナーは、ツールやビデオ、ドキュメントや静的なデザインを使って、プロトタイプが「何をするはずなのか」を示します。  

UXPin Mergeでデザインハンドオフを行うと、エンジニアが同じコンポーネントを使うため、不確実性がなくなり、文書化を減らすことができます。デザイナーは、各コンポーネントのインタラクションやスタイリングのプロパティで技術的な制約を受けないようにできるので、エンジニアが再現できないデザインを目にすることはほとんどありません。  

5. 有意義なフィードバック

  ユーザビリティの参加者やステークホルダーも、コンポーネント駆動型のプロトタイプの恩恵を受けます。完全にインタラクティブなプロトタイプは、最終的な製品とその能力について、誰もが現実的に期待することができ、デザインチームは、より高い忠実度と機能性により、ステークホルダーとエンドユーザーから有意義で実用的なフィードバックを得ることができるのです。

6. より高速なイテレーション

コンポーネント駆動型のプロトタイプのワークフローにより、デザイナーはテストやステークホルダーからのフィードバックに対して、より速やかにイテレーションを行うことができます。ドラッグ＆ドロップによるデザインプロセスと簡単にできるプロパティへのアクセスにより、デザイナーはその場で変更を加えることができるのです。ちなみにPayPalは、UXPin Mergeに切り替えた後、以下のようにその効率性の向上を実感しました：

「忠実度の高いプロトタイプをより早く作り、セッション後にすぐにフィードバックが得られます。すぐに修正できることがあれば、次の参加者の前にその変更を行い、以前よりずっと早くフィードバックを得ることができます。」- PayPal, UXシニアマネージャー、エリカ・ライダー氏

UXPin Merge のユーザーはPatternのようなツールの恩恵を受け、デザインチームは1つのコンポーネントが持つ複数のバージョンを共有のパターンライブラリに保存することができます。そしてデザイナーは、UXPinのPropaties Panel（プロパティパネル）を使う代わりに、UI要素とパターンを切り替えて、より速くイテレーションを行うのです。  

7. レスポンシブデザイン機能

  レスポンシブデザインは、デザイナーにとって時間のかかる作業です。1つの画面に対して複数のレイアウトの作成が必要があり、それによってデザインプロジェクトに多大な時間が費やされることになります。そこで、レスポンシブコンポーネントを開発することで、デザイナーはプロトタイプを１つ作成するだけで、すべてのレイアウトに対応できるようになります。  

Merge のコンポーネント駆動型のプロトタイプのソリューションでは、デザイン システムチームはコンポーネントをiFrameでラッピングして、複数のビューポートに対応させることができ、デザイナーはデザインをプレビューする際に、ドロップダウンを使ってこのようなレイアウトを切り替えることができます。  

8. デザインの拡張性

  コンポーネント駆動型のプロトタイプのドラッグ＆ドロップの特性とは、非デザイナーが、画像ベースのデザインツールを使う熟練のUXデザイナーよりも、高い忠実度と機能性でプロトタイプを構築することができるということです。  

PayPalが2019年にUXPin Mergeを使い始めた際に、製品チームをトレーニングすることでデザインプロジェクトの90%を完了させることができました。UXデザイナーは製品チームを指導し、複雑なユーザビリティの問題をサポートすることで、UX専門家を増やす必要性が下がるとともに、ハイレベルなUXの取り組みに集中できるようになりました。  

コンポーネント駆動のワークフローは、学習曲線を大幅に短縮し、プロトタイプを高速化することで、非デザイナーにもデザインプロセスがより身近なものになっているのです。  

コンポーネント駆動型のプロトタイプのワークフローを導入している会社

  PayPalとTeamPasswordは、コンポーネント駆動型のプロトタイプを使って不整合を排除し、顧客にポジティブなユーザー体験を提供しています。  

PayPalが巨大な多国籍企業であるのに対し、TeamPasswordは小規模なチームで運営されていることから、今回この２社を例に選びました。  

両社とも、UXPin Mergeに切り替え、コンポーネント駆動型のプロトタイプのワークフローを採用することで、大きなメリットを得られました。  

PayPal

  PayPalは、コンポーネント駆動型のプロトタイプのとてもいい成功例です。同社はUXPin Mergeに切り替えた後、画像ベースのデザインツールを使っていたときよりも8倍速くデザインプロジェクトを完成させました。  

「PayPalで使っている別のデザインツールで、1ページのベクターベースのデザインを行い、その後、UXPinでMergeコンポーネント ライブラリを使って全く同じプロトタイプを作成しました。Merge だと、デザイナーは約 8分間でできますが、他のデザインツールでは1時間以上かかりました。」

「社内でよくある問題は、製品チームがUXデザインをボトルネックと捉えていることです。まずはそのボトルネックを取り除き、製品チームが自分たちでデザインを行えるようにする戦略を実行しました。」 – Paypal、エリカ・ライダー氏  

PayPalのコンポーネント駆動型のワークフローでは、製品開発に関わるすべての人がUXに責任を持つようになります。最も大きな影響として、コンポーネント駆動型のプロトタイプによって、PayPalの製品チームはより多くのデザイン責任を担うことができるようになった点です。  

Teampassword

  パスワード管理は、組織が顧客の確保および維持のために信頼を勝ち得なければならない、競争の激しい業界であり、デザインは、ブランドの強化や、顧客の信頼とロイヤルティを獲得する一貫したユーザー体験を生み出す上で、重要な役割を担っています。  

「お客様は私たちに「ログイン記録」という重要な情報を託しています。矛盾や時代遅れのデザインは、当社がその情報を安全に保つのに十分な最先端の技術を備えているかどうか、一部のお客様に疑念を抱かせてしまうことになります。フロントエンド開発は、バックエンドのパフォーマンスに対する信頼と自信を築くのです。」トニー・カッチャーボ氏、TeamPasswordオペレーションディレクター  

TeamPasswordはゼロからデザインする代わりにオープンソースのコンポーネント ライブラリを使い、プロトタイプとテストのためのデザイン チームは設けられてません。その代わりに、TeamPasswordのフロントエンドのデベロッパーは UXPin Merge を使って新しいUIや機能のプロトタイプとテストを行っています。  

このコンポーネント駆動ワークフローによって、TeamPasswordは製品のデザイン、テストなどが高い整合性で行うことができ、市場競争の中での運営において欠かせないものとなっています。  

コンポーネント駆動型のプロトタイプの始め方

  デザインと開発の間に信頼できる唯一の情報源（Single source of truth）を作成することはこれまで以上に簡単になります。UXPin Mergeでを使用することで、組織はコンポーネント ライブラリをインポートでき、デザイナーとエンジニアは同じ UI 要素を使えるようになります。  

コンポーネントの取り込み

  デザイナーは、UXPinのNPM統合を使ってオープンソースのコンポーネントライブラリをインポートしたり、エンジニアの協力を得て、MergeのGitまたはStorybookの統合を使って製品のデザインシステムを同期させたりすることができます。

プロトタイプ

どの方法でUXPinとコンポーネントを同期させても、デザインの流れは同じです。

• MergeのUI 要素をキャンバスにドラッグして、プロパティパネルで変更する。また、より大きく、より複雑なコンポーネントを作成するのにUXPin Pattern（パターン機能）を使って要素を組み合わせることも可能。
• コンポーネントを接続してプロトタイプを作成し、ユーザビリティテストやステークホルダーへのプレゼンテーションを行う。
• 完璧なソリューションを見つけるまで、テストとイテレーション行う。UXPinでは、【プレビューと共有】を使ったブラウザでのテストや、【UXPin Mirror】を使ったモバイルでのテストが可能。
• プロジェクトに【ドキュメンテーション】を追加し、デザインハンドオフの時にコメント機能を使ってエンジニアと共同作業を行う。

Mergeの信頼できる唯一の情報源（Single source of truth）

UXPin Mergeは組織全体での「信頼できる唯一の情報源（Single source of truth）」として機能し、それによって製品のデザインシステムの管理および拡張のお手伝いをします。さらに、コンポーネントライブラリのレポジトリに変更があると、UXPinのデザインエディタに自動的に同期され、チームに更新が通知されます。

UXPin Mergeのバージョンコントロール機能で、リリースの追跡や、デザイナーによる以前のバージョンへの切り替えができるため、アップデートを完全にコントロールすることができます。

UXPin Mergeが提供するコンポーネント駆動型のプロトタイピングを試してみませんか？詳細とこの革新的なテクノロジーへのアクセス権のリクエスト法については、Mergeのページをぜひご覧ください。

The post コンポーネント駆動型 プロトタイプとは？ appeared first on Studio by UXPin.