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.

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

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

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.

新しいプロジェクトの開始時に企業が考えることの一つとして、「コンポーネントライブラリを採用するか、ゼロから始めるか 」というのがあります。メリット・デメリットの比較検討が必要であり、プロジェクトの範囲と優先順位の考慮も必要です。 その際に最も人気のあるコンポーネントライブラリの1つがMUIで、GoogleのMaterial Design UIを最初にモデル化された包括的なReact UIライブラリです。

今回はMUIについてみていきましょう、なぜMUIを使いたいのか、他のコンポーネントライブラリとの違いは何か、そして次のプロジェクトのデザインの始め方ついてお話します。 コードでデザインってどんな感じだろう、と思ったことはありませんか？

UXPin Mergeは、コードコンポーネントをレポジトリからUXPinのエディタに同期させる画期的な技術です。この強力なツールにより、デザイナーは一行のコードも書かずに、きちんと機能するコードベースのプロトタイプを作成することができます。Merge の詳細と、次のプロジェクトのためのアクセス要求方法についてご覧ください。

また、UXPinのトライアルでは、コードコンポーネントを使ったデザインがどんな感じか試すことができ、トライアル中にMUI 5キットを用意していますので、MUIを間近で体験することができます。14日間の無料トライアルに登録して、MUIをぜひご利用ください。

MUI とは

MUIは、デザイナーやデベロッパーがReactアプリケーションを構築するのに使えるUIコンポーネントの巨大なライブラリです。このオープンソースプロジェクトは、コンポーネント作成のためのGoogleのガイドラインに従っており、基礎的なUI要素と高度なUI要素のカスタマイズ可能なライブラリが備わってます。 また、MUIはReactのテンプレートやツールを販売しており、プロジェクトに合わせて微調整できる既成のユーザーインターフェースがあります。

MUI のような コンポーネントライブラリ を使う理由

デザイナーは、新製品の開発や既存プロジェクトの機能追加にUIキットを使用することがよくありますが、これらのライブラリにより、デザイナーは必要なコンポーネントをドラッグ＆ドロップして、さっとインターフェースのデザインができます。

MUIコンポーネントライブラリを使用する7つの理由を探ってみましょう。

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

競争の激しい今日のテク環境において、市場投入までの時間は、企業が常に最適化を求めるメトリクスとなっています。コンポーネントライブラリを利用することで、デザイナーやデベロッパーは、すぐに使える徹底的にテストされたUI要素で、大きな幸先のいいスタートを切ることができます。

デザイナーは、要素をドラッグ＆ドロップしてユーザーインターフェースを構築し、製品やブランドの要件に合わせてコンポーネントをカスタマイズすることができます。

デザインチームは、UIコンポーネントをゼロから構築してテストすることに煩わされることなく、優れたカスタマーエクスペリエンスのデザインにより多くの時間を費やすことができ、市場投入までの時間が大幅に短縮されます。

デザイナーがプロトタイプの作成、テスト、反復を速くできるため、ユーザビリティテストはずっと速くなります。テスト中にユーザーインターフェースがうまく機能しない場合は、膨大なライブラリからその場で変更を加え、参加者やステークホルダーから即座にフィードバックを得ることができます。

デザインハンドオフでは、エンジニアはコンポーネントライブラリをインストールし、プロトタイプやスタイルガイドからの変更をコピー＆ペーストすることで、ゼロから始めることなく製品を開発することができます。

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

信頼できる唯一の情報源（Single source of truth）の維持は、デザインシステムのガバナンスにおける最大の課題の1つです。製品チーム、UXデザイナー、およびデベロッパーが、同期していないデザインシステムを使用していることは珍しいことではなく、その結果、エラーや再作業が発生し、DesignOpsは大きな課題に頭を抱えることになります。

MUIのコンポーネントライブラリを使用することで、デザインと開発の間に信頼できる唯一の情報源（Single source of truth）を作成しながら、こういった課題を大幅に減らすことができます。デザイナーとエンジニアは別々のデザインシステム（デザイナーは画像ベース、エンジニアはコードベース）を持つことになりますが、MUIは彼らに同じスタートブロックを提供します。

UXPinのコードベースエディターでMergeを使用すると、デザイナーとエンジニアは同じデザインシステムのコンポーネントを単一のレポジトリで同期して使用します。レポジトリが更新されると UXPin に同期され、デザイナーに変更点が通知されます。Reactコンポーネント ライブラリにはGitを、その他の一般的なテクノロジーにはStorybookを使用してMergeを接続できます。

3. デザインの一貫性

一貫性は、ユーザーエクスペリエンス、信頼の構築、ブランドロイヤリティには欠かせません。同じUIコンポーネントを使用することで、デザイナーは一貫性を高め、エラーや手戻りを最小限に抑えることができます。

4. 拡張性

拡張性もまた、製品デザインの重要な要素です。ゼロからデザインシステムを構築する場合、デザイナーは製品をスケールアップする前に、新しいコンポーネントのデザイン、プロトタイプの作成、テストが必要です。

MUIの包括的なUIライブラリにより、デザイナーはプロトタイプに必要なコンポーネントを検索して、すぐに拡張することができ、エンジニアは、MUIから同一のReactコンポーネントをコピー＆ペーストし、デザイナーの仕様に合わせてカスタマイズできます。

MUI Xには、データグリッド、日付ピッカー、チャート、ページネーション、フィルタリングなど、複雑な製品をより速く拡張するためにチームが使用できる高度なReactコンポーネントのライブラリが含まれています。

5. 容易なメンテナンス

MUIのようなコンポーネントライブラリには、コンポーネントのインストール、使用、更新、カスタマイズのための詳細なドキュメントが付属しています。デザイナーやエンジニアは、このフレームワークを使って企業のデザインシステムの維持ができ、ガバナンスシステムやプロトコルを簡単に確立することができます。

また、MUIには、あるバージョンから次のバージョンへの移行のためのハウツーガイドもあるので、企業はMUIがアップデートをリリースするたびに、最新のUIスタイル、テクノロジー、トレンドを利用できます。

6. アクセシビリティ

デザインシステムを設定した経験のある方は、すべてのコンポーネントがアクセシビリティ基準をクリアするのに必要な時間と費用をご存知でしょう。MUIのデザイナーは、WCAD 2.0のアクセシビリティ・ガイドラインを満たすようにコンポーネントをデザインすることに細心の注意を払い、研究者やデザイナーの負担を軽減しています。

ただし、アクセシブルなコンポーネントを用いてインターフェースをデザインする場合でも、ナビゲーションやユーザーフローをテストして、製品全体がアクセシビリティの基準を満たしていることの確認が必要であることに留意することが重要です。

7. スキルの強化

MUIのオープンソースコンポーネントUIライブラリは、スタートアップ企業や若い起業家が新製品を開発する際に、特に教育、指導、技能伝授を受けられない発展途上国において、その能力が発揮されるようにします。

また、チャリティ団体、非営利団体、NGOなど、製品やツールを開発したいがデザインシステムに投資する予算がない場合にも、このライブラリーは非常に有益です。 誰でもMUIの優秀なデザイナーやデベロッパーのスキルを活用し、フォーチュン500社で使用されているのと同じコンポーネントライブラリを使用して、洗練されたデジタル製品を開発し、グローバル市場で競争することができます。

MUIが他の コンポーネントライブラリ と異なる点

GoogleのMaterial Design UIは、間違いなく世界で最も優れた、最も包括的なデザインライブラリの1つであり、MUIは、Material Designの上に構築することで、それに匹敵するReactコンポーネントライブラリを提供します。

MUIはTheming機能で簡単にカスタマイズでき、ライブラリのドキュメントも充実しているため、多国籍企業や製品アイデアを持つ一人のデベロッパーでも製品の構築が可能です。 MUIは非常に広く使われているため、デザイナー、研究者、デベロッパーからなる大規模なグローバルコミュニティが存在し、指導やサポートを受けることができます。

Reactが最も人気のあるフロントエンドフレームワークの1つであるという事実も加わり、MUIは魅力的なコンポーネントライブラリとなっています。

興味深い事実と数字

ここでは、MUIの興味深い事実と数字をご紹介します。 注：MUIの統計は上昇を続けており、これは、2022年1月時点のものです。

• MUIは、Googleと差別化するために名称を変更することにして、2014年にMaterial UIとしてスタートしましたが、多くの人がMaterial UIはGoogleの製品だと思い込んでいるようでした。
• MUIには2,200人以上のオープンソースの貢献者がいます。
• GitHubで73,700スター以上獲得しています
• MUIが実施した2020年調査の回答者1,488人のうち、35％のデベロッパーが従業員5人以下の企業で働いていました。
• 調査では、27％のデベロッパーがエンタープライズ・アプリケーションにMUIを使用し、20％が管理者用ダッシュボードにライブラリを使用しています。

UXPinのMUI5キット

UXPin MergeのMUI統合で、UI Reactコンポーネントでプロトタイピングの力が発揮されます。 MUIは、きちんと機能するコードコンポーネントでのデザイン作成をサポートします。信頼できる唯一の情報源（Single source of truth）により、デザイナー、デベロッパー、製品チームなどは、エラーや摩擦を減らし、より効果的にコラボレーションを行うことができます。 忠実度が高いほど、参加者とステークホルダーから有意義なフィードバックを得られるような、より良いユーザビリティ・テストとなります。

その結果、全体的なユーザー体験が向上し、ビジネス価値が高まります。 UXPinのMUIキットの詳細と、この画期的なコードベースのデザイン技術へのアクセスをリクエストするための申し込み方法についてご覧ください：UXPinのMUIライブラリ：より速くデザインする。

UXPin Mergeによるコンポーネントライブラリの同期

UXPin Mergeで、Gitレポジトリ、Storybook、またはMUIからコードコンポーネントを同期し、実際のコードで完全に機能する高忠実度のプロトタイプの構築ができます。 メニュー、フォーム、タブ、データテーブル、日付ピッカー、アコーディオンなどの複雑なUIコンポーネントは、UXPinのコードベースエディタに機能が搭載されており、デザイナーは、ユーザーインターフェースの構築に必要なMUIコンポーネントをドラッグ＆ドロップします。

標準的な画像ベースのデザインツールと同じように、コンポーネントのプロパティパネルを調整することができます。 UXPin Mergeの優れた点は、デザイナーがコードベースのコンポーネントを使用してデザインするのに、新しいスキルセットを学んだり、コードの書き方を知る必要がないことです。

ワークフローは変わりませんが、プロトタイプの忠実度と機能性が大幅に向上します! デザイナーが Merge を使用せずに UXPin を使用する場合でも、ステート、Javascriptのようなインタラクション（条件付きインタラクションを含む）、変数、エクスプレッション、オートレイアウトなど、コードベースの高度な機能を利用できます。

The post MUI とは？MUIについて何を把握すべき？ appeared first on Studio by UXPin.

UXエンジニアは、現代のソフトウェア開発チームにおいて重要な役割を担っており、デザインと開発の間の連携を強化するためのスキルと言語を持ち合わせています。

UXエンジニアは、大抵は部門を超えたチームで働き、デザイナーとエンジニアの間を明確にしてサポートする役割を担っています。UXエンジニアとデザイナーが協力して、デザインのアイデアを機能コードに変換することで、分野間のギャップが埋まり、フロントエンドエンジニアとバックエンドエンジニアは、このコードを基盤として最終製品を開発します。

​​UXPin Mergeにより、デザインと開発の間のギャップを埋めることがこれまでになく簡単になりました。デザイナーの皆さん、コードコンポーネントをUXPinのデザインエディタに同期して、完全に機能するプロトタイプを構築しましょう。無料トライアルにサインアップして、無料の MUI 統合により Merge をお試しください。

UXエンジニアとは？

UXエンジニアは、UIエンジニアまたはUI/UXエンジニアとも呼ばれ、UXデザイナーとUXデベロッパーのハイブリッド的な位置づけになりますが、一般的には、デザイン思考やデザイン原理を理解したフロントエンドのデベロッパーです。

UXエンジニアは、デザインチーム、エンジニアリングチーム、またはその中間で、デザインと開発の橋渡し役として働き、通常は、レイアウト、ボタン、リンク、その他のインタラクティブなコンポーネントなど、UI要素の構築と最適化を行うフロントエンド開発を専門としています。

UXエンジニアは、静的なデザイン要素をインタラクティブなコードコンポーネントに変換する、デザインシステムを扱うことが多いです。

UXエンジニアのスキルセットと業務内容

「UX Engineers: What We Are」内で、UXエンジニアのブライリー・サンドリン氏は、UXエンジニアの職責をグラフィックで表現しています。

UXデザイナーが行う：

• UXリサーチ
• アセット作成・管理
• ワイヤーフレーム作成

UXエンジニアとUXデザイナー両方が行う：

• アイデア出し
• デザインテスト
• 再デザイン

UXエンジニアが行う：

• プロトタイピング
• UIコンポーネント開発
• UIメンテナンス
• スタイリングのアーキテクチャ

UXエンジニアとフロントエンドエンジニア両方が行う：

• 実装
• 技術的実現性
• バックログ管理

フロントエンドエンジニアが行う：

• パフォーマンス
• クエリのアーキテクチャ
• 検索エンジンの最適化

UXエンジニアは、デザインプロセスや原則に関する知識と理解を持ち、フロントエンドのプログラミングの高い能力が備わってなければいけません。ここでは、ソフトウェア開発プロセスにおけるUXエンジニアのスキルや責任について説明します。

UXエンジニア にコードは必要か

はい、UXエンジニアはコーディングの方法を知っておかければならず、最低でもHTML、CSS、Javascriptといった主要なフロントエンドのプログラミング言語についての高い能力が必要です。

フロントエンド開発 – HTML、CSS、Javascript

UXエンジニアの主な業務はフロントエンドの開発であり、他のフロントエンド開発と同様、HTML、CSS、Javascriptに関する高い能力と経験が求められます。

製品によっては、React、Angular、Vueなど、特定のフロントエンドフレームワークの経験を求める企業もあります。

パッケージ管理

プログラミング言語によっては、Node.jsプロジェクトで使用されるNPM（Node Package Manager）やYarnなどのパッケージマネージャの操作法を知っておかなければいけません。

バージョン管理（Git）

フロントエンドの開発は、常に変化し、進化しています。UXエンジニアは、Gitなどのバージョン管理システムを使って、変更と更新を管理し、バージョン管理によって、他のプログラマーと同時にプロジェクトに取り組むこともできます。

デザイン思考

UXエンジニアがデザイナーと連携するには、デザイン思考プロセスの理解が不可欠であり、エンドユーザーへの共感や、UXデザインの原則の理解が必要です。

ユーザーインターフェース（UI）デザインとインタラクションデザイン

UIデザインとインタラクションデザインは、UXエンジニアにとって重要なスキルです。UXエンジニアは、デザイナーと協力してアイデアを出し合い、プロトタイプを機能コードに変換します。UXエンジニアはユーザーインターフェースをデザインしませんが、デザインファイルをコードに変換するため、UIデザインの原則を理解しておかないといけません。

ヒューマンコンピュータインタラクション（HCI）

ヒューマンコンピュータインタラクション（HCI）は、インタラクションデザインと似ていますが、デザインの原則よりもコードに重点を置いており、UXエンジニアの仕事は、デザイナーのプロトタイプを基にした、直感的なフロントエンド体験の構築になります。

デザインシステム

UXエンジニアは、デザイナー、リサーチャー、その他のエンジニアからなる、職域を超えたチームと共にデザインシステムに携わることが多く、デザインファイルから新しいコンポーネントを構築する役割を担っています。

デバッグとテスト

UXエンジニアは、リリース前にフロントエンドのバグを発見して修正する責任を担っていることから、デバッグとテストは、UXエンジニアの重要な作業の一部といえます。又、UXエンジニアは、コードのプロトタイプを作成してデザイナーやエンジニアに提示します。

デザイナーがプロトタイプがデザインと一致していることを確認し、UXエンジニアと一緒に働くデベロッパーがベストプラクティスや命名規則などを確認しながらコードをチェックします。

UXエンジニアは、このようなコードプロトタイプを構築することで、デザインのハンドオフプロセスを効率化し、エンジニアが最終製品を開発するための基盤を構築しています。

ナビゲーションと情報アーキテクチャ

UXエンジニアは、画面、モーダル、ページをつなぐ役割を担っているため、ナビゲーションと情報アーキテクチャを理解しておかなければいけません。

レスポンシブデザイン

レスポンシブデザインは、フロントエンドの開発において非常に重要であり、UXエンジニアは、CSSメディアクエリを使って、モバイル、タブレット、デスクトップなど、複数の画面サイズやデバイスに対応したブレイクポイントの設定が必要です。

ワイヤーフレームとモックアップ

UXエンジニアは必ずしもワイヤーフレームやモックアップを作るわけではありませんが、これらのデザインのコードへの変換が必要です。

UXエンジニアは、上記で挙げた必須スキルとは別に、デザインチームとの連携のために、以下の基本的なデザイン原則を理解しておかなければいけません：

• ビジュアルデザイン
• ユーザビリティテスト
• UXリサーチ
• ユーザージャーニーマップ

UXエンジニアの実際の仕事内容

UXエンジニアの担当は、組織や製品によって異なりますが、通常はデザインプロセスとエンジニアリングプロセスを行き来して仕事をし、4つのステージにUXエンジニアのプロセスが定められます：

1. アイデア出し
2. デザイン
3. 構築
4. テスト

1. アイデア出し

UXエンジニアは、ユーザーリサーチャーやデザイナーと協力して、ユーザビリティの目標の確定や、解決策のブレインストーム、初期デザインの技術的な実現性についての助言をします。

アイデア出しの段階では、ブレインストーミングとアイデアのスケッチが非常に重要であり、UXエンジニアは、アイデアがどう働くかや製品の技術的制約の範囲内であるかどうかについて、技術的なインサイトを提供します。

アイデア出しの段階でUXエンジニアがいれば、デザイナーやリサーチャーはエンジニアリングの能力を超えたソリューションを回避できるため、企業の貴重な時間を節約することができるのです。

2. デザイン

UXエンジニアは、ワイヤーフレームや低忠実度のプロトタイピングからモックアップや高忠実度のプロトタイピングまで、デザインプロセスで積極的な役割を果たし、デザインシステムを使う場合は、デザイナーと協力してUXPinなどのツールでコンポーネントのライブラリをデザインします。

UXエンジニアは、デザイナーのデザインのハンドオフのためのデザインファイル、ドキュメント、プロトタイプの準備をサポートする役割を担っており、デベロッパーに言葉や指示を確実に理解させ、デザイナーとエンジニアのコミュニケーションを円滑にします。

3. 構築

UXエンジニアは、静的なデザインをコードに変換する役割を担っています。役割はレイアウトやUI要素に及び、データ統合、API、パフォーマンス、分析などのその他のフロントエンド開発はエンジニアリングチームに任せます。

UXエンジニアは、開発段階を通じてエンジニアリングチームと協力し、意図したとおりにデザインを実行します。

4. テスト

UXエンジニアは、デザイナーと密接に協力して、デザインプロセスでのアイデアのテストや、ソリューションの開発、エンジニアと協力してコードのバグの特定や修正をします。

UXエンジニア になるには

大手の企業でUXエンジニアとして就職したい場合、通常、コンピュータサイエンス、ヒューマンコンピュータインタラクション（HCI）、またはUXデザインのいずれかの学位が必要とされます。

UXエンジニアになる方法はいくつかあります：

• UXデザイナー：HTML、CSS、Javascriptなどのプログラミング言語と、Git、Chrome Developer Tools、NPM/パッケージマネージャ、コマンドラインなどのフロントエンドスキルの習得が必要
• フロントエンドデベロッパー：フロントエンド開発からの移行が、UXエンジニアになるための最も一般的なルートであり、フロントエンドデベロッパーは、UXエンジニアに必要なほとんどのスキルをすでに持っているが、さらにUXデザインのプロセスや原則の習得が必要
• プロダクトデザイナー：プロダクトデザイナーからUXエンジニアへの道もまた、単純明快であり、プロダクトデザイナーは、デザイン思考を仕事に応用し、ほとんどがプロトタイプを作るための基本的なプログラミングスキルを持つ

UXエンジニアもまた、多様なツールキットを使って仕事をします。デザイナーとデベロッパーの2足のわらじを履いているため、デザインツール、DevOps、デベロッパー用ツールキットを熟知しておかなければいけません。ここでUXエンジニアのツールをチェックしましょう。

UXエンジニアの多くはデザインシステムを扱う職種であるため、高収入のUXエンジニアを目指すのであれば、デザインシステムの知識と経験が不可欠です。

UXエンジニアの給与

Glassdoorによると、2022年の米国におけるUXエンジニアの平均給与は116,625ドルです。

UXPin MergeによるUXエンジニアリングワークフローの最適化

UXPin Mergeで、UXエンジニアがデザイナーやデベロッパーと1つのツールで連携できるようになり、レポジトリからUXPinのデザインエディタにコンポーネントを同期させることにより、デザイナーとエンジニアが同じUI要素で作業できるようになります。

UXエンジニアがプロトタイプをコーディングする代わりに、UXデザイナーはUXPinでコンポーネントをドラッグ＆ドロップして完全に機能するプロトタイプを構築することができます。また、デザイナーはUXPinのプロパティパネルでコンポーネントを編集し、これにより、UXエンジニアがコピー＆ペーストで変更できるようJSXを簡単にレンダリングすることができます。

UXエンジニアがレポジトリに加えた変更は、自動的にUXPinのデザインエディタに同期され、デザイナーは新しいコンポーネントで作業することができます。この信頼できる唯一の情報源（Source of truth）により、UXエンジニアは毎回プロトタイプを一から構築するのではなく、コードにわずかな調整を加えるだけで済み、市場投入までの時間が大幅に短縮されます。

UXPin Mergeでは、デザイナーとエンジニアがすでに同じ言語で会話しているため、デザインのハンドオフが効率的であり、UXエンジニアは、レポジトリからスターターコードを使用してUIを開発した後、フロントエンドおよびバックエンドのデベロッパーに引き継いで最終製品を完成させることができます。UXPin Mergeのリクエストはこちらから。

The post UXエンジニア って具体的にどんな人？ appeared first on Studio by UXPin.

組織が製品を作る際に考慮しなければならない重要な UXデザイン原則 が数多くあります。これらのUX原則は、ユーザーをすべての意思決定の中心に据えるデザイン思考プロセスを補完するものです。

この記事では、企業がより良い製品を作るために利用できる16の UXデザイン原則 を紹介します。

UXPinの高度なプロトタイピングとテスト機能によりデザインチームはユーザビリティの問題を最小限に抑え、より良いユーザー体験を生み出すことができます。14日間の無料トライアルに今すぐお申し込みください。

16の UXデザイン原則 

その1：ユーザーにフォーカスする

ユーザーに焦点を当てるのは当たり前のように思えるかもしれませんが、多くのデザイナーはユーザーを十分に理解することなく、個人的な好みや偏見に基づいて意思決定を行っています。 またユーザーの問題を解決したり、製品に大きな付加価値を与えたりするとは限らないデザインや技術的なイノベーションに、デザイナーは振り回されてしまいます。

最良のデザイン決定はユーザーを理解し、そのニーズを満たすことから生まれます。なぜかというと、人間のための製品のデザインだからです。

経験豊富なUX専門家の多くは、人間ではなくユーザーに焦点を当てることはデザイナーが人間を相手にしていることを忘れてしまうという断絶を生むと考えています。

この言葉を人間中心設計と言い換えることで、UXチームはデザインや技術的な問題を解決することから、”人”を助けることへ考えをシフトすることができます。 デザイン思考の原則に基づいてフレームワークを構築することで、常にユーザーを中心に据えることができます。

• 共感-対象の”人”（エンドユーザー）を知る
• 問題を定義する
• アイデアを生み出す
• プロトタイプ
• テストとイテレーション

人間中心設計についての詳細はこちらをご覧ください。

その2：一貫性を保つ

デザインの一貫性は良いユーザー体験を提供するための重要な要素です。一貫性のないユーザー体験は製品の一部を使いこなせなかったり、機能のリリースやアップデートのたびに使い方を学び直さなければならないことを意味します。

デザイナーの目標は矛盾を気にすることなくユーザーのニーズを満たす製品を作り、最終的には信頼と愛用者を獲得することです。

デザインシステムを構築することで、デザイナー、プロダクトチーム、開発者が常に同じ要素、タイポグラフィ、色、コンポーネント、アセットなどを使用し、一貫性を養うことができます。

デザインシステムをお持ちでない方は ゼロからデザインシステムを構築するための7つのステップをご覧ください。

その3：わかりやすい

ユーザーが簡単に理解できるコンテンツや体験を提供すること。デザイナーは、人は常に最も簡単なルートを探すものだと認識しなければなりません。この競争の激しいテクノロジーの世界であなたが使いやすいものを提供しなければ、他の誰かが使ってしまうでしょう。

製品にオンボーディングが必要な場合は、ステップバイステップでわかりやすいドキュメントを作成してください。

UXPinのドキュメントはその例です。まず手順を分類し、探しているものを簡単に見つけることができます。次に、小見出し、ステップ・バイ・ステップの説明、説明ビデオなどでコンテンツを整理し、情報をフォローして消化しやすいようにしています。

その4：ユーザーに考えさせない

情報設計者でありユーザーエクスペリエンスのプロフェッショナルであるスティーブ・クルーグは、著書『Don’t Make Me Think』の中で、「ユーザーとしては、物事がクリックできるかどうかについて、1ミリ秒も考える必要があってはならない」と述べています。

UXデザイナーはプロダクト、アプリ、Webデザインのデザインスタンダードに従わなければなりません。例えば、ユーザーが予想しないような場所にナビゲーションを隠さないこと。またボタン、CTA、リンクなどがわかりやすく配置され、ユーザーを目的地に導くようにしましょう。

創造性や革新性は、競合他社が思いつかないような問題を解決することで得られるものであり、ユーザーが基本的な基準やプロセスを学び直さなければならないような体験を作り出すことではありません。

人間の心理や認知負荷がUXデザインにどのように関係しているかは、すべてのデザイナーが学ばなければならないことです。認知的負荷を最小限に抑えた製品設計を行うことで、より良いユーザー体験とブランドへの信頼が生まれます。

その5：点・線・面-視覚的な文法を理解する

1900年代初頭にバウハウスで定義されたデザインの基本は、「点」「線」「面」の3つの要素で構成されています。

その7：シンプルな言葉が一番

デザイナーは、人々が理解できないような専門用語や社内でのみ使う用語の使用は避けましょう。複雑な言葉を使ってしまうことで、顧客を失うことにもつながってしまいます。

読みやすさは、たとえ高学歴のユーザーであっても認知的負荷に大きな影響を与えます。これは、ポイント4の「ユーザーに考えさせない」でも同じです。

広く使われているライティングサポートツール「Grammarly」によると、書かれたコンテンツには（アメリカでは）13歳位の言葉を使うべきだとしています。

その8：オーディエンスへの共感を持つ

共感は、人間中心のデザインの核心です。デザイナーは理解を超えて、ユーザーとより深いレベルでつながることができます。デザイナーはユーザーやその苦労、環境に共感するために共感を用います。

エンパシーマップとはUXリサーチツールのひとつで、ユーザーが何を求めているのかを明らかにすることで、デザイナーが共感を得るためのツールです。

• 見る
• 聞く
• 考える
• 感じる

エンパシーマップは初期のリサーチやユーザビリティテストの際に、さまざまな感情や気持ちを確認するために使用します。ユーザーをより深く理解することで、彼らが言葉にしないような問題を発見することができます。

その9：フィードバック

マイクロインタラクションやアニメーションを使ってユーザーとコミュニケーションをとり、ユーザーの行動に対するフィードバックやコンテキストを提供します。

例えばアクションの処理に時間が必要な場合は、スローバーやローディングアイコンを使ってユーザーに待つように伝えます。エラーメッセージは、ユーザーが問題を修正するのに役立つようなものにしましょう。

ブランドメッセージに沿った一貫したフィードバックを使用することで、常にポジティブなユーザーエクスペリエンスを提供することができます。

その10：ビジネスバリューを忘れてはいけない

デザイナーは、ユーザーとブランドという2つの要素を満たさなければなりません。製品を成功させるためにはユーザーに焦点を当てることが重要ですが、デザイナーは、デザインがビジネス価値を生み出すことも保証しなければなりません。

ビジネスバリューと人間中心のデザインはしばしば重なり合います。例えば、よりスムーズでスピーディなEコマースのチェックアウトでの体験は、ユーザー・エクスペリエンス（ユーザー中心）を向上させると同時に、コンバージョン率（ビジネス価値）を高めます。

ユーザーの問題を解決しようとするときは常にビジネス価値を同時に生み出す機会を探しましょう。

ポーランドのエージェンシー、HERODOTのEwelina Łuszczek氏は、ビジネス価値に対するデザイナーの義務を簡潔な一文にまとめています。

「優れたUXデザイナーはユーザーの目標とビジネスの目標をリンクさせて、ユーザーと会社の両方が利益を得られるように管理します。」

 2014年のINFRAGISTICSの調査「The Business Value of User Experience」から4つの素晴らしい例を紹介します。

Bank of America

• デザイナーのアクション：登録プロセスのユーザーセンターの再設計
• 結果：登録数が45％増加

Anthropologie (衣料品会社) 

• デザイナーの行動 チェックアウトプロセスのUX再設計
• 結果：売上が24％アップ

GFK (コンサルティング会社)

• デザイナーの行動：購入ボタンの再設計
• 結果：売上高が5億ドル増加

United Airlines (航空会社)

• デザイナーの行動：ユーザーリサーチ
• 結果：オンラインチケット販売が200％増加

UXデザインによるビジネス価値の創出についての詳細は、INFRAGISTICSの12ページにわたる調査結果をこちらでご覧いただけます。

その11：ユーザーテスト

その6の「まず問題を特定する」と同様に、ユーザーテストはデザイナーが経験的な推測をするのではなく、実際のユーザーの問題を理解するために非常に重要です。 ユーザビリティテストは、UXチームに以下のような貴重なフィードバックとユーザーインサイトを提供します。

• ユーザーの問題を解決するためのデザインコンセプトの検証
• 修正すべきユーザビリティ上の問題の発見
• 改善の機会を発見する
• ユーザーについてより深く知る
• ビジネスバリューの機会を特定する

チームは、コンセプトの立案から最終的なデザインの引き渡しまで、常に解決すべき問題を探し、その解決策を検証するためにテストを行う必要があります。 テストについて詳しくはこちらをご覧ください。ユーザビリティ・テストとは何か、どのように実行するか。

その12：視覚的な階層化

視覚的な階層は、製品や画面のレイアウトを整理するのに役立ちます。ユーザーは重要な要素を識別し、必要なものを素早く探し出すことができます。

デザイナーは色、コントラスト、スケール、グループ化などの明確なバリエーションを用いて、視覚的な階層を作ります。

このブログ記事のようにライターがヘッダータグを使って記事の内容を構成し、整理することも視覚的な階層化の好例です。

Nielsen Norman Groupのこちらの記事も合わせてご覧ください。：Visual Hierarchy in UX: Definition

その13：アクセシビリティ

アクセシビリティは、障害のあるユーザーが製品を利用できるようにするための重要な設計上の考慮事項です。また、Google社が「次の10億人のユーザー」と呼ぶ人々（初めてテクノロジーを利用する人々）についても、アクセシビリティを考慮する必要があります。 アクセシビリティに関する主な検討事項は以下の通りです。

• スクリーン・リーダーがコンテンツや指示を解釈できるようにする
• 読みやすさを損なわないような色やコントラストにする
• すべてのユーザーがリンクやナビゲーションを理解できるよう、アイコンとテキストを組み合わせて使用すること
• 読みやすいフォントと文字サイズを使用する
• UXデザイナーは、デザインツールがアクセシビリティチェック機能を備えていないため、これらの配慮を忘れがちです。

UXPinでは、「一人、ひとりに合わせたデジタル体験を提供したい」という思いがあります。そこで、デザインエディタにアクセシビリティ機能を組み込みました。

 14日間の無料トライアルに登録して、UXPinでよりインクルーシブな製品作りを始めましょう!

その14：ユーザーがコントロールできるようにする

可能な限りユーザーが自分の考えを変えたり、送信した情報を編集したりすることが簡単にできるようにしましょう。例えば、チェックアウトフローのすべての画面に戻るボタンを用意することで、ユーザーはエラーを修正したり、変更を加えたりすることができます。

また意図的であるかどうかに関わらず、ユーザーに誤解を与えないようにしてください。

多くの企業ではユーザーが定期購入をキャンセルできないように設定でオプションを隠したり、サポートに連絡するように仕向けたりしています（サポートでは通常、定期購入を継続するためのインセンティブを提供しようとします）。

ユーザーが考えを変えたり情報を編集したりする手段を制限することはブランドへの不信感を生み、お客様に他の解決策を探させることになります。

その15：デザインハンドオフ

デザインの受け渡しは社内のプロセスですが、デザインの受け渡しがうまくいかないと不必要な遅延や技術的なエラーが発生し、ユーザーに悪影響を及ぼします。

UXチーム、プロダクトデザイナー、開発者が協力してプロセスとプロトコルを開発し、デザインハンドオフを最小限のエラーでスムーズに行う必要があります。 UXPin Mergeは、デザインと開発の間のギャップを埋めるのに役立ちます。

まず第一に、Mergeはデザイナーがコンポーネントをリポジトリと同期させることができるので（GitまたはStorybookの統合を介して）、デザインチームは完全に機能する高忠実度プロトタイプを構築することができます。

また、UXPinのSpec Modeは、開発者がデザインの詳細情報を得るための簡単なハンドオフプロセスを提供します。

• プロパティの検査：サイズ、グリッド、カラー、タイポグラフィなど、要素やコンポーネントのCSSを取得できます。
• 距離の測定：要素にカーソルを合わせると、要素とキャンバスの端の間の距離が表示されます。
• スタイルガイド：製品のデザインシステムの概要と、必要に応じてアセットをダウンロードするオプションを表示します。

UXPin Mergeのパワーと、React用のGit統合や他の人気フロントエンドライブラリ用のStorybookなど、お好みのテクノロジーを接続する方法をご紹介します。

その16：再評価と修正

UXデザインの素晴らしい点の1つは、製品やユーザーエクスペリエンスを継続的に改善できるよう、常に進化し続けていることです。 新しい製品やリリースを開始するとデータを分析し、デザインを見直す作業が始まります。

• 何千人、何百万人もの人々が製品を使用したとき、製品のパフォーマンスはどうなるのか？
• ユーザーは意図したとおりに製品を使っているのか？
• ユーザーは、ユーザー体験を向上させるための近道を使っているか？
• ヒートマップはユーザーの行動について何を教えてくれるのか？
• サインアップやチェックアウトの際、ユーザーはどこで脱落するのか？

製品のパフォーマンスを分析する際、チームは常にユーザー・エクスペリエンスを向上させる方法を模索するとともに、ビジネス価値を高めるための道筋を探るべきです。

まとめ

今回ご紹介した16の UXデザイン原則 はワークフローを改善し、ユーザーにとってより良い製品体験を生み出すために活用していただけると幸いです。これは決して網羅的なリストではありませんので、常にプロセスを改善する方法を模索することをお勧めします。

UXPinは、企業の健全な UXデザイン原則 を育むためのコラボレーションデザインツールです。UXPinはデザイナー、製品チーム、開発者の間のギャップをうまく埋め、UXデザインプロセスのあらゆる側面を改善することができる唯一のデザインツールです。

UXPinで新しいデザインの世界を探求するために、14日間の無料トライアルを始めてみませんか？

The post UXデザイン原則 – ユーザーが喜ぶための法則 appeared first on Studio by UXPin.

UXの世界は常に成長し、進化し続けていおり、特定のタスクや研究に対応するための新しいUXでの役割または部門が生まれています。 

UXアーキテクトとUXデザイナーは何が違うのか？また、デザインプロセスを改善するために、会社ではこの2つのポジションを満たす必要があるのでしょうか？

ここでは、UXアーキテクトの仕事内容や、UXデザイナーとUXアーキテクトの役割や責任の違い、重複する部分などをご紹介します。この記事の最後に、UXチームが効果的にコラボレーションするためにUXPinがどのように役立つのかを簡単に説明します。

UXPinは、UXデザイナーとUXアーキテクトがより良い製品体験をデザインするためのコラボレーションツールです。UXPinの14日間無料トライアルに今すぐお申し込みください！

UXアーキテクトとは？

ユーザー・エクスペリエンス・アーキテクトとは、基本的に、製品やデザインをハイレベルな視点で見ることができるUXのスペシャリストです。UXアーキテクトは、ユーザーや市場の綿密な調査に基づいて、構造や流れに関心を持ちます。

そのために、UXアーキテクトはリサーチチームと密接に連携したり、自らリサーチを行うこともあります。このリサーチによって、UXアーキテクトは、ユーザーが製品をどのように使用するかについて十分な情報を得た上で判断し、それに基づいて情報アーキテクチャを構成します。

UXアーキテクトの責任を簡単に説明します：

• 製品がユーザーのニーズを満たすようにする
• 情報が整理され、簡単にアクセスできるようにする
• ユーザビリティやアクセシビリティの問題を解決する

コンテンツの整理

UXアーキテクトは、コンテンツやアセットを作成するのではなく、ユーザーにとって最適なコンテンツを整理して配置します。この整理は3つのカテゴリーに分類されます：

• コンテンツインベントリ—製品に含まれるすべてのデジタルコンテンツのリスト。
• コンテンツのグループ化—製品のコンテンツを整理するための論理的な構造で、異なる情報の関係性やそれらがどのようにつながっているかを定義します。
• コンテンツ監査—製品のコンテンツを定期的に見直し、更新が必要なものや新しいコンテンツが必要かどうかを判断すること。

UXアーキテクトは、各ページのコンテンツを整理し、タイトル、小見出し、リンク、ナビゲーションをどこに追加するかを決定し、ユーザーが探しているものを見つけやすくする必要があります。

階層構造、サイトマップ、ナビゲーション

情報アーキテクチャとは、製品やウェブサイトの階層、サイトマップ、ナビゲーションなどを整理するものです。これらの重要な要素が、アプリやウェブサイトの使いやすさやアクセスのしやすさを決定します。

• サイトマップ – アプリやWebサイトの全てのページのこと。
• 階層 – ページのコンテンツを重要度の高い順に並べる方法。
• ナビゲーション – ユーザーがアプリやWebサイト内をどのように移動するかを示すもの。

社内でのワイヤーフレーム作成とローフィデリティプロトタイピング

UXアーキテクトは、社内のUXチームが製品やWebサイトをデザインする際の参考資料として、ワイヤーフレームやローフィデリティプロトタイプを作成します。

UXチームはこれらのモックアップをデザインのためだけに使用し、通常はユーザビリティスタディやステークホルダー間での共有には使用しません。

UXデザイナーとは？

UXデザイナーとは、デザインとリサーチの役割を包括する幅広い用語です。しかし、UXデザイナーとUXアーキテクトの比較では、デザイナーはユーザーインターフェースの設計を担当します。最終的に、UXデザイナーは製品を使いやすくします。

UXデザイナーは、UXアーキテクトが作成したワイヤーフレーム、プロトタイプ、アーキテクチャーの指示を受けて、それを実際の製品に仕上げます。また、UXデザイナーはUXリサーチャーと協力して、どのようなフォント、色、ボタン、その他のデザイン要素を使用するかを決定します。

ペルソナ開発

UXデザイナーは、初期のリサーチとユーザーペルソナの作成を担当します。大規模な組織では、専任のユーザーリサーチャーやチームがいるかもしれませんが、UXデザインの役割を果たしていることに変わりはありません。

ユーザーペルソナは、ユーザーの属性情報、動機、欲求、潜在的な反応などをUXデザイナーに伝え、これらのユーザーニーズに対応したユーザーインターフェースを設計します。

ワイヤーフレーム、モックアップ、プロトタイプ

UXデザイナーは、初期のユーザーリサーチとUXアーキテクトの情報アーキテクチャをもとに、製品のページやフローのワイヤーフレームやモックアップを作成します。

研究チームは、これらのハイフィデリティ・プロトタイプを使用してユーザビリティ・スタディを行い、ユーザーが最終製品をどのように操作するかを学びます。

ユーザーテスト

専門のリサーチチームを持たない企業では、UXデザイナーが必要なユーザビリティ・スタディを行います。UXデザインの重要な部分であるこのテストは、ユーザーが最終製品をどのように操作するかについて、UXデザイナーに貴重なフィードバックをもたらします。

UXデザイナーは、ユーザビリティスタディの結果をもとに、ユーザーエクスペリエンスを向上させるためにデザインを調整します。

UXアーキテクトとUXデザイナーの主な相違点

UXアーキテクトとUXデザイナーの最も大きな違いは、UXアーキテクトは大局的に見るのに対し、UXデザイナーは細部にこだわることです。

UXアーキテクトはナビゲーションやユーザーフローを重視し、UXデザイナーは各画面やページのユーザーインターフェースやインタラクションを作成します。

UXアーキテクトもUXデザイナーもリサーチを行いますが、UXアーキテクトはユーザーがどのような機能やコンテンツを必要としているかを考えます。一方、UXデザイナーは、ユーザーがこれらの要素をどのように操作するのかを知りたいと考えています。

UXアーキテクトとUXデザイナーの役割をまとめると、以下のようになります。

• UXアーキテクト – ユーザーは誰で、何を必要としているのか？
• UXデザイナー – ユーザーは誰で、そのニーズをどのように満たすのか？

UXアーキテクトとUXデザイナーの連携について

多くの企業、特に中小企業では、UXデザイナーがUXアーキテクトの役割を担っていることに注意する必要があります。

これらの役割が分かれている場合、UXデザイナーはインターフェイスとインタラクションに焦点を当てるため、しばしばUIデザイナー（ユーザーインターフェイスデザイナー）と呼ばれます。

UXアーキテクトは、デザインに焦点を当てるのではなく、情報アーキテクチャに特化したUXのスペシャリストです。

UXアーキテクトとUXデザイナーは、コンテンツに関して緊密に連携します。UXデザイナーはコンテンツの詳細に焦点を当て、UXアーキテクトはコンテンツをどのように構成するかを決定します。このことを正しく理解するためには、デザイナーとアーキテクトが密接に協力する必要があります。

UXアーキテクトとUXデザイナーの典型的なワークフロー

以下のワークフローは、UXアーキテクトとUXデザイナーの責任の分担を示す大まかな概要です。

1. プロジェクトは、建築家が物理的な構造物を設計するのと同じように、UXアーキテクトが市場やユーザーリサーチを分析し、プロジェクトに必要なものやコンテンツの構成を決定することから始まります。
2. UXアーキテクトは、UXデザイナーが構築プロセスを開始するための青写真（ワイヤーフレームとプロトタイプ）を作成します。
3. UXデザイナーは、ユーザーリサーチとUXアーキテクトの設計図を分析し、各ユーザーインターフェースのデザインを開始します。
4. UXデザイナーは、ステークホルダーやユーザビリティ・スタディのために、ワイヤーフレーム、モックアップ、ハイフィデリティ・プロトタイプを作成します。
5. ユーザビリティスタディでは、UXアーキテクトは、ユーザーがどのようにコンテンツにアクセスし、製品内を移動するのかを知りたいと考えています。UXデザイナーは、ユーザーが各画面上の要素やコンテンツをどのように操作するのかを確認します。
6. 製品が発売されると、UXアーキテクトの仕事は、正確で最新のコンテンツを確保することです。また、アクセシビリティの問題にも目を配り、適宜アップデートを提案します。UXデザイナーは、UXアーキテクトの提案を受け、インタラクションデータを分析して、各画面を最適化し、ユーザーに最適なサービスを提供します。

あなたの会社には、UXアーキテクトとUXデザイナーが必要ですか？

UX/UIデザイナーとUXアーキテクトの役割を分けることで、製品やWebサイトの品質と効率を向上させることができます。

小規模なプロジェクトや資金力のあるスタートアップでは、専任のUXアーキテクトに十分な仕事がないかもしれません。ここで重要なのは、UXデザイナーがUXアーキテクトの役割を果たすことができるということです。

プロジェクトの規模が大きくなると、情報アーキテクチャが複雑になり、管理に時間がかかるようになります。このような場合、プロジェクトの成功にはUXアーキテクトの存在が欠かせません。

代理店は一般的に少人数のチームで仕事をしていますが、クライアントのために複数のアプリやWebサイトを制作することも少なくありません。UXアーキテクトがいれば、UXデザイナーに必要な情報を伝え、すぐに構築を開始できるので、生産性の向上につながり、技術的な生産ラインを作ることができます。

企業は、UXアーキテクトが必要かどうかを判断するために、いくつかの質問をしてみましょう:

• UXデザイナーはレイアウトや情報アーキテクチャの構築にどのくらいの時間を費やしているのでしょうか？
• これらの作業は制作の遅延を引き起こすのでしょうか？
• ユーザビリティ調査において、ユーザーはナビゲーションの問題で苦労することが多いですか？
• 品質と効率の向上から得られる利益に比べて、専任のUXアーキテクトのコストはどのくらいですか？
• 御社の製品では、ユーザビリティやアクセシビリティの問題が頻繁に発生しますか？
• 誰かが製品のコンテンツを監視していますか？古いコンテンツや使用されていない製品機能を定期的に見つけていますか？

UXPinがUXチームの生産性を向上させ UXPinは、UXチームが共同でより良い製品を作るための強力なデザインツールです。UXアーキテクトはUXPinを使用してレイアウト、ワイヤーフレーム、ローファイプロトタイプを作成し、ガイダンスとコンテキストのためのコメントを付けることができます。

UXデザイナーは、これらの情報をもとに、美しい画面やインターフェースを設計し、モックアップを作成して関係者に提示したり、ユーザビリティ・スタディに使用したりすることができます。

14日間の無料トライアルを提供

14日間の無料トライアルでは、UXチームが効果的にコラボレーションし、顧客のためにより良い製品を作るためにUXPinがどのように役立つかをご覧いただけます。ぜひコードベースデザインの世界をご体験ください！

The post UXアーキテクト とUXデザイナー、その違いは？ appeared first on Studio by UXPin.

Storybookではデザイナーと開発者がプロトタイプを構築する際に、コードコンポーネントを使用することで、サイロ化を解消しUIの一貫性を向上させることができます。（詳しくは「画期的なStorybookの魅力」に関するこちらのブログをご覧ください）

当社のMergeテクノロジーをベースにしたこの連携により、コードの力を利用して高度なプロトタイプを迅速に構築し、デザイナーも開発者も同じコンポーネントを使って製品を作ることが可能になりました。これにより、ハンドオフプロセスの複雑さを大幅に軽減することができます。

 Product Hunt にもStorybook 連携に関して載せておりますので、ぜひご覧ください！

製品チームが信頼できる唯一の情報源を必要とする理由

製品開発における信頼できる唯一の情報源 とは、製品を設計・製造するために必要なすべてのドキュメントや要素を保管する1つの場所のことです。理想では、信頼できる唯一の情報源 は簡単に共有、常に最新の状態、プロセスに関わるすべての人が使用できることです。

 デザインシステムは、製品チーム間で情報がバラバラになってしまうという問題を解決するはずでした。デザインシステムはUIやドキュメントをシステム化するための素晴らしい第一歩ではありますが、それだけではデザインと開発の作業において完璧には解決できないこともあります。

そこで、Mergeという革新的なテクノロジーが誕生しました。製品チームは、GitリポジトリやStorybookなどの開発ツールを活用して、DesignOpsプロセスを改善し、デザインとコードの同等性を維持することができます。その結果、デザイナーも開発者も同じUI要素、ドキュメント、コードを1つのソースから使用することができます。

開発ライブラリからコードベースの完全なインタラクティブコンポーネントを取り出し、キャンバスにドラッグ＆ドロップするだけで、デザインエディタで使用できることを想像してみてください。これが非常にエキサイティングな理由です:

もう 「あのコンポーネントはどこだっけ？」と悩むことはありません。

パズルのピースが散らばっているのと同じように、製品開発に必要なピースを探して作り上げることは、かなりの時間がかかります。コンポーネントやドキュメントを常に最新の状態に保つのは本当に大変なことです。しかし、すべての情報を１つに保管する場所があれば、正しいバージョンのコンポーネントやそのコードを探す必要はありません。

開発者用のライブラリからデザインエディタにUI要素を持ってくると、1つの場所でメンテナンスするだけでよく、ライブラリも自動的に同期されます。

デザイナーと開発者が共通のテクノロジーを使用

デザイナーが作成・開発者が作成したものの間で起こる問題の原因はそれぞれが異なるテクノロジーを使って仕事をしているということです。デザインツールは一般的にベクターやピクセルを使っているのに対し、アプリやウェブサイトは特定のプログラミング言語やフレームワークを使っています。

ベクトルやピクセルを使った手法は非常に限られたもので、最終製品を単純にイメージにしたものに過ぎません。例えば、プロトタイプに実際に動いたりなどの高度なインタラクションを追加したい場合、ベクターやピクセルでは変数や条件付きロジック、あるいは単純な入力フィールドを扱うことができないため、必ずしもそれが作れるとは限りません。しかし、開発者がUIコンポーネントにコードを使用すると、これらの障害はなくなります。

もし、デザイナーがコードに反映されるようなコードパワーのあるテクノロジーを使ってプロトタイプを作ることができれば、デザイナーと開発者は共通の言語でコミュニケーション、作業ができるのです。つまり、2つの異なる環境でUI要素を作成するのではなく、まったく同じ環境を使用することで、製品制作をスムーズにさせます。

10倍の成果

製品をデザインする際には、ユーザーがクリックしたときに何が起きてどのように動くのかを開発者に説明する必要があります。また、すべてのインタラクションを使用して製品の動きをより上手く説明するために、高再現性なプロトタイプを作成することもできます。通常だと、高度なプロトタイプの作成には多くの時間がかかり、詳細を正確に把握するためには、インタラクションやプロトタイプの機能性についてコメントで長い会話をする必要があります。

この流れはデザインオペレーションの観点から言うと、決して効率的なワークフローとは言えません。しかし、コード化されたUIコンポーネントをデザインエディターで使用することにした場合、デザインプロセス全体が決定的にスピードアップします。

完全にインタラクティブで、すべての制作基準に沿った要素を使って作業すると、従来の方法でプロトタイプを作るのに比べて、10倍以上のデザインにおいての成果が得られます。  節約できた時間をユーザーテストなど他の重要なことに回して、費やすことができます。

ユーザーテストの特典：最終製品と同じように動作するプロトタイプ

すべてのUIパーツが完全にインタラクティブでない場合、どうやってプロトタイプをテストする方法としてユーザーテストがあります。しかし、ユーザーテストでは、ユーザーが自身でクリックし、プロジェクトを進めることができなければ十分な信頼性が得られません。アコーディオンをクリックしたり、メニューにマウスを置いたりすると何が起こるかを説明しても、それを見せるのと同じ品質のフィードバックは得られません。

コードで作られたプロトタイプが最終製品とまったく同じように動作するようになれば、ユーザビリティテストで完全に没入感のある体験を提供して、リサーチチームをサポートすることができます。

コードでデザインする  Storybookの連携を試す

Storybook は、開発者がUIコンポーネントを構築し、保存するための唯一の場所です。また、要素をテストしたり、明確なドキュメントを作成するのにも最適なツールです。Storybookは、React、Angular、Vueなどの人気の高いフレームワークを含む多くのフレームワークをサポートしています。

UXPinで Storybook連携 

Storybook は、Merge 技術を使用してコード化されたコンポーネントをデザインツール UXPin と同期させる 2 つの連携のうちの 1 つです（Git repo が最初の連携です）。Storybookとの連携は約1分で完了し、コード化されたコンポーネントを使ってすぐにデザインすることができます。

プライベートまたはパブリック？

あなたのStorybookライブラリは、プライベート（あなたのサーバーにホストされ、選ばれたユーザーだけがアクセスできる）と、URLを知っている人が自由にアクセスできるパブリックのいずれかにすることができます。私たちの統合は両方のタイプをサポートしているので、どちらを使用するかは問題ではありません。

パブリックのライブラリでは、ストーリーブックのURLをコピー＆ペーストするだけで簡単に利用できます。プライベートライブラリでは、開発者は2つの簡単なコマンドを実行するだけです。プライベートライブラリをお試しになりたい場合は、ガイドツアーをご利用ください。

既にお持ちで、他社のパブリックライブラリを使用されたい場合は、オープンソースのStorybookのサンプルをお楽しみください。

コードで自由にデザイン

同期されたコンポーネントはコード化されているので、デザイナーは開発者の手を借りずに、UXPinエディタ内でプロパティ、入力、スタイルを自由に変更することができます。また、コードに埋め込まれた制約は、スタイルにミスマッチがないようにガイドしてくれます。

ノンデザイナーに権限を与え、より良いDesignOpsを実現する

コードを使ってデザインすることで、DesignOpsプロセスを再定義することができます。PayPalは、製品開発のデザインフェーズを変革することで、デザイナー以外の役割を持つ人々がUXPinのコード・コンポーネントを使ってアイデアを視覚化できるようにした素晴らしい例です。PayPalのErica様と彼女のチームはMergeとGit の連携を使用していますが、Storybookを活用しても同様の結果を得ることができます。

デザイナー以外の人は、コンポーネントをキャンバスにドラッグ＆ドロップして、必要に応じてコントロールを操作するだけなので簡単です。その後、デザインドラフトをもとにUIの専門家がプロジェクトを仕上げ、ユーザビリティに焦点を当てることができます。

コードの力を味わう

登録して、Storybookから直接コンポーネントが提供されている内蔵のマテリアルUIライブラリを試してみたり、ご自身で新しいライブラリを同期させたりすることができます。コードの力を実感し、信頼できる唯一の情報源を使用することで、製品チーム全体がどのようなメリットを得られるかをご覧ください。

The post Storybook連携を試してみましょう appeared first on Studio by UXPin.

UXデザインの仕事を獲得するには、 ポートフォリオ の質が重要になります。uxfolioのような企業がオンライン ポートフォリオ 作成のためのソリューションを専門に提供しているほど、 ポートフォリオ は採用プロセスの重要な一部となっています。

しかし、どのようなツールを使ってポートフォリオを作成しても、プロジェクトマネージャーに優れたデザインを見せることができなければ、仕事を獲得することはできません。ポートフォリオのプレゼンテーションの質よりも、UXデザインの質の方が重要視されますが、プレゼンテーションを自分のスキルの例として使うことはできます。

残念ながら、自分のUX ポートフォリオ を客観的に見ることはほとんど不可能と言えるでしょう。レビューを受けることで、自分のポートフォリオの強みと弱みを簡単に把握することができるはずです。いくつかの視点が得られれば、自分のスキルや才能を示すUXデザインのセレクションをまとめることができます。

UXPinでは、進行中の作品や完成したプロトタイプを簡単に共有することができ、必要なフィードバックを得ることができます。

UXPinの無料アカウントを作成すれば、誰とでもプレビューを通じて作品を共有し、レビューを受けることができます。

UXデザインを共有し、他の人からポートフォリオのフィードバックをもらう

UXデザインの ポートフォリオ を誰かに送っても、必ずしも有意義なフィードバックが得られるとは限りません。たとえレビュアーがあなたのポートフォリオの完成度を高めるために多大な努力をしてくれたとしても、結局はあまり役に立たない情報になってしまう可能性があります。

その難しさの多くは、人々のオンラインでのコミュニケーション方法にあります。ほとんどのUXデザイン、プロトタイプ、ポートフォリオでは、レビュアーは作品に直接意見を書き込むことができません。その代わりに、メールなどで意見を送ってもらいますが、その際には自分が確認したい機能と、それをどのように改善できるかを説明してもらいます。

ビジュアルメディアでは、デザインに直接レビューを残せる機能が必要です。

UXPinでは、メンターや同僚がワークスペース内でリアルタイムにコミュニケーションを取ることができるので、より洞察力のあるUXポートフォリオレビューを得ることができます。右上隅付近にある青いアイコンは、クリックすると何が起こるのかユーザーに伝わっていないのではないでしょうか」というようなことを書く代わりに、アイコンの近くに「これは分かりにくいアイコンですね。機能をもっとわかりやすくしてみてください」というコメントをアイコンの近くに置くことができます。

また、デザインや完全に機能するプロトタイプを共有できるため、UXポートフォリオレビューの質も向上します。プロトタイプレビューが実際の情報や機能に基づいていれば、人々はLorem ipsumや偽のデータに気を取られることなく、正確なアドバイスをすることができます。

おすすめの記事: How collaboration makes you a better designer

Spec Modeを使って、素晴らしいデザインアイデアを実現する

UXPinのSpec Modeでは、あなたのデザインにアクセスして、劇的な結果につながる微妙な変更を加えることができます。例えば、メニューを少し左にずらすことで、ユーザーにアピールできるバランスになるかもしれません。また、無理に多くの機能を盛り込もうとすると、UXを向上させるためにもドロップダウンメニューの追加を検討する必要があります。

また、Spec Modeのデザインを開発者と共有し、静的なデザインをデジタル製品に変換する人たちからポートフォリオレビューを受けることもできます。あなたのUXデザインが、開発チームに無理な期待をさせていることがわかるかもしれません。一方で、あなたの作品からCSSコードを生成する能力を評価する開発者からは、賞賛の声が寄せられるかもしれません。UXPinは、あなたのグラフィックから自動的にコードを生成することで、2番目の部分をシンプルにします。

 UXPinの無料トライアルを開始すると、Spec Modeでのレビュアーとの共同作業のメリットを実感できます。

おすすめの記事:２０２３年版 UX / UI デザイン の最新 トレンド １０選

コンセプトを表現する完全な機能を持つプロトタイプを作る

完全に機能するプロトタイプを共有できなければ、最も深いレベルの洞察を得られるポートフォリオレビューを受けることはできません。UXPinはあなたのUXデザインからプロトタイプを生成し、同僚やメンターと共有することができます。

理想的には、機能するプロトタイプを送ることで、現実的なフィードバックを得ることができます。静的なデザインは素晴らしく見えるかもしれません。しかし、それがインタラクティブな機能になることを計画しているのであれば、あなたが期待する機能をレビュアーに体験してもらう必要があります。そうしないと、作品の間違った側面に対するフィードバックを得ることになります。

確かに、優れたデザインは採用担当者やプロジェクトマネージャーを惹きつけるのに役立ちます。しかし、実際に意図したとおりに機能するデザイン機能は、より多くの注目を集め、他の応募者と差をつけることができます。

プロトタイプで機能をテストしてみると、一見すると問題なく機能しているように見えるかもしれません。しかし、その機能が何をすべきかについてのあなたの期待は、あなたの判断を曇らせてしまいます。先入観のない客観的なレビュアーは、新しいユーザーとしてプロトタイプの機能にアプローチすることができます。もし何かが直感的に感じられなければ、改善すべき点を指摘することができます。

おすすめの記事: クリッカブル ・プロトタイプの作成方法

UXPinを使って作品の作成と共有を始める

UXPinでUXポートフォリオを共有することで、あなたの能力をより強く表現するための率直なフィードバックを簡単に得ることができます。UXPinのアカウントを作成すると、誰でもフィードバックやデザインの微調整、反復作業に招待することができます。UXPinアカウントがなくても、フィードバックしてくれる人はいます。UXPinのアカウントは必要ありませんが、正しいリンクを渡しておけば、あなたの成功に貢献してくれます。

今すぐUXPinの無料トライアルを開始して、誰とでも共有できる完全な機能を持つUXプロトタイプを作成しましょう。UXPinはあなたのキャリアに関係なく、あなたのニーズと収入に合ったメンバーシップレベルを提供します。

The post UXの質を高める ポートフォリオ レビュー appeared first on Studio by UXPin.

Whitespaceと共同で、数百人の技術者を対象とした「How to Overcome Challenges of Scaling a Design System ?（デザインシステムを拡張する際の課題を克服するには）」というウェビナーが開催し、DesignOpsとプロダクトデザインリーダーシップのエキスパートであるデイブ・マルーフ氏の司会で、多国籍企業２社から以下のスピーカーにご参加頂きました：

• ライアン・ケイン氏：Weir GroupのUXデザイン責任者
• ジュリアン・ヴァニエール氏：Sage社のシニアデザインシステムディレクター

このウェビナーでは、メンテナンス、スケーリング、ガバナンスを含むデザインシステムにおいての２つの 大企業 の取り組みについて、興味深いインサイトが得られました。本記事ではウェビナーでの内容をまとめたものです。 大企業 におけるデザインシステムの活用方法や その ベストプラクティス をご紹介します。

UXPin Mergeで、デザインシステムの成熟と「信頼できる唯一の情報源（Single source of truth）」を達成しませんか。詳細とアクセス権の申請方法については、Mergeのページをぜひご覧ください。

 デザインシステム の利点

ウェビナーに入る前に、まずはデザインシステムの利点に着目したいと思います：

• 一貫性および整合性の向上：デザインシステムは、統一されたビジュアルデザイン言語と機能を確立し、それによって製品およびプラットフォーム間で一貫したUX（ユーザーエクスペリエンス）が保証される。
• 連携と連絡の強化：デザインシステムが「信頼できる唯一の情報源」として機能することによって、デザイナー、デベロッパー、ステークホルダーのチームワークが高まり、それによってハンドオフの効率化や、ミスコミュニケーションの減少が促される。
• デザインおよび開発プロセスの迅速化：：デザインシステム内の再利用可能なコンポーネントとガイドラインにより、チームのワークフローが速まり、それによって個々の要素のデザインやコーディングに費やされる時間が短縮される。
• 拡張性および整備性：デザインシステムは適応性のために構築されており、それによってプロダクトチームは一貫性と使いやすさを保ちながら、製品の更新、拡張、整備がしやすくなっている。
• より良いUXと製品品質：デザインシステムは、デザインに対する構造的なアプローチを提供することで、ユーザーのニーズと期待に応える洗練された高品質の UX の提供を支援する。

上記のメリットに関連する課題が組織でありますか？次のステップは、ビジネスケースの構築です。以下では、Sage社とWeir Groupのチームが、デザインシステムのための資金とリソースを確保する方法を見ていきます。

 デザインシステム のための資金・リソースの獲得と維持

１．Weir Groupにおける大規模な連携デザインチームのケース構築

多くのデザインチームが連携している 大企業 である Weir Group に勤めるライアン・ケイン氏は、デザインシステムによって実現される効率的な節約は、資金調達の説得材料になると主張しています。

さまざまなプロジェクト間で部品の再構築や再デザインを行う冗長性を回避することで、会社は大幅なリソース削減を実現できるのです。

また、ライアンは、コード化されたコンポーネントとデザインされたコンポーネントのレンズを通してこの「節約」を説明し、ローコードやノーコードのソリューションに依存するチームに対応するデザイン言語システムについて、より広い範囲で検討します。

この幅広いアプローチにより、開発手法に関わらず、全チームが時間短縮、一貫性、信頼、そして整合性のある製品体験のメリットを受けられるようになるのです。

Weir Groupの戦略は、構成上のニーズに合わせて ReactとReact Native のコンポーネントの軽量版を作成する点に魅力があります。またそれは、直接開発に携わってはいないけれど、購入および設定されたソリューションを使うチームにも、デザインシステムのメリットを広げています。

そして、大規模な組織では、SalesforceやSAPなどのシステムを含むさまざまな技術スタックがさらに複雑になり、適応性の高いデザインシステムの必要性がさらに高まります。

２．デイブ・マルーフ氏によるクリエイティブなアプローチ

デイブ・マルーフ氏は、Northwestern Mutual社における自身のチームが、デザインシステムの資金を獲得するための基礎的な議論として、アクセシビリティをどのように利用したかを説明しました。彼のチームは法務と連携し、組織はアクセシビリティをデザインシステムに組み込んで、法域によっては罰金や訴訟の可能性がある規制上の課題を回避できることを実証しました。

彼の例では、デザインシステムやその他の UX のイニシアチブのケースを構築するには、チームが製品や業界の状況を総合的に評価する必要があることが示されています。

３．Sageの体験から学ぶ

Sage 社でのジュリアン・ヴァニエール氏の経験は少し異なります。彼のチームは、以前Intuit社でデザインシステムを構築したマネージャーからの経験・知識に基づいてデザインシステムを積極的に開始しました。各ステップを検証する必要はありませんでしたが、代わりに導入や実際の制約事項に焦点を当てました。

ヴァニエール氏のチームは、コンポーネントよりもパターンに焦点を当て、それが大きな違いを生むと見ています。Sage社のグローバルで多様な製品は、人事ソフトウェア、ERP（企業資源計画）、会計ソフトウェアなどへの注力を後押ししており、同社は完全な一貫性よりも、製品およびニーズに対応したシームレスなエクスペリエンスを目指しています。

デザインシステムのための資金とリソースを確保および維持の鍵は、組織固有の状況によって変わってくるのです。

コストや効率の削減、拡張性、多様な製品や地域にわたってシームレスな UX を提供する能力を実証することで、説得力のある事例を作ることができます。よりインクルーシブで包括的なデザインシステムのためには、パターンを超え思考や、より大きなデザイン言語の配慮が極めて重要です。

開発プロセスをより効率的に

ジュリアン・ヴァニエール氏は、Sage社がどのように デザインシステム の取り組みを構成しているかについてのインサイトを示し、アクセシビリティを重視することの重要性を強調しています。そして彼のチームは、５人の UX/UIデザイナーとアクセシビリティデザイナーを中心に、さまざまな役割で構成されています。

ジュリアンは、アクセシビリティへの取り組みを推進し、それがデザインシステムに新たな一面を加えています。また彼は、チームにアクセシビリティデザイナーがいることが、製品が全ユーザーにとってアクセスできるものであるのを保証するのに非常に重要であると述べています。このアクセシビリティは、地域やユーザーのニーズに関係なく、シームレスなUXの実現に不可欠なのです。

４．デベロッパーは、デザイン決めよりも構築に集中したい

ジュリアンによると、Sage社のデベロッパーは機能の構築に最も関心があり、通常はアクセシビリティの修正やデザインの決定には時間をかけたくないようです。デベロッパーのこのような傾向から、そういったことを効率的に処理できるデザインシステムチームへに対してのコストを正当に充てがうことができ、このように責任を分離することで、デベロッパーは自分たちの得意分野である機能構築に集中することができるようになります。

また、彼のチームは、各チーム内に「アクセシビリティチャンピオン」というアプローチを採用しました。この「アクセシビリティチャンピオン」というのは、その知識と専門性を活かして組織の他のメンバーを指導し、アクセシビリティのために全員が何をしなければならないかを明らかにする人のことを言います。

５．デベロッパーが開発に集中できる デザインシステム とは？

デザインシステムは、ガイドラインやコンポーネントを提供することで、デザインの決定やアクセシビリティよりも機能の構築に集中したいという開発チームの要望を促進することができ、その統一されたデザイン言語で、開発プロセスは効率化され、様々なプロジェクトや製品間の一貫性は保証されます。

また、Sage社のアクセシビリティ・チャンピオンのような役割を担うことで、アクセシビリティのようなデザイン上の考慮事項に関する知識や専門知識をデザインチームに効率的に分散させることができ、より集中的で効率的な開発プロセスが実現され、デザイン専任チームによる費用対効果が強化されます。

厳しい状況における、いい仕事の維持

 Weir Groupは、企業機能がその上にある各事業から成る「連携構造」になっており、各事業では同じデザイン言語が使われますが、戦略や予算については個々に委ねられています。

また、デザイン言語は企業レベルで管理されますが、ライアンは、デザイン言語を本当に「所有」している人はおらず、それはそのコミュニティ全体が責任を担っていると強調しています。

６．多くのデザイン組織が直面する課題

企業レベルでのいわゆる「オーナーシップ」の理論的根拠は、責任を過剰に背負わないような専用のリソースを持つことにあります。多くの企業では、デザインチームは、製品やプロジェクトにデザインを提供すると同時に、デザイン言語の維持および成長という二重の負担を負うことが多く、リソースがひっ迫すると、必然的にデザイン言語の維持は優先されなくなってしまいます。

次回のウェビナーにぜひご参加ください： Strategies for Building a Resilient DesignOps Practice（無料ウェビナーのご案内： 復旧力のあるDesignOpsプラクティス構築の戦略）.

７．責任の分散および共有

この優先順位の低下を補うために、ライアンのチームは「デザイン作業」と「デザインシステムの維持」を分けており、実践的なデザイン作業は連携した事業者が行い、デザインシステムの維持や成長は中央のデザインシステムチームが管理するようになっています。

このように責任を分担することで、組織のデザインチームは製品やデザインプロジェクトに集中でき、コーポレートチームはデザインシステムの成熟度とメンテナンスの管理が確実にできるのです。

８． デザインシステム は決して完成されたものではない

 Weir Groupは、そのガバナンスのために「貢献モデル」を採用しており、「デザインシステムは進化するものであり、決して完成されたものであってはならない」と認識しています。

また、連携する企業のデザインチームには、ライブラリでは対応できない新たなユースケースに基づいて、新しいコンポーネントをデザインし開発する権限が与えられており、各チームは、そのようなコンポーネントを UXPin Mergeを通じて、GitHubのリリースと同様に中央のライブラリに還元します。

このアプローチには以下のように複数の利点があります：

• チームが単独の中央ライブラリに貢献できるようにすることで、作業の重複がなくなる。
• 共有リソースに貢献するビジネス全体で力を発揮するチームと共に、すべてを統括する企業機能によって効率性が促進される。
• リソースが限られている場合でも、デザインシステムの維持と成長が保証される。

UXPin Mergeによる デザインシステム の構築、拡張、成熟、および配布

Weir Groupでは、連携するデザインチームのための「信頼できる唯一の情報源（Single source of truth）」として UXPin Merge が使われています。ライアン・ケイン氏のチームは、UXPin Merge のバージョン管理機能を利用して、組織全体に変更を同期しており、従来のDesignOpsチームにとって複雑なタスクが、UXPin Merge によって完全に自動化されました。

「UXPin Mergeによって、重複がなくなり、権限のあるチームが単独の中央ライブラリ（デザインシステムのレポジトリ）に貢献し、企業機能がそれを管理および維持することで効率化が実現されました。」 – The Weir Groupの UXデザイン責任者、ライアン・ケイン氏。

デザインプロジェクトのデザイン、プロトタイプ作成、テストに複数のデザインツールを使っていますか？デザインシステムの変更の同期や更新でDesignOpsに苦労していませんか？

UXPin Merge で、「信頼できる唯一の情報源（Single source of truth）」を作成し、時間のかかるタスクを自動化しませんか。詳細やアクセスのリクエストは Merge のページでぜひご確認ください。

The post 大企業 が実践する デザインシステム のベストプラクティス８項目 appeared first on Studio by UXPin.

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

主なポイント：

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

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

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

Ant Design （AntD）とは

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

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

Ant Design の主な利点

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

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

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

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

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

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

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

テーマ設定

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

アクセシビリティ

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

技術スタックの互換性

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

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

Ant Design と Bootstrap

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

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

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

Ant Designで構築できるもの

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

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

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

Ant Designのデザイン言語

１．デザイン言語

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

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

２．動作の原理

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

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

３．グローバルスタイル

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

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

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

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

Ant Design のコンポーネント

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

一般的なコンポーネント

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

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

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

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

レイアウト

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

ナビゲーション

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

データ入力

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

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

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

データ表示

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

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

フィードバック

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

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

その他

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

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

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

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

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

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

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

Ant Design の npm統合

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

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

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

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

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

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

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

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

２０２１年１２月から２０２２年１月にかけて、UXPin と Whitespace は、約２０の企業レベルの組織のデザインシステムマネージャーにインタビューを行い、この調査を「Design Systems and DesignOps in the Enterprise（企業における デザインシステム とDesignOps）」と題した１万語の無料 レポート にまとめました。

 レポート は以下で無料でダウンロードできます：Design Systems and DesignOps in the Enterprise.

この記事は、本レポートの概要と、調査から学べることをまとめたものです。理想では、組織で共通のツール、文書、ガバナンスがあることが望まれますが、現状ではこれらの結果を効果的に達成できていないことがわかりました。

 レポート の目的

UXPin のチームは、組織がどのように デザインシステム を利用しているのか、そしてその利用を促進および効率化するために DesignOps がどのような役割を担っているのかを理解したいと考えていました。

このレポートを通じて、 デザインシステム に関する「組織の課題」を把握し、その課題を解決するためのツールやソリューションを明らかにしたいと考えました。

調査資料

UXPin は Whitespace と提携し、アメリカ、スイス、ドイツ、フランス、イギリス、インドネシア、オーストラリアの７カ国から１９の企業機関にインタビューを行いました。

その企業はそれぞれ、テクノロジー、ヘルスケア、輸送、小売、行政など、様々な業界へのサービスを提供しています。

インタビュー内容

各組織への取材では、以下の重要な６テーマを取り上げました：

1. これまでの デザインシステム の歩み
2.  デザインシステム の成熟度
3. ガバナンスとプロセス
4. デザイナーとデベロッパーの連携と課題
5. ロードマップとマイルストーン
6. 既存の市場調査との比較

企業の現状

デザインシステムに関する多くの企業の現状は以下のようになります：

• 「信頼できる唯一の情報源（Single source of truth）」が主な目標だが、サイロと不十分な文書によって、この理想的な成果への進歩が妨げられている
•  デザインシステム のガバナンスのサポートが欠けており、チームメンバーは自分の仕事の ROI （投資収益率）を示そうとリソースを浪費してしまう。
•  デザインシステム の導入が多くの組織で課題となっている
• デザインシステムの成熟度は組織や業界によって大きく異なり、多くの場合、リーダーシップやステークホルダーのサポートに左右される

無料ダウンロードはこちらより：Design Systems and DesignOps in the Enterprise.

各章の簡単な概要

デザインチーム

デザインチーム編では、組織構造や部門横断的な連携、そしてデザインシステム採用への影響について述べられています。

リーダーシップのサポートがあるケースでも、サイロや不十分なコミュニケーションチャネルにより、デザインシステムの導入が遅れたり大変になったりしています。そこで本レポートでは、以下のような解決策を概説しています：

• チーム間の透明性のあるコミュニケーション
• 「信頼できる唯一の情報源（Single source of truth）」の確立
• 測定可能な目標設定および、進捗確認のための KPI の設定
• 共通の目標に向けたチーム全体の責任の割り当て

デザインプロセス

デザインプロセス編では、作業標準、ハンドオフプロセス、チームの願望について見ていますが、デザイナーは新しいものを作るのを好み、デベロッパーは使い回せるだけ使い回したいということがわかりました。

多くのデザインシステムのワークフローやコンポーネントは時代遅れになっており、コンポーネントライブラリの更新、要素の追加、全体的な変更などは、企業にとって最大の懸念になっています。

もう一つの課題は、デザインハンドオフです。ほとんどの組織で、現在のデザインプロセスに対する懸念の声が聞かれましたが、より効果的にするための明確な道筋は示されていませんでした。しっかりとしたデザインシステムがあっても、デザインから開発への移行は大変であり、チームは、このハンドオフプロセスをシンプルにするためにツールを採用しますが、断片的なコミュニケーションと非効率がよく起こってしまいます。

ツール

ここでは、デザインおよび開発時に使うツールが、デザインシステムの採用や成功にどのような影響を与えるかを探ります。

多くの企業は「信頼できる唯一の情報源（Singe source of truth）」をもたらす直感的なツールが必要であると認識していますが、ツールを変えるのは、みんなの意識を変えるために時間とリソースを必要とする大変な仕事です。

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

デザインシステムを管理する上で最も大変な作業の１つは、その各部を常に最新の状態に保つことであり、ドキュメントは、デザイナーやデベロッパーが一貫した UI を提供するための労力をモデル化できるようにするための貴重なリソースになります。

組織は、適切なドキュメントなしには、製品のデザインと納品の成功はほぼあり得ないことがわかりましたが、デザインシステムのドキュメントの維持に必要な帯域は、特にリソースの少ない小規模なチームにとっては大変です。

適切なツールによって、文書化のための構造を提供しながら、デザインシステムの成熟を促進することができます。ツールについての詳細は、以下のレポートからご覧ください：Design Systems and DesignOps in the Enterprise.

デザインシステムの採用

デザインシステムの採用には、その価値と効率性をステークホルダーに理解してもらうための継続的な伝道（トレンドや新技術などをわかりやすく伝えること）とアウトリーチが必要です。

効果的な採用には、トップダウンのサポートと人事および DesignOps チームによる変更管理が必要であり、採用戦略は、組織が進捗をモニタリングし、成功したイニシアチブを特定できるように、測定できるものでないといけません。

理想的なモデル像

調査から得られた見解をもとに、理想のデザインシステムモデルのビジョンをまとめました。理想的なデザインシステムの枠組みは組織によって異なりますが、明確に共通しているのは、「より良い製品開発のための、より効果的なワークフローの構築 」でした。

組織は、以下のような目的達成のために、デザインシステムを導入します：

• 効率性を高め、要素やコンポーネントを複製する機能を使用した、大規模なデザインおよび開発作業の作成
• デザインリソースへの負担の軽減
• 統一されたデザイン言語の作成
• 製品、チャネル、部門を超えたビジュアルの一貫性の創出
• 明確な基準、プロセス、ドキュメントを備えたオンボーディングツールとしての提供

 レポート の活用法

この調査は、製品開発およびデザインシステムに関して、企業が同じような問題を抱えていることが示されています。なのでこの調査結果を共有することで、他の企業が同じような課題をどのように解決したか（あるいは解決する予定か）に基づき、企業が解決策をモデル化できるよう、また、デザインシステムの成熟度や製品デザインの未来をめぐる議論につながるよう期待しています。

 レポート を無料ダウンロードできます：Design Systems and DesignOps in the Enterprise.

The post 企業のデザインシステム活用とDesignOpsに関する レポート appeared first on Studio by UXPin.

UXPinによって顧客のデザイン体験がどのように改善されたかについてフィードバックを受けると、私たちはいつもワクワクします。その顧客が世界最大のデジタル決済プラットフォームの１つであれば、特別感はなおさらです。

今回、PayPal のデベロッパーツールおよびプラットフォームエクスペリエンス担当のシニアマネージャーであるエリカ・ライダー氏と、彼女のチームのシニアUX デザイナーであるアンソニー・ハンド氏にお話を伺うことができたのでご紹介します。

エリカは、PayPal で解決しなければならなかったデザイン上の課題、すなわちデザイン、製品、開発の間のギャップを埋めることについて、彼女自身の言葉で説明しています。

多くの企業では、デザイナーとデベロッパーの比率は、「デベロッパー１０人」に対して「デザイナー１人」ですが、PayPal では、「１０００人以上のデベロッパー」に対して「デザイナー５人」です。

PayPal はこの課題を克服するためのツールや戦略を必要としていました。そこで、彼らは UXPin Merge に注目し、DesignOps のプロセスを改善しました。

彼女とPayPal のデザインチームが、UXPin Mergeを使ってどのようにデザインと開発のプロセスに革命を起こしたかを、これからご紹介します。

体験談を動画で見る 

PayPalの主な２つの課題

 デザイン拡張 の課題：

私を含め、５人のデザイナーからなる小さなデザインチームがあり、６０〜１００の製品と、１０００人を超えるデベロッパーを担当しています。

このような大きな組織を支える小さなデザインチームとして、私たちは革新的な問題解決のアプローチを開発しなければいけませんでした。デザイナー増員の予算は確保できないので、デザインそのものをスケールアップする方法を考えなければならなかったのです

一貫性の課題：

PayPal の製品チームには、経験豊富な UX 担当者やUIデベロッパーはおらず、その結果、さまざまなユーザビリティとデザインの一貫性に問題が生じ、製品がどれ１つとして同じにならなくなってしまいました。

そこで私は、まとまりのある一貫したユーザー体験を生み出すという、難しい仕事を任されましたが、３人のデザイナーと無限の製品チームからなる私たちは、従来のようなモデルで規模を拡大するのは無理だと思いました。加えて、デザイナーの増員が問題解決になるとも思えませんでした。

製品チームを成功に導くには、私たちにはデザインの拡張が必要だったのです。

今までは…

PayPalが使ってみたツール

まず、製品チームは自分たちで製品をデザインしないといけないことが分かっていたので、私たちはさまざまなツールを検討し、まずはデザインシステムや規格がある従来型のモデルから始めました。

最初の考えは、デザインについて製品チームを教育しながら、従来のデザインアプローチを適応させることでしたが、ドキュメント作成、サポートの提供、デザインツールの学習曲線をたった３人のデザイナーで行うとなると、従来のモデルではうまくいかないことにすぐに気づきました。

製品チームが製品をうまくデザインするには、彼らが学ぶべきツールやスキルを最小限に抑える必要があったのです。

従来のやり方

従来の UX プロセスでは、デザイナーがベクターベースのモックアップを作成し、それをデベロッパーに渡していましたが、残念ながらこのプロセスでは、コンポーネントがどのように機能することになっているかと、そこにあるべきコンポーネントの間にギャップが生じてしまいます。

その結果、デザイナーとエンジニアの間で「デザインはどうあるべきか」、「プロトタイプはどうあるべきか」を明確にするために、何度もやり取りをすることになり、デベロッパーは、製品の見た目や機能だけを考えていたため、デザイナーに思いもよらない質問を重ねることになってしまいます。

UXPin Mergeの導入

製品チームが製品をデザインするには、このデザイナーとデベロッパーのギャップを最小限に抑え、連携を改善する必要がありました。

PayPal に入社する数年前、私には「デザインの効果的な拡張には、デベロッパーやプロダクトマネージャーを  デザインプロセス に関わらせないといけない」という持論がありましたが、それを行う方法は知りませんでした。何をするかは分かっていたのに、どのようにするかは分かっていなかったのです。

ですがMergeとUXPinに出会ったことで、デザインと開発のギャップを埋める方法を理解する道が開かれ、PayPal の デザインプロセス 改善のきっかけとなりました。

従来の DesignOps のプロセスは、スケーリングに関するものであり、通常はデベロッパー１０人に対してデザイナー１人という割合が一般的です。まずデザイナーを追加し、次に大規模なデザインチームを収容するためのサポートインフラを構築します。

社内組織として、従来のデザイナーとデベロッパーの比率である１対１０にスケールアップするためのリソースが得られないことは分かっていたので、デザイナーを増やすことなく、デザインの課題を解決するための革新的なソリューションを見つけなければいけませんでした。

UXPin Mergeの仕組み

PayPalの消費者向けアプリ、サービス、Venmo、その他の外部サービスは、すべて異なる技術が使われています。社内ツールの開発には、より企業向けに特化し、社内のユーザーインターフェースに適していることから、『Microsoft のフルーエントデザインシステム』と 『UIコントロール』を採用しました。

UXPin Mergeがあれば、Microsoft の フルーエントデザインシステムを Githubレポに入れ、コンポーネントを UXPinのデザインエディタにインポートすることができるようになります。そしてこのUXPin Merge のセットアップを使って、製品チームは、エンジニアが DevOps ツールの開発に使っているコンポーネントとUIコントロールを正確に活用したプロトタイプをデザインすることができます。

たとえば、UXPinのエディタでキャンバス上のボタンをレンダリングすると、ホバー/クリック効果、フォント スタイル、その他のメトリクスを含め、デベロッパーツールでレンダリングしたものとまったく同じになります。UXPin Mergeでデザインすると、PayPal のときよりもはるかに忠実なプロトタイプを作成できるのです。

Mergeを使った感想

最初の展開で、UXPin Mergeを使うことでデザインにかかる時間を大幅に短縮できることが分かっていました。

すると PayPalの上級管理職から、「UXPin Mergeを使った場合」と「従来のデザインモデルを使った場合」の時間短縮の比較をしてほしいという依頼がありました。

そこで、あるデザイナーに単一ページの比較テストを選んでもらいました。PayPal で使っている別のデザインツールで、ベクターベースのデザインを１ページ行い、UXPinで当社のMergeコンポーネントライブラリを使って、まったく同じプロトタイプを作成しました。この２つのツールは、時間面でどのように比較されるでしょうか？

結果：Mergeを使った場合、デザイナーは約８分かかりましたが、他のデザインツールを使用した場合は、同じプロトタイプに 1 時間以上かかったのです! これは、私たちが比較対象として選んだツールを使い慣れている、能力を持った経験豊富なデザイナーによるものであることに留意してください。

ベクターベースのデザインツールを製品チームに提供するのは気が進みませんでした。彼らはデザインを始める前に、ドキュメントを整備し、ツールの使い方を学ばないといけませんでしたから。たとえトレーニングに時間がかかったとしても、経験豊富なデザイナーの能力に達することはできなかったでしょうし、同じプロトタイプを１時間でデザインすることもできなかったでしょう。

UXPin Mergeを使えば、プロダクトマネージャーの一部は、同じようなプロトタイプ１ページを８～１０分で作れます – UXPinの経験豊富なデザイナーにかかる時間と同じです！

以前は、限られたリソースとデザイナーで、１ページの製品を作るのに、モックアップのデザインだけで２〜３カ月かかっていましたが、今は、プロダクトチームが同じ時間内に製品をデザインし、提供することができます。

UXPin Mergeが与える大きな影響

UXPin Merge の大きな影響の１つは、より忠実度の高いプロトタイプを作成できるようになった点です。デザイナー、経営陣、ディレクター、デベロッパーなど、すべての人が最終製品の外観、UX、インタラクティブ性についてより確信が持てるようになり、それによってステークホルダーからより質の高いフィードバックを得ることができるようになりました。

経営幹部やディレクターは、こういったプロトタイプの機能と目標を実際に体験することから、最終的な方向性について、たとえば「このようなボックスがどのようにテキストフィールドのように見えないか」について単にコメントするのではなく、より強力なフィードバックをしてくれるようになりました。

Merge で UXPin を使うようになってから、私のデザイン哲学と生産性は格段に上がりました。３０分以内にプロトタイプを実装できる自信があります。ちなみに、以前使っていたツールでは半日かかっていましたからね。

フィードバック：UXPinを使うことで、ステークホルダーはかなり迅速なフィードバックの提供ができます。彼らにプロトタイプのリンクを送ると、好きな時間にプロトタイプで遊んでもらい、UXPinでプロトタイプに直接コメントを記入してもらうことができます。UXPinのコメント機能は、私たちの対応後に、コメントを【解決済み】としてマークする点が素晴らしいですね。

製品の質：この新しい UXPinのアプローチでは、より協力的で統合的なデザインプロセスが実現されます。デザイン、プロトタイプ、開発を別々にするのではなく、UXPinによって、プロセス全体を通してエンジニアリングと製品チームが関与する統合的なフローを作り出すことができ、その結果、製品の最終的な品質が劇的に上がりました。

ユーザーテスト：UXPinで作成した忠実度の高いプロトタイプは、私たちにはとても便利です。忠実度の高いプロトタイプをより早く作成でき、セッション後にすぐにフィードバックが得られます。そしてすぐに修正できることがあれば、次の参加者の前にその変更を行い、以前よりずっと早くフィードバックを得ることができます。

UXPinは、コンセプトから忠実度の高いプロトタイピングまで、即座に対応できるツールを提供します。UXPin Merge を使って、高度なプロトタイピングとテストがデザイン プロセスをどのように変えるかをぜひご覧ください。

 PayPalが再定義したデザインプロセス

 PayPalのDesignOpsは、エンド・ツー・エンドのプロセスです。

1. 製品チームはユーザーを十分に理解するのが必須である
2. ユーザーのニーズに基づいた製品をデザインする
3. ドメインエキスパートが、彼らの知識とテストに基づいてデザインを完成できるようにする
4. デザインの成功を検証する

社内の共通の課題として、製品チームが UX デザインをボトルネックとして捉えていることがよくあります。そこで私たちの戦略は、まずそのボトルネックを取り除き、製品チームが自分たちでデザインを行えるようにすることから始めました。

そこで私たちは、このような「スナップ・トゥギャザー」型のデザインを実現できるUXPin Mergeを使うことでそれを実現しました。ドラッグ＆ドロップでユーザーインターフェイスを構築できるコンポーネントが製品チームに提供されます。

製品チームは、余白や構成要素を固定したレイアウトを作成することができ、すべてが想定通りに表示され、機能するようになりました。デザイナーは、何も取り締まる必要も、製品デザインのために介入する必要もありませんでした。

製品チームが標準的なデザイン原則に従っていないときや、大変な問題で行き詰まったときは、デザイナーは今でも製品チームを手伝っていますが、製品チームは作業の９０％を自分たちで行うことができるため、デザイナーはより大局的なデザインの問題に集中することができます。

成果

顧客中心

私自身、顧客中心やデザイン主導というのは、デザイナーが常にリードしているという風には考えていませんし、組織の誰もが、デザイン主導とはどういう意味なのかを理解しています。

私達は PayPal でデザインをするとき、あっちこっちの小さな問題に焦点を当てるのではなく、グローバルレベル、組織全体、製品ライン全体で問題を解決することに重点を置いています。

小さなコーナーケースだけでなく、PayPal の製品すべてで一貫性のある体験がユーザーに提供されないといけないのです。

PayPal のプロダクトチームとドメインの専門家がデザインをしている間、我が UX チームはメンターやコーチとして動きます。以前は UX デザイナーが１製品、あるいは１ドメインを担当していましたが、Design Ops 2.0では、製品デザイナーが一度に１０～１５種類の製品を担当するようになりました。

企業における教育 

UX デザイナーがプロダクトチームを指導する場合、より良いレイアウトやプロダクトをデザインするためのガイダンスを配るだけでなく、デザイン思考を教えることもあります。

デザイン思考は UIデザインだけでなく、完全な UX を考えることです。API のレスポンスタイムは UX にどのような影響を与えるでしょうか？レイテンシーは UX にどのような影響を与えるのでしょうかか？

私たちは、UIのトップレベルからのデザイン思考を求めており、製品チームがエンドユーザーのために適切な判断を下せるように、全員に UX の影響を理解してほしいと思っています。

重要なことに集中する

我がデザインチームは、さまざまな製品チームのサポートに５０％の時間を費やし、残りの５０％は、グローバルな組織に影響を与える大きなUXイニシアチブに費やしています。

こうした UXの取り組みには、以下のようなものがあります：

• 「プラットフォーム上でのユーザー間の信頼関係の構築法」といったことに重点を置くか。
• プラットフォーム上でいかにしてユーザー間の本質的な繋がりを築くか。
• どのようにすれば、すべての製品にユーザー調査を組み込むことができるか。- 調査ではなく、ユーザーがどのように製品を使い、どこにギャップがあり、それをどのように修正し、そのデータを製品チームに提供するにはどうすればいいかのの理解である。

将来への投資

デザインプロセスの拡張は、長い目で見れば投資となります。デザインと開発のライフサイクル全体を俯瞰し、それが現在どのような状態になっているかを把握し、「このステップは長すぎる」ではなく、「どうすれば短縮できるか」を考えるには、経験豊かなチームが必要です。

すべての技術を構築する最初のプロセスは長い時間のように思えますが、実は長い目で見れば、開発、デザイン、開発プロセスの全てにおいて、かなりの時間を節約することができるのです。

UXPin Mergeとデザインプロセス 

もし UXPin Mergeが世界最大のデジタル金融プラットフォームの複雑なデザイン問題を解決できたとしたら、これがあなたのビジネスだとどうなるかを想像してみてください。

PayPal はMergeを使って Git レポジトリから UXPinとReactコンポーネントを同期しましたが、MergeはStorybookとの統合も可能であり、Vue や Angular など、さらに多くのフレームワークにアクセスすることができます。

  デザインプロセスの速度を上げる準備はいいですか？

The post PayPalがUXPin Mergeで デザインプロセス を拡張した方法 appeared first on Studio by UXPin.

デザイナーと デベロッパー の間のギャップで、ワークフローが遅くなったり、製品の市場投入がしにくくなることがよくあります。デザインチームと開発チームの強力な連携がなければ、製品を完成させて消費者に届ける前に、多くの間違いを直さなければならないことになるでしょうからね。

デザイナーと デベロッパー 間のギャップに目をつぶる必要はありません。本記事でお話するヒントは、両者の距離を縮め、プロセスを改善し、より良いユーザー体験につなげるためのものになります。

おすすめ記事：Coding Designers and Design Collaboration with Developers – 2020 Design Trends with Joe Cahil    

デザイナーと デベロッパー  が同じ部品を使うデザインシステムを作る

デザイナーと デベロッパー が同じコンポーネントを使うデザインシステムを作成することは、チーム間のギャップを埋めるのに最も重要なことです。デザインシステムは、製品の以下のような承認を含め、デザインとコーディングのフェーズで必要なものをすべて提供する必要があります：  

• タイポグラフィ
• カラー
• アイコン
• フォトグラフ
• GIF
• サウンド
• インタラクティブ要素

  デザイナーとデベロッパーが同じデザインシステムを使うことで、使用するフォントと色や、ボタンやフォームのコーディング方法を決めるような無駄な時間を省くことができ、制作の各ステップを改善することができます。従来、企業は製品の構築に画像ベースのアプローチを採用しており、デザイン システムの維持に多くの労力を費やす必要があるため、このアプローチでは大変なのです。これだとデザインチームが作業を終えた後に、デベロッパーはコンポーネントを機能させる方法を探す必要がありますが、コードベースのアプローチでは、デザイナーとデベロッパーがいつでも再利用可能な「信頼できる唯一の情報源（Single source of truth）」を利用できるようにすることで、このギャップをなくすことができます。

デザインシステムの例をご覧ください。  

デザインシステムでの準備はいいですか？コード化されたコンポーネントの技術である UXPin Mergeで、さらに一歩進みましょう。UXPin Mergeは、GITのレポジトリからUXPin エディタにコード化されたコンポーネントをインポートし、同期させることができますよ。  

インポートされたコンポーネントは、デベロッパーが開発プロセスで使うコンポーネントと全く同じです。つまり、コンポーネントには、エンドユーザーが体験する実際の製品と同じような外観、感触、機能（インタラクション、データ）があり、デザインシステムと整合性があり、生産可能であるということです。それは、デザインと開発のギャップが埋まるのはもちろん、デジタル製品のデザインとコーディングの両方にかかる時間が大幅に短縮され、市場投入までの時間が早くなるということです。  

おすすめの記事：デザインツールはイメージベースからコードベースへ  

ウェブデザイナーとフロントエンドのコミュニケーションを高める

デザイナーと開発チームには、簡単に連絡を取り合える方法が必要ですが、少し前までは、チーム間のコミュニケーションを上げる方法は限られており、ワークスペースの共有やSNSグループへの参加などくらいしかありませんでした。  

今日では、チームメンバーがリモートで仕事をしている場合でも、以下のアプリのような連絡と連携を高めるツールが豊富に揃っています：  

• Slack 
• Trello
• Google Workspace

  対面での会話に代わるものが必要なときは、以下のようなビデオ通話アプリなどを使うといいでしょう：  

• Zoom
• GoToMeeting
• Microsoft Teams

  コミュニケーションがしやすくなると、それに伴ってチームメンバー同士の会話も増えます。連絡を取り合って仕事上の関係を築くのに必要なツールを設けましょう。  

製品デザインのブレーンストームにデザイナーや デベロッパー を招く

チームメンバーは、製品についての重要なブレーンストームのセッションからしょっちゅう外されてしまいます。プロジェクトマネージャーは、開発チームのリーダーくらいは招待して、製品にある機能を追加する際の課題についてのインサイトを得ようと考えているかもしれませんが。  

より多くのデザイナーやデベロッパーがブレーンストームに参加することで、仲間意識が高まり、アイデアが共有され、全員が参加しなければ見逃してしまうかもしれない革新的なコンセプトを発見することができるのです。

そのような話し合いをより成功させるには、次のような方法があります：  

• ユニークなスキルを持つ多様な参加者を選ぶ
• セッションのルールを決め、参加者が集まる前にそのルールを伝える
• 時間を気にしなくていいようにタイマーをセットしておく
• アイデアを話してもらうときは、順序よく進める（不意打ちは緊張させるだけ）
• あらゆるアイデアをとかく書き留める
• 進行役がフィードバックを提供し、グループが気に入ったアイデアを議論できるように、その日または週の後半にフォローアップのミーティングを予定する

  さらに、製品開発の初期段階から多くの人に参加してもらうことで、社内での役割に関係なく、みんな何かしらの役に立てることを各部門に示すことができるのです。  

UXデザイナーとフロントエンドエンジニアが互いの役割について学ぶことを促す

  UXデザイナーとフロントエンドエンジニアは、一緒に仕事をする時間が長くなければ、製品作りにおけるそれぞれの役割についてあまり知らないかもしれません。だとしたら、他のグループが行う基本的な用語や作業の種類をチームに紹介することで、デザインプロセスにおけるコミュニケーションのギャップを埋めることができます。  

だからといって、全員がスキルセットを共有する必要はありません。ただ、コミュニケーションをとって他の人が貢献していることの本質を理解するのに、十分な知識が必要なのです。  

デザイナーに必要な知識

  ウェブデザインチームは、HTMLの基本的なスキルは必要かもしれませんが、コードを学ぶ必要はありません。ただし、デベロッパーが使う一般的なツールは知っておく必要があり、それには、次のようなプログラミング言語が含まれます：

• PHP
• JavaScript
• Java
• CSS

  Web開発に欠かせないJQueryのようなツールを知ることで、デザイナーは自分の依頼に関わる仕事の多さを理解することができ、デベロッパーの仕事に対して、より深い敬意を抱くようになるはずです。  

フロントエンドとバックエンドの デベロッパー に必要な知識

  デベロッパーは、デザインのインタラクティブなコンポーネントへの変換のために、多くの技術的な知識とコーディングスキルが必要です。なのでデベロッパーの中には、「デザイナーの方が仕事が少ない」と誤解している人もいるかもしれません。

もちろん、デザイナーにも、製品の使いやすさや人気の高さに貢献する、以下のような並外れたスキルがあります。デザイナーには長年の経験があることを、コーダーは知っておくべきです：

• WCAG（ウェブ・コンテンツ・アクセシビリティ・ガイドライン）に沿ったユーザーインターフェースの作成
• 製品のターゲット市場にアピールするタイポグラフィの選択
• さまざまな視覚要素をより大きな全体の一部のように感じさせる、詳細なスタイル ガイドに従うこと

  みんなが同僚の専門性のレベルを理解することで、チーム全体の尊敬とチームワークの向上が見られるかもしれませんよ。  

おすすめ記事：コードを学ぶ事なくコードベースデザイナーになる方法  

UXPin Mergeを使い、デザイナーとデベロッパーのギャップを埋める

  UXPin Merge は、コードベース独自のアプローチで製品のデザインとプロトタイプを実現します。画像ベースの要素の代わりにライブコードを使用するツールを選択することで、デザイナーと開発者の間のギャップを埋め、デザイナーと開発者に等しく適用されるデザインシステムの強みを活かすことができます。

UXPin Merge へのアクセス権をリクエストして、チーム間の連携を促すコードベースのデザインの利点をぜひご体験ください。

The post デザイナーと デベロッパー の連携においての課題と解決方法 appeared first on Studio by UXPin.

誰もが知っている従来の「労働」は、ここ2、3年で劇的に変化しました。世界中のオフィスがバーチャルワークスペースやハイブリッドワークスペースを取り入れた働き方にシフトしていき、そのような変化は新しい考え方や働き方をもたらし、従業員と企業の成功に有益であることが証明されました。  

多くの人にとって、オフィスを離れることでより自律的になり、ワークライフバランスも良くなります。直接的にせよ間接的にせよ、従業員の幸せは企業の成功につながる傾向があります。良い姿勢と前向きなリーダーシップは、そのための直接的な橋渡しとなるのです。では、このような考え方は、デザインリーダーシップにどのように反映されるのでしょうか。  

主なポイント

• いい雰囲気で統合されたチームは、より多くのイノベーションを生み出し、個人は自らのデザイン能力に自信を持ち、参加者は増えていく。
• いちいち細かい管理や、何をすべきかを全員に指示することなくチームが機能するところまで到達できれば完璧。
• 権限を与えられたリーダーは、最終的にデザインの世界にポジティブな革新と変化をもたらす。もし、次のステップに進むべきか迷っていたら、人は本来励まされ、従事していると感じたときに最高の仕事を完成させるということを思い出すといい。
• まずは自ら切り込み、自身の決断を振り返る：その決断はチームの助けになったか、それとも進行を妨げたか？
• 行動計画を作成する：目標達成のために何を変えるべきか、どのようなリソースが必要かを決定する。
• 変更を加えつつ、それが思うようにいくかどうかを観察する。必要なら反復する。

もしあなたが現在デザインリーダーで、チームを効果的に管理し、ビジネスを成功させる方法をお探しでしたら、良いデザインチーム構造を作るためにできる重要なステップをいくつか見ていきましょう。本記事では、デザインリーダーシップとは何か、そしてそれをどのようにあなたの デザインチーム やビジネスに適切に適用できるかを探ります。

チームのワークフローを最適化し、より良いコミュニケーションを実現するプロトタイピングツールをお探しでしたら、UXPin Mergeがピッタリです。UXPin Mergeは、チームがより高いレベルのデザイン成熟度をすぐに達成できる強力なテクノロジーです。インタラクティブなUI要素を含む高忠実度のプロトタイプをデザインし、デザインプロセスの連携がどれだけ上がるかをぜひご確認ください。UXPin Mergeについてもっとみる

 デザインチーム の管理 – 正しく行うために重要なステップ 

デザインリーダーシップとは、すべてのステップをいちいち細かく管理することではなく、優れたデザインリーダーは、むしろチームに対してインパクトのある指示を出すことができます。では、具体的にどのようにすれば、有意義なプロダクトデザインの職場環境が実現されるのでしょうか。

まずは、 デザインチーム をうまく管理するための重要なステップと、結束力のあるチームを作るために避けるべきことを見ていきましょう。  

ステップ１：デザイン部門の監査から始める

  UXデザインの監査から始めるように、目標を振り返ってみましょう。ロードマップの作成によって、組織におけるデザイン目標における達成すべきことがより明確に見えてきます。このロードマップで、道のりの凸凹が少なくなり目標に到達しやすくなります。  

次のステップでは、 デザインチーム の構造を全体的に監査します。チーム内にどのような人材がいるのかを把握し、その強みと弱みを確認するのです。こういったことの把握により、会社の目標達成のために必要な、適切なスキルを持ったメンバーが十分にいるかどうかがわかります。  

チーム全体をより深く理解するには、チームミーティングがいい方法です。さらに、デザインチームの監査は、日々の業務全体がどの程度うまくいくかを判断する上で非常に有効です。

監査によってチーム構造が明確になり、すべてのチームメンバーの役割と、彼らが役割を果たすために期待される能力を特定できます。明確化することで、全員に高い目的意識を持たせることができ、混乱や滞りなく一貫したタスクが設定されます。  

ステップ2：自分の間違いを確認し、認める。

  デザインチームのリーダーとしてチームを管理する際には、誠実な考え方を取り入れる必要があります。リーダーシップを発揮する上で、先天的な思い込みや古い思い込みはつきものですが、緊密なチームの雰囲気の中で働く場合、外部からのアウトプットは非常に貴重なものとなるのです。  

チームメンバーからのフィードバックという形で、外部からの意見をどんどん求めましょう。その際、匿名のアンケートや、毎日一緒に働いている人たちから情報を集めるための全員参加の電話でもかまいません。

厳しい意見を聞くのは大変ですが、そのような意見を直接メモすることは、チーム全体の強化につながります。リーダーシップの不足部分はさまざまな形で表れ、例えば、チームの明確な目標設定の度重なる失敗や、従業員に対して細かく管理しがちであるといった指摘がチームから来るかもしれません。  

どんな欠点があるにせよ、デザインリードとして少し工夫が必要なところは積極的に確認し、認めるようにしましょう。あなたやチームのメンバーも含めて、完璧な人間なんていないですからね。

ステップ３：やるべきことの計画を書く

  チームを成功に導くために、リーダーシップスタイルの改善や計画の立案と同様に重要なのが、プロジェクト管理に関わる要素であり、これはデザイン監査と密接に関係しています。把握したい質問としては、「増員は必要ですか？だとしたら、現在のチーム構成の中で、どのスキルのギャップを埋める必要があるか分かりますか？」などがあります。  

関連する項目として、スキルギャップ評価の実施が挙げられます。チームメンバーに得意なスキルを聞いてみましょう。直接聞いてみることで、これまであまり意識されていなかったスキルや、今後のデザインプロジェクトに役立つスキルが見つかるかもしれません。

チームメンバーとの1対1のミーティングやグループミーティングでは、これから伸ばしたいスキルについて質問するのもいいでしょう。そうすることで、彼らが望むキャリアパスとデザインチーム全体のコンピテンシーをどのように統合するかを計画することができます。スキルのギャップを埋めるために、チームメンバーがスキルを磨き、開発する方法を提案しましょう。

企画段階では、募集・採用の段階で、デザインチームづくりがうまくいっているかどうかの確認が重要です。遅れをとっている分野があればメモをしておき、以下を考えてみましょう：

• 候補生の離職率が高くなっているか
• オンボーディングプロセスで、新入社員が繰り返し質問をし続けることがあるか

  このような質問と、タスクの配分、仕事量の管理、一貫したパフォーマンスなど、その他の潜在的な改善点を検討しましょう。  

ステップ４：成果の測定法を決める

  このような項目を把握し、具体的な変更が実施されたら、その変更をどのように評価するのか、しっかりとした計画がいると考えるでしょう。実施した変革が成功したかどうかを測るのに必要なのです。  

成果の全体的な成功を評価するとき、以下を自分自身に問いかけてみてください：

• 問題を解決できたか？：デザインとは、単なるグラフィックやカラーパレットではなく、その核心は、クリエイティブなチャンネルを通じて、相互作用と問題解決を促すことなのです。もしあなたが、例えば従業員の定着率の低さなどの現実の問題を特定し、よりオープンなコミュニケーションとフィードバックなどのより良い解決策を提供したのなら、それは成功と言えるでしょう。　
• プロセスを改善したか：デザインは、必ずしも補足に関するものである必要はなく、むしろ、調査中に冗長で役に立たなかったステップが特定されるかもしれません。優れたデザイン・リーダーシップとは、うまくいっていないものを切り捨てたり、取り除いたりすることもあるかもしれません。様々な開発ルートを通じてプロセスをより効率的にしたのなら、よかったですね、またひとつうまくいきましたよ！
• フィードバックに対してオープンだったか： デザインの成功は、まさに従業員と経営陣の個人的な成長であり、効果的なコミュニケーションを通じて示すことができます。フィードバックを受け入れてオープンなコミュニケーションをとることは、なかなか習得しにくいスキルですが、優秀なリーダーなら誰にでもあるはずです。プライドを捨て、率直なフィードバックを受けましょう。あなたもチームも、もっと良くなるはずです。

オススメの測定方法は、改善しようと計画している特定の領域によって異なります。例えば、自身のデザインリーダーとしての資質を測りたいのであれば、職場について従業員がどう感じているかを測るメトリクスである「従業員NPS（ネットプロモータースコア）」などの定量調査を実施するといいでしょう。

このようなアンケートを実施することで、例えば3ヶ月や6ヶ月間でスコアがどのように変化したかを確認することができます。これは単なる一つの手段ですが、従業員の満足度を見るのによく行われる方法です。  

例えば、チームメンバーの定着率を上げて離職を防ぎたいと考えていたら、従業員の適切な定着のために必要な措置を講じた後、特定の行動項目を実施した後に平均在職期間がどのように変化したかを測るといいでしょう。  

あるいは、2週間という時間枠の中で、チームがどのくらいのタスクをきちんと完了したか測定したい場合は、このようなメトリクスを隔月で比較するといいでしょう。測定は、さまざまな影響要因にアプローチする現実的な方法がある「フィボナッチ数列のポイント」を通してアプローチできます。  

ステップ５：トランスフォーメーションプロセスの開始  

これで、デザインチームの働き方の効率化ができるようになりました。上記のステップを要約して実行すると、次のようになります：  

• １対１のミーティング：チームリーダーとチームメンバーの報告者が緊急の問題について個別に連絡を取り合い、強い関係を構築するには、１対１でのミーティングがいい方法です。また、このミーティングによって、従業員は自分が製品チームの重要な貢献者であると感じ、目標に向かってきちんと仕事をこなし、スキルも上がっていることを確認することもできます。1対1は、現状報告としてではなく、定期的にフィードバックを行い、キャリアアップや新しいスキルの習得を促すプラットフォームとして活用すべきです。
• 毎日のスタンダップ：デイリースタンドアップでもハドル会議と呼ばれるものでも、その考え方は同じです。スタンダップでチーム全体が情報を共有し、つながっていることを実感できるようにすることで、進捗状況の把握、必要な改善点や未解決の問題の明確化、仕事の完了状況についてのチームの状況の把握ができます。
• チームビルディング活動：士気を高め、チームワークを活発にするためのさまざまな活動があり、コミュニケーションを前面に押し出し、製品チームの連携を自由な流れにし、最高の職場の雰囲気を作り出すのに使えます。チームビルディングで、プロダクトマネージャーと従業員が、従来の職場環境以外で互いのことをより深く知ることができるかもしれません。脱出ゲームやゴルフコースでの1日など、楽しくて魅力的なアクティビティになるといいですね。

チームの成功には、成長と連携が欠かせません。当社のDesignOps eBookの最初の柱で説明したように、デザインチームの幸福度は、経営計画の最重要事項であるべきです。上記のステップは、チームが成長し、大切にされていると感じる事ができるようになるための、提案の一つに過ぎません。

ステップ6：反復の力を見逃さない. 

  成長は一筋縄ではいきません。なので定期的にチームメンバーとのコミュニケーションを取るようにしましょう。そうすることで、何がうまくいっているのか、どんなやり方がうまくいっていないのかが見えてきます。そうなると、そこからが巻き返しのチャンスです。

ここでもまた、チームメンバーに率直なフィードバックを求めましょう。それは、対面式の会議でもアンケートでも構いません。オープンなコミュニケーションは、デザインプロセスや製品開発のワークフローを円滑に進める上で理想的な環境であり、気づきを得た従業員は、最終的に評価されていると感じるのです。一般論ではなく、明確なアクションに焦点を当てることを忘れないでください。具体的に掘り下げることで、誰もがより良い結果を得ることができます。  

アンケートを実施する場合は、頻度を上げ過ぎないように注意しましょう。データを収集した期間が短すぎて適切な結論を導き出せない可能性や、チームメンバーにあなたの決断を頻繁に評価してもらうことは、あなたがデザインリーダーとしての能力に自信がないと思われる可能性があります。デザインリーダーとして進むべき方向性を明確にすることで、チームはそれを評価してくれるはずです。

チームの連携とデザインチームの管理方法を改善するために、繰り返し実験しましょう。適切なデザインチームの管理は長距離走であり、短距離走ではないことを忘れないで下さい。良いチームを育てるには、試行錯誤が必要なのです。  

チームを成功に導こう

DesignOpsの第一の柱は、優れたビジネスの核となる「人」を扱うことです。  

従業員をサポートしたいのであれば、その仕事に適した技術スタックが必要です。UXPin Mergeはそのような技術であり、これを使えば、デベロッパーのインタラクティブなコンポーネントをデザインエディターに持ってきて、ステークホルダー、プロダクトマネージャー、そして何よりもデベロッパーが理解しやすいプロトタイプを構築することがでます。コミュニケーションのギャップを埋め、組織内のワークフローを強化しましょう。UXPin Mergeについてもっと読む

The post デザインチーム を効果的に管理する方法とは appeared first on Studio by UXPin.

デザインコンサルタントは以前から存在しており、企業が外部のサービス会社や代理店にデザインコンサルティングを依頼することは昔からありました。  

しかし、デザイン変更管理が進化し、現代のデザイン思考がデザインチームと他部門との統合方法を変えるにつれ、このようなデザイン業界の役割は、さまざまな刺激的な可能性と利益をもたらしてくれるようになりました。  

本記事では、社内デザインコンサルタントが業界で果たす役割が大きくなっていることにスポットを当て、デザイン品質やデザインチームのパフォーマンスにどのようなプラスの影響を与えているのかお話します。  

ここでは、社内デザインコンサルタントがこれらのチームとどのように融合し、デザイン品質にどのようなメリットをもたらしているかを探るとともに、効果的な社内デザインコンサルティングを立ち上げるためのステップについてみていきましょう。  

デザインコンサルティングの立ち上げと運営に必要な時間を獲得する方法は、現在のワークフローの改善であり、そのうちひとつが、プロトタイピングとデザインのハンドオフプロセスをスピードアップする技術を試してみることです。それにはまさにUXPin Mergeがピッタリです。企業がフロントエンドの負債と戦い、自身のデザインシステムに基づいた製品を開発するのをUXPinがどのようにサポートするか、詳しくはこちらをご覧ください。

社内デザインコンサルタントとは

  まずは、デザインコンサルタントのコンセプトと、コンサルタントがどのように組織内の問題解決者として機能し、実行可能なデジタルデザインソリューションを特定・実行するのかについてみていきましょう。  

社内デザインコンサルタントとは、デザイン会社の中で、アイデアの提案、推奨や監査の実行、既存のデザインシステムへの助言を行う機能であると言えます。  

デジタル製品のデザインの形状や機能性から、美観や市場性まで、社内デザインコンサルタントは、これらの特徴や要素が互いにどのように融合しているかを把握しています。

このようなコンサルタントは、デザインチームの中での重要な役割をいくつか担い、以下を行うことによってその専門知識を提供し、付加価値を高めています：  

• デザインチームのメンバーが検討し、最善の決断ができるようサポート
• 潜在的な解決策や代替案について、常にチームに情報を提供し、最新情報を入手
• デザインフレームワークを使って業務プロセスやタスクの効率化をサポート

  効果的なデザイン戦略の策定により、チーム全体のパフォーマンスとアウトプットをモニタリングし、改善します。   さらにデザインコンサルタントは以下を日常業務としています：  

• デザインワークショップの企画・運営
• 組織的なデザインシステム構築の監修
• デザインのアイデア出しや実行に必要な経験や意見の追加

社内デザインコンサルタントと社外デザインコンサルタント

  社内デザインコンサルタントは社外デザインコンサルタントとほぼ同じですが、デザイン会社の業務やチームダイナミクスにおいて遥かにいい見解があります。そして社内デザインコンサルタントと社外デザインコンサルタントの違いは、クライアント企業との関係にあります。  

• 社内デザインコンサルタント：クライアント企業にフルタイムまたは契約ベースで雇用され、クライアント企業に直接報告する。雇用主のために継続的に働き、組織内の製品デザインに特化し、企業の経営陣やデザインチームと長期的な関係を築く。
• 社外デザインコンサルタント ：デザインコンサルティング会社から来て、指定されたデザイン関連のプロジェクトやタスクの完了のために短期間雇われる。大抵は社外のコンサルティングやデザインサービスに雇われ、複数の組織のプロジェクトに同時に取り組み、自身の経験やより広いビジネス視点に基づいたアイデアをもたらす。ちなみに、Ideoがイノベーションのコンサルティング会社として有名なのは聞いたことがあるかもしれないが、この会社はパロアルトに拠点を置き、多くのスタートアップ企業のデザインへの取り組みをサポートした。

つまり、社内デザインコンサルタントは自社専属で、通常、長期的なプロジェクトに参加します。一方、社外デザインコンサルタントは、代理店から派遣され、短期間の仕事でサポートします。  

社内デザインコンサルタントの利点

1. 一貫性と明瞭性の確保

  外部のコンサルタントを入れるたびに製品デザインチームのワークフローが混乱するのではなく、製品デザイン活動の中で社内デザインコンサルタントが機能するように投資することは、誰にでも一貫性と明瞭性があるということです。

これには、共感、定義、アイデア出し、プロトタイピング、テストを柱とするデザイン思考プロセスをチームに導入することが含まれ、また、社内デザインコンサルタントは、デザインにおける変更管理を効果的に行うことができます。  

社内デザインコンサルタントは、この非常に重要だけど時間のかかるプロセスを監督・管理するのに適任です。チーム全体の一貫性と明瞭性を確保するために取り組みを整理・効率化することで、デザインにおける変更管理を組織全体に浸透させることができるのです。  

2. 知的資本と問題解決能力の向上

デザイン会社は、製品デザインチーム内に社内コンサルティンググループを設けることで、コスト削減、より良いデザインサービスの人材獲得、製品開発の加速、戦略的デザインソリューションやブランド戦略などを進めることができます。それにより社内コンサルティングを通じてのみ得られる知的資本の成長と維持が促され、社員が会社そのものをよりよく理解できるようになります。

社内デザインコンサルタントは、第一線で活躍する社員として、社内のデザインアーキテクチャに関する豊富な経験と知識を積み重ねており、このような深いインサイトで、他の社員が社内デザインコンサルタントと交流する際や、ライン管理のポジションに移行する際に、問題解決能力が上がります。

3. 組織全体でのデザイン推進

  大抵のデザインチームにとって、デザイン思考の組織全体への普及は難点です。社内にデザインコンサルタントを置くということは、チーム内にデザイン支持者を置くということでもあるのです。

社内デザインコンサルタントは、デザイン思考を実践し、 戦略的なデザインに必要な視認性と注目度を常に保証します。また、デザイン大使として、他のビジネスステークホルダーが製品デザインやデジタル製品のユーザビリティの重要性を理解できるようサポートします。  

4. デザイン部門と他部門のコミュニケーションの橋渡し

多くのデザイン関係者は、組織内のサイロ解消がいかに難しいかを指摘しており、デザイン変更管理には、デザインチームメンバー間だけでなく、他部門との間でも明確で曖昧さのないコミュニケーションが必要になります。  

デザイン変更管理とデザイン思考を常に提唱している社内デザインコンサルタントは、そのシステムでいかに仕事が楽になるかを、他の部署や担当者が理解するのに長けています。彼らは、システムの複雑性を説明することに長けており、例えば、ソフトウェアデベロッパーにシステムの機能やブランディング戦略における役割を伝えることで、デベロッパーとデザインチームとの連携をより円滑にすることができるのです。

ただ、このような最新のプロセスには、円滑なコミュニケーションだけでなく、適切なツールも必要です。UXPin Mergeのような技術スタックは、デザインチームがUI、UXデザイナーとデベロッパー間の穴埋めをするのに、彼らを信頼できる唯一の情報源（Single source of truth）に合わせることで、より密接した作業環境や、孤立した邪魔なサイロの軽減に繋がるのです。

このようなツールがどのように役立つかを示す素晴らしい例として、影響力のあるデザイン運営の第一人者、デイブ・マルーフ氏によるものがあります。彼はウェビナーで、社内コンサルタントはこのようなソフトウェアで、信頼できる唯一の情報源（Single source of truth）を活かし、デザインチームと部門間の溝を埋めることによって、組織におけるサイロを解消できると述べています。

社内デザインコンサルタントを配置するには

では、デザイン運営に社内デザインコンサルタントを加えることを検討されているのですね。いいですね！ただし、始める前に計画が必要であり、社内デザインコンサルタントを始める前に、デザイン思考の哲学を採用し、伝えることから始まるのです。

ステップ1：コミュニケーション

デザイン業界では、社内デザインコンサルタントがまだ普及しておらず、外部デザインコンサルタントへのデザインシステムのレビューやアップデートの依頼に慣れているか、コンサルタント業務を自ら行うことをすでに習得している場合が多いようです。

社内デザインコンサルタントを置く目的は、チームのパフォーマンス向上であることを覚えておきましょう。なので事前に必ずコミュニケーションをとり、チームと連携しましょう。なぜ社内コンサルタントを配置するのか、専任のコンサルタントを配置することでどのようにデザインの負担が軽減され、問題解決に役立ち、デザイン思考の一貫性を確保できるのかを確実に理解してもらいましょう。

ステップ2: 目的の明確化

目標がなければ、コンサルタントもチームも、自分たちが目指す成果物がわからず、闇雲に作業することになります。よって次のステップでは、早い段階から社内デザインコンサルタントの目標を明確に定めます。 

そのようなコンサルタントの目的には、以下のようなものがあります：

• マーケティングチームが新規ビジネスを呼び込むためのメールフローを見直し、CX（カスタマーエクスペリエンス）を上げるのをサポート
• カスタマーサクセスチームによるアカウント解約プロセスのUX（ユーザーエクスペリエンス）向上へのアシスト
• デザインチームとデベロッパーの連携と連絡を促し、信頼できる唯一の情報源（Single source of truth）を中心としたデザインの仕組みの導入
• 見込み客のコンバージョンプロセスをより効率的にデザインするための営業部門との連携
• 企業のブランディングチームと連携し、企業の最新情報についてのより魅力的なメディアリリースの予定や、製品の優れたデザインを紹介するためのSNS戦略の見直しをサポート

ステップ3: コンサルティングを始める

次に、作業を始めましょう。デザインチームと連携し、社内デザインコンサルタントの目的を明確に定めて伝え、コンサルタントを見つけたら、その任務の遂行を開始します。

他部門と関わりを持ちましょう。協議、観察、テストを実行し、チームとのブレインストーミング、プロセスの監査と更新、フィードバックの獲得、目標に到達したかどうかの報告をしましょう。  

ステップ4：測定と学習

作業を実行に移す時間ができたら、結果を測定して分析し、作業の微調整が必要になります。チームからフィードバックを求め、データを分析し、改善すべき点があればそこを指摘します。間違いが見つかったら、それを教訓にして、デザイン戦略を修正しましょう。

完成したら、測定した結果と最初に設定した目標との比較が必要です。目標に到達していれば、引き続きコンサルティングを行い、改良を加えましょう。そうでない場合は、もう一度最初からやり直しましょう。

このヒントで最高のデザインコンサルタントを輩出しよう

デザインチームのニーズが進化し、より複雑になるにつれ、デザイン会社や組織は、社内デザインコンサルタントの雇用、トレーニング及び育成の利点と可能性が、外部コンサルタントの導入の必要性を上回っていることに気づきました。

社内デザインコンサルタントは、スポーツチームのキャプテンとして新しいシーズンに向けてチームを安定させ、新たな高みへと導いてくれる存在だと考えてください。彼らの仕事は、パフォーマンスを上げ、「プレーヤー」の能力を最大限に引き出すことなのです。  

社内デザインコンサルタントは、すでにデザインサービスにおける重要性を示しており、近い将来、あらゆる職場でデザイン思考の重要な推進力となることでしょう。彼らは、製品デザインプロセスにおける一貫性を確保し、デザイナーが目指すものと、デベロッパーがデザインシステムの必要性をどのように理解しているかとの間のギャップを埋めるサポートをします。  

生産性を上げよう

社内デザインコンサルタントはデザイン思考の完璧な支持者であり、UXPinのようなデザインツールで武装することで、デザインチームを最大限に活かし、生産性を上げることができるようになったのです。

UXPinには「Merge」という技術があり、デジタル製品の構成要素である機能的なUIコンポーネントを正確に使ってプロトタイプを構築することができ、事実上、デザインのハンドオフがよりスムーズになります。デベロッパーは、構築する必要があるものを正確に把握することができ、デザイン要素の背後にあるコードをコピーして、そのプロセスで使うことができます。その結果、デザインと開発間の透明性が高まり、会社全体がより明確になるのです。

The post デザインとコンサルティング – 社内コンサルティングのメリットとは appeared first on Studio by UXPin.

2022年5月、UXPinはDelivery Hero MENA（中東・北アフリカ地域（talabat））のDesignOpsディレクターであるアンバー・ジャビーン氏をお迎えし、「Enterprise Design System – How to Build and Scale.」と題したウェビナーを開催しました。

本記事では、彼女の講演の一部を要約し、デザインシステムの賛同を得る際にチームが直面した課題と、彼女ならどうするかということについてお話します。

アンバーは、UXPinの無料eBook「 DesignOps 101: Guide to Design Operations」の共同執筆者です。この本は6つの章からなり、DesignOpsの紹介とその実践法が説明されています。

UXPinでデザインシステムを構築、拡張、共有、成熟させましょう。

デザインシステムの賛同を勝ち取るために多くのチームが行っていること

2019年、Delivery Heroは、多くのスタートアップが経験する、あまりにも身近な困難に見舞われていました。UIライブラリやデザインシステムもないまま、9つのチームが製品に取り組んでいたことにより、Delivery Heroはサイロを生み出し、重複が多く、拡張しにくく、結果的に「非常に断片的なUX（ユーザーエクスペリエンス ）」になっていたのです。

アンバーとそのチームは、デザインシステムこそが、自分たちの問題を解決するイチバンの方法だと考え、ステークホルダーの賛同を得るためのケース作りに取りかかりました。

デザイン監査の実施

Delivery Heroの製品チームは、まずデザイン監査から始めました。そして監査報告書では、以下のような多くのユーザーインターフェースの不整合が明らかになったのです：

• 数種類のCTA（Call To Action）
• タイポグラフィ・スタイリング基準なし
• 複数のアイコン形式

アンバーは講演の中で、「…私たちのデザイン言語は、あちこちにあったのです。これは、大きな気づきの瞬間でした。」と言っています

チームは監査報告書をもとにビジネスケースを構築し、Delivery Heroの幹部に提示した結果、アプリ再デザインの賛同を得ることができました。

製品チームはまず、主要な画面とユーザーフローの再デザインを行いました。新しいデザインは、より一貫性があり、クリーンで、ブランドとの整合性が高く、UXを上げるものでした。

UIパターンでUIライブラリーを構築する

製品チームはこの再デザインをもとに、色、タイポグラフィー、立面図、UIパターン、コンポーネントなどのUIキットとスタイルガイドを作成しました。

Delivery Heroの製品部門は規模を拡大し、新しいデザイナーを採用しました。アンバーは、「このような規模の拡大にもかかわらず、Delivery Heroのデザインプロジェクト全体の一貫性が向上し、デザインを拡張することができた」と述べています。

コンポーネント・ライブラリ構築の初挑戦

デザイナー向けの信頼できる唯一の情報源（Single source of truth）のデザインに成功したDelivery Heroの製品チームは、エンジニアリング向けにも同じことをしたいと考えていました。そこでアンバーと彼女のチームは、コンポーネントライブラリのための別のビジネスケースをまとめました。

ビジネスケースのDelivery Heroデザインシステムの主要な利点を以下にまとめました：

• デザイン – 開発間の信頼できる唯一の情報源（SSOT）
• より良いUX（ユーザーエクスペリエンス）
• ブランドとの親和性強化
• 実験、プロトタイピング、テストの迅速化

Delivery Heroの幹部は、プレゼンテーションを気に入り、製品チームの提案に価値を見いだしました。 なのに、デザインシステムを作るお金もリソースもなかったことから、コード・コンポーネント・ライブラリの構築の答えは「ノー」だったのです！! 

アプローチの練り直し

アンバーのチームは、もう一度振り出しに戻って、スタイルガイドを使った新しいデザインをアプリ全体に展開することにしたのです。このプロジェクトには3ヶ月を要しましたが、製品開発チームにとっては大成功でした。

その後6ヶ月の間に、Delivery Heroはたくさんの新機能と実験結果を出しました。製品チームの新しいデザインは新鮮で一貫性がありましたが、エンジニアにとっての信頼できる情報源がないため、Delivery Heroの最終的なリリースに一貫性がないという問題がありました。

製品チームは、一連の監査を再度行うことにして、そこでデザインハンドオフとプロダクションのスクリーンショットを撮った結果、コンテンツやUI要素の欠落など、多くの矛盾が明らかになりました。この監査で、Delivery Heroがリリースごとに負債を積み重ねていることがわかったのです。

Delivery Heroのデザインシステムに対する説得力のある事例の構築

Delivery Heroのデザインシステムチームにはエンジニアがいなかったので、デベロッパーと組んで、幹部に新しい売り込みをするためのコンポーネントを作り、テストする必要がありました。

アンバーのチームは、Delivery Hero の【No results】画面用のコンポーネントを作成し、デザイン システムを「使用する場合」と「使用しない場合」とで比較して実験しました

• デザインシステムなしで構築 – 合計時間：7.5時間
• 再利用可能なコンポーネントとして構築 – 合計時間：3.25時間

製品チームは、フロントエンドの開発時間のみを記録しました。この実験では、再利用可能なコンポーネントによって、フロントエンドの労力が57%削減され、負債が0%になることが実証されました。

アンバーのチームが、この新しいデータを使って、コンポーネントライブラリ構築のための別の事例を提示すると、Delivery Heroの幹部はこの結果に感動し、デザインシステムの開発にゴーサインを出したのです。

そして現在、Delivery HeroのデザインシステムであるMarshmallowは、デザインシステム専門チームが管理するUIキットとコードUIライブラリの30以上のコンポーネントを持ち、デザインと開発を一元化しています。

Marshmallowには、以下のものがあります：

• デザインシステムのウェブサイト
• 専用Slackチャンネル
• ブランド、コード、デザイン、コピーなどのガイドライン 
• デザイン言語
• 作業やコミュニケーションのためのプロトコル
• コードコンポーネントライブラリ
• アイコンのテンプレート
• UIキット
• UIサンプル
• デザインシステムガバナンスの手順

ゼロからのデザインシステムの作り方はこちらでご覧になれます：Design Systems: Step-by-Step Guide to Creating Your Own.

企業向けデザインシステム構築のための賛同取得と拡張

アンバーは、学んだことを振り返りながら、企業向けデザインシステムへの賛同を得るための6つのアドバイスをしています。

本当のペインポイントから始める

製品、ユーザー、ビジネスに悪影響を及ぼしているペインポイントを特定することは、重要な第一歩です。アンバーとそのチームは、監査システムを使って、デザインと開発の間に大きなずれがあることを突き止めました。

価値提案の構築

ビジネスケースのための価値提案の構築に、ペインポイント（複数可）を使いましょう。そして解決策は、問題を解決し、ステークホルダーに投資対効果をもたらすものでなければなりません。

最大の支援者とスポンサーを特定する

アンバーは、デザインシステムの売り込みを裏付けるために、他部署からの支持者を探すことを勧めています。その支持者は、1, “これは会社にとって本当の問題である” 2, “これは最良の解決策である “というあなたの主張を支持してくれるでしょう。

語る前に見せる

アンバーは、最初のプレゼンテーションで犯したミスは、証拠なしにストーリーを語ったことだと言います。そこで、コンポーネントライブラリで何ができるかをステークホルダーに見せると、チームの話はより説得力を増し、ビジネスケースも納得のいくものになりました。

ビジネスメトリクスを語る

“シナリオのビジネスケースを、KPIやビジネスに影響を与えるメトリクスと関連付けなければ、ストーリーは完成しません。” アンバー・ジャビーン氏

さらに、ビジネスケースには、この問題がどのように会社のリソースに負担をかけているのか、そしてその解決策によって何ができるのかを示す、デザインシステムのメトリクスが含まれていなければいけないと言います。

一人でしない：ネットワークを築く

技術、デザイン、製品、マーケティング、顧客サービスなど、部門を超えたパートナーのネットワークとしてビジネスケースを売り込み、デザインシステムが、組織のための解決策であり、デザインチームの負担を軽くするためだけのものではないことを証明しましょう。

アンバーの1時間のウェビナー全体はYouTubeでご覧になれます。

UXPinによるコードベースのデザインシステム

UXPin独自のMergeの技術により、デザインシステムのコンポーネントライブラリとUXPinのエディタを同期させ、デザインと開発の間に信頼できる唯一の情報源（SSOT）を作成することができます。

The post 企業デザインシステムの構築と拡張に関する11の教訓 appeared first on Studio by UXPin.

2022年5月、UXPinはデリバリーヒーローMENA（Talabat）のDesignOps DirectorであるAmber Jabeen氏を招き、「エンタープライズデザインシステム – 構築と拡張の方法」と題したウェビナーを開催しました。本記事では、彼女の講演の後半にあたる、デリバリーヒーローのデザインシステム採用戦略に焦点を当てた内容をご紹介します。ちなみに、概要については当社のブログに掲載されています。

「デザインシステムの成功は、その採用にかかっており、ユーザーに使ってもらうまでは、成功とは言えないのです。」 – アンバー・ジャビーン氏

UXPin Mergeで、より優れたデザインシステムの採用、一貫性、結束を実現しませんか？デザイン システムのコンポーネント ライブラリを UXPin のデザイン エディタに同期させ、組織全体で信頼できる唯一の情報源（Singe soruce of truth）を作成しましょう。今すぐアクセスをリクエストし、Mergeの技術をぜひご体験ください。

デリバリーヒーローの3つの導入戦略

アンバーと彼女のチームは、様々な取り組みを試した結果、デリバリーヒーローのために以下の3つの要素からなるデザインシステム採用戦略を開発しました。

• ゲーム化
• ソーシャル化
• 称賛

「一貫した楽しい 」ビジョン

アンバーのチームは、デザインシステムを他の製品と同じように扱うことが、採用率を高めるのに必要だと考えました。そこでまず、戦略の指針となる「ノーススター」を定めました。

ステークホルダーやチームメンバーからの意見を参考に、チームは「すべてのプラットフォームで、一貫した楽しいユーザー体験を提供しよう」と考えました。

デザインシステムチームは、ビジョンのモットーや理念を強調するのに、一貫した楽しさを全面に出しました。

一貫した（モットー）：

「いつも…例外なく。考えるまでもない。」 デザインの一貫性により、ユーザーはUIやその機能を覚える必要がなく、より直感的なユーザーエクスペリエンスが得られるという考え方です。

楽しさ：

• talabatの配慮：製品体験では、デザインシステムのユーザーと製品のエンドユーザーの両方のユーザーを大切にすることを示すことが必要
• あなたのために：個別化された体験
• 速い：配送業者として、お届けは速やかに行いたい
• シンプル：直感的なユーザーインターフェース
• 楽しい：楽しいユーザー体験

明確なビジョンを持って、デリバリーヒーローのデザインシステムチームは、3つの要素からなる採用戦略を立てました。

第一の要素：ゲーム化

第一の要素は、ゲーム化です。チームは、新システムの導入に気付いていました。それはつまり、多くのメンバーが既存のテンプレートを捨て、ゼロから作り直さなければならなかったのです。そこでデリバリーヒーローは、ゲーム化戦略によって、デザインシステムへの切り替えを楽しく、競争的なものにしました。

採用段階

デザインシステム（DS）チームは、システムのビジョンに沿ってゲーム化された採用段階をデザインしました。その目的は、チームメンバーに小さなことから使い始めてもらってその規模を拡大してもらうことでした。DSチームは、ビデオゲームのような感じで、ある「レベル」をクリアすると、次のステージに進むようにユーザーを促したのです。

• ブロンズ：基礎（デザイントークン）
• シルバー：一貫性と纏まり（コンポーネント）
• ゴールド：楽しい体験（音声と音、マイクロインタラクション、ハプティクス、トランジション）
• プラチナ：もっと上を行く体験（モーション、ダークテーマ、ボイスUI）

デザインチームは、デザインシステムの階層と関連するUIパターンをポスターにしてワークスペースに貼り、「ゲーム」と「レベル」を連想させるようにしました。

デザインシステムのダッシュボード

チームメンバーにとって、進歩のために何をしなければならないかを知るための進捗状況の可視化は重要でした。そこでDSチームは、Discovery Squadのダッシュボードを作成し、ユーザーの採用状況や次の階層への進捗を可視化しました。

第二の要素：ソーシャル化

デザインシステムの戦略の2つ目の要素は、「コミュニティ主導でデザインシステムをソーシャル化し、人々の投資と関心を維持する 」ことでした。

デリバリーヒーローのソーシャル化施策には、「楽しさ」と「包容力」という一貫したテーマがあることにお気づきでしょう。そしてそれはデザインシステムのビジョンに沿っていますよね。

デザインシステムの名付け大会

ンバーのチームは、「デリバリーヒーロー」のデザインシステムの命名に参加するよう、みんなに呼びかけました。社内にメールを送り、名前を募集したのです。

その結果、2つの選択肢に絞られ、「マシュマロデザインシステム 」が選ばれました。デリバリーヒーローの社員は、自分たちが名付けのプロセスに参加したことで、マシュマロに愛着を感じているようです。

チームメンバーがすぐに投資し、参加してくれたことから、この戦略はデザインシステムチームにとって成功でした。

マシュマロのアバター、ハッシュタグ、絵文字

マシュマロのアイデンティティを確立し、認知度を高めるために、DSチームはアバター、ハッシュタグ、絵文字を作成し、社内のやりとりで使用しています。

デザインシステム展示イベントの開催

チームは、ユーザーと交流するイベントを開催し、以下の質問を投げかけるなどして、生の声やディスカッションを促しました：

• 私たち（デザインシステム・チーム）についてどう思いますか？
• デザインシステムでの仕事はどうですか？

ユーザーから新しいインサイトやアイデアを集め、デザインシステムを改善することが目的でしたが、みんな自分の意見を聞いてもらえたと感じ、自分がデザインシステムに貢献しているとわかったら、そのデザインシステムに愛着が湧いて支持者となり、ゆくゆくは更なる採用につながるのです。

また、チームメンバーにマシュマロがふるまわれるなど、明るく楽しいイベントも開催されました。

フィードバックのアンケート

DS チームは、デザインシステムのさまざまな部分についてさらに関与し、フィードバックを集めるのにアンケートを使いました。

デザインシステム組合

マシュマロデザインシステム組合には、互いに学び合い、マシュマロコミュニティを成長させるという目的の下、デリバリーヒーローの各ブランドのチームメンバーが参加し、課題の議論や、アイデアの共有がなされました。

メールマガジン

マシュマロのメールマガジンは、デザインシステムチームのユーザーとの最新情報の共有、ステークホルダーへの情報の提供や会話の一部になるサポートになりました。

第三の要素：称賛

アンバーは講演の中で、プロセスの称賛が採用戦略の最も重要な要素であると述べています。マシュマロチームでは、100%の採用に向けて前進している象徴として、どんな小さな成功も認めて称えます。

「小さな勝利を称えて、それが本当に大きな勝利につながったのです」– アンバー・ジャビーン氏

アンバーが言うように、チームは「それがとても上手」でした。例えば、マシュマロのデザイン言語の70％を完成させるなど、重要なマイルストーンに到達すると、彼らは祝杯をあげました。社内のさまざまなチャネルで、色々な功績を称えました。写真やビデオを使って、組織全体でその瞬間を共有したのです。

アンバーはプレゼンテーションの中でこう述べています：

• 毎月のニュースレター、All Hands、Slackチャンネルなどで、各隊の採用層を祝いました。
• 採用された階層を称えることで、チームはより大きな目標に向かって前進し続けることができ、貢献を促すことができました。
• 次のステップは、デザインシステムへの貢献に対する報奨を始めることです。例えば、それを組織の業績評価の一部にすることで、採用や貢献が促進されるでしょう。

「デザインシステムを構築することはできても、健全な有機的貢献がなければ、それを拡張することはできません。それにはシステムに貢献する人々に報酬を与えるのがいい方法です。」– アンバー・ジャビーン氏

成果の表示

マシュマロチームは成長を測定し、グラフを使ってチームメンバーやステークホルダーに結果を提示しました。以下はDSチームの主な成果です：

• マシュマロによって、前月比で約20％のデザイン負債が削減されました。DSチームは、最初の実験からこの影響を測定することができました。デリバリーヒーローのデザインシステムに対する賛同を得る方法については、こちら（No link)をご覧ください。
• 製品のコンポーネントライブラリの80%をデザインすることで、DSチームは創造性と新しいコンポーネントのための余地を残し、マシュマロのコンポーネントライブラリは、新機能のフロントエンドの労力を約40%削減しました。
• コンポーネントの採用＝一貫性があり纏まりのあるエクスペリエンス：デベロッパーは、ライブラリにないコンポーネントに気づいたとき、マシュマロチームに連絡を取り、アドバイスを求め、それがデザインシステムの拡張に関する会話を促します。

マシュマロの成功戦略

• デザインシステムの構築と運営には、同士が必要であり、部門横断的なパートナーシップの構築が必要：デザインシステム専門のチームがあっても、ステークホルダー、リーダー、チームメンバーの協力と支持があってこそ、成功につながるのです。
• コミュニティ主導での持続可能な採用戦略：デザインシステムを拡張したい場合は、その成長と成功のために全員を結集させる戦略をデザインすることで、組織全体を取り込む方法を見つけましょう。いつでも対応可能で、チームメンバーとつながり、デザインシステムのユーザーに 5 つ星のサービスを提供しましょう。
• 小さな成功を認めて讃える：「第三の要素」で説明したように、小さな成功を祝うことは、大きな勝利と幅広い導入につながります。人は認められることを好むので、進歩を祝い、奨励しましょう。
• 成功の数値化と360度にわたるコミュニケーション：成功は、価値提案と達成しようとしたことに基づいています。デザインシステムの目標達成に向けた進捗状況を示すのにメトリクスを使いましょう。ステークホルダー、パートナー、スポンサー、チームメンバーなど、この進捗状況を、組織の全員にまんべんなく伝えましょう。
• 洗い出しと繰り返し！： アンバーは、うまくいくものを見つけ、組織全体に採用を拡大するのにその戦略を繰り返していくことが重要だと言います。

デリバリーヒーローがマシュマロデザインシステムを構築するまでの完全なストーリーは、アンバー・ジャビーン氏の講演「エンタープライズデザインシステム – 構築と拡張の方法」で見ることができます。

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

デリバリーヒーローの話から分かるように、デザインシステムを拡張し、組織全体に普及させるのは大変なことです。

DSチームは、デザイナーにはUIキットを、エンジニアにはコンポーネントライブラリを使うように促さなければなりません。どんなに優れたデザインシステムであっても、デザイナーとエンジニアでは話す言語が違うのです。

UXPin Mergeがあれば、デザイナーとエンジニアはまったく同じコンポーネントライブラリを使用することができます。Mergeは、レポジトリからUXPinのエディタにコンポーネントを同期し、エンジニアが最終製品に使用するのと同じインタラクティブなコードコンポーネントを、デザインチームがプロトタイプの作成に使用できるようにします。

デザインシステムチームは、各コンポーネントのプロップ、又は、Storybookの統合とではArgsをインタラクションすることも含めてプログラミングできるので、デザイナーは製品作りに専念するだけです。簡単なワークフローと少ない作業で、より楽しく、より広く普及させることができます。

Merge へのアクセス権をリクエストして、世界最先端のコードベースのデザインツールで、部門を超えた連携を強化しながらデザインシステムを拡張する方法をぜひご覧ください。

The post デリバリーヒーロー（Talabat）デザインシステムの採用 appeared first on Studio by UXPin.

  フィンテック  （FinTech：金融機関に関するテック）はどの分野にとっても一筋縄ではいかない業界ですが、特にUXデザイナーにとってはそうでしょう。 フィンテック のデザインにおいて、デザイナーは州や国によって異なる金融規制を勉強しなければならず、その金融規制は詳細かつ広範であることが多いです。ということは、デザイナーはプロジェクトの始動前に多くの読み物が必要であるということです。

本記事では、 フィンテック 製品デザインの基本について、製品がユーザーに優しく、コンプライアンスに適合し、顧客に最大限の価値を提供するためのベストプラクティスを含めてお話します。

UXPinは、暗号通貨製品をデザインするフィンテックスタートアップ企業でも、モバイルバンキングアプリに革命を起こそうとしている既存の多国籍企業でも、より高い忠実度と機能を備えたプロトタイプとテストのための洗練されたコードベースデザインツールをUXデザイナーに提供します。無料トライアルにぜひサインアップして、UXPinの高度なコードベースの機能をぜひすべてご体験ください。

 フィンテック とは

フィンテック（Financial Technology）とは、金融テクノロジーの製品やサービスを生み出す市場部門を指し、このような金融商品には、業界の革新と改善を目指すアプリケーション、API、あるいはアルゴリズムが含まれます。

フィンテック の例

以下は、フィンテックの例です：

• ネットバンキング（ネオバンクとも呼ばれる）：Monzo (イギリス)、Chime (アメリカ)
• デジタルお財布： Payoneer、Skrill、Revolut
• 決済サービス：PayPal、Venmo、Cash App、Stripe
• 投資サービス：Robinhood、Betterment
• 暗号化商品:：Coinbase、Ripple

フィンテックの事例については、Insider Intelligenceのフィンテックスタートアップの記事をご覧ください。

 フィンテック のUXデザインの課題

1. コンプライアンスへの挑戦

企業コンプライアンスは、フィンテックデザインの最大の課題の1つです。複数の国や世界中のユーザーを対象に製品をデザインする場合、異なった法律に準拠するために市場ごとにデザインを変更することがあります。

例えば、AML（マネーロンダリング防止）やKYC（顧客情報保護）などの規制には、オンボーディングやユーザーフローに影響を与える詳細なプロトコルがあり、こういった規制には、ユーザーの識別、プライバシー、不正防止、アクセシビリティ、さらにはテロリズムなどに関する複雑なレイヤーが追加されています。

さらに複雑なことに、州や国がこのような法律を定期的に更新したり、新しい法律を導入したりするため、UX研究者やデザイナーは、コンプライアンスの維持のためにデザインを修正しなければならず、それによって製品のロードマップやUX戦略がぐちゃぐちゃになってしまう可能性があります。

2. 顧客の期待に応える

規制とは別に、UXデザイナーは、レガシー（旧式）バンキングや金融サービスからの顧客の期待も乗り越えなければなりません。例えば、多くのネオバンクは顧客のために実店舗を持たないので、アプリは対面での体験を再現するツールや機能を提供しなければなりません。

3. 製品の複雑さへの対応

フィンテックデザインのもう一つの課題は、製品の複雑さと、UXデザイナーがまとまりのあるエコシステムをどのように作るかであり、フォーブス誌では、それを「断片化から生態系への転換 」と表現しています。

従来の銀行や金融機関は、クレジット、小切手、預金、住宅ローン、ローンなど、商品ごとに異なる部門が担当しています。デザインチームは、適切な連絡と連携がなければ、シームレスな顧客体験を提供する全体的なエコシステムではなく、断片的な製品をデザインしてしまう危険性があります。

セキュリティプロトコル

フィンテックのセキュリティプロトコルは、UXのワークフローや、デザイナーがリサーチを実施、共有、保存、分析する方法に影響を及ぼします。UXチームは、ISO-27001（ISMSの要求事項などをまとめた規格）やISO-27002（実践規範の規格）など、さまざまなセキュリティプロトコルに準拠する必要があります。

また、UXデザイナーは、安全なパスワード、OTP（ワンタイムピン）の共有、テキストや電子メールのリンクに注意するなど、安全な習慣を採用するようユーザーに促す必要があります。

 フィンテック アプリデザインの8つのヒント

1. クリーンなUIデザイン

クリーンでミニマルなUIはあらゆるデジタル製品に不可欠ですが、免責事項やポリシーへのリンク、その他の必要な情報を掲載するスペースを確保しなければならないことが多いフィンテックのデザインだとなおさらです。

段階的開示は、複雑なフィンテック UIをデザインする際によく使われる戦略です。UXデザイナーは、重要かつ必要なコンテンツのみをユーザーに表示し、その他の情報はツールチップ、ドロップダウン、アコーディオン、モーダル、その他のUXパターンの背後に「隠す」のです。

段階的開示のアプローチにより、デザイナーはきれいなUIを作りながら、ユーザーが必要なときにコンテンツを提供することができます。

2. 明確でシンプルな言語

金融商品・サービスは、その条件が長く複雑で、多くの人が理解できないことで知られています。

言葉を簡素化し、ユーザーに明確な予測を持たせることは、フィンテック製品のデザインにおいて非常に重要です。また、それによって金融の専門用語やその意味を理解していないユーザーとの信頼関係も構築できるのです。

例えば、クレジットの申し込みは、ユーザーのクレジットスコアに影響を与える可能性があります。UXデザイナーは、モバイル画面の制約がある中で、このような重要な情報を通常は数個の箇条書きで説明をしなければいけません。

3. アクセシビリティ

アクセシビリティはあらゆるデジタル製品に不可欠ですが、フィンテックのデザインには特に重要です。ノルウェーやオーストラリアなどの国では、製品はウェブコンテンツのアクセシビリティに関するガイドライン　(WCAG) 2.0 レベルAA基準を満たさなければいけません。

こちらのPowerMapperの記事には、国とその関連するアクセシビリティ要件の一覧があります。

4. 有益な可視化

データを視覚化することで、ユーザーは情報を素早く消化し、理解することができます。UXデザイナーは、例えば収入と支出のように、数字を分けるのに色を使うこともできます。

5. 適切なキーパッドの使用

モバイル端末でフォームを入力する場合、ユーザーは数字、文字、特殊記号を切り替えて入力する必要があります。フィンテックのフォームは、一般的に他のデジタル製品よりも長く、ユーザーが入力する項目も多くなっています。

UXデザイナーは、モバイル機器に以下のようなどのキーパッドを使用するかを指示することで、このプロセスを効率化することができます：

• 数字優先のキーパッド
• 日付ピッカー
• 電子メールフィールド（デフォルトで@と.comが表示されるようにする。）

6. 説明的で有益なCTA（Call To Action）の使用

CTAをクリックすると何が起こるかについて、ユーザーに誤解があってはいけません。例えば、誰かがローンの申し込みをする場合、フォームのCTAは通常の 【送る】や【送信 】ではなく【適用 】でなければなりません。

7. 助ける、妨げない

しかし残念なことに、デジタル製品では、顧客がサービスをキャンセルしたりダウングレードしたりするための機能が隠されていることがまだよくあります。UXデザイナーは、顧客の購読終了やオプトアウトを可能にするものも含めて、ユーザーがタスクを完了できるよう、常にサポートしなければいけません。

管轄区域によっては、有料サービスのオプトアウトに関する明確なガイドラインがある場合もありますので、デザインが規制やベストプラクティスを満たしていることを常に確認しましょう。

8. モバイル向けの最適化

多くのユーザー（特に30代以下）は、モバイルアプリやブラウザーを通じて、モバイルでタスクを完了したいと考えています。フィンテック製品にモバイルアプリがない場合、ウェブサイトやウェブアプリがモバイルユーザー向けに最適化され、デスクトップと同じ体験が提供されるようにしましょう。

モバイルアプリの場合、ユーザーが確実にデスクトップと同じタスクを実行できるようにしておく必要があります。多くの製品では、モバイルアプリでできることが制限されており、これが不満の原因になったり、サービスのダウングレードや定期的な支払いのキャンセルができないなど、マイナスの影響を与えることがあります。

フィンテックのユーザビリティに関するよくある課題の克服

ここでは、フィンテック UXの一般的なシナリオとその克服方法をご紹介します。この例は、GoogleのUX Playbook for Financeから引用しています。

ユーザーへの教育とコンバージョン

デザイナーが直面する課題の1つは、複雑な金融商品についてユーザーを教育しながら、コンバージョンさせることです。ここでは、典型的なモバイルオンボーディングフローの推奨例を紹介します：

• 箇条書きで提供品と規制情報をまとめる
• スクロールを減らし、コンバージョンの可能性を高めるために、価値提案をCTAとともにフォールドの上に配置する
• オンボーディングフォームの冒頭に価値提案を繰り返す
• 信用と信頼を築くために、TrustPilotウィジェットなどのソーシャルプルーフを含める。
• 「サインアップして見積もりを入手する 」など、明確なCTAを使用する
• 既存ユーザーが新しい製品やサービスを申し込む際に、フォームのフィールドを予め埋めておく
• プログレスバーを使用して、ユーザーがプロセスのどの段階にいるのかを表示する

大容量データの表示

フィンテック製品は、多くのデータを1つの画面に表示しなければならないことが多く、特に面積の限られたモバイルデバイスでは困難です。ここでは、スペースを最大限に活用し、認知負荷を軽減するための推奨事項をご紹介します：

• メインのCTAは説明的なラベルで確実に目立たせる
• 二次的CTAにはアウトラインボタンやゴーストボタンを使う
• コンテンツの区切りには、色と一定の間隔を使う
• 見出しと本文の区別を明確にする
• 読みやすく、読みやすい書体を使用する
• 二次的コンテンツはカルーセル、アコーディオン、ツールチップの後ろに隠す

長文フォームの効率化

フィンテック製品は、法律の準拠のために多くの個人情報の収集が必要なことがよくあります。このようなフォームには長い時間がかかり、ユーザーにとっては圧倒されるように見えるかもしれません。そこで、長いフォームを効率化するためのヒントをご紹介します：

• 期待に応えるべく、フォームの入力にかかると思われる時間を最初にユーザーに伝える
• フォームをセクションに分割し、ステップに分け、ユーザーがいつでも簡単に前後に移動できるようにする
• ユーザーがあとどれくらい完了しなければならないかを示すために、進捗状況を示すインジケータを使用する
• 申し込みに必要な情報のみを尋ね、本人の肩書きや性別、人種など、金融機関にとって無関係な余計な項目は避ける
• 選択肢が3つ以下の場合は、ドロップダウンメニューを使用せずラジオやチェックボックスを使用して、素早い選択を可能にする
• ユーザーが時間のあるときに戻れるように、進捗状況を保存できるようにする
• 生年月日、連絡先番号、米国の郵便番号、クレジットカード番号などの適切なフィールドには、テンキーを使用する
• ユーザーを案内するプレースホルダとエラーメッセージを提供し、エラーメッセージには、ユーザーが問題を解決するための明確で実行可能な指示を必ず付ける

PayPalがUXPin Mergeを使用して製品を8倍速く構築する方法

PayPalは、200カ国以上、25通貨をサポートする世界最大級の決済プラットフォームです。2019年、PayPalの社内製品開発チームはUXPin Mergeの使用を開始し、デザインの拡張と製品の提供を8倍速く行えるようになりました。

Mergeとは

Mergeは、コンポーネントライブラリをUXPinのエディタに同期させるデザイン技術で、デベロッパーが製品段階で使用するUI要素を完全にコード化し、デザイナーがプロトタイプを作成できるようにします。

PayPalのMergeはどのように機能したか

PayPal は Merge を使用して、Microsoft の Fluent デザインシステムと UI コントロールを同期させています。各 React コンポーネントのプロップを通じてすべてが事前に設定されているため、PayPal の製品デザイナーはそのコンポーネントをドラッグ＆ドロップして新しいユーザーインターフェースの構築ができるのです。

PayPalのUXチームは、デザイン、プロトタイプ、およびテストの90%をデザインハンドオフ前に完了する製品チームに指導とサポートを提供していますが、UXデザイナーが丸一日かけて行っていた作業を、プロダクトマネージャーは10分以内で、しかも忠実度や機能性を大幅に向上させながら完了させることができるのです。

このプロトタイプには、完全に機能するグラフやデータの可視化、ソートフィルター、実データ、動的なユーザー体験など、画像ベースのプロトタイプでは実現できなかった機能が含まれています。

MergeのプロトタイプはPayPalのユーザビリティテストの改善だけでなく、ステークホルダーがガイドや説明なしにプロトタイプに関与することができます。

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

UXPin Merge が世界最大の フィンテック企業のワークフローに革命をもたらすことができるとしたら、このコードベースのテクノロジーがあなたのビジネスに何をもたらすか想像してみてください! 無料トライアルにサインアップし、MUI React ライブラリ統合を通じて UXPin Merge をぜひお試しください。

The post 【フィンテックデザイン】プロダクトデザイナー向けUXのヒント appeared first on Studio by UXPin.

PaypalのUX Lead EPXであるエリカ・ライダー氏 とPayPalは、UXPinを知らないわけではありません。彼女は長年にわたってUXPin Mergeを賞賛し、この技術がPayPalの社内製品開発プロセスにどのような革命をもたらしたかを声高に語っています。

彼女はデザインバリュー会議2022で、デジタル決済の一大企業におけるデザインをスケーリングさせるための新しいフレームワークである、PayPalのDesignOps 2.0について語っています。

PayPalの新製品開発ワークフローの開発において、UXPin Mergeが重要な役割を果たしました。UXPin Merge へのアクセス権をリクエストして UXPin Merge をご体験いただき、コードベースのデザインがエンドツーエンドのデザインプロセスにどのような革命をもたらすかをご覧ください。無料トライアルにサインアップして、MUI ライブラリとの統合によるコードコンポーネントでのデザインで UXPin Merge をぜひお試しください。

従来のDesignOpsとDesignOps 2.0

UXデザイナーが自身を含めて5人しかいない状況で、エリカは従来のDesignOpsモデルがPayPalのニーズに合わないことに気づきました。DesignOpsの原則は、大規模なデザイン組織には有効ですが、5人のチームには合わないのです。

1000人以上のエンジニアを抱えるPayPalのDesignOpsは、デザインと開発を効率化されたエンドツーエンドの製品開発ワークフローに組み込まなければいけませんでした。

DesignOps 2.0には以下が求められました：

• すべてのツールで一貫した予測可能なユーザー体験の提供
• 製品チームが有用で使い勝手の良い製品の提供できるようにする
• 新たなデザイナーを加えることなく、デザインを可能な限り効率よく大幅に拡張する

エリカとチームは、一般的なエンタープライズデザインソリューションをいくつか試した後、DesignOpsとDevOpsのハイブリッドフレームワークを作成する必要があることがわかりました。そこで彼女たちは、DesignOpsを作る代わりに、DevOpsの中でデザインを運用することにしたのです。

担当業務の進化

エリカは、自分のビジョンを実現するための鍵の1つは、UX（ユーザーエクスペリエンス）の責任をUXから組織の他の部分に移すことだと気づきました。デザインをDevOpsに組み込むということは、プロダクトチームとエンジニアリングチームが “良いUX “を持つ製品を提供しなければならないということなのです。

製品チーム

製品チームは、以下のようなUXの責任も負わなければなりませんでした：

• 優れたUXを備えた製品の提供
• UXチームと連携したユーザー調査の実施
• UXチームの指導のもとでのプロトタイプのデザイン

UXチーム

UXデザイナーは、デザイナーからビジョナリーやメンターへと進化を遂げ、部門の責務は以下のように変化していきました：

製品チームのための「自分でするUX」の実現

• PDチームが簡単に学んで使えるデザイン・調査ツール

PDチームへの指導と助言

• チームがチームの デザイン思考やユーザー中心のデザインをまとめる
• プラットフォームにおける各チームの位置づけを理解させる

プラットフォームレベルでのソリューションデザイン

• 共有できるサービスや、大抵の製品で必要とされるサービス

UXの大きな問題の解決

• ユーザーとプラットフォームとの信頼関係をどう築くか
• 定量的・定性的なユーザーデータをプラットフォーム上で直接収集するためのリアルタイムなユーザー調査分析の構築

UXに関するエンジニアリングチームの教育

エリカは、エンジニアが考えるUXを、美観を重視したUIから、ボトルネックやロードブロックを引き起こす問題へとシフトさせる必要がありました。

彼女は、エンジニアの視点からUXを示すために、製品開発のワークフローを作成しました。

• ビルドに失敗したが原因がわからない＝エンジニアのUXがお粗末
• API契約変更があったのを知らなかった。誰に相談すればいいのか＝エンジニアのUXがお粗末

彼女はまた、製品チームやエンジニアリングチームと、UXに関する問題について以下のようにいくつか議論しました：

• レイテンシ：ボタンをクリックしても読み込みに時間がかかるということは、お粗末なUXである
• 可用性：URLが読み込まれないということは、お粗末なUXである
• セキュリティ：もし誰かが私のアカウントをハッキングしたら、それは相当お粗末なUXである
• 「人間が読める」ものではない、あるいはユーザーが解決する術のないエラーメッセージ：なぜ、その意味も解決方法も告げずに、「エラーコード1578-B1273 – 失敗しました！」というメッセージがユーザーに表示されるのか？これもまた、お粗末なUXである。

エリカはこのような例を用いて、UXがフルスタックの問題であることをエンジニアリングチームに伝えました。エンジニアリングの問題、遅延、可用性、セキュリティなど、すべてUXに影響を与えるため、UXはこれら考慮するのです。

PayPalのDesignOps 2.0プロセスを進化させる

エリカが2019年にDesignOps 2.0を発表した当初、それはデザインを拡張し、小規模なデザインチームの作業をしやすくするためのものでした。

現在、彼女とチームは、デザイナーの作業負荷を軽減するためのシステムではなく、より良い製品を提供するための製品チームのためにDesignOps 2.0の最適化を検討しています。

エリカは、ユーザー調査を運用するためのシステムに取り組んでいます。「Getting to DesignOps 2.0」のロードマップには、完了するのに重要な3つのユーザー調査のコンポーネントが以下のようにまだ残っています：

• ユーザーへの理解
• UXの成功度の測定
• PDチームの説明責任

説明責任は、エリカが克服すべき最大の課題の1つであり、ほとんどの企業は、コントロールと説明責任のバランスが大きく崩れています。

• UXデザイナーは、ユーザーに提供されたUXのコントロールは0なのに、説明責任は100%負っている。
• エンジニアは、ユーザーに提供されたUXに対する説明責任は0なのに、コントロールは100％担っている。

優れたUXを持つ素晴らしい製品の提供には、デザイナーとエンジニアはバランスの取れたコントロールと説明責任を持たなければならないと彼女は考えています。UXチームはエンジニアと協力してPayPalの優れたUXを実現しますが、最終的な製品に対して説明責任を負うのはエンジニアなのです。

UXの成功度の測定

エリカとチームは、製品開発プロセスにおけるユーザーの行動と成功率を自動的に追跡するウィザード・ツールを開発しました。このツールによって、UXチームは問題の追跡や特定ができます。

ユーザーメトリクスの継続的かつ自動的な収集：

• デベロッパーは特別なコーディングは不要
• ウィザードコンポーネントのすべてのインスタンスのデータはPayPalのダッシュボードに自動的にフィードされる

完了までの時間や離脱率の追跡：

• ワークフローを完了するまでの総時間
• 各ステップを完了するまでの時間
• 総ドロップオフ率
• 最もドロップオフ率の高いステップ（ステップ固有の問題の特定に使用）

戦略的な割り込みによるリアルタイムの定性データ：

• ユーザーが困っているときに割り込みを発生させる
• ユーザーが条件を満たしたときのみ

ベースライン、ベンチマーク分析搭載：

• 完了までの時間が増えているか減っているか
• 離脱率は改善されているか

PayPalのDesignOps 2.0の詳細な説明と背景については、エリカ・ライダー氏による30分のデザインバリュー会議の講演をごぜひ覧ください。

エリカのチームにおけるUXPin Mergeのスケーリングされたデザイン

UXPin Mergeは、エリカがPayPalの新しい製品開発システムのビジョンを達成する上で極めて重要な役割を果たしました。

Mergeによって、彼女は製品チームが膨大なドキュメントやトレーニングなしに、完全に機能するプロトタイプを構築できるようになったのです。

PayPalは、63のReactプロトタイピングコンポーネントをレポジトリからUXPinのデザインエディタに同期し、製品チームとエンジニアリングチームがまったく同じUI要素を使用することで、組織全体で信頼できる唯一の情報源（Sigle source of truth）を提供します。

エンジニアと協力し、エリカはReactのコンポーネントプロップを使って制約を設定し、デザインの柔軟性を確保しました。このような制約により、PayPalの製品チームは100を超える社内製品に一貫した品質を提供することができます。

UXPin Mergeが5人のデザイナーと1,000人以上のエンジニアからなる企業組織のためにデザインをスケーリングできるとしたら、あなたにとって何ができるかを想像してみてください！

無料トライアルにサインアップして、UXPinに同期されたMUIライブラリのコンポーネントでプロトタイピングを行い、UXPin Mergeをお試しください。アクセス権をリクエストして、ぜひコードコンポーネントを使用したデザインの可能性をすべてご覧ください。

The post PayPalデザインチームを超えたDesignOps：エンジニアと働く秘訣 appeared first on Studio by UXPin.

2022年3月に開催されたUXPinの第1回デザインバリュー会議では、世界最大級の企業におけるデザインとDesignOpsを理解すべく、デザイン業界のリーダー5人が招かれました。

本記事では、「デザインバリュー会議2022」で取り上げられた内容がすべてまとめられ、各講演のあらすじと30分の動画にリンクしています。

デザインバリュー会議 2022は、世界最先端のコラボレーティブプロトタイピングツールであるUXPin Mergeの提供で行われました。無料トライアルにサインアップし、MUI Storybookとの統合を通じてUXPin Mergeをご体験ください。

Merge Component Managerについて：ユーガ・コーダ氏（UXPin CEO）

  UXPin CEOのユーガ・コーダ氏は、デザインバリュー会議 2022の開幕にあたり、エンジニアに頼ることなくコンポーネントライブラリを同期させる新しい方法である、UXPinの新製品「Merge Component Manager」を発表しました。

現在の形態の Merge では、UXPin と同期するコンポーネント ライブラリおよびレポを準備すのにエンジニアの助けが必要ですが、Merge Component Managerだと、コンポーネントを取り込む際のコードは不要です。

Merge Component Manager では、NPM パッケージを通じてコンポーネントのインポートおよび設定ができ、デザイナーはコードレスプロセスにより、UXPin内でコンポーネントのプロパティを設定および管理し、プロトタイプの構築時にコード化されたインタラクションの力を発揮することができます。

ぜひ、まずはあなたからUXPinのMerge Component Manager試してみてください– これでデザイナーはコードコンポーネントを使ってプロトタイプを簡単に作成できます。

マギー・ディエンジャー氏（Uber Eats）

UberのシニアDPM（デザインプログラムマネージャー）であるマギー・ディエンジャー氏が、UberにおけるDesignOpsについて貴重な見解を語ってくれました。

Uberの様々な製品に携わってきたマギーは、複数のチームの規模とあらゆる成熟度において、どのようにDesignOpsに取り組んだかの事例を紹介しました。

こちらが、彼女の講演のポイントです。

フレーミングとスケーリング

マギーは、DPMが効果を最大限発揮するのにどこに時間をかけるべきかを決めるフレームワークとスケーリングプロセスを採用しています。彼女は、組織を正確に捉え、十分な情報を得た上で意思決定を行うために、3つのフレーム化要素を使用しています：

• デザイン組織の規模と状態
• デザインチームのリソース
• 提携のレベル

DPMのインパクトを上げる

組織とその問題を明確に理解した上で、彼女は適切な 「関与のレベル 」を選択します。DPMは、ズームインしているときはより実践的で、チームと一緒に日々の仕事に取り組みますが、ズームアウトしているときは、アドボカシー、戦略、プランニングに重点を置きます。

DPMの軌道をサポート

最後に、彼女は長期目標でのDesignOpsのロードマップを作成し、フレームワークのエクササイズを使って、以下の重要な軌道の質問３つに答えたいと考えています：

• 今日どこにいますか？
• どこにいたいですか？
• チームはどこにいたいですか？

サロメ・モルタザヴィ氏（SiriusXM）

SiriusXMのDesignOpsディレクターであるサロメ・モルタザヴィ氏が、DesignOpsのロードマップを作成するためのフレームワークの使用について語っています。

彼女はSiriusXMやフォーチュン500の多くの企業との仕事を通じて貴重な知識と経験を得ており、今回の講演でそれをシェアしてくれます。

こちらが、サロメのトークのポイントです。

初心者のためのアドバイス

初心者のDesignOps実践者が犯しがちな間違いの1つは、なんでも屋なってしまうことです。彼らは、より大きな絵に焦点を当てる代わりに、あまりにも多くの日常的な業務を引き受けてしまいます。

始めるにあたって、サロメはこれを克服するために3つの提言をしています：

• 価値を見出す：自分が最も付加価値の高い分野を探す
• 効率と有効性：ベースラインの特定に正しい測定基準を使用して問題のフレームワークから始める
• 話を聞き、メモを取る：あなたが必要だと思う改革に飛びつくのではなく、チームメンバーにインタビューし、彼らの課題を把握する

DesignOpsフレームワーク：デザイン成熟度指数

サロメは、「デザイン成熟度指標」を使ってテーマや問題を特定し、以下の2つの “バケット “に分類しています：

1. DesignOps（デザイン組織運営）
2. デザインリーダーシップ/デザインチーム/プロダクト　（デザインプラクティス運営）

彼女は、これらのテーマや問題をメニューツールで適宜割り当て、分類しています。

DesignOpsロードマップの作成

確定され割り当てたられた問題を元に、サロメ氏は、3つの時間軸といくつかのカテゴリでDesignOpsのロードマップの概要を作成し、【構築】、【測定】、【学習】の方法論を使って実装・進化させます。

彼女の講演の模様は、ブログでご覧いただけます。

エリカ・ライダー（Paypal）

PayPalのUX Lead EPXであるエリカ・ライダー 氏が、デザインの拡張のために従来の DesignOps モデルをどのように修正し、UX の責任を企業全体に移したかについてお話します。

従来のDesignOpsとDesignOps 2.0の比較

エリカのDesignOps戦略は、デザイン部門ではなく、デザインプラクティスを拡張する必要がありました。これを実現するために、彼女とチームは、DesignOpsの構築の代わりにDevOpsの中でデザインを運用しようということで、DesignOpsとDevOpsのハイブリッドフレームワークを作成しました。

責任の進化

このハイブリッドシステムを成功させるために、エリカはプロダクトチームにデザイン、プロトタイプ、テストの権限を与えるとともに、プロダクトマネージャーやエンジニアにUXの重要性を説く必要がありました。

PayPalのDesignOps 2.0プロセスを進化させる

2019年からDesignOps 2.0に取り組んできたエリカと彼女のチームは、より良い製品の提供のために、製品チームのプロセスを進化させることに取り組んでいます。

彼女は、ユーザーリサーチ運用のためのシステムに取り組んでおり、PayPalのハイブリッドな運営モデルにおいて、製品、デザイン、エンジニアリングがUXの責任を共有できるよう、コントロールとアカウンタビリティのバランスを整えているところです。

PayPalのUXチームは、UXウィザードツールを使って、このDesignOps 2.0の次のイテレーションを測定し、進化させています。

エリカ・ライダー氏は、PayPal の DesignOps 2.0 の基盤として UXPin Merge を使いました。無料トライアルに登録し、Merge がどのようにデザイン運用を拡張できるかをご確認ください。

オムカー・チャンドガドカー氏（Amazon）

Amazon Alexa Smart HomeのシニアUXデザイナーであるオムカー・チャンドがドカー氏が、自身の2つのフレームワークを用いて、よくあるデザイン上の課題を克服することについてお話します。

オムカー氏は、ハイテク大手のIBMやアマゾンでの経験から、これらのフレームワークを開発し、積極的に行動することで、戦術的アプローチ（オムカーが言うところの「飛びながら飛行機をデザインする」）から戦略的アプローチへと移行しました

デザインチームのよくある課題

オムカー氏は、デザインチームが大企業で経験する3つの一般的な課題について概説しています。つまり、デザインチームは長期的な戦略に取り組むというより、躍起になっていることが多いのです。

オムカーは、この「躍起になる問題」の克服のために、2つのフレームワークを使用しています。

フレームワーク1：オムカー氏の「点と点をつなげるマップ」

点と点をつなげるというのは、プロダクト、デザイン、エンジニアリングの各活動とフレームワークを連携させ、ソフトウェア開発プロセス全体を通じて連絡と連携を改善することです。

点と点をつなげるマップの目的で、あなたの企業がどのように意思決定し、これらの意思決定がどのように相互依存しているかを特定しやすくなります。そうすると、DesignOpsは、デザインを組織の他の部分と連携させる戦略を実施し、より合理的な製品提供が可能になります。

フレームワーク2：オムカー氏が提供するデザイン

オムカーの積極的なDesign Offerings戦略は、DesignOpsがプロジェクトのプロダクトマネージャーを販売する製品を作るプロセスです。

これらの製品は、プロジェクトの取り込みを合理化し、デザインチームに実用的な最初のステップを提供します。DesignOpsの実践者は、新規プロジェクトや製品バックログにDesign Offeringsフレームワークを使うことができます。

オムカー氏のフレームワークの使い方

点と点をつなぐマップ：

• プロジェクトの進め方やプロジェクト計画作成の参考として
• 過去の決定事項とのギャップを確認するための仕組みとして

デザインの提案：

• パートナーがデザインからどのような利益を得ることができるかを教育する手段
• 戦術的なプロジェクトと戦略的なプロジェクトのバランスをとるための取り込みメカニズム

UXPinでは定期的にさまざまな業界からのゲストをお呼びしたウェビナーを開催しています。

Delivery Hero MENA（talabat）のDesignOpsリーダー、アンバー・ジャビーン氏を招いた新しいウェビナーをご覧いただけます。彼女は、異なる市場にまたがって機能する集中型デザインシステムのための企業の賛同を得ることについてお話しています。

こちらも是非ご覧くださいませ。

The post Design Value Conference 2022のまとめ：世界企業のDesignOps課題への取り組み appeared first on Studio by UXPin.