デザインハンドオフツール を使用することで、デザインから開発へのスムーズな移行を促進させることができます。

エンジニアには、実用的なドキュメント、忠実度の高いプロトタイプ、効率的なコミュニケーションおよび連携向けの機能を提供します。

効果的なデザインハンドオフのプロセスがなければ、デザインと開発間のギャップを埋めるために多くの時間を費やしてしまいます。

コード化コンポーネントを使ってデザインすることで、ハンドオフのプロセスを効率化してみませんか？

UXPin Mergeでは、npm、Storybook、Gitレポジトリからコンポーネントをインポートして、エディタにドラッグ＆ドロップするだけで高度なプロトタイプを作成できます。

この技術についてさらに詳しく知りたい方は、こちらのページをぜひご覧ください。

１．UXPin Merge

UXPin Mergeは、ReactやStorybookコンポーネントで構築されたコードベースのHi-Fi（高忠実度の）プロトタイプをデザインしてハンドオフをすることができます。

この「信頼できる唯一の情報源（Single source of truth）」によって、デザイナーもエンジニアも同じUI要素で作業できるため、市場投入までの時間が大幅に短縮されます。

プロトタイプが完成すると、次にデザイナーはそれをエンジニアと共有します。

エンジニアはスペックモードを使って、ドキュメント、スタイルガイド、コメントを見ることができるだけでなく、開発段階で使用可能なコンポーネントのJSXコードをコピーして使用することができます。

ちなみに、UXPin Mergeは最初から完全にコード化されたコンポーネントを使ってデザインできるのでエンジニアとデザイナー間で伝達ミスが起きることはありません。

Mergeがデザインプロセスとハンドオフをどのように最適化できるかについての詳細は「デザインハンドオフ ーUXPin Mergeで実現することー」の記事をご覧ください。

２．Zeplin

Zeplinは、デザイナー、エンジニア、その他のチームメンバーが効率的に連絡・連携しやすくなる人気の デザインハンドオフツール です。

Jira、Slack、Trello、Microsoft Teamsなどのコラボレーションツールと統合可能です。

Zeplinを使うと、デザイナーは注釈を含むユーザーフローの作成と、エンジニアにコンテキストの提供が可能です。

スタイルガイドから色、テキストスタイル、スペーシング/レイアウト、デザイントークン、コンポーネントを保存することができます。

また、開発で使えるコードスニペット、その他のスタイリングが含まれているのも魅力ポイントです。

３．Marvel

Marvel は、Zeplinと同じくデザインハンドオフ機能がある人気のデザインツールです。

自動生成されたモックアップを使って、プロトタイプの作成・他のデザインツールからのインポートが可能です。

MarvelはモックアップからスターターコードとCSSを生成して時間を節約でき、デザインと開発のギャップを埋めることができます。

また、エンジニアは各コンポーネントのチェックとアセットのダウンロードができるため、連絡ミスやツール間の切り替えを回避できます。

４．Sympli

Sympli は、バージョン管理とデザインのハンドオフを目的としたツールなので、コンポーネントディレクトリのStorybookに相当する “デザイナーのような” 存在と言えるでしょう。

Sympliをプロトタイピングツールと統合し、UI要素やデザインシステムを同期させることで、要素の説明やコンテクストを加えるためにチーム間のレビューや共同作業が可能です。

また、エンジニアはスタイルガイド、スペックモード、スペックとアセットを参照して開発プロセスを開始できます。

さらに、Sympliにはモバイルアプリ開発用のXcodeとAndroid StudioのプラグインでIDE（統合開発環境）と同期できるのが最大の魅力です。

５．Avocode

Avocode は、開発チームのためのデザイン ハンドオフ ファイルを作成します。

また、Avocode の「ワンクリック」統合が、ダウンロード可能なアセット、スペックモード、１０種類のコード言語用のスニペットを生成することで、デザイナーには時間の節約になります。

そして、Avocode のデザインレビューでは、デザイナーは他のチームやステークホルダーを招待して、デザインの批評やフィードバックを行うことができます。それでデザイナーは、全員が更新を認識できるように、フィードバックを反復し、変更を再同期して新しいバージョンを作成できます。

なのでデザインチームは、Avocodeのレビュー機能を使って、矛盾点や修正点について話し合うことができます。

６．InVision

InVision は UXPin のような機能があるデザインツールであり、InVision Studioのデザインからのプロトタイプの作成や、他の一般的な画像ベースのデザインツールからのファイルのインポートなどができます。

Inspect は、デザインスペックとコードスニペットを自動生成する、InVisionのデザインハンドオフツールであり、デザイナーとエンジニアは、コメント機能で連絡をとって連携とフィードバックを一箇所で維持することもできます。

また、InspectのStorybook統合により、InVision はコードレポジトリにあるコンポーネントをエンジニアに通知し、それがライブラリを検索する時間の節約や、不慮の手戻りの予防になります。

そして、InVisionはコミュニケーションやプロジェクト管理タスクを同期するのに、Jira、Confluence、Trello などのソフトウェアとの統合もします。

７．Framer

Framerは、React コンポーネントを同期して編集するコードエディタを備えたレイアウトデザインツールです。

これはデベロッパーにとっては素晴らしい機能ですが、コードの知識や経験があまりないデザイナーには不向きです。

UXPinのようにプロパティパネルでコンポーネントのプロップを編集することはできないので、代わりにFramerのコードエディタでの変更を加える必要があります。

これもコードに慣れていない人にとっては理想的ではありません。

しかし、デザイナーはReactコンポーネントをプロトタイプやテストに使うことができ、他の一般的な画像ベースのツールよりも優れた忠実度と機能性が得られます。

また、Framerの高い忠実度と機能性によって、デザインのハンドオフがスムーズかつ効率的になり、エンジニアは、React コンポーネントからコードをコピーして、新しい製品やUIを構築することができます。

ただ、Framer のコードベースのデザインテクノロジーは、React製品には優秀ですが、UXPinの Storybook統合が提供する他の一般的なフロントエンドフレームワーク用の機能がありません。

８．Spectrr

Spectrr は、色、フォント、スペーシングなど、エンジニアがコンポーネントやレイアウトを検査するための自動注釈が付いたデザイン仕様ツールです。

デザイナーは、各コンポーネントのメモや、レスポンシブレイアウトの作成指示を含めることができます。そしてエンジニアは、Spectrr がプロジェクト用の完全なCSSファイルの生成もするため、開発を開始するための優れたスターターテンプレートを手に入れることができます。

９．Adobe XD

UXデザインやプロトタイピングツールとして広く使われていましたが、2023年に廃止されました。Adobe XDの共有モードを使って、デザイナーは仕様書やCSS のスターターコードなどをエンジニアに渡すことができます。

コメント機能はAdobe XDとJira、Slack、Microsoft Teamsなどのプロジェクト管理ソフトウェアと統合させて共同作業を行うことができます。

また、Adobe XDの共有モードでは、他のデザインハンドオフツールに比べて限られていましたが、Zeplinにデザインを同期することで、より多くの機能とより良い連携ができました。

１０．Figma

Figmaは世界中で最も人気のあるデザインツールの１つです。初期リリース時点では Sketchに似ていましたが、その後プロトタイプやテスト機能を提供できるように進化しました。

Figmaの共有機能によって、エンジニアは要素を検査し、Web、iOS、Android用のコードスニペットを生成することができます。

また、React、Flutter、Vue、Ember、Angular などのフレームワーク向けのコードを生成するために、サードパーティのプラグインのインストールもできます。

2023年現在、デザインプロジェクトに無料で「開発モード」が追加できるので、エンジニアはプロジェクトにアクセスして、コメント機能でフィードバックができるでしょう。

ちなみにUXPinは、従来の画像ベースのデザインツールのようなベクターファイルではなく、HTML、CSS、Javascript をレンダリングするコードベースのツールです。そのため、デザイナーとデベロッパーにとってドリフトが少なく、実際のデザインがイメージしやすいというメリットがあります。

デザインハンドオフが大変な理由

デザインハンドオフの最大の課題として、プロトタイプの忠実性と機能性があります。

デザイナーは、トランジションやアニメーション（例：GIFやビデオなど）のようなコードベースの機能を再現するために、さまざまなツールや方法を用いる必要があります。

非現実的な期待

技術的制約がないと、デザイナーや製品チームに非現実的な期待を抱かせてしまうかもしれません。

実際のプロトタイプには含まれていないことから、エンジニアはどのように組み合さっているかを確認するためにプロトタイプから外部ファイルにアクセスしたり、アニメーションを見てどのように組み合わされているかを確認する必要があります。

コードレンダリングに不十分な画像ベースツール

もうひとつの問題は、デザインのコードへの変換です。

多くの画像ベースのデザインツールには、CSSを含むHTMLテンプレートが自動生成できるプラグインやアプリケーションがあり、これで十分に思えるかもしれません。

しかし、実際のところ、このコードだけではデザインを完全には再現はできません。共通言語が異なることから、”ズレ” がでてきてしまうのです。

技術的制約 

デザインドリフトのもう一つの原因は、製品を表示するブラウザやデバイスのレンダリングエンジンです。

よく起きがちなケースとしては、モックアップから最終的なコードへの色やグラデーションでのドリフトが挙げられます。

多すぎるデザインハンドオフツール

ハンドオフではデザインファイル、プロトタイプ、ドキュメント、アセット、コラボレーションのためのツールが複数使用されていることがよくあります。

さまざまな場所やプラットフォームに分散していると、ハンドオフではミスやエラーが起こりやすくなってしまいます。

ここで紹介したのは、あくまでデザインと開発間の摩擦が起きやすい場面の一部の例であり、ハンドオフ経験者であればよくご存じかと思います。

しかし、ラッキーなことに、このプロセスを効率化できるデザインハンドオフツールがあります。

UXPin Mergeによるデザインハンドオフの改善

UXPin Mergeは製品開発フローにおけるすべての課題を解決できるオールインワンUXデザインツールです。

ツールの使用を１つにして、デザインワークフローを効率化し、完全に機能するプロトタイプの作成、連携の強化、製品のUXの向上を実現しましょう。

まずは14日間の無料トライアルでUXPinをお試しいただき、すべてがつながることで製品開発がどれくらい簡単になるかを実感ください。

UXPin Mergeのアクセスのリクエストはこちら。

The post ２０２４年に試すべき デザインハンドオフツール １０選 appeared first on Studio by UXPin.

ワイヤーフレームの作成は、UXデザインプロセスにおける重要なステップであり、最終製品の設計図としての役割を果たします。

このガイドでは、コードベースのテクノロジーと内蔵機能で際立つエンドツーエンドのデザインツールであるUXPinを使って効果的なワイヤーフレームを作成する方法を詳しくご紹介します。

本記事では、基本的なUI要素の組み立てからユーザーフィードバックの組み込みまで、アプローチを一つずつ詳細に提供しています。

インタラクティブなフォーム要素や「Code-to-Design（コードからデザイン）」の機能など、UXPinのユニークな機能が、どのようにデザインプロセスの効率化や連携強化、よりユーザーにとって使いやすい製品への貢献をできるかを見ていきましょう。

主なポイント：

• UXPinには、デザイナーが完全にインタラクティブで機能的なワイヤーフレームを作成できるようになるコードベースのワイヤーフレーム作成機能がある。
• UXPinは、デザインライブラリや高度なプロトタイピング機能などが内蔵されていることによって、他のデザインツールとは一線を画している。
• UXPinは、ワイヤーフレームから忠実度の高いプロトタイプへのシームレスな移行をしやすくすることから、複雑なインタラクションや API連携まで実現し、包括的なフルスタックデザインソリューションとなる。

UXPin でデザインプロセスを効率化し、ワイヤーフレームをもっと速く作成しませんか。こちらから無料トライアルにサインアップして、UXPin のフルスタックデザインソリューションをぜひお試しください。

UX のワイヤーフレームとは

UX のワイヤーフレームは、UI（ユーザーインターフェース）の基本的なフレームワークを表現する、低忠実度（Lo-Fi）の視覚的な設計図であり、通常は色やグラフィック、複雑な詳細はなく、主にスペースの割り当て、コンテンツの優先順位、および意図された機能に焦点を当てています。

デザイナーは、Web ページやアプリ、システムの構造を伝えるために、デザインプロセスの初期段階でワイヤーフレームを作成しますが、ワイヤーフレームは、詳細なモックアップや高忠実度（Hi-Fi）プロトタイプに入る前に、基本的なレイアウトとインタラクションのパターンを確立することを主な目的としています。

ワイヤーフレームの利点

ワイヤーフレームには、デザインプロセスの効率化や、チームメンバー間の効果的なコミュニケーションの促進を実現するさまざまなメリットがあります。以下に、その利点を挙げましょう：

• 明瞭性： ワイヤーフレームが、レイアウトを視覚的に表現することで曖昧さを取り除き、関係者は誰でも明確なロードマップを得られる。
• 効率性： ワイヤーフレームが早期に問題を解決することで、開発後期の時間とリソースが節約される。
• 整合性： ワイヤーフレームで、プロジェクトの目標と機能性に関するステークホルダーとチームメンバーの足並みが揃う。
• ユーザビリティ：UX（ユーザーエクスペリエンス）を評価する機会を提供することから、 直感的なナビゲーションとレイアウトが確保される。
• 連携： ワイヤーフレームがディスカッションのツールとして機能することから、デザイナー、デベロッパー、ステークホルダーが初期のデザインのフィードバックを提供できるようになる。
• 優先順位付け： デザインの最も重要な要素を特定し、コンテンツの効果的な階層化が実現する。
• 柔軟性： ワイヤーフレームで、反復と変更がしやすくなることから、実験のための Lo-Fi（低忠実度）モデルとして機能できる。
• アーキテクチャ：ワイヤーフレームは、デジタル製品の情報アーキテクチャのベースとなる。

UXPinはワイヤーフレーム作成に適したツールか

UXPinは、優れたUXを実現できるワイヤーフレームが作成可能なエンドツーエンドのデザインツールです。デザイナーは次のような機能を使用してインタラクティブなワイヤーフレームを簡単に作成できます：

• ボックス（Box）：テキストを追加できる柔軟な UI 要素
• シェイプ（Shape）：長方形、楕円、円、丸、線、矢印、多角形、星形
• テキスト（Text）：基本的なテキストブロック
• フォーム（Form）：ボタン、テキストエリア、セレクト/マルチセレクト、チェックボックス、ラジオボタンなど、基本的なスタイルのないフォーム要素のセット
• ホットスポット（Hotspot）: UIの任意の要素や特定の場所をインタラクティブにする
• アイコン（Icon）：マテリアルデザイン、Fonts Awesome、Retina アイコンなど、複数のアイコンセットから選ぶ

他のデザインツールとは違い、UXPinのUI要素はデフォルトでもインタラクティブなものです。

例えば、UXPinのすべてのフォーム要素は完全に機能し、チェックボックスやラジオをキャンバス上にドラッグ＆ドロップするだけで、クリック可能なオン/オフの状態のインタラクティブ機能がすでに備わっています。

このようなインタラクティブな要素により、デザインチームは、デザインプロセスのよりコストのかかる忠実度の高い（Hi-Fi）段階に移行する前に、ワイヤーフレームのプロセスでより多くのデータとフィードバックを集めることができます。

UXPinと他のワイヤーフレームツールの違い

UXPin の最も大きな違いは、このプラットフォームがコードベースのテクノロジーを採用している点です。UXPin は、SketchやFigmaのようにベクターグラフィックスを生成するのではなく、HTML、CSS、Javascript を裏でレンダリングします。

このコードベースのアプローチにより、デザインチームは完全にインタラクティブなワイヤーフレームやプロトタイプを構築するための機能が強化できます。

たとえば、画像ベースのツールでは、入力フィールドはグラフィカルな表現ですが、UXPinではユーザーデータをキャプチャ、保存、共有できる機能的になります。

内蔵機能とプラグイン

もう一つの違いは、UXPinは他のワイヤーフレームツールよりも多くの機能を標準で提供し、プラグインや拡張機能を必要としない点です。UXPin のプランには、デザインシステム、ビルトインデザインライブラリ、コンテンツとデータ、フォント（Googleとカスタム）、アクセシビリティ機能など、他のデザインツールではプラグインが必要なものが多数含まれています。

Code-to-Design（コードからデザイン）

UXPin Mergeのテクノロジーにより、デザインチームはコードコンポーネントをデザインプロセスにインポートしてプロトタイプを作成を可能にします。デザイナーは、デベロッパーが最終製品に使うのと同じ UI ライブラリを使って、完全に機能するインタラクティブなプロトタイプを作成できます。

エンジニアリングチームで特定のワイヤーフレームのコンポーネントライブラリが使われている場合、Merge を使ってこれを UXPin にインポートできます。

また、Merge にはインタラクティブなプロトタイプの作成に使えるビルトインライブラリ（例：Material UI、MUI、Ant Design、Fluent UI、ボイラープレートなど）があり、ワイヤーフレーム作成から忠実度の高いプロトタイプ作成まで、コンセプトやアイデアをすぐにテストすることができます。

UXPin でワイヤーフレームを構築する方法

ここでは、フィードバックの収集やステークホルダーとの連携など、UXPin でワイヤーフレームを作成するためのステップをご紹介します。

このステップバイステップのチュートリアルに従うには、UXPin のアカウントが必要です。

まだお持ちでない方は、１４日間の無料トライアルにサインアップしてください。

ステップ１: UXPin を開いて新規プロジェクトを作成する。

• UXPin を開き、青い［＋New project］のボタンをクリックする。
• プロジェクト名を入力し、［ Create New Project（新規プロジェクトの作成）］をクリックする。
• 次に、「What do you want to start with today?（今日は何から始めますか？）」画面から［New prototype］を選択する。

ステップ２：ワイヤーフレームのキャンバスサイズを選ぶ

右側のプロパティパネル（Propaties Panel）で、ワイヤーフレームのキャンバス（CANVAS）のサイズを選択します。

UXPin には、デスクトップ、タブレット、モバイル、ウェアラブルなど、幅広い標準ビューポートが用意されています。

グリッドとガイドを使って、水平または垂直方向の一貫性を保ちましょう。

ステップ３：各画面のページを作成する

アートボードやフレームが使われる FigmaやSketchとは異なり、UXPinは画面ごとに独立したページが使われます。

• 左サイドバーの下部にある［Pages & Layers］を選択する
• サイドバー上部の［＋］のアイコンをクリックし、新規ページを作成する（［OPTION + N］のキーボードショートカットでも可能。）
• ページ名をダブルクリックして変更する（今回は「Login（ログイン画面）」と「Welcome（ウェルカムページ）」の２つのページを作成する）

アドバイス：ユーザーフローライブラリを使って、ユーザージャーニーと情報アーキテクチャを設計し、プロジェクトの画面数とナビゲーションレイアウトを決定しましょう。

ステップ４：ワイヤーフレームの UI 要素の作成

UXPinのシェイプ、フォーム、ボックスなどを使ってワイヤーフレームのパターンやレイアウトを組み立てることができます。

また、オートレイアウト（Auto Layout）では、サイズ、ギャップ、配置、分布など、グループ要素を効率的に管理できます。

UXPinのコンポーネントを使って、再利用可能なワイヤーフレーム要素を作成しましょう。これによって、より迅速な反復と最大限の一貫性を実現できます。

ステップ５：インタラクションを定義する

このデモでは、ログイン画面からウェルカムスクリーンに基本的なナビゲーション・インタラクションを追加します。

• 要素をクリックして選択し、Properties Panel（プロパティパネル）の Interactionsをクリックする。
• 以下のようにナビゲーションのインタラクションを作成する：
  • Trigger：Click (Tap)
  • Action： Go to Page
  • Page：ドロップダウンリストから Welcomeを選択
  • ［Add（追加）］をクリックしてインタラクションを完了する

Trigger、Action、Animation、条件などのインタラクションの設定方法をご覧ください。

ステップ６：連携とフィードバックの収集

UXPinのPreview（プレビュー）と Share（共有）機能を使って、ステークホルダーにワイヤーフレームを共有します。

また、Comments（コメント）機能で、ステークホルダーはデザインに注釈を付けてフィードバックしたり、特定のチームメンバーにコメントを割り当てることができます。

UXPin でワイヤーフレームからプロトタイプへ移行する方法

UXPinでは、ワイヤーフレームからプロトタイプまで簡単にできます。

ゼロからコンポーネントをデザインしてモックアップを作成することも、デザインシステムを使って忠実度の高いインタラクティブなプロトタイプをすばやく構築することもできます。

UXPinには、プロトタイピング機能を強化する主要機能が以下のように４つあります：

1. ステート（状態）: UI要素１つに対して複数のステートを作成でき、メニューやドロワーなどの複雑なインタラクティブコンポーネントをデザインできる。
2. Variables（変数）：ユーザーの入力からデータを取得し、登録後に個別に送るウェルカムメッセージのように、個別化された動的なユーザー体験を作成する。
3. Expression： 複雑なコンポーネントや高度な機能を作成するための Javascript のような関数であり、コードは不要。
4. 条件付きインタラクション：ユーザーのインタラクションに基づいて「if-then」や「if-else」の条件を作成し、複数の結果を持つダイナミックなプロトタイプを作成して、最終的な製品エクスペリエンスを正確に再現する。

API連携でより高度なプロトタイプにする

UXPinのIFTTT統合で、例えば、ユーザーのカレンダーへの予定の追加や、ウェルカムメッセージのようなメールの送信など、API連携を通じて外部の製品やサービスと連携することができます。

UXPinのデザインシステム、高度なプロトタイピング機能、および API機能を使うことで技術的な知識やエンジニアからのサポートがなくても、複雑な製品のレプリカを作成できます。

この洗練されたプロトタイプによって、ユーザーやステークホルダーから有意義なフィードバックを得ることができ、製品のUXを向上させることにつながります。

世界最先端の製品デザインツールを使って、ワイヤーフレームとプロトタイプを作成しませんか？

無料トライアルにサインアップして、UXPin でインタラクティブなワイヤーフレームを作成してみましょう！

The post 【プロダクトチーム向け】UXPin ワイヤーフレーム 入門 appeared first on Studio by UXPin.

デザイン会社のIDEOによれば、持続可能な長期的成長や成功する製品の特徴として、有用性（Desirability）、持続可能性（Viability）、実現可能性（Feasibility）が必ずあるといいます。

 デザイン思考 のプロセスでは、最も顧客の役に立つ製品や機能性を決めるために、リサーチ、つまり「デザインレビュー」を行います。このデザインレビューがうまくいけば、競合他社が解決していない問題を特定することができ、エンドユーザーとビジネスの双方に利益をもたらすでしょう。

しかし、デザインレビューは何から始めるべきでしょうか？競合における自社の強みはどうやって見つけるのでしょうか？そして、ユーザーや組織のために実行可能なビジネスモデルかはそのように判断するのでしょう？

本記事では、 デザイン思考 を概念化する段階でのリサーチと、以下３つの重要な基準を満たすアイデアを発掘する方法について見ていきます：

• 有用性（Desirability）
• 持続可能性（Viability）
• 実現可能性（Feasibility）

UXPinは、顧客に最高のユーザー体験を提供するための、高度なエンドツーエンドのデザイン、プロトタイピング、テストツールです。無料トライアルにサインアップして、UXPinでUXワークフローとデジタル製品デザインがどのように強化されるかをぜひお試しください。

デザインにおける有用性、持続可能性、実現可能性とは

有用性、持続可能性、実現可能性とは、アイデア、コンセプト、仮説を検証し、独自の価値提案（UVP （Unique Value Proposition）とも言う）があるかどうか、それを追求する価値があるかどうかを判断する デザイン思考 の方法論です。

この３つをすべてクリアしないと、リスクやコスト、失敗の可能性が高まってしまいます。有用性、持続可能性、実現可能性は、アイデアのリスク分析手法であり、イノベーションの芯の部分を見つけるためのツールキットであるとも言えるでしょう。

この方法論を適用することで、デザインコンセプトの弱点を突き止め、さらなるリサーチを重ねたり、アイデアを破棄して次のステップに進むことができるのです。

この方法論の由来

世界的なデザイン会社である IDEO は、２０００年代前半にアイデアをテストする方法として、『有用性』、『持続可能性』、『実現可能性』という デザイン思考 の手法を概念化しました。

IDEOは、最高のアイデアは、この３つの条件が満たされたときに成功すると考えました。逆を言えば、「素晴らしいアイデア」は、これら３つの基準のうち１つでも欠けているとうまくいかないことが多いのです。

では、この３つのレンズを通して、これらの３要素がどのように組み合わされているのかをみてみましょう。

有用性

デザイナーがまずチェックしないといけないのは、有用性 です。もし製品アイデアに市場価値がなく、誰もそれを欲しがらない、必要としないのであれば、それは売れませんよね。

また、有用性を調査することで、その商品が「欲しいもの」なのか「要るもの」なのかがわかります。

例えば、以下のようになります：

• 徒歩、公共交通機関、車、相乗りなどでの通勤が必要。
• 車通勤は便利で公共交通機関よりも快適かもしれないから、車通勤したい。

要るものとは、顧客にとってなくてはならないものであり、欲しい物とは、そのニーズを満たすための、より望ましい選択肢であることが多いです。どちらも「有用性」を満たすものですが、「欲しい」や「あったらいいな」よりも、「必要」という欲求を満たすものの方が、はるかに価値があります。

有用性のある製品を見つけるには、顧客を調査して、満たすことのできるペインポイント（「欲しいもの」と「必要なもの」）を特定しないといけません。

• 製品で問題が解決される人がいるか
• 競合他社は解決策を提示しているか
• もっといい考えはあるか
• そのアイデアは何がユニークなのか、なぜ競合他社ではなくそのアイデアを選ぶ人がいるのか
• その製品でエンドユーザーはどう思うか
• その製品は、使った人が誰かに話したくなるような有用性があるか
• その製品は、一度使ったら一生手放せないようなものか

有用性を調査する場合、そのアイデアをストレステストして、修正すべきギャップを見つけるという意図があります。ギャップが埋まれば埋まるほど製品は強くなり、ステークホルダーからの厳しい質問や顧客満足度にも耐えられるようになるのです。

持続可能性

持続可能性とは、その製品がビジネスとして成立しているかどうかを示すものです。たとえ世界で最も有用性のある製品があるとしても、それが高すぎたり、利益が出なかったりすれば、それは良いビジネスモデルとは言えませんからね。

本当に持続可能な製品アイデアは、短期的にも将来的にもビジネスとして意味があり、投資に対するプラスのリターンをより早く、より長く提供できるほど、デザインアイデアの持続可能性は高くなります。

持続可能性の素晴らしい例として、いかにしてコカ・コーラが１８８６年に生み出した飲料が、今でも世界で最も消費されている飲料の 1 つであり続けられるのかが挙げられます。その初期投資は、発明者に莫大な富をもたらし、１３５年以上経った今でも株主に信じられないほどの利益をもたらしていますよね。

また、持続可能性は、社会的、環境的なインパクト、つまりデザインの倫理的な側面も重要です。そのデジタル製品は、社会にとってプラスの利益をもたらしますか？例えば２０２１年に、フェイスブックの内部告発者フランシス・ハウゲン氏は、SNS 大手の内部調査で、インスタグラムが１０代の少女たちの不安や鬱、自殺願望を生み出していることを示す文書を公開しました。

Instagramは短期的には高い経済的リターンをもたらすかもしれませんが、このティーンエイジャーへの害は長期的に持続し得るものでしょうか。また、政府はFacebook や Instagram を規制するために何ができるのでしょうか？

Facebookは、社会的な論争、罰金、訴訟を克服するためのリソースを持つ巨大企業ですが、小さな会社やスタートアップ企業は、同じような圧力に直面した場合、ほとんどが折れてしまうでしょう。

そのため、持続可能性を検討する際には、事業、顧客、社会に対する価値の提供が必要であり、以下のようなことを検討してみるといいかもしれません：

• このデザインが成立するには何が必要か
• デザインを機能する製品にするには、どのような費用がかかるか
• 新製品や新機能を構築するための設備投資はあるか
• 価格モデルはどうなっているか、また、そのビジネスは利益を上げられるか
• ROI（投資対効果）が出るまでどのくらい時間がかかるか
• その製品はサステナブルか
• その製品は社会にどのような影響を与えるか

なお、持続可能性は有用性と同様に、その製品が確実に実行可能で持続可能であるようにするために、アイデアの調査、分析、ストレステストが求められます。

実現可能性

実現可能性は、現在のリソースに注目し、予測可能な将来において製品を開発する能力があるかどうかを判断します。そしてデザイナーは、その製品がビジネスにどのような影響を与えるかを考慮しないといけません。

実現可能な要因としては、以下のようなものがあります：

• 技術的な制約
• 財務上の制約
• 製品がブランディング、マーケティング、カスタマーサポートなどに与える影響
• 想定される市場投入までの時間
• 運営能力

理想的には、利用可能なリソースを用いて、会社の現在の能力の範囲内で新製品や機能をデザインしたいものです。新製品をサポートするためにインフラを構築しないといけないとなると、リスクとコストが増加しますからね。

新製品や新機能をデザインする際に考慮したい実現可能性に関する質問として、以下のようなものが挙げられます：

• 現在のデザイン体制で、新製品を開発するための部品が揃っているか
• デザイン・開発にかかる時間はどれくらいか
• 新製品の構築や拡張に十分なプロダクトデザイナー、UX デザイナー、エンジニアがいるか？
• 技術的な制約は新しいデザインに対応できるか
• 組織は新しい人材の採用が必要か
• 組織の能力を拡張する必要がある場合、それが将来の製品にどのような利益をもたらすのか
• その製品はブランドにどのような影響を与えるのか
• 製品のリリースは、マーケティング、セールス、カスタマーサポートなど、組織の他の分野に影響を与えるか？また、そのような部門はより多くの仕事をこなす能力があるか

デザインレビューにおける「有用性、持続可能性および実現可能性」の使用

組織は、「インフラ、マーケティング、販売、カスタマーサポートなどのコストを伴う開発を行う前にデザインやプロトタイプの問題点を特定する」という目的のもと、製品デザインの初期段階でデザインレビューを実施し、特定の基準に照らしてデザインを評価します。

基本的には、組織は製品デザインの有用性、持続可能性、実現可能性を知りたいと考えています。

UXデザインレビューのテンプレートのご紹介

「有用性、持続可能性、実現可能性」の デザイン思考 の方法論を適用することで、ステークホルダーに包括的かつ客観的なデザインレビューを提示するためのインサイトとデータを得ることができます。

以下は、ステークホルダーが読みやすく、理解しやすいように、デザインレビューの説明する際に使用できるストラクチャーまたはテンプレートです。

問題：問題は簡潔に述べましょう。デザインチームとビジネスチームは、この土台から共通の理解を深めていきますからね。

システム（現状）： 問題のコンテクストを理解するために、現在のシステムがどのように機能しているかを示しましょう（既存の製品であれば）。その後、あなたの提案する経験によって、システムがどのように機能するかを示すといいでしょう。

JBTD（ジョブ理論）： デザインレビューでは、何が顧客のモチベーションを高めるのかについて、共通の理解を持つことが重要です。Tony Ulwick氏はJBTDを「市場、顧客、ユーザーニーズ、競合他社、顧客セグメントを異なる角度から観察することでイノベーションをより予測しやすく、収益性の高いものにする。」であると定義しており、これによって、顧客がソリューションをどのように「採用」または「不採用」にするかの決定方法をステークホルダーが理解するために役立ちます。

事業目的： 顧客の問題解決におけるビジネス価値とROI を述べましょう。

把握すべきメトリクス： 測定しないものは改善できません。このメトリクスによって、新製品のデザインによって生み出されるビジネスと顧客の価値を定量化できるはずです。

提案された体験： 提案内容を文章でまとめ、明確で理解しやすいものにしましょう。その場にいる人たちは、その提案があなたが以前に明確にした問題とどのように関連しているのかを理解しないといけませんからね。

提案の意味合い：その提案がビジネスの他の部分にどのような影響を与えるか、もしかしたらわからないかもしれません。製品デザインの初期段階でそれを理解するのは、有用性、持続可能性、実現可能性のバランスを取るのに重要です。

基本的なエクスペリエンスデザイン： ワイヤーフレーム、モックアップ、プロトタイプ、またはMVP（最小実行可能製品）を提示して、顧客が製品をどのように望ましいと感じるかをステークホルダーがイメージできるようにしましょう。

デザインに反映されるインサイト：このデザインを選択した理由は何でしたか？インサイトや仮説などは何でしたか？いくつかの項目を箇条書きにして思考の深さを示しましょう。

新デザインに関する仮説：

• 新しいデザインについての仮説とは
• どのようにしてこの仮説にたどり着いたのか
• この仮説を、重要だと思われるメトリクスとどのように整合させることができるか

このような仮説は、明確でテスト可能なものであるべきです。明確な合格・不合格のメトリクスでテストを行うことで、この仮説は、少しずつ前進していることを測るための強力な基礎となるはずです。

チームの協調性を重視： ステークホルダーからどのような意見が必要か？デザインレビューのテンプレートのこのセクションによって、製品の成功の鍵を握るステークホルダーのために、明確なコンテクストと焦点を設定できます。

UXPinにあるデザインライブラリを使って、忠実度の高いプロトタイプやMVP を手短に構築し、デザインレビューの際にステークホルダーに提示することができます。無料トライアルにサインアップして、早速 UXPinプロトタイプ第１号を作成しましょう！

The post デザイン思考 における「有用性、持続可能性、実現可能性」とは appeared first on Studio by UXPin.

リソースの節約

デザインプロセスを反復すると、ユーザー（少なくともステークホルダー）からのフィードバックも定期的に得ることができるため、多くの時間節約につながります。

受け取ったフィードバックはポジティブなものも、ネガティブなフィードバックも正しい方向性を知ることができるきっかけとなるので、貴重な時間を無駄にすることはありません。

フィードバックが全くない場合、ゴールまで急いでも失敗している危険性があり、時間と帯域の大きな無駄となります。さらに、「時は金なり」ですから、デザインイテレーションは最も費用対効果の高い選択肢となりますね。

連携の促進

デザインプロセスを反復することで、ステークホルダーが意見を述べたり、自分のアイデアを共有したりする機会ができるため、健全な連携が促進されます。その結果、「自分の視点でのみ物事を見る」ということにならないため、自分だけでは発見できないような気づきが得られます。

本当のユーザーニーズへの対応

デザイン イテレーション のプロセス（特に連携を取り入れたプロセス）が確立されていないと、デザイナーは孤立して仕事をするという罠にはまりがちです。サイロ化すると、内省的になりすぎてしまい、それが早合点や、生産性のない完璧主義への暴走につながってしまいます。

しかし、デザインプロセスを反復的に実施することで、ユーザーのニーズに焦点を当て、ユーザーからのフィードバックに従った意思決定を行うことができます。また、漫然とした改善に終始するのではなく、次善の策に優先順位をつけてデザインの改善ができるようになります。

さらに、ユーザーからのフィードバックによって、ステークホルダー間の意見の対立を解消できるようにもなります。

定期的な更新のしやすさ

デザインプロセスの反復によって、ステークホルダーに最終結果を投げかけて「見といてね」と放置するのではなく、定期的に進捗状況の更新を提供することができます。

特にデベロッパーにとっては、これは「デザインの途中でも開発に着手できますよ」ということです（実際、デベロッパーは反復的な開発プロセスを活用することができますから、みんなにとっていい話になります）。

また、顧客と仕事をする場合、頻繁に更新することで、製品にかける努力を示すことができ、それによって顧客との良好な関係を築くことができます。さらに、製品の定期的な更新を顧客に伝えることで、マーケティング上の話題を提供し、世間の声を得ることだってできます。

UXPinのプロトタイプは、顧客やステークホルダーとの共有がすぐにできます。数回クリックするだけで、デザイナーは、顧客やステークホルダーが本物と同じように見えて機能するデザインイテレーションをテストする際に、コンテクストに応じたフィードバックのコメントを得られるようになります。また、アダプティブバージョンを使うと、シミュレーションされたプロトタイプは、デバイスやスクリーンサイズに適応します。ただし、プロトタイプの共有前に、プレビューモードでエラーや見落としがないかをチェックすることを忘れないでください！

 イテレーション が使われる場所

イテレーションはデザイナーだけのものではありません。ソフトウェアデベロッパーも、非同期で、あるいはデザインのイテレーションに連動して、仕事に反復的なアプローチを取ることができます。さらに大規模なものでは、プロジェクト全体をイテレーションで計画的に管理することも可能です。

デザインにおける イテレーション 

デザインにおいては、イテレーションは、以下のような多くのデザイン方法論において重要な役割を担っています：

• デザインスプリントの方法論
• HCD（人間中心のデザイン）
• デザイン思考およびリーンUX 
• ラピッドプロトタイピング （3Dテクノロジーを使って迅速（ラピッド）に製品の試作品（プロトタイプ）を作成する開発技法）のアプローチ

どのような方法論であっても、必要なリソースがあれば、同時進行の反復デザインプロセスを用いて、非同期で複数のユーザーニーズに対応することができます。

ソフトウェア開発におけるイテレーション

ソフトウェア開発では、イテレーションは継続的な改善の促進や、誤差の範囲の提供、そして製品開発プロセスの他の側面が妨げられるのを防ぐのに使われます（直線的で、すべてのプロセスを順次行うことを強制するウォーターフォール方法論とは違いますね）。実際、反復的なアプローチによって、例えば「アジャイルUX」と「アジャイルソフトウェア開発」を組み合わせて機能性を構築したり、デザインと開発のチームメンバーが連携して作業できるようになります。

プロジェクト管理におけるイテレーション

最後に、イテレーションは、より高いレベルでも機能し、それによって製品やプロジェクト管理プロセス全体の包括的なテーマとなることもあります。プロジェクトのステークホルダーに、ライフサイクルを通じて製品の方向性に関する定期的な最新情報や、主要な成功メトリクスを測るのに使えるデータを提供しますからね。

さらに、イテレーションは DesignOps や DevOps などの社内業務の改善にも活用でき、それによってチームの士気と生産性が大幅に上がります。

リサーチにおけるイテレーション

イテレーションは、リサーチによって促進されるべきです。デザインにおけるフォーカスグループであれ、開発におけるブラウザテストであれ、リサーチで学んだことはすべて、次のイテレーションを推進するために使用されるべきです。

場合によっては、リサーチは非同期かつ独立して行うことができ、「デザイン」または「開発」された成果物を得る必要がないこともあります。例えば、ナビゲーションのラベルや構造を考えるとき、デザイナーは様々な形式的・総括的なカード分類を繰り返し、最終的にシンプルな要件にたどり着くことができますよね。

反復的なデザインプロセスとはどんな感じか

反復的なデザインプロセスは、方法論によって異なりますが、一般的には、計画、アイデア出し、プロトタイプ、テスト、レビューという５つのステージにハッキリとと分けてまとめることができます。

ステージ１：計画

イテレーション（反復）は早いだけでなく、効果的に行われないといけないので、特定のユーザーニーズに焦点を当てたイテレーションを続けるには、ある程度の計画が必要です。

計画段階は、イテレーション中にどの問題を解決するかを決めることがほとんどです。時にはステークホルダーの観察に耳を傾けることもありますが、ほとんどの場合、以前のイテレーションやフィードバックフォームなどの別の場所からユーザーのフィードバックを直接集めるということになります。

いずれにせよ、この段階は常に「リサーチ」という燃料を得て、「目的」によって動かされます。多くのデザイン方法論では、問題は「機会」としてとらえ直され、多くの機会が存在する場合には、方法論は「ステークホルダーは製品の改善に一番いい機会であると思われるものに投票すべきである」述べています。例として、デザインスプリントの方法論は、機会を選択するために「How might we（どのようにすれば〜できそうか）」と「ドット投票（多数決のようなもの）」に依存しています。

つまり、計画段階では、 「今回のイテレーションで何を改善すべきか」という問いに答えられるはずです。

ステージ２：アイデア出し

この段階では、アイデアの良し悪しに関係なく、スケッチによってできるだけ多くのアイデアを出すことが目的です。これは通常、最高のアイデアを磨き上げ、最悪のアイデアを脇に置くという、それ自体が反復的なデザインプロセスそのものです。

創造力を維持するために、Crazy 8s（チームメンバーが30~60秒ごとに合計8つの異なるアイデアを考え、それぞれを紙に書き出す手法）、Four-Step Sketch（1）重要な情報を確認、2）紙の上でデザイン、3）複数のバリエーションの検討、4）詳細な解決策の作成を元にコンセプトを作り上げる）などの反復的な方法論があり、プロセスを無駄なく、楽しく、生産的に保つために時間制限を設けています。

最終的に、我々やチームは、少し洗練されたアイデアを１つ選び、前進させることになります。そして選ばれたアイデアは、プロトタイプ担当が問題提起、明確に定められた実行可能なタスク、そして詳細で十分なビジュアルガイドを得ることができるように、よくユーザーストーリーとして表現されます。

ステージ３：プロトタイプ

プロトタイプの段階になると、特定のアイデアに集中するため、反復的なデザインプロセスが少しシンプルに感じられるようになります。

生産性を最大化するために、通常は時間制限が設けられているので、UXPin のようなワークフローをサポートするデザインツールを使うのがベストであり、製品チームが手元にデザインシステムを用意して、UXデザイナーがそれを徹底的に理解すれば、さらなる効果が期待できます。

ステージ４：テスト

テスト段階は、解決しようとしている問題をプロトタイプが解決しているかどうか、また、どの程度解決できているかの確認を目的としています。何かを実装したり、リサーチを統合したりすることはなく、適切なリサーチ方法を用いて、ソリューションについてできるだけ多くのことを学び、フィードバック、発見、インサイトを文書化するだけです。

ステージ５：レビュー

最終段階であるレビューでは、リサーチを総括して、ソリューションの有効性について結論を出します。

結論は通常、以下のカテゴリーのいずれかに分類されます：

• 「すばらすい」：実装の時期
• 「いいですけど、、、」：プロトタイプに戻る
• 「不具合あり」：アイデア出しに戻る

デザインイテレーションプロセスの「やるべきこと」と「やってはいけないこと」

やる：失敗を恐れない

たとえ失敗したとしても、失敗を恐れず、試行錯誤し、「やってはいけないこと」を学びましょう。失敗は避けられないものなので、早めに解決して、そこから学ぶようにするのが一番です。

やる：柔軟に行く

デザインの方法論は、イテレーションに時間をかけすぎず、自由な創造性を発揮できるように厳しいルールを設けていますが、それでもある程度の自由度は認められています。最終的に、どの機会を優先するか、どのタイミングでイテレーションやテストを行うか、また、同時にいくつのデザインイテレーションプロセスを実行するかは、私たち次第なのです。

その判断は、あらゆるデータやリサーチを駆使しながらも、直感と経験によるところが大きいです。

やる：非同期での作業

ツールやチームメイトなど、利用できるすべてのリソースを活用し、他のデザイナーが非同期で製品の他の側面を解決でき、デベロッパーも有効な解決策を実装し始めることができることによって、最短時間で最大の成果を得ることができます。この２つが行われることで、製品のタイムラインが大幅に短縮されるのです。

やる：連携して耳を傾ける

どの問題を解決すべきなのか？どのイテレーションがベストか？プロトタイプをテストする準備はできているか？このフィードバックにはどんな意味があるのだろう？チームメイトから新鮮な視点と独自の専門知識を得ることで、このような疑問に自信をもって答えられるようになります。

やらない：すべてを解決しようとする

デザインイテレーションプロセスで解決する問題が決まったら、それ以外の問題を解決しようとするのは避けましょう。テストや観察の時に改善すべき点が見つかるのは当然ですが、それが後のイテレーションで良い出発点になるかもしれないので、それは書き留めておきましょう。

スコープクリープ（デザインイテレーションプロセスに忍び込む新たな問題）を許すと、気が散ってスピードが落ち、イテレーションが主要なメトリクスに与える影響を測るのが難しくなるだけですからね。

まとめ

デザインイテレーションの基礎は理解できたので、次のステップは、自身やチームに合った反復デザインの方法論を選択し、全員がそれを習得するために十分な時間を確保しましょう。

ただ、完璧なデザイン手法なんてないので、もしうまくいかない場合は、ワークフローを変更するか、別の方法を試すことを検討してください。

UXPinによるイテレーション（反復）デザイン

UXPinは、製品チームの速やかなイテレーションやアイデアのコラボレーション、実用的なフィードバックの獲得、そして最終的にはコードベースの高忠実度プロトタイプをサポートし、デベロッパーがより多くの作業を行えるようにするために作られたエンドツーエンドのデザインツールです。

UXPinでは、デベロッパー が HTML、CSS、JavaScript に変換されたプロトタイプの仕様の実装、デザインシステムのドキュメントの共同作成、さらにUXPin Mergeを使った実際のReactコンポーネントをプロトタイプにインポートできるため、検証済みのイテレーション作業をより速やかにして生産に移ることができます。

気になった方は、まずは14日間の無料トライアルからぜひお試しください。

The post デザイン イテレーション プロセス入門 appeared first on Studio by UXPin.

近頃、リーンスタートアップ、リーン生産方式、リーンソフトウェア開発、リーンUXなど「 リーン （Lean） 」という言葉をよく耳にするようになったのではないでしょうか。これらのリーンプロセスの目的は「余計なものを取り除くこと」であり、生産性を下げたり混乱させたりするシステムやプロセスをなくします。

リーン UX の主なポイント

• 「リーン生産方式」と「アジャイル手法の原則」を取り入れた、UXデザインへの共同アプローチである。
• ２０００年代初頭に出版されたリーンソフトウェア開発に関する本から派生したものである。
• 学習の優先順位付け、成果の重視、継続的な発見など１５の原則がある。

  適切なデザインツールを選択することで、UXのワークフローとプロセスの効率化につながります。UXPinは、スピード、一貫性、効率を向上させるために構築されたコラボレーションデザインツールです。１４日間の無料トライアルでぜひお試しください。

リーン UX とは

  リーンUX は、連携を促し、MVP（最小実行可能プロダクト）で多くのテストや実験行う成果ベースのデザインプロセスです。

リーン UX は、成果物よりも成果を優先し、「デザインするもの」ではなく「デザインする理由」を問います。「何」を「なぜ」に置き換えることで、デザイナーは「いいと思う人がいるから何か作ろう」という曖昧なものではなく、具体的に「デザインする理由や裏付けとなるデータ」を見つけないといけません。

このように、リーンUXでのデザインは「ワークフローの概念」というよりも１つの「思考プロセス」と言えます。デザイナーは構築する前に仮説を立て、それを検証しないといけません。この思考プロセスが、MVPコンセプトのテストと実験がリーンUXでのワークフローにおいて重要な理由です。

リーン UX の歴史

リーンUX は、２００３年に出版された『Lean Software Development（リーンソフトウェア開発）』という本とアジャイル手法から派生したものです。国際的に有名なデザインとビジネスの専門家であるジャニス・フレイザー氏は、２０００年代に「リーン UX」という言葉を世界で広めました。

“Lean UX is UX practice adapted for Lean Startups…”（日本語訳：リーンUX は、リーンスタートアップのために適応された UX手法である）と言います。

そして、彼はイノベーションとシリコンバレーのスタートアップ企業数社のスケールアップに関する知識と経験を活かし、リーンのコンセプトを UXデザインに応用しました。

アジャイル UX と リーン UX

  アジャイルUX と リーンUX は似たようなコンセプトですが、アジャイルUXはアジャイルを使っているチームに効果的であるのに対し、リーンUX のプロセスはどんなスタートアップや組織にも適しています。

リーン UX のプロセス

リーンUX のプロセスには、従来のUXデザイン思考のフェーズがすべて含まれており、プロトコルが違うだけであることに注意するのが重要です。

デザイン思考のプロセスには５つのステージがあります：

1. 共感：ユーザーが何を必要としているかを発見する
2. 確定：解決したい問題を特定する
3. アイデア出し：ユーザーの問題に対する解決策を考える
4. プロトタイプ：プロトタイプを作成する
5. テスト：プロトタイプをユーザーやステークホルダーとテストする

  一方、リーンUX はプロセスを３つのステージに分けます：

• 思案： 結果、仮定、ユーザーリサーチ、アイデア、メンタルモデル、スケッチ、ストーリーボード
• 作成：ワイヤーフレーム、プロトタイプ（MVP）、価値提案、仮説
• 確認：データと分析、ユーザビリティ・テスト、ステークホルダーとユーザーからのフィードバックの分析

  ご覧のように、どちらのプロセスも同じ要素を含んでおり、方法論だけが異なっています。

リーン UX の原則

こちらの記事で、Ben Ralph氏はコアとなる リーンUX の１５原則を概説しています：

1. 部門横断チーム – 同じプロジェクトに取り組む複数の部署のメンバーでチームを作る。
2. 小規模、専任、同拠点 – チームを５〜９人ほどの少人数にし、ひとつの問題に集中し、同じワークスペース（リモートチームの場合は同じタイムゾーン）に置く。
3. 進歩＝成果であり、アウトプットではない – ビジネス目標の達成は成果であり、機能やサービスはアウトプットである。
4. 問題集中型チーム – チームは新機能のデザインではなく、問題の解決に集中しないといけない。
5. 無駄を省く – ビジネス目標につながらない作業やプロセスを省く。（チームは明確な理由もなく会議に出席したり、報告書を作成したりしていないか？）
6. 少人数制 – チームは一度につき１つのタスクや目的を完了することに集中しないといけない。
7. 継続的な発見 – 顧客、エンドユーザー、ステークホルダーと定期的に関わる。
8. GOOB（Get Out Of the Building）- 社内で仮定をごちゃごちゃ話し合うのであれば実際のユーザーとアイデアをテストする。
9. 理解の共有 – チーム全体が共に学び、成長できるよう、協力し、アイデアを共有する。
10. アンチパターンのロックスター、達人、忍者 – どのチームメンバーも同じように評価する。
11. オープンな職場 – 自由にアイデアを共有できる環境を作る。アイデアに正誤はない！
12. 分析より創造 – うまくいくかどうか議論して時間を無駄にせず、まずはやってみて、その経験から学ぶ。
13. 成長よりも学習 – 最初に正しいものを作り、それから規模を拡大する。
14. 失敗の許可 – 実験とリスクを取ること。マーク・ザッカーバーグ氏の“move fast and break things.” （素早く行動し、破壊せよ）という有名な言葉にあるように、完璧さよりも市場投入スピードを優先する。
15. 成果物ビジネスからの脱却 – UXドキュメントは最小限に。結果に優先順位をつける。

  また、このリーンUXの １５原則には、以下の２つの共通テーマがあります：

• 行動を起こす – アイデアを MVP とプロトタイプに変える。テストを繰り返す。
• チームワーク – 共有、連携、連携

リーンUX のメリット

  従来のUXデザインプロセスには、監督会議、不要な文書や成果物、部署やチームのサイロ化、コミュニケーション不足など、時間をムダにしてしまう障害がありました。

リーンUX で、部門間で連携を促進させ、付加価値をもたらさないプロトコルを避けることでUXワークフローが最適化されます。

また、リーンUX の成果主義とは、UXデザイナーが、CTA（Call to Action） ボタンの色を議論するためにミーティングするのではなく、ユーザーの問題を解決し、アイデアのテストに集中するということです。

複数の部門から代表者を集めた部門横断チームを構築することで、デザイナーは多様なアイデア、経験、視点を活用することができます。この豊富な知識により、チームはより良いMVPを作り、より多くのアイデアをより早くテストすることができるのです。

リーンUX の利点は以下の５つにまとめられます：

1. 無駄を省く
2. 連携を促進
3. 速い
4. 効率的
5. ユーザー中心

 リーンUX の手法

リーンUX 手法の中心となる主な原則は以下の３つです：  

1. 仮定
2. 仮説
3. MVP（最小実行可能製品）

仮定

仮定は単なるアイデアですが、メリットとしては、間違っていても許されることです。これは「実験とリスクを取る」という リーンUX の哲学を補完するものですね。

仮説を立てるには、 思考 の段階で得た研究知識と問題提起が必要です。これらの知識があれば、次のような仮説を立てることができます：

• ビジネスの成果 – うまくいく成果とは？
• ユーザー – サポートしようとしている人（ユーザー・ペルソナ）について具体的にする
• ユーザーの成果 – ユーザーのペインポイントは何であり、製品がそれをどのように解決できるか？
• 製品の特徴 – 問題の解決に必要な製品の改善点

  一連の仮定を強みに、問題解決のための仮説を立て始めることができます。

仮説

UXの仮説とは、以下の３つの変数を持つ検証可能な仮定です：

1. しようとしていること
2. （ユーザーのための）問題解決
3. 望む結果の達成

  仮説は次のように書くことができます： ［このユーザー］のために［これをする］ことで［この結果］が達成されると思われる。

理論は検証されるべきものであって、議論されるべきものではありません。なのでチームメンバーは、仮説がどうなるかについての意見をめぐって議論になることは避けないといけません。次に何をすべきかは、テスト結果に任せましょう！

MVP（最小利用可能製品）

製品全体をデザインする代わりに、チームは仮説を検証するための MVP（最小利用可能製品）を作ります。  

仮説がうまくいけば、それを発展させるための小さな機能的製品を手に入れることができ、仮説が正しくない場合は、そのアイデアを捨てて、無駄な時間を最小限に抑えて次に進むことができます。

デザイナーは、ワイヤーフレーム、モックアップ、プロトタイプを使ってMVPを作り、あらゆるものをテストすることができます。チームは、より時間のかかるデジタルのデザインプロセスに取り組む前に、多くのアイデアをサッと洗い出すために、初期のテスト中に紙のMVPを作成することもあります。

MVP は仮説を検証できるものでないといけません。例えば、ボタンのインタラクションをテストしたい場合、紙のプロトタイプでは有意義な結果は得られませんよね。なので、デジタル製品のコンテクストの中でインタラクションをテストするには、色とコンテンツを備えた忠実度の高いプロトタイプを使用する方がいいでしょう。

それに対し、登録フォームをテストするために、何時間も何日もかけて完全に機能する忠実度の高い製品プロトタイプを作る必要はなく、シンプルなワイヤーフレームがあれば、より早く仕事を終わらせることができます。

UXPin における MVP

UXPin にあるデザインライブラリを使えば、デザイナーはコンポーネントをドラッグ＆ドロップして、MVP をサッと構築できます。高度なインタラクションを追加することもできるので、プロトタイプは最終製品のように見え、感じられるのです。

テストの精度を上げるために、より忠実なテストが必要ですか？  

デザインと開発のギャップを埋めるテクノロジーである UXPin Merge を使って、MVP を次のレベルに引き上げましょう。UXPinのデザインエディタをリポジトリ（GitおよびStorybookとの統合が可能）を介して社内のデザインシステムに同期することで、デザイナーは完全に機能するコードコンポーネントを使用してプロトタイプを構築できます。

UXPin Mergeを活用してリーンUX のプロセスを最適化した使用事例として、PayPalが行った検証があります。あるデザイナーが１ページのプロトタイプ（またはMVP）を2つ作成しました。１つ目はイメージベースのツールで、２つ目はUXPin Mergeを使用しました。イメージベースのデザインツールを使用した場合では、デザイナーは MVP の作成に１時間強かかり、UXPin Mergeを使用した場合だと８分で作成できることがわかりました。その上、Mergeで作成したプロトタイプの方がより忠実で機能的でした。

UXPin Mergeについての詳細や、洗練されたコードベースのデザイン技術で DesignOpsの課題を解決する方法については、ぜひこちらをお読みください。

デザイナーが MVPを作り終えたら、次はテストです！

テスト

最後に、チームは仮説と MVP をテストします。プロトタイプのテストでアイデアの検証をできるだけでなく、リサーチャーがユーザーの行動やプロトタイプとのインタラクションを観察することで、貴重なインサイトを集めることができます。

また、ユーザビリティテストによってユーザビリティの問題やビジネスチャンスも明らかになり、デザイナーはそれを次の反復に追加することができます。

テスト結果を元に、リーンデザインチームは新たなインサイトを得ることができ、思考 の段階に戻ってプロセスを再開することができます。

まとめ

リーンUX のプロセスは、ワークフローを最適化し、連携を強化するために、従来のデザインプロセスを再構成します。チームは新しいスキルを学ぶ必要はありませんが、製品をデザインする新しい方法論へのマインドセットシフトが必要なのです。

この記事で説明してきたように、UXPinを使うことで リーンUX の考え方とワークフローが実現できます。また、コメント機能を使うことで、チームはコミュニケーションをとったり、タスクの割り当て、完了後は［解決済み］にしてタスク管理を円滑で明確に行うことができます。

さらに、デザインライブラリがあれば、デザイナーは低忠実度のプロトタイプを省略でき、ユーザビリティテスト参加者やステークホルダーから実用的なフィードバックを得られる、高忠実度の MVPにすぐに移ることができます。

そして何よりも、UXPinのドキュメンテーション機能によって作業を最小限に抑えることができます。デザイナーはデザインのハンドオフ時に、デベロッパーのために UIに注釈を付けたり、指示などの説明を作成したりすることができます。 世界最先端のコードベースデザインツールの使いやすさをぜひご体験ください。１４日間の無料トライアルはこちら。

The post リーン UX ：UXで効率性を最大化するためのヒント appeared first on Studio by UXPin.

組織と製品の成功に導くためにも、「ユーザー」と「ビジネス」２つの目標において、適切な目標内容とそのバランスを取ることは極めて重要です。双方にメリットのあるソリューションを提供するために、製品チームは企業の戦略目標を達成し、ユーザーの目的や欲求、課題について考慮しなければいけません。

そこで本記事では、「ユーザーゴール」と「ビジネスゴール」２つの違いについて解説し、それぞれの目標内容を見ていきます。また、AirbnbとSpotifyの成功例も合わせてご紹介します。

エンドユーザーやステークホルダーとのテストを強化するために、完全にインタラクティブなプロトタイプを構築しませんか？適切なテストの実施とユーザビリティテスト参加者からの適切なフィードバックを得ることで、ユーザーとビジネスでのニーズを満たすデジタル製品体験を提供しましょう。無料トライアルはこちらから。

ユーザーゴール と ビジネスゴールのちがい

ユーザーゴール

ユーザーゴールとは、ユーザーが製品を使用する際に達成したい、満足させたい、解決したい目的、願望、問題のことです。ユーザーゴールを理解して優先順位をつけることで、デザイン思考の核となる原理である「使いやすく」「機能的」で「楽しい」製品となります。

ビジネスゴール

ビジネスゴールとは、企業が製品やサービスを通じて達成しようとする目標のことであり、収益の増加、市場シェアの拡大、ブランドの評判の向上などが挙げられます。

ユーザーゴールとKPIの把握

ユーザーゴールは、製品の種類やターゲット層によって異なりますが、ここでは一般的なユーザーゴールと、組織がその追跡に使うKPIをいくつかご紹介します。

効率性

ユーザーは、最小限の労力で効率的にタスクを完了させたいと思うものです。なので製品は、ユーザーがタスクを完了して目標を達成するまでの時間を短縮するのにプロセスが効率化されないといけません。

「効率化」のKPI：

• タスク完了時間
• タスクに完了に必要なクリック数/ステップ数/インタラクション数

使いやすさ

ユーザーは、わかりやすく、習得しやすく、操作しやすい製品を求めていることから、シンプルなナビゲーションと親切なガイダンスを備えた直感的な製品だと、UX（ユーザーエクスペリエンス）が向上します。

「使いやすさ」のKPI：

• エラー率
• CES（カスタマーエフォートスコア）
• SUS（システムユーザビリティスケール）

アクセシビリティ

デザイナーは、多様なユーザーや能力に対応した製品体験の提供が必要であり、調整可能なフォントサイズ、代替入力方法、スクリーンリーダーとの互換性などの機能は、インクルーシブなUX（ユーザーエクスペリエンス） の提供には不可欠です。

「アクセシビリティ」のKPI：

• アクセシビリティのチェックリストによる適合度

パーソナライゼーション（個別化）

パーソナライゼーションは、個人のニーズや好みに合わせてコンテンツや機能をカスタマイズして製品体験を上げるものであり、そのニーズを満たすことで、楽しささ、継続性、そしてその “いい体験” が提供される可能性が上がります。

「パーソナライゼーション」のKPI：

• 設定をカスタマイズしているユーザーの割合
• カスタマイズ可能な数
• 活用されたカスタマイズの数

信頼性

ユーザーは、製品に対してエラーのない安定性のある動作を好みます。特に、無料ではない場合はなおさらです。なのでユーザーの信頼と満足感の維持には、製品はエラーや不具合、性能上の問題がなく、正しく機能するものでないといけません。

「信頼性」のKPI：

• クラッシュ、ダウンタイムなどの、技術的な不具合の発生率
• MTBF（Mean Time Between Failure：平均故障間隔）
• MTTR（Mean Time To Repair：平均回復時間）

セキュリティとプライバシー

ユーザーは、組織に対して個人情報やデータの保護を期待しており、強固なセキュリティ対策と透明性の高いプライバシーポリシーを導入することで、ユーザーは自分のデータが保護されていることを確信できます。

「セキュリティとプライバシー」のKPI：

• セキュリティインシデントの発生件数
• データ侵害の件数
• 個人情報保護に関する苦情件数
• 管轄ごとの個人情報保護苦情件数

美観

魅力的で視覚に訴える製品は、CX（顧客体験）を上げ、製品の好感度アップに貢献します。また、優れた美観はブランドのアイデンティティを強化し、製品を競合他社から際立たせてくれます。

「美観」のKPI：

• インタビュー、レビュー、アンケートなどの、デザイン要素に関するユーザーからのフィードバック

楽しさ

ワクワク感、楽しさ、エンターテイメントなどの要素を取り入れることで、商品をより魅力的で楽しいものにすることができます。

「楽しさ」のKPI（エンゲージメントのメトリクス）：

• 平均セッション時間
• 継続率（リテンションレート）
• 使用頻度
• NPS（ネットプロモータースコア）

ソーシャルインタラクション

ユーザーは、社会的な交流や、自分の経験を他の人と共有することを求めることが多いことから、ソーシャルな機能を取り入れたり、ユーザーとのコミュニケーションを促したりすることで、製品の魅力が高まります。

「ソーシャルインタラクション」のKPI：

• コメント、いいね！、シェアなどの数
• １アカウントあたりの平均フォロー数
• 友人への招待状送付数

支援・サポート

アクセスしやすく、迅速なカスタマーサポート、包括的なドキュメントやチュートリアルを提供することで、ユーザーの満足度が上がり、ロイヤリティが構築されます。

「支援・サポート」のKPI：

• カスタマーサポートのチケット数
• カスタマーサポートの対応時間
• チケットの解決率
• サポート交流による満足度スコア

ビジネスゴールと KPI の把握

ビジネスゴールは、事業や業界、組織の戦略的優先順位によって異なりますが、ここでは、プロダクトデザインにおける複数のセクターで見られる、一般的な会社のゴールをご紹介します。

収益成長

多くの企業にとって、売上と収益の向上は主要な目標です。プロダクトデザインチームは、魅力的で機能的、かつ価格の高い製品を作ることで収益の増加に貢献することができ、収益を生み出すインターフェースやユーザーフローを効率化することで、収益の向上を図ることができます。

「収益成長」のKPI：

• 日次/週次/月次/四半期/年次の総売上高
• 収益成長率
• ARPU（１ユーザーあたりの平均収益）

マーケットシェア拡大

マーケットシェアは、業界全体の売上高に占める企業の割合を示すため、製品のメトリクスとして極めて重要です。マーケットシェアを高めるには、組織が多くの要素で競争力を持つことが必要です。例えば、イノベーション、機能、性能、良いUXの提供は製品チームに最も関係の深い要素です。

また、革新的なデザインで製品が差別化され、潜在的な顧客にとってより魅力的なものになり、マーケットシェアの拡大につながります。

「マーケットシェア拡大」のKPI：

• マーケットシェア率
• 市場浸透率
• 顧客獲得数 と 業界/競合他社のベンチマーク の比較

顧客獲得

新規顧客の獲得は、ビジネスの成長にとって極めて重要であり、他の多くのビジネスの目的に影響を与えますが、ターゲットとするユーザーのニーズや好みに合わせた製品をデザインすることで、新規ユーザーを獲得し、有料会員にすることができます。

「顧客獲得」のKPI：

• 日次・月次・年次の新規顧客数
• CAC（顧客獲得コスト）
• コンバージョン率（トライアルから有料プランへ、購読者/ユーザーから顧客へ、など。）

顧客維持

長期的な成功には、既存顧客のエンゲージメントと満足度の維持（顧客ライフサイクル）が不可欠です。プロダクトデザインは、ユーザーからのフィードバックの対応、機能に関する要望の実装、UXの継続的な改善によって、顧客維持の向上を実現できます。

「顧客維持」のKPI：

• 顧客維持率
• チャーン率
• CLV（顧客生涯価値）

ブランドの評価と認知度

強力で一貫性のあるブランドアイデンティティで、企業は際立ち、消費者の信頼が築かれます。プロダクトデザインは、製品が企業の価値観や美意識、ブランド戦略全般と確実に合致しているようにすることで、ブランドの評価を上げることができます。

「ブランドの評価と認知度」のKPI：

• ブランド認知度の測定
• NPS（ネットプロモータースコア）
• 定期的なセンチメント分析
• SNS のセンチメント分析

コスト削減

コストは利益に影響します。つまり、給与やボーナス、株主利益が下がるということです。なので企業は、製品開発、製造、またはサポート関連のコストを削減しようとすることがよくあります。

そのようなコストは、効率的なプロダクトデザインであれば以下のような方法で最小化することができます：

• 製品性能の最適化（サーバーコストの削減）
• インプットコストの削減
• ワークフローとプロセスのシンプル化
• 製品の品質向上
• 新作の市場投入までの時間の短縮
• サポートチケットの削減

「コスト削減」のKPI：

• デザイン、プロトタイプ、テストなどのプロダクトデザインのコスト
• プログラミング、サーバー、APIリクエストなどの製品開発コスト
• 運用コスト
• 労働時間・コスト
• 従業員のオンボーディングコスト

スケーラビリティ

特に、成長意欲の高いスタートアップ企業では、需要の増加や新しい市場への進出のために、ビジネスの規模を拡大しなければならないことがよくあります。なのでプロダクトデザインチームは、製品やサポートするリソースが将来のニーズに対応できるよう、スケーラビリティを考慮する必要があります。

「スケーラビリティ」コストにおいてのKPI：

• 新製品リリースの市場投入までの時間
• 負荷や需要が増加した場合のシステム性能
• 新しい市場や顧客セグメントへの製品適応性

イノベーションと差別化

関連性と競争力の維持には、継続的なイノベーションが必要です。製品チームは、新しい技術、製品、アプローチを探求し、イノベーションを推進する上で極めて重要です。

「イノベーションと差別化」においてのKPI：

• リリースされた新機能や製品改良の数
• 研究開発予算のうち、イノベーションに配分される割合
• 特許出願数または業界賞受賞数

法規制の遵守

企業は、製品が関連する法律、規制、および業界標準に確実に準拠しているようにしないといけません。そのため製品チームは、製品、UI、およびプロセスが確実に規制要件を満たしているようにし、例えばカリフォルニア州やヨーロッパのユーザーなど、特定の管轄区域に合わせて必要な調整を行う必要があります。

「規制遵守」のKPI：

• コンプライアンス監査の合格数
• コンプライアンス違反の発生件数
• コンプライアンス違反により発生した罰金または違約金。

環境および社会的責任

多くの企業は、持続可能性や社会的責任への取り組んでいます。特に法律で特定の目標や要件を満たすことが義務付けられている国や州で、このような取り組みを行っています。そのため、製品チームは、e-waste（デジタル廃棄物）の削減、パフォーマンスの最適化（サーバーリクエストの削減）、製品ファイルサイズの縮小によるストレージの最小化などの目標に貢献するといいでしょう。

「環境および社会的責任」のKPI：

• 製品に関連する温室効果ガス排出量の測定と削減
• デザインおよび開発プロセスにおけるエネルギー消費量の測定と削減
• E-wasteの測定と削減
• 製品の社会的インパクトの測定

ビジネスゴール と ユーザーゴール のバランスのとり方

「ビジネスゴール 」と「 ユーザーゴール 」のバランスをとるのは難しく、ユーザーのニーズとビジネスゴールに対応した機能や改善の開発には、継続的な反復が必要です。

そこで、製品チームが適度なバランスを取ることに成功した２社の実例を以下でご紹介します。

例１：Spotify

•  ユーザーゴール ： ユーザーは、お気に入りの曲やアーティスト、プレイリストに簡単にアクセスでき、パーソナライズされた楽しいリスニング体験を望んでおり、自分の好みに合わせて新しい音楽を発見することも大切にしている」。
  
•  ビジネスゴール ：ユーザーベースを拡大し、プレミアム購読と広告による収益を増やすことを目標としており、製品チームは、ストリーミング業界における競争力を維持するために、UI（ユーザーインターフェース）、機能、パフォーマンスを常にアップデートしている。
  
• 両者のバランスを取るためのアプローチ：『Discover Weekly』 や 『Release Radar』 など、パーソナライズされたプレイリストを生成するアルゴリズムに投資することで、ユーザーとビジネスのゴールに取り組んでいる。このような機能は、ユーザーに合わせた音楽のオススメを提供し、ユーザーがプラットフォームでより多くの時間を過ごすことの促進、広告露出の増大、購読のアップグレード促進をすることで、ユーザーの満足度を高める。また、UXを向上させる機能に焦点を当てながら、収益モデルに対応することで、ユーザーとビジネスのゴールをうまく両立させている。

例２：Airbnb

•  ユーザーゴール ：ゲストは、シームレスな予約体験、宿泊施設の多様性、ホストとの信頼できるコミュニケーションを望んでいる。
  
•  ビジネスゴール ：ホストのネットワーク拡大、予約数の増大、サービス料による収益の獲得を目的としており、信頼できる宿泊施設マーケットプレイスとしての評判を維持したいとも考えている。
  
• 両者のバランスを取るためのアプローチ：Airbnbは、直感的な UI、強固な検索とフィルタリング機能、ゲストとホスト間の信頼できるメッセージシステムに投資することで、 ユーザーゴール に取り組んでおり、ビジネスゴール達成のために、「Airbnbのホスト向けリソースセンター」など、ホストがリスティングやカスタマーサービスを改善するためのサポートやリソースを提供している。

また、Airbnbはレビューと評価システムを導入することで、ゲストとホストの透明性と信頼性を確保しており、企業の成長と成功には、このような「ユーザーゴール」と「ビジネスゴール」 のバランスが欠かせません。

インタラクティブなプロトタイプを使って、ステークホルダーに好印象を与える・顧客に愛されるユーザー中心の製品をデザインしてみましょう。無料トライアルにサインアップして、UXPinの多機能で高度な機能をぜひお試しください。

The post UXのティッピングポイント – ユーザーゴール と ビジネスゴール appeared first on Studio by UXPin.

コンポーネント駆動型のプロトタイプは、UXデザインの次なるイテレーションです。デザイナーはもはやゼロからデザインすることはなく、エンジニアが書くコードはより少なくなっています。  

これによってもたらされることは、機能横断的な連携の強化、市場投入までの時間短縮、一貫性、エラーの減少、より良いテスト、ステークホルダーからの有意義なフィードバック、そしてスムーズなデザインのハンドオフが実現します。  

UXPin Mergeを使うことで、これらのメリットがすべて実現可能です。詳しくはこちらのページをご覧ください。  

 コンポーネント駆動型 プロトタイプとは

  コンポーネント駆動型のプロトタイプは、デザイナーが既製のUI（ユーザーインターフェース）要素を使ってUIを構築する製品デザイン手法の１つです。ゼロからデザインするのではなく、インタラクティブなコンポーネントをドラッグ＆ドロップしてプロトタイプを作成します。  

このデザイン手法は、フロントエンドエンジニアがゼロからコーディングするのではなく、既存のコンポーネントライブラリを使ってUIを構築するコンポーネント駆動開発に由来するものです。  

Storybookはこの開発方法でよく使用されるツールであり、エンジニアはコンポーネントを分離して構築・管理することができます。

コンポーネント駆動型プロトタイプも同様に、ゼロからデザインするのではなく、オープンソースのUIライブラリや製品のデザインシステムを使って、既製のコンポーネントでUI構築に集中することができます。  

コンポーネントは通常、色、タイポグラフィー、サイズ、スタイルなどの定められたプロパティで完全にインタラクティブであり、それによってデザイナーはプロトタイプ作成、テスト、イテレーション、デザインプロジェクトの提供をより速く、より正確に行えるようになります。  

 コンポーネント駆動型プロトタイプ の手法

  コンポーネント駆動型のプロトタイプはコンポーネント駆動開発からヒントを得たものですが、ブラッド・フロント氏のアトミックデザイン原則がデザイン手法の基礎となります。  

アトミックデザインにおいては、UI構築の際に最小のUI要素から始めて徐々に規模を拡大していく段階的な取り組み方法を採用しています。ゼロからデザインするのではなく、要素を組み合わせ、より大きなコンポーネントやテンプレート、UI（ページ）を作成します。

アトミックデザインの5つの要素には、以下のようなものがあります：  

1. 原子（Atoms）：HTMLタグ、フォント、アニメーション、カラーパレットなど、UIの基礎となる要素。デザイナーはこれらの要素を分解することはできない。
2. 分子（Molecules）：原子が組み合わさって、フォームのラベルや入力フィールドのような小さなインタラクティブなコンポーネントを作る。
3. 生体（Organisms）：ユーザビリティやアクセシビリティの問題を解決するために、デザイナーが使うインタラクティブ性の高い複雑なUIコンポーネントであり、ロゴ、検索フィールド、プライマリーナビゲーションなどが例として挙げられる。
4. テンプレート：ブログのフィード、カルーセル、導入事例、フッターなど、さまざまなウェブサイトやアプリケーションの部門の構造を定めるものであり、テンプレートには、このような大きな構造を作成するための原子、分子、生体のグループ化が含まれている。
5. ページ：ユーザーのニーズとビジネスゴールを一致させ、まとまりのあるUIを作成するためのテンプレート集を使った完全な画面。

コンポーネント駆動型プロトタイプにおける8つのメリット

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

  コンポーネント駆動型のプロトタイプの最も大きなメリットは、デザインと開発の連携の強化であり、デザイナーとエンジニアは、レポジトリやnpmパッケージ、Storybookでホストされている同じコンポーネントライブラリを使って作業します。  

UXPin Mergeのようなツールは、デザインと開発の間の繋がりを促し、各部門が単一のコンポーネントライブラリにアクセスできるようにします。デザインチームが視覚的なUIコンポーネントを使う一方で、エンジニアはその背後にあるコードを見るというように、同じ要素を異なる視点から見ることができます。   

2. デザインの一貫性

  この信頼できる唯一の情報源（Single source of truth）は、デザインと開発全体の一貫性の維持に優れており、インタラクティブ機能とスタイリングが組み込まれているため、デザイナーはUIコンポーネントを組み合わせてUIを作成することだけを考えればよく、色、タイポグラフィー、サイズ、境界線の半径、正しいアイコンの使い方などのバリエーションといったよくある問題を排除することができます。  

また、デザインの一貫性は、複数のチームが同じ製品に取り組む際に重要な、承認され統一されたコンポーネントやUIを受け取るエンジニアにも利点があります。

3. 共有可能

  デザインチーム間でコンポーネントを共有することで、デザインの一貫性を維持しながら、UXワークフローとデザイナーの連携を効率化することができます。  

静的なUIキットで、デザイナーはUI要素の共有ができますが、そのようなキットは忠実性と機能性に欠けています。そうなると、デザイナーが自らセットアップしなければならず、それがインタラクションデザインの矛盾やドリフトにつながります。  

そこでコンポーネントライブラリを共有すれば、デザイナーはビジュアル要素、インタラクション、スタイリング、その他デザインシステムが設定するあらゆる制約を受けることができます。  

4. よりスムーズなデザインハンドオフ

  デザインハンドオフは、デザイナーとエンジニアにとって、本来はストレスの多い、虚構に満ちたプロセスであり、デザイナーは、ツールやビデオ、ドキュメントや静的なデザインを使って、プロトタイプが「何をするはずなのか」を示します。  

UXPin Mergeでデザインハンドオフを行うと、エンジニアが同じコンポーネントを使うため、不確実性がなくなり、文書化を減らすことができます。デザイナーは、各コンポーネントのインタラクションやスタイリングのプロパティで技術的な制約を受けないようにできるので、エンジニアが再現できないデザインを目にすることはほとんどありません。  

5. 有意義なフィードバック

  ユーザビリティの参加者やステークホルダーも、コンポーネント駆動型のプロトタイプの恩恵を受けます。完全にインタラクティブなプロトタイプは、最終的な製品とその能力について、誰もが現実的に期待することができ、デザインチームは、より高い忠実度と機能性により、ステークホルダーとエンドユーザーから有意義で実用的なフィードバックを得ることができるのです。

6. より高速なイテレーション

コンポーネント駆動型のプロトタイプのワークフローにより、デザイナーはテストやステークホルダーからのフィードバックに対して、より速やかにイテレーションを行うことができます。ドラッグ＆ドロップによるデザインプロセスと簡単にできるプロパティへのアクセスにより、デザイナーはその場で変更を加えることができるのです。ちなみにPayPalは、UXPin Mergeに切り替えた後、以下のようにその効率性の向上を実感しました：

「忠実度の高いプロトタイプをより早く作り、セッション後にすぐにフィードバックが得られます。すぐに修正できることがあれば、次の参加者の前にその変更を行い、以前よりずっと早くフィードバックを得ることができます。」- PayPal, UXシニアマネージャー、エリカ・ライダー氏

UXPin Merge のユーザーはPatternのようなツールの恩恵を受け、デザインチームは1つのコンポーネントが持つ複数のバージョンを共有のパターンライブラリに保存することができます。そしてデザイナーは、UXPinのPropaties Panel（プロパティパネル）を使う代わりに、UI要素とパターンを切り替えて、より速くイテレーションを行うのです。  

7. レスポンシブデザイン機能

  レスポンシブデザインは、デザイナーにとって時間のかかる作業です。1つの画面に対して複数のレイアウトの作成が必要があり、それによってデザインプロジェクトに多大な時間が費やされることになります。そこで、レスポンシブコンポーネントを開発することで、デザイナーはプロトタイプを１つ作成するだけで、すべてのレイアウトに対応できるようになります。  

Merge のコンポーネント駆動型のプロトタイプのソリューションでは、デザイン システムチームはコンポーネントをiFrameでラッピングして、複数のビューポートに対応させることができ、デザイナーはデザインをプレビューする際に、ドロップダウンを使ってこのようなレイアウトを切り替えることができます。  

8. デザインの拡張性

  コンポーネント駆動型のプロトタイプのドラッグ＆ドロップの特性とは、非デザイナーが、画像ベースのデザインツールを使う熟練のUXデザイナーよりも、高い忠実度と機能性でプロトタイプを構築することができるということです。  

PayPalが2019年にUXPin Mergeを使い始めた際に、製品チームをトレーニングすることでデザインプロジェクトの90%を完了させることができました。UXデザイナーは製品チームを指導し、複雑なユーザビリティの問題をサポートすることで、UX専門家を増やす必要性が下がるとともに、ハイレベルなUXの取り組みに集中できるようになりました。  

コンポーネント駆動のワークフローは、学習曲線を大幅に短縮し、プロトタイプを高速化することで、非デザイナーにもデザインプロセスがより身近なものになっているのです。  

コンポーネント駆動型のプロトタイプのワークフローを導入している会社

  PayPalとTeamPasswordは、コンポーネント駆動型のプロトタイプを使って不整合を排除し、顧客にポジティブなユーザー体験を提供しています。  

PayPalが巨大な多国籍企業であるのに対し、TeamPasswordは小規模なチームで運営されていることから、今回この２社を例に選びました。  

両社とも、UXPin Mergeに切り替え、コンポーネント駆動型のプロトタイプのワークフローを採用することで、大きなメリットを得られました。  

PayPal

  PayPalは、コンポーネント駆動型のプロトタイプのとてもいい成功例です。同社はUXPin Mergeに切り替えた後、画像ベースのデザインツールを使っていたときよりも8倍速くデザインプロジェクトを完成させました。  

「PayPalで使っている別のデザインツールで、1ページのベクターベースのデザインを行い、その後、UXPinでMergeコンポーネント ライブラリを使って全く同じプロトタイプを作成しました。Merge だと、デザイナーは約 8分間でできますが、他のデザインツールでは1時間以上かかりました。」

「社内でよくある問題は、製品チームがUXデザインをボトルネックと捉えていることです。まずはそのボトルネックを取り除き、製品チームが自分たちでデザインを行えるようにする戦略を実行しました。」 – Paypal、エリカ・ライダー氏  

PayPalのコンポーネント駆動型のワークフローでは、製品開発に関わるすべての人がUXに責任を持つようになります。最も大きな影響として、コンポーネント駆動型のプロトタイプによって、PayPalの製品チームはより多くのデザイン責任を担うことができるようになった点です。  

Teampassword

  パスワード管理は、組織が顧客の確保および維持のために信頼を勝ち得なければならない、競争の激しい業界であり、デザインは、ブランドの強化や、顧客の信頼とロイヤルティを獲得する一貫したユーザー体験を生み出す上で、重要な役割を担っています。  

「お客様は私たちに「ログイン記録」という重要な情報を託しています。矛盾や時代遅れのデザインは、当社がその情報を安全に保つのに十分な最先端の技術を備えているかどうか、一部のお客様に疑念を抱かせてしまうことになります。フロントエンド開発は、バックエンドのパフォーマンスに対する信頼と自信を築くのです。」トニー・カッチャーボ氏、TeamPasswordオペレーションディレクター  

TeamPasswordはゼロからデザインする代わりにオープンソースのコンポーネント ライブラリを使い、プロトタイプとテストのためのデザイン チームは設けられてません。その代わりに、TeamPasswordのフロントエンドのデベロッパーは UXPin Merge を使って新しいUIや機能のプロトタイプとテストを行っています。  

このコンポーネント駆動ワークフローによって、TeamPasswordは製品のデザイン、テストなどが高い整合性で行うことができ、市場競争の中での運営において欠かせないものとなっています。  

コンポーネント駆動型のプロトタイプの始め方

  デザインと開発の間に信頼できる唯一の情報源（Single source of truth）を作成することはこれまで以上に簡単になります。UXPin Mergeでを使用することで、組織はコンポーネント ライブラリをインポートでき、デザイナーとエンジニアは同じ UI 要素を使えるようになります。  

コンポーネントの取り込み

  デザイナーは、UXPinのNPM統合を使ってオープンソースのコンポーネントライブラリをインポートしたり、エンジニアの協力を得て、MergeのGitまたはStorybookの統合を使って製品のデザインシステムを同期させたりすることができます。

プロトタイプ

どの方法でUXPinとコンポーネントを同期させても、デザインの流れは同じです。

• MergeのUI 要素をキャンバスにドラッグして、プロパティパネルで変更する。また、より大きく、より複雑なコンポーネントを作成するのにUXPin Pattern（パターン機能）を使って要素を組み合わせることも可能。
• コンポーネントを接続してプロトタイプを作成し、ユーザビリティテストやステークホルダーへのプレゼンテーションを行う。
• 完璧なソリューションを見つけるまで、テストとイテレーション行う。UXPinでは、【プレビューと共有】を使ったブラウザでのテストや、【UXPin Mirror】を使ったモバイルでのテストが可能。
• プロジェクトに【ドキュメンテーション】を追加し、デザインハンドオフの時にコメント機能を使ってエンジニアと共同作業を行う。

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

UXPin Mergeは組織全体での「信頼できる唯一の情報源（Single source of truth）」として機能し、それによって製品のデザインシステムの管理および拡張のお手伝いをします。さらに、コンポーネントライブラリのレポジトリに変更があると、UXPinのデザインエディタに自動的に同期され、チームに更新が通知されます。

UXPin Mergeのバージョンコントロール機能で、リリースの追跡や、デザイナーによる以前のバージョンへの切り替えができるため、アップデートを完全にコントロールすることができます。

UXPin Mergeが提供するコンポーネント駆動型のプロトタイピングを試してみませんか？詳細とこの革新的なテクノロジーへのアクセス権のリクエスト法については、Mergeのページをぜひご覧ください。

The post コンポーネント駆動型 プロトタイプとは？ appeared first on Studio by UXPin.

 Facebook のマーク・ザッカーバーグ氏の“Move fast and break things!（素早く行動し、破壊せよ）“ という言葉もある通り、ラピッドプロトタイピング  によって「プロトタイプ」の制作過程がスピードアップし、デザインチームは最終デザインをより早くエンジニアリングチームにプッシュすることができます。  

完璧を求めると貴重な時間が費やされ、それによって製品チームは競争から一歩遅れてしまいますが、ラピッドプロトタイピングによって、デザインチームはデザインの主な機能とフローだけに集中でき、速やかに市場に投入することができます。  

主なポイント  

• ラピッドプロトタイピングは、製品開発の次の段階で絶対に必要な機能や画面を考慮しながら、実用的なプロトタイプを迅速に作成する方法論である。
• ラピッドプロトタイピングのプロセスにプロトタイプの作成やユーザーとのテスト、可能な限り迅速な反復があることによって、デザインは可能な限り早く開発されるようになる。
• ラピッドプロトタイプによって、ステークホルダーは、リソースを投入して製品を作る前に、製品がどのように見えるか、 UX（ユーザーエクスペリエンス）がどのようなものかをすぐに確認することができる。
• ラピッドプロトタイピングは、効率的で、速く、アクセスしやすく、ユーザーが楽しめる製品を作ることに重点が置かれている。

  UXPinの高度なプロトタイピング機能により、デザインチームは製品を迅速に構築できます。プロトタイピングでReactコンポーネントを使って、生産可能なプロトタイプを１０倍速く構築してみませんか。詳しくは UXPin Mergeをぜひご覧ください。  

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

ラピッドプロトタイピングは、ユーザーフローをテストして速やかにアイデアを検証するために、忠実度の高いプロトタイプを作成するプロセスであり、デザイナーがUXの最適化だけに集中して「あったらいいな」の機能や見た目に振り回されるのを防ぐべく、「スピード」を目標としています。

チームが製品を市場に投入するのが早ければ早いほど、成長と製品改良のための資金を得るための収益が生み出されますからね。

ラピッドプロトタイピングと従来のプロトタイプ

ラピッドプロトタイピングに比べ、従来のプロトタイピングプロセスでは、以下５つの段階で定義されています：

1. スケッチ：紙に大まかなスケッチを描き、ブレインストーミングを行う。
2. ワイヤーフレーム：ボックスや大まかなシェイプで骨格を作り始める。
3. モックアップ：色、タイポグラフィ、写真、その他のビジュアルデザイン要素を使って、ワイヤーフレームに詳細を注入する。
4. プロトタイプ：基本的なプロトタイプのために画面をつなぎ合わせたり、高度なプロトタイプのためにアニメーションやインタラクションを追加することで、モックアップにインタラクティブ性を追加する。
5. ハンドオフ：エンジニアリングのチームは、最終製品にするためのプロトタイプを受け取る。

ただし、Lean UXやラピッドプロトタイピングのような新しい考え方が一般化し、できるだけ早くコーディングに取りかかりたい派の人も多いことから、上記のような従来の手法は時代遅れになりつつあります。

 ラピッドプロトタイピング の利点

 ラピッドプロトタイピング の主な利点を４つざっと見てみましょう：

1. コスト削減：製品をより早く市場に投入することで、人件費が削減されると同時に、製品の早期収益化が実現する。
2. 時間の節約 ：テスト中にユーザーのペインポイントを把握できることで、変更に多大な時間とコストがかかるような開発にエラーが発生する可能性がなくなる。
3. ユーザー重視：時間が限られているため、チームはUXの最適化に集中し、「あったらいいな」のような機能に惑わされない。
4. アクセス可能：デザイナーでなくてもプロトタイプを作成してテストできる環境が作り出され、このプロセスにより、製品チームは 、（多くの場合は数回の反復を経て）デザインを製品チームに提示する UXデザイナーにアイデアを説明する必要がなくなり、時間が節約される。

 ラピッドプロトタイピング のプロセス

ラピッドプロトタイピングは独立したプロセスというより、効率化のためのフィルターであり、できるだけ質の高いフィードバックを得るために、フィードバックに基づいてサッと修正を行い、Hi-Fi（高忠実度）のプロトタイプに素早く移行します。

また、ラピッドプロトタイピングでは、明確な目標とKPIの設定が重要であり、チームは設定した目標を達成するために必要なタスクだけに集中します。

そして以下のステップは、ラピッドプロトタイピングとテストのフェーズに適用されます（デザインプロセスの初期段階はすでに完了していると仮定します）。

事前準備 – インタラクティブワイヤーフレーム

ラピッドプロトタイピングがデザインプロセスの最終段階に重点を置くのに対し、インタラクティブワイヤーフレームは初期段階のデザインにスピードと効率をもたらします。

インタラクティブなワイヤーフレームがあれば、UXチームはモックアップや忠実度の高いプロトタイプのデザインに移行する際に、大きなスタートを切ることができます。

インタラクティブワイヤーフレームに関する無料電子書籍をダウンロードして、この初期段階のデザイン戦略がラピッドプロトタイピングプロセスの最適化にどのように役立つかぜひご覧ください。

ステップ１：デザインシステムの構築

デザインシステムで、デザイナーは効率的なラピッドプロトタイピングに不可欠な要素である「スピード」と「一貫性」を維持することができます。また、デザインシステムによって、新しいデザイナーのオンボーディングは効率化され、（PayPal が Mergeで行なっているように）デザイナーでなくても製品を構築できるようになります。

UXPinでは、デザインシステムをゼロから作成したり、Google のマテリアルデザイン、Bootstrap、iOSのような広く使われているシステムを使うことができます。さらに、すぐに使えるインタラクティブな UIパターンを使って、再利用可能なコンポーネントを簡単に構築できます！

ステップ２：モックアップの作成

デザインシステムが完成すれば、モックアップの作成はドラッグ＆ドロップで簡単にできます。

ちなみに、Sketchでデザインしたい場合は、UXPinのSketchインポートを使えば、デザイナーは簡単にモックアップをアップロードして、プロトタイプやテストを始めることができます。

ステップ３ – UXPin 流インタラクションの作成

モックアップが完成したら、ユーザーフローをつなげてインタラクションを追加します。

まずはインタラクションをシンプルにしておきましょう。チームメンバーがコピー＆ペーストするだけで済むように、デザインシステムでインタラクションのガイドラインを作成するといいですね。シンプルなインタラクションで時間の節約になるだけでなく、統一性が保たれ、最終製品は見やすくて一貫性のあるものになりますからね。そしてデザイナーはいつでもインタラクションの修正をすることができます。

ここでの目標は、ユーザーがフローを完了するために重要なインタラクションだけに集中することだと覚えておいてください。UXデザイナーは、テストから正確なフィードバックを得るためにも、最終製品のように見えるプロトタイプを作らなければなりません。

UXPinを使うことで、コンポーネントや変数を作成、ステートを追加し、実際のデータを使って、忠実度の高いプロトタイプ作成して最終製品とまったく同じ外観と機能性を確かめることができます。

• コンポーネントを使うと、ボタン、アイコン、カードなどの再利用可能な要素を作成できるため、時間の節約になる。マスターコンポーネントはコンポーネントのプロパティを確定し、インスタンスコンポーネントはマスターコンポーネントの内容を反映する。マスターコンポーネントへの変更は、すべてのインスタンスコンポーネントに反映されるため、デザイナーは要素を１つ編集するだけで、フロー全体に変更を加えることができる。

• 変数を使うと、ユーザーの入力を保存し、提供されたデータに基づいてプロトタイプ内でアクションを実行できる。UXチームは、ユーザビリティテストやステークホルダーへのデモンストレーションの際に、個別化されたエクスペリエンスを提供することができる。これが、UXPinが持つラピッドプロトタイピングを促進する強力な機能である。
• 例えば、デフォルト、ホバー、アクティブ、無効など、要素やコンポーネントのステートを作成できる点は、UXPinのもう一つの強力な機能である。さらに、ドロップダウンやナビゲーションメニューのように、ステートをアクティブにしたり切り替えたりする「トリガー」を設定することもできる。
• UXPin Mergeを使うと、デザイナーは忠実度の高いプロトタイプを他のデザインツールにはないレベルで作成できる。UXPin Mergeは、コード化されたコンポーネントを使ってデザインする際に、プロトタイプの外観や機能を最終製品とまったく同じにすることができる。 − UXPin Merge については、本記事の後半で。

ステップ３：テスト、微調整、繰り返し

忠実度の高いプロトタイプが完成したら、いよいよテストです。UXPin では、ブラウザ上でプロトタイプをテストしたり、UXPin Mirror （iOS & Android）をダウンロードしてモバイルデバイスでテストすることができます。

そして UXチームは、ステークホルダーからのフィードバックやユーザビリティ調査を集め、デザインを微調整してから、テスト段階に戻って変更を検証することができます。

また、UXデザイナーは、即座にフィードバックを得てラピッドプロトタイピングプロセスをスピードアップするために、テスト中にちょっとした変更を行うかもしれません。

UXPin Merge がラピッドプロトタイピングを速める方法

従来のデザインツールは、ベクターまたはラスターグラフィックスをレンダリングします。そのグラフィックは最終製品のように見えるかもしれませんが、機能が限られているため、テストやステークホルダーからの有意義なフィードバックは得られません。

この方法で作成されたプロトタイプだと、カートに商品を追加したり、ビデオを再生したりするように、ユーザーがデータを入力したり、要素の状態をアクティブにしたりしたことを「想像」しないといけません。

UXPinはコードベースのデザインツールです。デザイナーがキャンバスに何かを描くと、UXPin は HTML/CSS/JS のコードをレンダリングします。そこでさらに一歩進んで、Git や Storybookと統合する Merge テクノロジーを導入した結果、ゼロからデザインすることなく、用意されたインタラクティブなUI要素でプロトタイプを作成できます。

UXPinのプロトタイプは最終製品のように見え、機能するため、テスト参加者やステークホルダーは、UXPinのプロトタイプを操作したときに何が起こるかを考える必要がなくなります！また、デザイナーは、JSON、Google Sheets、または CSV から実際のデータを使って、本物の製品体験をシミュレーションし、複数のシナリオをテストするために素早く変更することもできます。

さらに、UXPin Mergeは、実際のUXと有意義なフィードバックによってラピッドプロトタイピングを加速させるだけでなく、デザインからエンジニアリング、そして最終製品への移行を大幅に短縮してくれます。

PayPalのDesignOps 2.0 – UXPin Merge のサクセスストーリー

UXPin Mergeは PayPalのDesignOps 2.0の中核を成しており、プロダクトチームのメンバーがラピッドプロトタイピングを使ってPayPalの社内ツールのインターフェースを構築しています。

基本的に、UXPin MergeでPayPalの製品チームは、UI（ユーザーインターフェース）を構築し、Reactコンポーネントで忠実度の高いプロトタイプをテストするための、ノーコードのドラッグ＆ドロップツールを使用できます。さらに、PayPalのプロダクトマネージャーは、JSON、Google Sheets、または CSVから実際のデータをインポートすることで、プロトタイプに最終的な製品機能が付きます。

また、PaypalのUXデザイナーは、プロトタイプやテストのプロセスに参加する代わりに、プロダクトチームのメンターとして、必要に応じて指導やサポートを提供します。

コードコンポーネントを使うことで、PayPalのエンジニアは、ベクターやラスターベースのデザインツールを使うよりもずっと速く製品チームのプロトタイプを開発することができるのです。

UXPin Mergeによって、PayPalがたった３人のUXデザイナーで効率的なラピッドプロトタイピングを実現できるのであれば、今あなたが行なっているデザインプロセスに何をもたらせるでしょうか？ぜひUXPin Mergeのページをご覧ください。

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

Discover UXPin Merge

The post ５分でわかる【 ラピッドプロトタイピング のプロセスと忠実度】 appeared first on Studio by UXPin.

組織がデザインプロセスを効率化し、連携を強化しようと努力する中で、DesignOpsは『デザイン目標』と『ビジネス目標』を一致させるための基盤としての役割を果たします。

UXPinは最近、３人の DesignOps エキスパートによるウェビナー「Strategies for Building Resilient DesignOps Practice（レジリエントな DesignOpsプラクティス構築のための戦略）」を開催し、そこでは貴重なインサイトと戦略が得られました。

ウェビナーでは、以下の３人の業界専門家によるパネルディスカッションが行われました：

• Salomé Mortazavi氏：SiriusXM社の DesignOpsおよびデザインシステム担当シニアディレクター
• Meredith Black氏：豊富な経験を持つDesignOpsコンサルタント
• Adam Fry-Pierce氏：Google社のUXリーダーシップ担当チーフスタッフ

知識が豊富なこの三方からユニークな視点と経験がもたらされ、DesignOpsにおける課題と機会について議論されました。

UXPinの「信頼できる唯一の情報源（Singoe source of truth）」で、効率的なタスク管理とワークフローを実現します。アクセス方法については、Merge のページをぜひご覧ください。

デザインチームの真のニーズを突き止める

レジリエントな DesignOps のプラクティスを構築するには、デザインチームの真のニーズを理解し、それに対処することが非常に重要です。デザインチームが直面する基本的な課題の１つに、デザインと全体的なビジネス戦略との整合性の欠如があり、この不整合はデザインプロセスを阻害するような、非効率性やコミュニケーションのギャップ、そしてリソース制約につながってしまいます。

共通のビジョン作り

デザインチームのニーズに対応するための極めて重要なステップは、共通のビジョンの作成であり、このビジョンの共有には、デザインチームの目標をビジネスの幅広い目標と一致させることが含まれます。組織内でのデザインの役割について共通の理解を確立することで、チームはより結束して効果的に働くことができるのです。

デザインチームのビジョンのステートメントの作成についてはこちら。

ワークフローの効率化

デザインチームをサポートするもうひとつの重要な側面は、ワークフローの効率化です。デザインチームは、断片化されたプロセスによるボトルネックや非効率によく遭遇します。そこで DesignOps が、ワークフローを効率化することで効率性を上げ、連携しやすい環境を促進することで、デザインチームがこのような課題を克服できるよう支援します。

デザインシステムの導入

デザインシステムの導入は、コミュニケーションギャップやリソースの制約に対処する効果的な方法です。デザインシステムは、さまざまなデザインプロジェクト間で一貫性を保つことができるような一連の基準とガイドラインを提供し、それによってチームメンバー間のより良い連絡と連携が促進されます。

ロードマップと成熟度モデルの整合性

ロードマップを成熟度モデルと整合させることは、デザインプラクティスの現状評価や改善領域の特定などのデザイン計画のプロセスにおいて有益です。デザインチームは、ロードマップを成熟度モデルと整合させることで具体的なマイルストーンと目標の達成に焦点を当てた取り組みを行うことができますからね。

こちらもチェック： UXPin Merge 顧客事例『Iress』：デザインツールの再想像

DesignOps のプラクティスを適切なサイズにする

DesignOpsのロードマップを組織の成熟度モデルと整合させるなど、デザインチームの特定のニーズと成熟度に合わせて運用を調整するには、DesignOps のプラクティスを適切なサイズに調整することが非常に重要です。

成熟度モデルの使用

効果的なアプローチの１つは、デザインリーダーシップチームが集まって定性的な課題やニーズ、目標について議論することによって、成熟度モデルを中心にDesignOpsロードマップを調整することです。成熟度モデルで、重点領域の概要や、テーマの特定および優先順位付けができるようになります。この調整によって、確実にDesignOpsが組織の成熟度に沿った具体的なマイルストーンと目標の達成に重点的に取り組めるようになります。

記事を読む：DesignOps の成熟度確認のためのチェックリスト

企画におけるインクルーシブデザインの提唱

もうひとつの重要な側面は、組織の企画（プランニング）のプロセスにおけるインクルーシブデザインの提唱です。デザインが主要な企画要素として認識されていないことがあるため、この認識を変えるにはデザインチームによる提唱が必要です。デザインを提唱してその価値を示すことで、DesignOps が組織の企画と意思決定プロセスにおいて、確実にデザインが重要な考慮事項となるようにすることができるのです。

内部統制とチームの成長

組織の目標に合わせるだけでなく、デザインチームのニーズに社内で焦点を合わせることが重要となります。この連携には、チームがどのように成長できるかの評価やデザイナーに開発の見通しを示す方法が含まれます。また、デザイナーが同じタイプのプロジェクトで行き詰まることもあり、彼らの成長と発展に貢献する多様な機会を提供することは非常に重要です。

デザインチームワークに関する電子書籍を読む： DesignOps First Pillar: How We Work Together.（DesignOps の第一の柱：協働の方法）

重要な部門横断的パートナーシップの特定と確立

DesignOps がうまくいくには、重要な部門横断的パートナーシップの確立が不可欠です。このようなパートナーシップによって、デザイン業務は確実に組織内の他のチームや部門の目標やインセンティブと一致できるようになります。

目標と動機の理解

部門横断的パートナーシップを確立するための重要な側面のひとつは、パートナーの『目標』と『動機』を理解することであり、さまざまなチームや部門には、それぞれの行動の原動力となる明確な目標と動機があることを認識することが非常に重要です。

この「目標」と「動機」を理解することで、DesignOps は他のチームの取り組みと連携し、共通の組織目標に向かって取り組むことができます。そしてこの連携は、DesignOps が確実により広範な組織目標と統合して、単独で運営されることがないようにするのに欠かせません。

緊急性と重要性のバランス

部門横断的なパートナーシップを確立する上でもうひとつ重要なことは、緊急性と重要性のバランスをとることです。文化を構築し、デザイナーをつなげることに力を注ぐのは重要ですが、緊急性が優先されることが多いことを認識しておくことも極めて重要です。DesignOps は、効率性を確保しながら、デザイン組織の価値を上げることに重点を置かないといけないのです。

DesignOps の規模および範囲

機能横断的なパートナーシップを確立する際には、さまざまなチームの固有のニーズを評価し、そのニーズを満たすための DesignOps の適切な規模と範囲を決定するなど、DesignOps の規模と範囲の考慮も不可欠です。

出だしに余裕を持ってチームや組織のニュアンスを理解することで、どのような種類のサポートやリソースが必要かを特定することができます。この体系的なアプローチによって、DesignOps は組織固有のニーズに合わせて確実に調整されるのです。

測定とインパクト：DesignOps のROIを説明する方法

インパクトを測り、DesignOps の ROI （投資収益率）を示すことは、組織内でその役割を説明し、デザインと部門横断チームに価値をもたらす重要な側面に焦点を当てるのに非常に重要です。

インパクトへの焦点

DesignOps を測る上で欠かせない側面の１つは、インパクトへの焦点です。DesignOps の実践者は、すべてをやり遂げたいという衝動を抑え、代わりに最も重要なことに集中しないといけません。DesignOps チームの規模とインパクトは必ずしも一致しないことを認識しておくことが重要であるため、低コストでも見返りの大きい取り組みに集中することが非常に重要です。

土台作り

DesignOps にレイヤーを追加する前に、デザインと部門横断チームの価値を促進する本質的な側面に焦点を当てることによる、強固な基盤構築が必要です。この土台を築いて組織からの賛同が得られたら、DesignOps が提供する中核的な価値を損なわないように注意しながら、追加のレイヤーを追加し始めることができるのです。

内部拡張と乗数

緊縮財政の時代には、創意工夫を凝らして取り組みの規模を拡大することが極めて重要です。これは必ずしも人員を増やす必要はありませんが、DesignOps に関心のあるマネージャーやリーダーとの提携が必要になる場合があります。また、同様にこれらに関心のあるデザインリードの機会を引き出すことにもつながるかもしれません。このような内部乗数は、必ずコストを増やすというわけではなく、取り組みを強化させることができるのです。

デザイナーの DesignOps 参加

DesignOps を拡張するもう１つのアプローチとして、デザイナーの DesignOps への参加があります。多くのデザイナーは、気づかないうちにすでにDesignOps 活動を行っているかもしれません。このようなデザイナーにDesignOps での役割を割り当てることで、組織はデザインへの理解を通して、 DesignOps の価値を上げることができます。

スコープの影響：コストセンターと収益源 – 管理範囲内のメトリクス

DesignOps の影響をスコープする際には、コストセンター（原価中心点）と収益源を通してビジネスニーズに焦点を当てることが不可欠であり、このスコープには、機能横断的な強固なパートナーシップの確立や、DesignOps の管理範囲内のメトリクスへの注力が含まれます。

ビジネスニーズへの焦点

ビジネスに価値をもたらす重要な側面を特定し、その側面に取り組みを集中させることは、影響範囲に不可欠です。DesignOps にできることがたくさんある一方で、ビジネスに最も大きな影響を与えるものに集中することが、最も大きな価値と ROI を生み出すということを認識しておくことが重要です。

部門を超えたパートナーシップの確立

強力な部門横断的パートナーシップを確立するということは、エンジニアリング、製品、技術プログラムマネージャなど、組織内の他の部門や機能との関係を築くということです。このようなパートナーシップにより、DesignOps は組織の広範なゴールと連携で、達成につながることができるのです。

投資としての人間関係

機能横断的なパートナーと個人的な関係を構築することで、DesignOps は他部門や機能の目標やニーズをよりよく理解できるようになり、DesignOps の管理範囲内のメトリクスに焦点を当てながら、調整して取り組むことができます。

時代の変化への対応

DesignOps は、たとえ緊縮財政の時代であっても、回復力性（ レジリエント ）があり、成長と発展の機会を模索することで、変化に機敏に適応できないといけません。柔軟で、回復力があることでDesignOps は世の中が変化しても、ビジネスに価値をもたらし続けることができるのです。

DesignOps × ChatGPT含む生成系AI

DesignOps のコンテクストでは、AI（人工知能）や ChatGPT のような生成系モデルは、デザインプロセスを大幅に効率化し、生産性を上げてくれます。その方法を以下に挙げてみましょう：

ルーティンタスクの自動化

AI はデザインプロセスにおけるルーティンワークや繰り返し作業を自動化し、それによってデザイナーはより複雑でクリエイティブな作業に集中できるようになります。例えば、DesignOps の実務者は、AI を使って、事前に確定されたルールやガイドラインに基づいて、デザインアセット生成、UI（ユーザーインターフェース）コンポーネント、さらにはレイアウト全体を自動化することができます。

迅速なプロトタイプ

生成系 AI モデルは、特定の入力に基づいてデザインコンセプトを生成することで、迅速なプロトタイプを支援することができます。AI を活用することで、デザインのアイデア出しやコンセプト開発の段階のスピードが大幅上がり、デザイナーはより短時間で幅広いアイデアを検討することができるのです。

ユーザー調査とデータ分析

AI は、ユーザー調査やデータ分析の支援もします。例えば、AI はユーザーの行動データを分析してパターンや傾向を特定し、デザインの意思決定に有益で貴重なインサイトを提供することができます。また、DesignOps は 、ユーザーテストを実施してフィードバックを集めることでユーザーの反応を集めて分析するような、時間のかかるプロセスを AI を使って自動化することもできます。

連携の強化

ChatGPT のような AI モデルは、アイデアを生み出し、フィードバックを提供し、様々なタスクを支援する仮想チームメンバーとして機能することで、連携を改善することができます。そしてこの AI アシスタントは、特に遠隔地や分散した作業環境において、デザインチームの効率性と生産性を上げることができます。

UXPin Merge テクノロジーでデザインワークフローのギャップを埋め、デザイナーとデベロッパーの連携を強化してみませんか？組織全体で「信頼できる唯一の情報源（Single source of truth」）を持ち、ドリフト排除、市場投入までの時間短縮、１つのツールで負債の最小化を実現しましょう。詳細は こちらのページをご覧ください。

The post レジリエント な DesignOps – 実践のためのヒント appeared first on Studio by UXPin.

プロトタイプ はデザインプロセスにおいて最も重要なステップの1つですが、いまだに一部のデザイナーやプロジェクトチームを悩ませています。

よくある誤解として、モックアップのことを「プロトタイプ」と呼んでいることです。また、プロトタイプは一連のスケッチでも、最終製品の機能的なレプリカでもありません。

プロトタイプ とは何か？

プロトタイプとは、最終製品のシミュレーションのことで、製品チームが実物の製造にリソースを投入する前にテストするために使用します。

プロトタイプの目的はアイデアをステークホルダーと共有し、最終的にデザインをエンジニアリングチームに渡して開発する前にアイデアをテストして検証することです。  

プロトタイプ はユーザビリティテストで参加者と共にユーザーのペインポイントを特定し、解決するために不可欠です。プロトタイプをエンドユーザーと一緒にテストすることでUXチームはデザインプロセスの中でユーザーエクスペリエンスを視覚化し、最適化することができます。

エンジニアリングにはコストがかかり、最終製品に変更を加えることはチームが予想しているほど簡単ではありません。そのため、デザインプロセス中にエラーを発見し修正することは非常に重要です。

プロトタイプには主に4つの観点における品質があります。

• 表現方法 – プロトタイプそのもの、紙やモバイル、またはHTMLとデスクトップなど。
• 精度 – プロトタイプの忠実度、ディテールのレベル（低忠実度または高忠実度）。
• インタラクティブ性 – テスト段階でユーザーが利用可能な機能（完全機能、部分機能、閲覧のみなど）。
• 進化 – プロトタイプのライフサイクル。あるものはすぐに作られテストされ捨てられ、その後改良されたバージョンと交換される（「ラピッドプロトタイピング」として知られる）。また作成と改良を繰り返し、最終的に最終製品へと進化するものもあります。

ElementorのUXディレクターによると、ウェブサイト構築プラットフォームのデザイナーは、デザインの複雑さにもよるが、平均4〜5回のプロトタイピングセッションを行うという。

ユーザーのニーズを解決するための初歩的なアイデアであっても、デザインのあらゆる可能なイテレーションをプロトタイプ化すべきです。プロトタイピングは、最終バージョンのベータテストのためだけに行うべきではありません！

プロトタイプをテストすることで、エンドユーザーが製品にどのように接するかについて新たな気づきが得られるのであれば、忠実度や方法は気にせず、時間をかけてユーザーのフィードバックを集めて反復する価値があります。

プロトタイプの種類

プロトタイプを紙、デジタル、HTMLの3つのタイプに分けてみていきましょう。

ペーパープロトタイピング

ペーパープロトタイプとは、紙やデジタルのホワイトボードに描かれたプロトタイプのことである。このようなプロトタイプは、デザイン思考のワークショップのように、デザイナーがまだアイデアを練っている初期段階で使用されます。

ペーパープロトタイピングは、デザインチームが協力して多くのコンセプトを素早く検討するデザイン初期段階で最も効果的です。チームメンバーは、シンプルな線、形、テキストを使ってアイデアを手書きでスケッチします。美学ではなく、多くのアイデアとスピードが重視されます。

UXチームは、床やテーブルの上にペーパースクリーンを並べたり、ボードに固定したりして、ユーザーフローをシミュレートする。これらのプロトタイプをテストするための一般的なやり方は、一人が「製品」を操作し、実際のユーザーの行動に従ってスケッチを切り替えることです。

ペーパープロトタイプのメリット

• 速い – プロトタイプのスケッチは数分でできます。そのため、紙はたくさんのアイデアをテストするのに適しています。ブレインストーミングの会議中であってもすぐにプロトタイプを描くことができるので、アイデアが頓挫しても数分以上は無駄になりません。
• 安価 – メーカー製のペンと紙があればプロトタイプを作ることができるので、安価で身近なものです。
• チームビルディング – ペーパープロトタイピングは共同作業であり、多くの場合、チームで楽しく新鮮なアイデアを生み出すことができます。これは素晴らしいチームビルディングのエクササイズであり、これらの自由な発想のセッションはしばしば創造性を刺激します。
• ドキュメンテーション – チームメンバーは、ペーパープロトタイプの物理的なコピー、メモ、TODOを保管し、将来のイタレーションの際に素早く参照することができます。

ペーパープロトタイプのデメリット

• 非現実的 – どんなに熟練した技術をもってしても、ペーパープロトタイプはデジタル製品を手書きで表現したものにすぎません。そのためペーパープロトタイプはすぐに描けますが、エンドユーザーとのテストではほとんど、あるいは全く結果が得られません。
• 誤検証 – ペーパープロトタイプでは、アイデアを正しく検証できないことがあります。紙の上では良いアイデアに見えても、デジタルワイヤーフレームでは効果的に機能しない場合があります。
• 本能的ではない反応 – ペーパープロトタイプはユーザーの想像力に頼っているため、刺激を見てから反応するまでに時間がかかります。UXを成功させるためには、この「本能的な」反応が重要です。

これらのメリットとデメリットを考慮すると、ペーパープロトタイピングはデザインの初期段階でのみ行うことをお勧めします。紙からデジタルに移行した後は、同じデザインやユーザーフローのために手書きのプロトタイプを再度作成する必要はありません。

ペーパープロトタイピングの詳細については、以下の参考資料をご覧ください。

• Paper Prototyping as a Usability Testing Technique （ユーザビリティテスト手法としてのペーパープロトタイピング）by Justin Mifsud
• Better Use of Paper in UX Design by Marcin Treder（紙の良い利用方法）
• iPhone User Interface Design, Paper Prototype Design （iPhoneのユーザーインターフェースデザイン、ペーパープロトタイピングのデザイン）(video)
• Printable Paper Prototyping Templates courtesy of Tripwire Magazine（印刷可能なペーパープロトタイピングのテンプレート）

デジタルプロトタイピング

デジタルプロトタイピングは、デザイン・プロセスのエキサイティングな部分です。プロトタイプは最終製品に近い形で作成されるため、チームはアイデアをテストし検証することができます。

デジタルプロトタイプには2つのタイプがあります。

• 低忠実度（Lo-Fi）：ワイヤーフレームを使用したユーザーフロー
• 高忠実度（Hi-Fi）：モックアップを使用したユーザーフロー

低忠実度のプロトタイプでは、調査チームは基本的なユーザーフローと情報アーキテクチャの概要を把握できます。高忠実度のプロトタイプでは、ユーザーインターフェース、インタラクション、およびユーザビリティテスト参加者が製品を実際に操作する方法をテストし、より詳細に検討します。

 デザイナーは、FigmaやAdobe XDなどのデザインツールを使ってプロトタイプを作成します。またデザイナーではない製品チームのメンバーが、パワーポイントやGoogleスライドを使ってユーザーフローをシミュレーションすることもあります。

UXPinの特徴として、デザイナーは、他のデザインツールでは実現できない、最終製品とまったく同じ外観と機能を持つプロトタイプを作成することができる点です。

デジタルプロトタイプのメリット

• リアルなインタラクション – ハイフィデリティのデジタルプロトタイプでテストすることにより、UXチームはユーザーが最終製品とどのようにインタラクションするかを見ることができ、ユーザビリティに関する問題を効果的に解決することができます。
• 柔軟性 – 早期にテストを行い、頻繁にテストを行うことができます。初期のプロトタイプから始めて、デザインプロセスが進むにつれ徐々に高度なものにしていくことができます。
• スピード – アイデアをテストするにはペーパープロトタイプが一番早いかもしれませんが、ユーザビリティの問題をテストするにはデジタルプロトタイプが一番早いです。製品がエンジニアリングの段階になると、変更にはかなりの時間と費用がかかります。

デジタルプロトタイプのデメリット

• 学習曲線 – プロトタイプを作成する前にソフトウェアを学び、理解する必要があります。しかし、ほとんどのデザインソフトウェアには同じツールが搭載されているため、ソフトウェアの切り替えは比較的簡単です。
• コスト – ローフィデリティからハイフィデリティのプロトタイピングへと移行するにつれ、時間と労力のコストが増加します。

プロトタイプが成功するかどうかは、チームが各ユーザビリティテストでの明確な目的とKPIを示すかどうかにかかっています。適切な計画がなければ、デザイナーは余計な機能やインタラクションを追加してしまう可能性があります。

デジタル・プロトタイプの作成に役立つリソースをいくつかご紹介します。

• A 10-Minute Rapid Prototyping Lesson by Marek Bowers（10分でできるプロトタイプの高速レッスン）

HTMLとJavaScriptのプロトタイピング

まれに、より正確な結果を得るためにHTMLとJavaScriptのプロトタイプを作成することがあります。この方法の欠点は、コーディングにかなりの時間と技術的コストがかかることです。

しかしUXPin Mergeではそのようなことはありません。

デザイナー（および非デザイナー）は、最終製品のような外観と機能を持つ、コードベースのハイフィデリティ・プロトタイプを作成することができます。

例えば、UXPin Mergeでは、チームはGitリポジトリから取り出したReactコンポーネントやStorybookコンポーネントを使用して、完全に機能する高忠実度のプロトタイプを作成することができます。UXPin Mergeではプロトタイプが最終製品のように機能するため、参加者はボタンやドロップダウンの動作を「想像」する必要がありません。

HTMLを組み込んだ低視覚・高機能のプロトタイプ。(画像提供：Mike Hill氏）

HTMLプロトタイピングのメリット

• 最終製品の機能性 – HTMLプロトタイプは、最終製品の正確なモデルを参加者に提供します。
• 最終製品の技術的基盤 – HTMLプロトタイプの構築は、研究者に貴重な研究ツールを提供し、開発者に最終製品を構築するための基盤を提供します。
• プラットフォームにとらわれない – ほぼすべてのOSやデバイスでプロトタイプをテストすることができ、ユーザーは外部のソフトウェアを実行する必要がありません。

HTMLプロトタイピングのデメリット

• デザイナーのスキルレベルに左右される – HTMLプロトタイプは、あなたのコーディング能力に依存します。コード化されていないプロトタイプは、UXデザインとは関係のないユーザビリティの問題を引き起こす可能性があります。
• 創造性の阻害 – 使えるプロトタイプを作るために、コーディングには時間と集中力が必要です。デザイナーは、使い慣れたデザインツールを使うのと同じレベルの革新性や創造性を達成できないかもしれません。

HTMLプロトタイピングに関する参考資料をご紹介します。

• Designing with Code by Andy Fitzgerald（コードでデザイン）
• The Advantage of Rapid Prototyping by ZURB（ラピッドプロトタイピングの利点）
• コードでデザインする【UXPin Merge入門】 – Robert Kirkman

プロトタイピングのプロセス

プロトタイピングに最適なプロセスというものはなく、製品や用途によって異なります。以下に、最も効果的な3つのプロトタイピング・プロセスをご紹介します。

(注：低忠実度から高忠実度に移行する際には、必ずプロトタイプをテストすることをお勧めします。)

紙⇒低忠実度デジタル⇒高忠実度デジタル⇒コード

ほとんどのデザイナーは、紙⇒低忠実度デジタル⇒高忠実度デジタル⇒コードのプロセスでプロトタイピングを行いますが、実はこれは私たちがUXPinをつくった方法でもあります。

チームで協力して多くのアイデアを練り、紙の上でワイヤーフレームをスケッチし、デジタルに落とし込む前にユーザーフローを作成します。ここでUXチームは、クレイジーエイトや「どうしたらいいか」という質問など、一般的なブレーンストーミングの手法を用いて、エンドユーザーの気持ちになって考えます。

低忠実度デジタルプロトタイプ（ワイヤーフレーム）は、デザインプロセスの早い段階で、ナビゲーションや情報アーキテクチャなどの重要な要素をテストします。モックアップに移行する前に、フィードバックをもとにワイヤーフレームを素早く調整することができます。

ナビゲーションや情報アーキテクチャが完成したら、デザイナーは、色やコンテンツ、インタラクション、アニメーションなどを追加して、最終製品に似せたモックアップを作成します。

リサーチャーによるテストが終了したら、UXチームはエンジニアにデザインを引き継ぎ、最終製品を開発します。  

紙⇒低忠実度デジタル⇒コード

低忠実度のプロトタイピングからコードに移行することは、以前からある手法ですが、最近ではほとんど使われていません。高忠実度と比較してみると、低忠実度のプロトタイピングではコストが安い反面、ユーザビリティの問題の多くを捉えることはできません。

Yelpのデザイン変更作業で作成された低忠実度のプロトタイプ。

Yelpのデザイン変更作業で作成された高忠実度のプロトタイプ。

HTMLプロトタイピング => コード

一人で開発をしていると、初期のプロトタイピングの方法を省略してすぐにコードに取りかかることがあります。アイデアを出し合う相手がいない中で、開発者がいきなりコードに取り組むのは理にかなっていると言えます。

基本的にプロトタイプは基礎を作り、最終製品へと進化していきます。このプロトタイピングの方法は、効率的なワークフローを持つ熟練した開発者にのみ有効です。

優れたデザインスキルを持つデザイナーでも、このプロトタイピング方法は避けた方がいいかもしれません。低忠実度プロトタイピングと高忠実度プロトタイピングは、コードを構築・編集するよりも圧倒的に速いからです。  

紙⇒UXPin Merge – 高忠実度プロトタイピング⇒コード

UXPin Mergeを使用すると、ラピッドプロトタイピングによってUXプロセスを加速できます。コードコンポーネントを使用して完全に機能する高忠実度プロトタイプを作成し、最終製品の実物と同じ状態でユーザビリティテスト参加者に提供します。

UXチームは、上記で説明したような通常のペーパープロトタイピングプロセスにしたがって作業を行います。次に、デザイナーはUXPin Mergeを使用して、すぐに使用できるインタラクティブなコンポーネントをキャンバス上にドラッグ＆ドロップするだけで、忠実度の高いプロトタイプを作成します。

その結果、最終状態を「想像する」必要はなくなり、プロトタイプは最終製品と同じように機能します。UXPin Mergeが提供するコードベースのデザインツールでプロトタイプを作成することは、エンジニアがベクターベースのデザインで作業するよりもはるかに早くプロトタイプを構築できるのです。さらに詳しく知りたい方はこちらのページをご覧ください。

The post プロトタイプ とは？機能的なUXへの道 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.

アフィニティ・ダイアグラムは、データ、ユーザーのニーズ、意見、洞察、その他のデータタイプなどの情報をグループ化するためのフレームワークです。

アフィニティ・ダイアグラムは、それぞれのコンセプト、アイデア、思考を小さなメモ用紙に書き出していきます。そして、2つのアイデアの親和性を確認するために、異なるカテゴリーでアイデアをグループ化します。

1960年代に人類学者の川喜田二郎氏によって考案されたダイアグラムは、アイデア創出のための貴重なツールです。デザイン思考の数多くのフェーズで発見された大量の情報を、チームが自然な連想関係に基づいて整理することができます。

アフィニティ・ダイアグラムは、アプリ内のどこに機能やフィールド、オプションを配置すべきかを考える際によく使われます。

UXPinでは、このアフィニティ・ダイアグラムをとても気に入っています。UXPinでは、アウトライン、ドキュメント、ワイヤーフレーム、UI/UXデザイン、Hi-Fiプロトタイプについて、デザインチームとリアルタイムで簡単にコラボレーションすることができます。

アフィニティ・ダイアグラムの例

1. 新しいアイデアのアフィニティ・ダイアグラム 

下の例では、UXチームがコミュニティ・コラボレーションについてブレインストーミングを行っていました。この図から、コミュニティ・コラボレーションが、彼らが議論していたアイデアの1つであることがわかります。コミュニティ・コラボレーションというカテゴリーは、その後、他のサブカテゴリーに細分化されました。「貢献者」「ユーザー」「評価」。

2. 組織親和図法(KJ法) 

下の例では、デザイナーが、お客様のニーズを満たすための最善の方法について、情報を整理しています。この図を一目見ると、ブレインストーミングによる解決策が見えてきます。

提供: Elegant Themes 

3. 色分けされた親和図法  

この例では、デザイナーはアイデアを色分けして整理しています。これは、複数の異なる色の付箋を使ってアイデアを整理するというものです。

統計、アイデア、顧客からのフィードバックに異なる色を選ぶことで、図式化を実行することができます。あるいは、それぞれのクラスターに異なる色のラベルを貼る。サブカテゴリーは、メインカテゴリーとは違う色にしてもいいでしょう。そうすれば、付箋紙を新しいグループに再編成しても、元の編成時の色を維持することができます。

アフィニティ・ダイアグラムの作成が完了したら、次はデザインとプランニングを始めましょう。UXPinは、チームメイトとリアルタイムでデザインしたり、テスターや関係者とプレビューを共有したりできる優れたデザインツールです。

アプリデザインで親和図法を使う理由は？

アプリのデザインには、情報やアイデアの集まりがあります。これらのアイデアに一貫性のあるフレームワークがなければ、チームはコンセンサスを得ることなく時間を浪費してしまうかもしれません。親和図法/アフィニティーマッピングを使用すると、新しい思考パターンを発見し、情報を関係性のあるものに分類してクラスタリングすることで、古いパターンを簡単に壊すことができます。チームは、情報やアイデアのクラスター内のカテゴリーやメタカテゴリーを発見し、そうすることで、どのアイデアがチーム内で共通しているかを見つけることができます。

親和性ダイアグラムを作成する理由はたくさんあります。まず第一に、ウェブやアプリのデザイナーが、ユーザーのニーズが複雑に絡み合ったウェブの中から意味を見出すのに役立ちます。ユーザビリティテスト、インタビュー、チャットなど、顧客からのフィードバックを収集する方法はさまざまあります。しかし、これらすべてのデータをKPIに照らし合わせて測定することは容易ではありません。それを試みるのは難しいことです。アフィニティ・ダイアグラムを使えば、デザイナーは多様なソースからの定性データを実用的なビジュアル・ダイアグラムに効率的に合成することができます。

アフィニティ・ダイアグラムは、”空間飽和とグループ化 “という手法とも呼ばれています。つまり、最初はみんながアイデアを持ってきて、ボードはリサーチとアイデアで “飽和状態 “になります。すべてのデータから意味を見出すためには、空間が飽和しているので、チームは情報をグループ化する必要があります。グループ化のプロセスでは、ビジネスの視点、個々の情報の間に関連性を引き出し、その結果、より深い洞察を得ることができます。これにより、問題点が明確になり、潜在的な解決策を見出すことができます。このようにして、分析から合成へと移行していきます。

アフィニティ・ダイアグラムが活躍する場面とは？

アフィニティ・ダイアグラムは、アプリを作る前に計画するのに役立ちます。アイデアを生み出すのに最適です。アフィニティマップは、設計前の段階で、定性的なユーザーリサーチや顧客からのフィードバックからつながりや意味を見出し、集めたデータを整理するのに役立ちます。

アプリ開発の初期段階では、チームでワークショップを開催し、コラボレーションやアイデアの共有を行います。このワークショップには、マーケティング、UXスペシャリスト、ビジネスアナリスト、法律家など、さまざまな部署のメンバーが参加します。その後、調査と分析の段階に入ります。アプリ開発者は、ユーザーのペルソナを構築し、次期アプリの欠点と利点を明らかにします。この手順は、実地調査、文脈調査、ユーザーインタビューなど様々なデータをマッピングするための一貫したフレームワークがないと、圧倒されてしまいます。

チームは親和図法を使って、大量のデータからカテゴリーやテーマを作ることができます。このマッピングは、データをグループ化し、グループ間のつながりを見つけることで、パターンを見つけ、学んだことを素早く発見するのに役立ちます。

例えば、親和性マップを使えば、次のようなことができます：

• 特定の研究課題に対する答えを見つける
• ブレインストーミングセッションの結果を整理する
• 革新的なソリューションの作成/開発
• プロセスの改善
• 関連するデータやノートのまとめ

アフィニティ・ダイアグラムの背景にある考え方は、全員の声を聞き、対立を避け、似たようなパターンのアイデアが好まれる環境を作ることで、イノベーションのプロセスを簡素化することです。

a) 機能的なアプリとなるように、アプリの運用ワークフローを設計する

アフィニティ・ダイアグラムは優れた手法であり、ステップ・バイ・ステップで進めていくと、調査結果の明確な概要と統合を作成するのに役立ちます。すべてのデータを整理したら、その情報を機能的なアプリに変えることに集中できます。

b) アプリを使いやすくする

UXに関しては、エンドユーザーのニーズを理解することが難しい場合があります。お客様の声を収集するソースが複数あるため、膨大なデータの中から関連性や意味を見出すのは困難です。しかし、アフィニティ・ダイアグラムを使えば、ユーザーから得たデータをマッピングして、ユーザーのニーズ、行動、動機を理解することができます。ユーザーリサーチをマッピングすることで、優れたユーザー体験を提供するために必要なアイデアを処理する方法が得られるのです。

アフィニティ・ダイアグラムのあまり良くない状況とは？

アフィニティ・ダイアグラムでは、チームメンバーがアイデアを付箋やカード、紙に書き留め、壁のチャートやホワイトボード、黒板などに貼り付けます。最終的には、似たようなテーマやパターン、グループに基づいて分類された付箋紙ができあがります。

しかし、この方法は一時的なものであり、メモの一部が落ちてしまったり、誰かに剥がされたりする可能性があるという問題があります（粘着性の高いものを使ったり、オンラインのテンプレートを選んだりしない限り）。また、遠隔地のチームでは使えませんし、その他の多くの状況でも使えません。

物理的にノートを書いてボードに貼るというプロセスは時間がかかります。ほとんどの場合、情報のマッピングを始めるには、研究の最後まで待たなければなりません。

また、親和性図には時と場所があり、複数の関係者の賛同を得られたときに最も効果的であることを覚えておいてください。

アフィニティ・ダイアグラムを作成するための最適なプロセス

1. ブレインストーミングのプロセスでは、ブレインストーミングの目的を明確にします。すなわち、どのような問題を解決しようとしているのか？データ、文書化された事実、アイデア、観察のすべての部分をメモ、カード、または紙片にまとめ、誰もが見える平らな面に貼り付けます。
2. チームの協力関係に基づいて、関連するすべての付箋を関係性に基づいて移動させ、クラスターを作り始めます。時間を節約するために、できるだけチームメンバーを巻き込みましょう。
3. どのカテゴリーにも属さない付箋は、「一旦保留（parking lot）」というカテゴリーを作ります。すでに表現されていると思われる付箋は、捨てないようにしましょう。アイデアの重複は、同じアイデアを持っているメンバーが何人いるかを明らかにするため、問題ありません。
4. コンテンツがクラスター化されたら、クラスターを表すカテゴリーをチームに提案してもらい、提案されたカテゴリーを各列の一番上に書き込んでいきます。このとき、カテゴリーの名前を考えるのに時間をかけすぎないようにします。例えば、「ツール」と「ガジェット」の間に意見の相違がある場合は、両方を記載します。もし、メンバーが大きく異なるカテゴリーを作成した場合は、最も賛同を得られたものを選択します。クラスターに名前をつけることは、テーマを発見するのに重要です。
5. クラスターを重要度の高い順に並べることもできます。例えば、あなたの会社では何を優先していますか？会社の価値観、動機、優先順位を参考にして、ランキングを決めましょう。
6. クラスターの中に線を引いてつながりを持たせることができます。
7. そのつながりから意味を持たせます。例えば、ユーザーのペインポイントなのか、ニーズなのか。取り組まれていないギャップを探す。
8. 似たような情報を特定するのではなく、合成された情報を実践に移すことに集中する。

優れたアフィニティ・ダイアグラムの結果

アフィニティーマッピングは、概念やアイデアの間のつながりを見つけることで、大量のデータセットを統合します。事実、調査、意見などをクラスターに整理することで、複雑な問題の解決策を見つけたり、共通の課題を見つけたりするのに役立ちます。優れたアフィニティーマッピングでは、自然な形で関係性が構築され、実用的な結果に変換することができます。次のようなことに役立ちます：

1. 問題を特定する
2. アイデアの創出
3. 複雑なアイデアをシンプルなソリューションに変換する
4. グループのコンセンサスを得る

アフィニティ・ダイアグラムは共同作業である。良い結果を出すためには、プロセスを適切にまとめるリーダーを任せる必要があります。また、アイデアがあふれないように、時間制限を設けるとよいでしょう。計画を立て、ブレインストームの目標をチームメイトに伝えましょう。そうすれば、生産性とアウトプットを向上させることができます。

アフィニティ・ダイアグラムの目的は、膨大な量のデータをより一貫性のある形式に整理することであることを忘れないでください。最良の結果を得るためには、正確さを優先し、生成されたアイデアの数に制限をかけないようにしましょう。

まとめ

UXPinでは、アフィニティ・ダイアグラムを使って情報共有や合意形成を行っています。UXPinでは、親和性図を使って情報共有や合意形成を行っています。また、親和性図は設計段階やプロジェクト管理の際に記録として残しています。

UXPinに参加すれば、リアルタイムでのコラボレーション、アイデアの共有、実際のデータやインタラクションを使った生き生きとしたプロトタイプの生成が可能になります。

The post アフィニティ・ダイアグラム とは？ appeared first on Studio by UXPin.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The post デザインオペレーションマネージャー は必要ですか？ appeared first on Studio by UXPin.

コンポーネントライブラリ を作ることで、UI開発を効率化し、失敗しないようにすることができます。（なぜUI開発に使う必要がある？）コンポーネントライブラリを作るメリットには以下のようなものがあります：

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

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

Storybook for React

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

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

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

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

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

Vue

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

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

Angular

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

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

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

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

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

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

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

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

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

Storybook のDIYフレームワーク

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

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

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

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

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

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

ヒューリスティック評価とは、一連のユーザビリティ原則に基づいてユーザーインターフェースをレビューすることです。

デザインプロセス全体を通してユーザビリティの問題を明らかにし、公開前に問題箇所を修正できることで、開発時間を大幅に節約することができます。

ヒューリスティック評価は、3～5人のユーザビリティの専門家がインターフェイスを検証し、ガイドラインに基づいて潜在的な問題を浮き彫りにしていきます。

この記事はNextUXのAndrew Coyleによって書かれました。NextUXはWebベースのビジュアルコミュニケーションツールを提供しており、チームがWebプロジェクトのフィードバックや方向性を示すのに役立ちます。

Jakob NielsenとRolf Molichは、90年代のヒューリスティック評価のパイオニアです。 ユーザー ・インターフェース・デザインのためのユーザビリティ・ヒューリスティックは、今日でも指針となっています。そのため、彼らの10のヒューリスティックについて学び、ヒューリスティック評価の方法について理解を深めることをお勧めします。

デザイナーとしての経験を通じて、私はウェブプロジェクトのレビューで使用するヒューリスティックスを明確にし、改善してきました。UIを評価する際には数え切れないほどのバリアブルやベストプラクティスを考慮しますが、ここで紹介する5つの原則は私自身がデザインを評価する方法をよく使用しています。

UXPinを使用して最終製品のように見える高度なプロトタイプをデザインしてみましょう。UXPinを使うことで、漠然としたアイデアを他のチームメンバーと共有可能で高機能なプロトタイプに簡単に変換することができます。14日間の無料トライアルはこちらまで。

ユーザーに自分の居場所を知らせる

 ユーザー はインターフェイスの中で自分がどこにいるのかを常に把握し、行きたい場所に移動する方法を理解する必要があります。アプリやウェブサイトでは、わかりやすいナビゲーションとサインマーカーを設置しましょう。また、デザインをインタラクティブにすることで、最終的に何が問題になるのかを徹底的にチェックします。

例：段階的なフローに進捗や状態を示す表示を追加し、説明的なヘッダーを用意して、どこにいるのか、次に何があるのかを伝える。

ルールの例外：ゲームのように、 ユーザー が現在地や次の段階を発見することで娯楽や価値を得られる場合。

ユーザーインターフェースに一貫性のあると美的なものにする

 ユーザーインターフェースを構成する要素やフローにおいて一貫性は不可欠です。

例： 一部のボタンに文語体を使用し、他のボタンにタイトル語体を使用しているデザインがあったとします。これではスタイル上の理由がない限り、一貫性が高いとは言えないでしょう。

見る人によってもちろん異なりますが、私は異なるデザインスタイルを使う場合、全体的なビジュアルに関しての魅力はあまりないかと思います。バランス、シンメトリー、ヒエラルキーなどの視覚的な原則をどのように使うかによって、普遍的なデザインを作ることができます。

例：不必要なボーダーやドロップシャドウなどの視覚的なノイズが多いインターフェイスだと、見た目の美しさを低下させてしまい、かえってユーザビリティを低下させてしまいます。

「読む」「待つ」「覚える」を減らす

残念なことに、デジタルの世界では人々の注意力は極めて低いものです。ユーザーが何かを読んだり、待ったり、記憶したりすることに頼ってはいけません。不必要なテキストは省き、スキャンしやすいようにデザインしましょう。

ユーザーが短期的な記憶に頼らなくてもいいように、できるだけ自動化しましょう。

例：特定のプロセスやインタラクションのロード時間が長いアプリの場合、待ち時間の負担を軽減するために、残り時間を示す楽しいロードアニメーションを追加することを検討します。

例:アプリの設定プロセスが複雑な場合、 ユーザー が説明書を読んだり要件を記憶したりすることを前提にしてはいけません。代わりに、長いセットアッププロセスを、簡潔で文脈に沿った情報を持つ短いステップに分割します。

エラーを防ぎ、行動を可逆的にする

アプリケーションに安全策を講じ、明確なコミュニケーションをとることで、エラーの可能性を減らすことができます。

例：

1. 不用意な削除を減らすために、重要なデータの削除をより手際よく行う。
2. 削除プロセスに特別なステップを追加し、ユーザーが自分のアクションの結果を確実に把握できるようにします。
3. 重要なアクションを元に戻す機能を追加する。

経験豊富な ユーザー に対応し、新しい ユーザー にも対応

複雑さや選択肢の多さで新しいユーザーを圧倒してはいけません。できるだけ早くユーザーが使いこなせるように、初めての使用感を提供すること。

強力なアプリケーションを使いやすくするために、経験豊富なユーザーの能力を制限してはいけません。頻繁に使用するユーザーが目的を達成し、ニーズを可能な限り早く解決できるように、オプション性とカスタマイズ性を提供する。

例：ユーザーインターフェースに表示されるアクションにキーボードショートカットを追加する。新しいユーザーはキーボードショートカットを知らなくても操作できますが、経験豊富なユーザーはショートカットを使うことでより早く操作できます。

ユーザビリティの原則を使用してプロダクトデザインを改善する

エンドツーエンドのデザインツールをお探しなら、ぜひUXPinを実際に使ってみてください。デザイン、イテレーション、プロトタイプの完成を10倍速くします。気になった方は、14日間の無料トライアルをこちらからお試しください。

The post ヒューリスティック評価 – 指針となる5つのユーザビリティ原則 appeared first on Studio by UXPin.

リモートデザイン・スプリントは、より多くの人々が都市や世界中のさまざまな場所からコラボレーションを行うようになり、ますます人気が高まっている。パンデミックがリモートワークへの動きを加速させたとはいえ、この動きは2020年よりずっと以前からあります。

正しい方法で行えば、リモート デザインスプリント は対面イベントと同等に有意義で生産的なものになります。この段階的なガイドで、リモート デザインスプリント を成功させるためのヒントとアドバイスを提供します。

適切なツールを選びはできていますか？UXPinは、チームワークと連携を強化するために開発されたコードベースデザインツールです。無料トライアルに登録して、次のデザインプロジェクトでUXPinをぜひお試しください。

 デザインスプリント とは？

 デザインスプリント は、5日間で特定のデザイン問題を解決するためにチームが参加する集中的なグループセッションです。スプリントでは、グループワークと個人ワークが組み合わさることで、アイデアを出し、プロトタイプ作成、テストを解決策を見つけるまで繰り返します。これは、スピードと効率性を目的としています。

誰が デザインスプリント をするのか？

ファシリテーターは、 デザインスプリント チームをまとめながら指導します。

主な仕事は以下の通りです：

• 場所の確保
• 日時設定
• チームと連絡
• 文房具や備品を集める
• 飲み物や軽食の手配
• デザインの印刷作業

場合によっては、ファシリテーター自身がスプリントに集中するために、デザイン業務外の仕事をアシスタントに任せることもあります。

リモートデザインスプリントでは、ファシリテーターとアシスタントがスプリントをまとめ、管理することが非常に重要です。

リモート デザインスプリント プロセスでの課題

• バーチャルな環境では、カジュアルな会話がしにくいこともある。
• オンラインの場での率直な意見やアイデアの流れを再現するのは難しい。ファシリテーターは、参加者を会話に参加させる努力をしなければならない。
• タイムゾーンを合わせることは、特にチームが世界の反対側にある場合、大きな課題です。リモートデザインスプリントでは、この課題を克服するために多くの計画を立てる必要があります。
• 指示は、説明や文脈なしに書き記すと曖昧になりがちです。デザインスプリントのファシリテーターは、全員がそのやり方や目的を理解できるよう、細心の注意を払わなければなりません。
• リモートのデザインスプリント環境では、チームは断絶を感じる。人の顔は見えても、言葉以外のコミュニケーションや合図は少ない。
• ビデオの品質、照明、音声、背景の環境が悪いと、コミュニケーションや連携が難しくなります。

これらの課題に直面すると途方に暮れてしまうかもしれませんが、リモートデザインスプリントを簡単に実行するためのツールや戦略があります。それでは、リモートデザインスプリントのステップガイドをみてみましょう。

リモートスプリントの準備

通常のデザインスプリントでは、多くの計画と準備が必要ですが、リモートではより最新の注意と計画が必要になります。以下で、リモートデザインスプリントを成功させるために考慮すべきことをいくつか紹介します：

照明、オーディオ、ビデオ

標準的なPCのオーディオとビデオは、デザインスプリントを行うには不十分です。よりチームメンバーが集中できるように、全員がヘッドセットの使用を推奨します。

また、全員が高性能なウェブカメラがあることも必須です。リモートデザインスプリントは、参加とエンゲージメントを最大化するために、全員がビデオ通話で見える状態で行うのが最も効果的です。

スプリントのファシリテーターとアシスタントは良い音響、映像、照明がある状態でなければなりません。追加の機器を購入する場合は、惜しみなく投資をしましょう。指示を見聞きしやすくすることで、全員にとってより効果的なスプリントを行うことができます。ウェブカメラ、ヘッドセット、ポータブルライトは100ドル程度で購入できます。

余裕があれば、チームメンバー全員に同等なセットアップを購入し、全員が同じクオリティを体験できるようにしましょう。

iPadとモニターの追加

最近では、ほとんどの人が2つ以上のスクリーンを使って仕事をしています。チームメンバーに確認して、誰がデュアルモニターをセットアップしているかを確認し、そうでない人のために追加のモニターを購入することを検討しましょう。

リモートデザインスプリントは、ビデオ会議と、メモやホワイトボード、デザインツールなどの作業面を分けるのが効果的です。そうすることで、チームメンバーは共有ワークスペースで起きていることを常に確認することができます。

スケッチやメモを取るためのiPadは、ライブ環境を再現し、デザインスプリントの体験を向上させるのに大いに役立ちます。全員がiPadを持っているわけではなく、高価ではありますが、リモートデザインスプリントにとっては最適なツールです。

適切なツールの選択

リモートデザインスプリントでは、適切なツールとプラットフォームを選ぶことはとても重要です。メモなども含めてすべてが同期していなければなりません。また、使用するツールはできるだけ少なくしましょう。

例えば、BasecampやNotionのようなツールは、メッセージやコメント、メモ書き、アセットのアップロード、ホワイトボード（プランによっては一部機能が制限されますが）などに使えるので、すべてのコミュニケーションを一カ所にまとめます。

リモートデザインスプリントツールのおすすめはこちらです。

メモ機能やミーティング：

• Basecamp： リモートコラボレーション向け
• Google Keep： メモ共有アプリケーション（無料）
• Notion：Basecampと似ていて、リモートスプリントのための優れた機能を備えています。

オンラインホワイトボード：

オンラインホワイトボードツールは急速に成長しました。スティックメモやポスト・イットに代わる、おすすめをいくつか紹介します：

• Miro
• Mural
• Sketchboard
• Stormboard
• Conceptboard
• Explain Everything
• Google Jamboard

ビデオ会議

• Zoom
• Google Meet
• GoToMeeting

ユーザーテスト

• User Interviews
• UserTesting
• Lookback
• Userlytics
• Helio
• UserZoom
• GoToMeeting

デザインとプロトタイピング：

コラボレーティブなデザインツールは数多くありますが、部門を超えたチームのためのシームレスなコラボレーションのオプションが必要です。UXPinはリアルタイムのプロトタイプコラボレーションに最適です。

チームのメンバーが必要とするすべての機能を備えています。非デザイナーでも、UXPinを使用してビルトインのデザインシステムでレイアウトやプロトタイプを構築できます。コンポーネントをキャンバスにドラッグ＆ドロップするだけで、モックアップやプロトタイプをデザインできます。さらに、プロトタイプをテストして、共有リンクを使うことで外部関係者からもフィードバックを得ることもできます。

UXPinのアカウントがなくてもプロトタイプの閲覧や、フィードバックを残すことができます。無料トライアルに登録して、次のリモートデザインスプリントにUXPinをご活用ください。

日時選択

リモートのデザインスプリントのスケジューリングは、ライブイベントよりも難しいものです。特に、複数のタイムゾーンにまたがるリモートチームの場合はなおさらです。

例えば、ヨーロッパとアメリカのチームでデザインスプリントを開催する場合、アメリカの参加者はできるだけ早い時間に開始し、ヨーロッパの参加者は午後または夕方にセッションを行うことになります。

8時間以上の差がある場合は、より多くのスケジューリングと計画が必要になります。ブリーフィングとグループセッションのために全員を集め、勤務時間中に個々のタスクのために分かれることができるようにすることもできる。

また、チームを2つのグループに分け、1日1回連絡を取り合ってメモを共有し、並行してスプリントを進める戦略を立てるという方法もあります。

アシスタントを雇う

リモートデザインスプリントでは、ファシリテーターとアシスタントを用意することが不可欠です。ファシリテーターはスプリントに集中し、アシスタントは参加と合図をビデオで監視し、チャットでチームメンバーに確認し、質問にフラグを立て、リモートミーティングに必要なすべての管理を行います。

事前ミーティング

リモートスプリントのツールと日程を決めたら、スプリント前のミーティングをスケジュールすることが重要です。このセッションで、フォーマットの概要を説明し、ルールを確認し、全員にツールを紹介します。

また、スプリント前に各自のサウンド、ビデオ、照明のセットアップを確認し、問題点を洗い出すのも良いアイデアです。チームメンバーが利用可能なすべてのツールを使って、1つのアイコンや小さなコンポーネントを作成しなければならない、15～20分の超高速デザインプロジェクトを実施することもできます。

スプリント前の集まりでは、必要なものが揃っていること、ツールの使い方を全員が知っていることを確認し、問題を解決することを目的としています。

リモートスプリントの実行

Always-Onビデオ

デザインスプリント中の効果的なコミュニケーションとコラボレーションにビデオは欠かせません。スプリントアシスタントはビデオも監視し、質問や問題を抱えている場合はメッセージを送ります。

チームへのご褒美

ランチを提供したり、全員に食べ物を注文できるクーポン券を渡したりなど。

休憩

「スプリントマニュアル」の中で、ジェイク・ナップ氏の著書『Sprint』では90分ごとに休憩を取ることを推奨していますが、リモートスプリントでは、これは少し長すぎるかもしれません。そのため、リモートスプリントを45～60分のセッションに分け、5～10回の休憩と60分の昼食・主食休憩をとることを推奨します。

休憩中に音楽を流すことで、チームメンバーが部屋を出て、音楽が止まったら戻ってくることができることに気づいた人もいます。これは、休憩時間をコントロールし、次のセッションのために人を戻す受動的な方法です。

リモートデザインスプリントのステップ

デザインスプリントのプロセスでは、各ステップに1日ずつデザイン思考を使います：

1. マッピング：ホワイトボードツールを使って、ユーザージャーニーをマッピングします。
2. スケッチ： スクリーンを使う時間を最小限にするため、2日目は紙にスケッチすることを許可しましょう。アイデアを写真に撮ったり、スキャンしてホワイトボードに貼ってプレゼンします。
3. 決定： BasecampやNotionのようなツールをデジタルホワイトボードと一緒に使い、行動計画やストーリーボードのアイデアをブレインストーミングする。
4. プロトタイプ作成： UXPinのようなデザインツールを使って、製品デザインのアイデアのプロトタイプを作成します。
5. テスト： UXPinで作成したプロトタイプを、お好みのユーザーテストツールでテストします。

その他のリモート向けのリソース

様々なロケーションで構成されるチームでデザインスプリントを実行するための、より詳細なガイドは以下のリソースをご参照ください：

• Sprint by Jake Knapp
• When Remote Design Fails: 5 Mistakes to Avoid
• How to Run a Remote UX Workshop
• How Can You Master Remote Work with UXPin

UXPinの無料トライアルを開始し、リモートデザインスプリントを成功に導く方法をご覧ください

UXPinは、今日のチーム作業ニーズを満たすコラボレーションデザインおよびプロトタイピングツールとして開発されました。リモートデザインスプリントへの依存度が高まるにつれ、チームが完全に機能するプロトタイプをリアルタイムで作成できるUXPinのようなプラットフォームが必要になってきます。

UXPinの 無料トライアルを開始して、ぜひ実感してみて下さい。

The post リモート デザインスプリント ガイド appeared first on Studio by UXPin.

 UXデザインプロセス とは、製品のUX（ユーザーエクスペリエンス）をつくる上で必要な体系的、反復的、構造化された一連の行動のことです。チームが繰り返しやすいプロトコルに従い、組織の品質基準を満たした製品を提供することができます。

デベロッパーがアプリ構築で使用するのと同じコンポーネントを用いてプロトタイプを作成することで、デザインプロセスをスピードアップすることができます。厳しい納期にも対応可能で高品質な製品をリリースしましょう。こちらからUXPin Mergeについてぜひご覧ください。

UXデザインとは

UXデザイン（ユーザーエクスペリエンス・デザイン）とは、ユーザーがデジタル製品上で抱える課題を解決するためのデザイン手法です。この人間中心のデザインアプローチにより、デザインチームは単なる思い込みではなく、ユーザーのニーズに基づいた正確な意思決定を行うことができるのです。

ここで重要なのは共感で、人間中心のアプローチの核心でもあります。UXデザイナーは、ユーザーがデジタル製品を使って達成したいことや、その過程で遭遇する可能性のあるペインポイントを理解しないといけません。

UXデザインプロセスとは

UXデザインプロセスは、UXデザインチームがプロジェクトを完成させるために使用する、反復的なステップバイステップの方法論であり、デザイン思考プロセスから派生したものです。デザイン思考プロセス同様に、UXデザイナーはユーザーの目線に立ち、ビジネス内容や背景などについて把握しながら問題のスコープ（範囲）を確定することに時間をかけます。

UXデザインプロセス と デザイン思考プロセス

デザイン思考プロセスは、人間の問題に対するユーザー中心のソリューションを開発するための５段階のプロセスです。一方、UXデザインプロセスはUXプロジェクトを実現するためにデザイン思考を取り入れた、多くの段階からなるエンドツーエンドの手法です。

UXデザインプロセスは、デザイン思考の原則をベースにしていますが、その手順や方法は微妙に異なります。

 UXデザインプロセス の重要性

以下に、企業がUXデザインプロセスを標準化する理由を挙げてみましょう：

• プロジェクトが品質と一貫性の基準を満たしていることを保証する
• デザイナーが確実に偏見や思い込みにとらわれずにソリューションをデザインできるようにする
• デザイナーが多くのアイデアをテストして反復することで、最善策を見つけられるようにする
• チームや部門間の連携を促進する
• 決められたプロトコルに従うことで、手戻りのリスクを下げる
• ステークホルダーがプロジェクトの進捗状況を把握できるようにする
• 隠れたリスクと機会を特定する

UXデザインプロセスでの ７ステップ

典型的な UXデザインプロセスには、「製品の目標決定」から「デザインハンドオフ」、そして「すべてが意図したとおりに機能するかの確認」までの、７つのステップがあります。

ステップ１：プロジェクトと範囲の確定

UXデザインプロセスの最初のステップでは、チームメンバーと（通常は以下のような部署からの代表者で構成されるような）複数の部署のステークホルダーとプロジェクトの目標と範囲を決めます：

• ビジネス – プロジェクトのビジネス要件と目標を説明する
• デザイン – 製品に期待されることのデザインや管理の前に、すべきことを伝える
• 製品 – コンテクストを共有し、デザインに必要なタイムラインとリソースの計画を支援する
• 技術 – UX デザインの実現可能性と技術的制約を確定する

この初期のデザイン段階では、新製品または新機能が解決すべき問題を特定することを目的としています。製品チームは、プロジェクトの範囲、計画、成果物、納期の概要の説明もします。

ステップ２：リサーチの実施

次に、デザイナーはあり得るソリューションを見つけるために問題についてのリサーチをしますが、この段階では、UXデザイナーは以下のようなリサーチを行います：

• ユーザーリサーチ：ターゲットとするユーザーを調査し、どのような人物で、何が必要で、どのような状況で活動しているかを理解する。この調査の結果、ユーザーペルソナ、ジャーニーマップなどである。
• 市場調査：市場を分析し、市場のセグメンテーションと製品の差別化を決定する。
• 競合調査： 競合他社が同様の問題をどのように解決しているかを理解し、機会を特定するための競合分析。
• 製品調査： 既存製品のインサイトやアナリティクスを分析して、ユーザーの行動を理解する。

ステップ３：ソリューションの大まかな下書きを作成する

ユーザー、市場、競争環境を明確に理解することで、デザイナーはソリューションがどのようなものになるかの大まかな下書きを作成できます。これは「アイデア出し段階」とよく呼ばれ、デザイナーは、アイデア出しの初期段階で紙とペンを使い、多くのアイデアを手短に反復します。

その低忠実度テクニックには、以下のようなものがあります：

• スケッチ：UI（ユーザーインターフェース）の手描きスケッチ
• ペーパープロトタイプ： プロトタイプの紙版
• ワイヤーフレーム： 基本的な線と形を特徴とするペーパープロトタイプのデジタル版
• 忠実度の低いプロトタイプ： ユーザーフローと情報アーキテクチャをテストするのにワイヤーフレームを使うデジタルプロトタイプ

チームはまた、特定の問題を迅速に解決するためにデザインスプリントを使う場合もあります。

ステップ４：忠実度の高いモックアップとプロトタイプをデザインする

次に、UIデザインチームはワイヤーフレームをモックアップに変換し、最終製品のような外観と機能を備えた忠実度の高いプロトタイプを構築します。その際、会社にデザインシステムがある場合、デザイナーは コンポーネントライブラリを使用してインタラクティブなプロトタイプを作成します。

ステップ５：ユーザビリティテストの実施

忠実度の高いプロトタイプの主な目的は、ユーザビリティテストです。UXデザイナーは、以下のプロトタイプを実際のユーザーでテストします：

• アイデアの検証
• ユーザビリティの問題の特定
• アクセシビリティのテスト

なお、ステップ２から５は反復可能であり、テスト結果を用いて、デザイナーはステージ２や３に戻り、有用性、持続可能性、実現可能性の基準を満たすソリューションが見つかるまで、アイデアを反復します。

ユーザーテストは第５段階ですが、デザインチームはアイデアや仮説を検証すべく、UXデザインプロセスを通して複数のテストを実施することに注意しておくことが重要です。そしてそのテストには、チームメンバーとの内部テストや、ステークホルダーとアイデアやプロトタイプを共有してフィードバックを得ることも含まれます。

ステップ６：デザインハンドオフの実行

UXデザインプロセスも終盤に近づくと、『デザインハンドオフ』をするときがきます。デザインチームは、エンジニアリングのプロセスを始めるために、プロトタイプとドキュメントを開発チームに引き渡します。

デザインハンドオフは UX のプロセスの終盤に近いですが、デザイナーとエンジニアは、デザインから開発への移行を効率化すると同時に、デザインが確実に技術的制約を満たすようにすべく、アイデア出しの段階から連携を始めます。そして彼らの連携は、コミュニケーションをしやすくするような様々なツールによって促進されます。

デザイナーとデベロッパーの連携をダメにする５つの間違いについてもぜひお読みください。

ステップ７：製品の発売

UXデザインのプロセスの最終段階は、発売と新リリースの明確な検査であり、新しいリリースがプロジェクトのビジネス目標、ユーザー体験、アクセシビリティの要件を満たしていることを確認する時です。

優れた UX デザインプロセスのベストプラクティス

UXデザインのプロセスは、どの組織、プロジェクト、チームにとって全て同じというわけではないかもしれませんが、以下のようにプロセスを効率化するためにデザイナーが従うことができるベストプラクティスがあります。

ユーザー中心思考を適用する

デザイナーは、エンドユーザーをデザイン決定の中心に据えて、デザインが確実にユーザーのニーズを満たすようにしないといけません。この人間中心の考え方により、無関係なUIコンポーネントや機能のコストは削減され、ユーザーは本当に欲しいと思える製品を手に入れることができます。

共感を実践する

ユーザー中心の考え方を維持する方法の１つに「ユーザーへの共感」があります。デザイナーが UXデザインプロセスを進めるにつれて「ユーザー中心」から、「見た目は素晴らしいが特定のユーザーニーズを満たしていない機能のデザイン」に流れてしまうことがあります。

そのため、UXデザインプロセスを通じて共感を実践することで、デザイナーはユーザーのペインポイントの解決に集中し続けることができるのです。

デザインシステムを構築する

デザインシステムは、組織全体の一貫性と整合性を高めながら、市場投入までの時間を大幅に短縮することができます。デザインシステムをゼロから構築する余裕がない場合は、MUIや Bootstrapのようなテーマ設定可能なオープンソースのコンポーネントライブラリを使用することを検討しましょう。

ちなみに UXPinには、デザインチームがモックアップやプロトタイプを簡単にと作成できるように、Material Design UI、Bootstrap、iOS、Foundationなどのデザインライブラリが組み込まれています。

デザイナーが開発コンポーネントの完全に機能するプロトタイプを構築できるように UXPinのエディターとコンポーネントライブラリを統合する機能である UXPin Merge を使うと、プロトタイプのクオリティは高くなります。

デベロッパーとの連絡と連携

UXデザインプロセスを成功させるには、コミュニケーションと連携は必須であり、デザイナーは他のデザインチームと連携しながら、エンジニア、ビジネスマネージャー、プロダクトチーム、ステークホルダーとオープンなコミュニケーションを取らないといけません。

そこで、DesignOpsにより、円滑なコミュニケーションや連携が促進されると同時に、時間を要するその他の運用・管理タスクまでもが効率化されます。

UXPinによる UXデザインプロセス の強化

UXプロセスがうまくいくかは、デザインチームが速やかに変更を加えて反復できるツールにかかっています。UXPin はエンドツーエンドのデザインソリューションであり、UXデザインプロセスの各段階にも対応できる機能をお使いいただけます。

完全にインタラクティブなプロトタイプ

デザイナーは、UXPin にあるデザインライブラリのいずれかを使うか、デベロッパーのコンポーネントライブラリをインポートし、すぐにプロトタイピングを開始することができます。UXPin はコードベースのため、プロトタイプは画像ベースのデザインツールよりも忠実度が高く、より多くの機能が備わっています。

質の高いユーザーテスト

コードベースのプロトタイプを使うことで、UXデザイナーは正確でより包括的なテストを実施できます。テストの質が上がることで、最終製品で起きるかもしれないエラーやユーザビリティー上での問題が少なくなります。

洞察に満ちたステークホルダーのフィードバック

UXデザインのプロセスにおいて、ステークホルダーからのフィードバックは非常に重要ですが、プロトタイプが直感的でなければ、ステークホルダーは購買意欲や資金調達に影響を与える可能性のあるデザインコンセプトを理解するのが大変になります。

UXPinを使っているかどうかにかかわらず、プロトタイプには、他の一般的なデザインツールよりもはるかに高い忠実度とインタラクティブ性があります。その結果、デザイナーはステークホルダーから実用的なフィードバックを得ることができるのです。

UX デザインのプロセスのレベルを上げよう

UXPin Mergeにより、デザイナーはテスト中により良い結果を得ることができ、同時にデザインのハンドオフを効率化できるため、市場投入までの時間とコストが削減されます。

ゼロからデザインする代わりに、コンポーネントをドラッグ＆ドロップして、最終製品のように見えて操作性のある、完全に機能するコードベースのプロトタイプを構築してみませんか。 14日間の無料トライアルでぜひコードベースデザインツールの効率性を実感ください。

The post UXデザインプロセス – ７ステップ【実用ガイド】 appeared first on Studio by UXPin.

ステークホルダーインタビューは、初めて参加する人にとっては不安で圧倒されるような体験かもしれませんが、UXデザインにとって非常に重要なものです。

本記事では、ステークホルダーインタビューを計画から実施するための7ステップのテンプレート（質問の作成方法など）を紹介します。

UXPinの高品質でインタラクティブなプロトタイプを使って、ステークホルダーインタビューから有意義なフィードバックを得ませんか。無料トライアルにサインアップして、UXPinの高忠実なデザインおよびプロトタイプ機能をぜひお試しください。

内部および外部の ステークホルダー 

内部ステークホルダーとは、従業員、経営陣、幹部、取締役会、株主など、組織内の人々を指し、このような内部ステークホルダーは、企業の意思決定や運営にダイレクトに関心があります。

外部ステークホルダーとは、顧客、サプライヤー、専門家、債権者、地域社会など、組織に間接的に関心がある人たちのことです。このような人々は意思決定権はありませんが、会社の行動は彼らに影響を与えるかもしれません。例えば、値上げは顧客に影響を与え、製品の製造中止はサプライヤーに影響を与えるかもしれないですよね。

今回は、デザインプロジェクトにおける内部ステークホルダー（および外部の専門家）とそのインタビュー方法に焦点を当てます。

デザインプロジェクトにおける ステークホルダー の役割

ステークホルダーは、デザインプロジェクトの目標、目的、要件、スコープ、予算、タイムラインについて意見を出し、プロジェクトが目標や目的を達成できるように、デザインプロセスを通じてフィードバックやサポート、アドバイスを行います。

なので、インタビュー対象者のそれぞれの役割や関心を理解することで、コミュニケーションが円滑になり、プロジェクトが彼らの期待に応えられるようになります。

 ステークホルダー インタビューの目的

 ステークホルダー インタビューには、目的がいくつかあります。

ビジネスゴールの理解

ステークホルダーは、プロジェクトの目標や目的、そしてそれが自分の部署や組織とどのように関連しているのかの全体像を把握していることから、デザイナーは、プロジェクトの着手前にステークホルダーにインタビューすることで、彼らの戦略的優先順位とそれがプロジェクトとどのように関連しているかを理解することができます。

プロジェクトの制約条件の把握

プロジェクトにはすべて、技術、予算、時間、労働力など、デザイナーがその範囲内で仕事をしないといけない制約がありますが、ステークホルダーによって、デザイナーはそのような制約を理解し、それがプロジェクトのデザインや最終的なリリースにどのような影響を与えるかがわかります。

エンドユーザーニーズの把握

ステークホルダーがデザインプロジェクトを始めるのは、ユーザーニーズやペインポイントを特定したことがきっかけであることが多いことから、そのステークホルダーと話すことで、デザイナーは問題を理解し、既存のユーザーリサーチを確認し、必要と思われる追加の UX リサーチについて話し合うことができます。

ステークホルダーとの意見交換

デザイナーは、デザインプロセスを通じて、ステークホルダーと定期的に意見交換を行いますが、このセッションでデザイナーはコンセプトを説明し、実現可能性や実用性についてステークホルダーに質問しないといけません。例えば、デザインチームがあるアイデアを思いつき、それを製品の現在の技術スタックでサポートできるかどうかを知るために、技術的なステークホルダーに話を聞きに行くことがあるかもしれません。

 ステークホルダー の賛同とサポート

デザイナーは、デザインプロセスのさまざまな段階で賛同を得ないといけないことがよくありますが、ステークホルダーインタビューには、主要なステークホルダーと話すことや、デザインコンセプトやイニシアチブの提唱を支援してくれそうな意思決定者のサポートを得ることが含まれます。

対立する意見の仲介

各部門の異なる戦略目標や優先順位に基づき、ステークホルダーがの意見が対立するというのは珍しくありません。このようなインタビューでは、デザイナーがインタビューを仲介してどちらにもメリットがあるような解決策を見出さなければならないので、厄介なことになることがあります。なので例えば、デザイナーは、両者の考えをある程度妥協して取り入れたコンセプトを提示することがあるかもしれません。

ステークホルダー インタビューの準備と実施方法

１：ステークホルダー分析の実施

ステークホルダー分析とは、プロジェクトに影響を与える人たちを特定するプロセスです。デザイナーはその結果をもとにステークホルダーをリストアップし、セグメント化することで、主な意思決定をする人とそのビジネスニーズに焦点を当てることができます。

さらに読む：ステークホルダー分析 とは？実施方法の紹介

２．ステークホルダーの調査

まずは、ステークホルダーの立場、関心、目標を理解し、それがプロジェクトとどのように関連しているかを理解しましょう。この準備によって、相手のニーズに合わせて質問や会話を調整することができますから。

ステークホルダーも多忙でありながら時間を割いてくれています。特に専門家や管理職、経営者などに質問をする際はより気をつけたいところです。

３．インタビューの目標設定

ステークホルダーからどのようなインサイトを学びたいですか？なぜステークホルダーと話をしたいのかを探ることは、インタビューのゴールを設定する上で非常に重要です。

インタビューの目標として、例えば以下のようなものがあります：

• ステークホルダーのビジネスゴール
• 製品の技術的な限界
• このプロジェクトにおけるステークホルダーの成功の定義
• 主要な競合他社
• このプロジェクトの主要な業績評価指標／指標（KPI）

インタビューの目標を明確にすることで、適切な質問をすることができるでしょう。

４．質問リストの用意

ステークホルダーの「ニーズ」と「要望」に関するインサイトを得られるような質問のリストを用意しましょう。ステークホルダーへのインタビューに最適なアプローチは、そのトピックについて何も知らないかのように質問することです。この質問スタイルだと、ステークホルダーはより詳細な説明をしようと促されます。

ステークホルダーインタビューの質問は、ユーザーインタビューと似ています。偏りのない回答を得るために、自由形式（５W１H）の質問をすることをお勧めします。そしてインタビューの目的に応じて、ステークホルダーに詳しく説明してほしい事項や、もっと詳しく説明してほしいことを特定しましょう。

UX 会社のAdam Fardの創設者であるアダム・ファード氏は会話のようなトーンを保つことを推奨しています。

“Remember, the interview should be steered in a more conversational direction. Although preparing specific questions is important, avoid asking them in a way that makes it seem like you’re just checking off bullet points on a list.”

「インタビューは、できるだけ会話に近いかたちにするようにしてください。具体的な質問を用意することは重要ですが、リストの箇条書きにチェックを入れるだけのような聞き方は避けましょう。」

（日本語訳）

また、インタビューの時間が足りなくなったときのために、質問に優先順位をつけて、重要なものから順に質問していくといいでしょう。

５．アジェンダの設定

おさえたいトピックと、各トピックにかける時間についてのアジェンダを作成しましょう。インタビューを構成することで、会話をスムーズに進め、質問を全部終わらせられるでしょう。

また、ステークホルダーインタビューは通常３０～６０分程度なので、各トピックをカバーするのに必要な時間を現実的に考えておきましょう。

６．インタビューの実施

ステークホルダーが許可した場合、インタビューの録音は、今後の分析に最適です。インタビューを録音することで、詳細なメモを取る必要がなくなり、ステークホルダーの回答に１００％集中することができますからね。インタビューを録音する許可が得られない場合は、チームメンバーにメモを取ってもらい、会話に集中できるようにしましょう。

まずは自己紹介をして、取り組んでいるプロジェクト、インタビューの理由（２番目の過程で設定した『目標』）を説明します。

質問は必ず、ステークホルダーに組織での役割やプロジェクトでの関心について聞くことから始めましょう。また、チームや部署が取り組んでいること（優先順位など）、追跡しているメトリクス、四半期や年間の目標なども聞いておくといいでしょう。その情報をもとに、相手の動機がわかってくるでしょうからね。

NNグループのサラ・ギボンズ氏は、例えば、より詳細な情報が欲しいときに、次のような形式で詳細なフォローアップタイプの質問を使うのを勧めています：

• …についてさらに詳しく教えて頂けますか
• …をもっと詳しくお伺いしてもよろしいでしょうか
• 例えばどのようなことでしょうか
• 前回…したことについてお伺いできますでしょうか
• …についてどのようにお思いでしょうか

または、以下のように具体的な「考え」に関することもいいですね：

• なぜそのように感じたのか、教えてください
• なぜそれをしたのか教えてください
• なぜそのことがあなたには重要なのでしょうか
• なぜそのことが印象に残っていますか

上記の質問は、最初の質問よりも重要です。チームがすでに試したことの理由やインサイトが得られるので、同じことを繰り返して時間を無駄にすることがありませんからね。

質問を一通り終えたら、最後に 「他に誰と話すべきか？」と尋ねてインタビューを終了します。この質問は、ステークホルダーが包括的な答えを出せなかったり、特定の詳細について不明な点がある場合に特に重要です。

７．アフターフォロー

ステークホルダーが時間を割いてくれたことに感謝し、追加情報やリソースの共有について思い出させるために、メールでアフターフォローすることは必要です。

UXPinで ステークホルダー との関係を強化して賛同を増やす

UXPinのインタラクティブなプロトタイプで、ステークホルダーは最終製品と同じようにデザインコンセプトを体験できます。このような高品質なプロトタイプで、ステークホルダーとの関係において、以下のような重要な利点がもたらされます：

• デザインチームの自信の向上
• アイデアの賛同者の増加
• より良いユーザビリティ・テスト
• より多くのビジネスチャンスの特定およびテスト
• ステークホルダーの意見の改善
• 最終製品のUX の強化
• デザインハンドオフの摩擦の最小化
• 市場投入までの時間短縮

UXPin のコメント機能を使えば、ステークホルダーが UXPin のアカウントを持っていなくても、フィードバックを残したり、チームメンバーにコメントを割り当てたりすることができますので、デザイナー以外の方との連携に最適です。

UXPin の高品質なインタラクティブプロトタイプで、ステークホルダーの連携と関係を強化しませんか。UXPin の無料トライアルにぜひお申し込みください。

The post ステークホルダー インタビューで使いたい質問とその方法 appeared first on Studio by UXPin.

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

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

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

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

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

Design-to-Code

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

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

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

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

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

「Design-to-Code」の利点

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

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

「Design-to-Code」の限界

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

デザインと開発間のズレ

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

デザインシステムの課題

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

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

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

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

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

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

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

重複作業

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

Code to Design

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

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

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

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

「Code to Design」の利点

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

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

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

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

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

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

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

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

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

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

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

ガバナンスの向上

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

拡張性と成熟度

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

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

検証の質を向上

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

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

制限事項

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

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

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

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

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

柔軟性が低い

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

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

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

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

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

PayPal

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

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

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

TeamPassword

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

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

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

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

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

では、どちらを選ぶべきでしょうか？このページでは、それぞれの長所と短所をご紹介します。

ユーザーの自然な行動が最も正確なユーザビリティデータを生み出すのであれば、もちろんテストはモデレートされない方がいいでしょう。しかし、そのデータが焦点の定まっていない、誤った方向に向かっているものであれば、テストをモデレートしたくなるのではないでしょうか？その場合、部屋にいる誰かと一緒に結果を偏らせることになりませんか？

「観察者効果」という言葉は、聞いたことがあるのではないでしょうか。観察されている人は、一人でいるときとは違う行動をするという考え方です。これは非常によく知られた現象ですが、モデレーターを使用するかどうかの唯一の影響であってはなりません。

予算、スケジュール、人員、テストの種類、必要なデータなど、これらは「ユーザビリティテストの手引き」で述べたより重要な検討事項です。

ここでは、さらに深く掘り下げてみましょう。

モデレートされた ユーザビリティテスト

確かに、モデレートされたテストでは、よりコントロールしやすくなります。司会者は、ユーザーから寄せられた即時の質問に答え、テストが研究の目標を満たすように導くことができます。

もちろん、モデレートされたテストでは、円滑な運営を維持するために、人間的なスキルと製品の知識を持ったモデレーターが必要です。これは、ユーザーとのスケジュール調整や、テストを受ける場所の制限が難しくなることを意味します。また、会場でテストを実施する場合は、さらに多くのリソースが必要となり、わざわざ足を運んでくれる参加者を募ることも難しくなります。

その点、リモートテストであれば、これらの問題の多くが解決されます。この方法では、ユーザーは好きな場所でテストを受けることができ、スケジュールにもある程度の余裕がある一方で、あなたがコントロールできる部分もあります。

モデレートされたテストは、より多くの労力を必要とするため、デザインの初期段階で行うことを強く推奨します。コンセプトやプロトタイプを作成している段階では、ユーザーにフォローアップの質問をすることができるようにしておきたいものです。

UserTesting社のこのアドバイスに賛同します:

1. 不完全でバグの多いインターフェース – 言い換えれば、初期段階のプロトタイプ。ユーザーを混乱させる危険性のある製品をテストしている場合、質問に答えたり、誘導したりするモデレーターが必要です。一般的ではないと思われるかもしれませんが、ユーザビリティテストをできるだけ早い段階で開始することは、常に良いアイデアです。
2. 複雑なインターフェイス – 製品の学習曲線が高い場合、モデレーターがいれば、有益な結果が得られないかもしれないテストを救うことができます。例えば、タスクを達成するための手順が必ずしも直線的ではない製品の場合、モデレーターによるテストは理にかなっています。
3. セキュリティが懸念される製品 – まれなケースではありますが、公開したくないデータにアクセスする製品をテストする場合、モデレーターはユーザーを適切な場所に留めておくことができます。

モデレートされたテストとモデレートされていないテストは、競合するものではなく、補完するものであることを忘れないでください。例えば、試作品に対してモデレートテストを行い、ユーザビリティに関する大きな問題を解決することができます。製品を完成させた後、モデレートされていないテストを実施して、「野生」でのパフォーマンスを測ることができます。

始める準備ができたら、Jeff Sauro氏の「モデレートされたユーザビリティテストのための20のヒント」に従うようにしましょう。

無節操なユーザビリティテスト

モデレートされていないテストは、コストが安く、より多くのユーザーをすぐに集めることができます。長所と短所を実際に見てみましょう。

提供: UserZoom

メリット

• 時間短縮 – スケジューリングの問題や限られた人員から解放された無修正テストでは、時間を問わず、ユーザーを同時にテストすることができます。つまり、より多くのデータを短時間で得ることができるのです。ユーザビリティガイドで説明したとおりです。
• 偏りの可能性が少ない – 観察者効果だけが要因ではありませんが、観察者効果やその他の社会的・技術的な偏りも関係する要因です。モデレーターがいないことで、これらの多くが緩和され、より自然で信頼性の高い結果を得ることができます。
• 安価 – 外部のユーザーリサーチ会社に依頼する必要がある場合、そのコストは確実にモデレーターなしのテストを上回ります。モデレートされていないテストでは、場所を確保する必要はありませんし、すべての設備はユーザビリティツール（以下を参照）で用意することができます。実際、これらのツールのコストはスケーラブルなので、適切と思われる金額を支払うことができます。
• 採用が容易になる – モデレートされていないテストのリラックスした環境は、意欲的な候補者のより大きなプールを作り出します。無秩序なテストは、いつでもどこでも、基準を満たす人なら誰でも行うことができます。

もちろん、コントロールの度合いが低い無調整テストには、欠点もあります。

デメリット

• フォローアップの質問がない – ユーザーに自由形式の質問をするためのフォームを用意することはできますが、モデレーターとユーザーの間で交わされる会話に勝るものはありません。モデレートされたテストでは、ユーザーがなぜそのような行動をとるのか、その理由を垣間見ることができます。時間とスケジュールが許せば、テスト後のディスカッションのために、メールまたはSkypeでユーザーをフォローアップすることをお勧めします。
• タスクの許容範囲が狭い – タスクが完了したかどうかは、モデレーターではなくユーザーが判断するため、ユーザーは早々に次のタスクに移ってしまうことがあります。そのため、成功または失敗の状態が簡単に定義された明確なタスクを書く必要があります。
• 質の高いフィルタリングに費やす時間が増える – モデレートされたテストには多少の偏りがあるかもしれませんが、モデレートされていないテストでは、ユーザーが純粋に報酬だけを目的とするリスクがあります。人を募集する時間は減りますが、回答の質を高めるためのフィルタリングにはより多くの時間を費やす必要があります。

もしあなたが無節操テストに興味があるなら、以下のツールをお勧めします。

Lookback – 無料のベータ版。Mac、Android、iOSに対応したこのツールは、これまで見てきた中で最も有望なツールの一つです。顔の反応、モバイル画面、ジェスチャーなどを60fpsで同時に記録します。録画した映像は、この実際の録画でもわかるように、洗練されたストーリー仕立てで再生されます。

UserTesting – 1ユーザー、1テストにつき39ドル。素早いフィードバックで知られるUserTestingでは、ウェブサイト（自社または競合他社）、アプリ、プロトタイプ、Facebookゲーム、Google広告など、あらゆるものをテストすることができます。

Userlytics – 1ユーザー、1テストにつき49ドル。パラメータを設定した後、Userlyticsは参加者を募集し、UserTestingと同様のスペクトルでテストを実施します。

Solidify – 月額19ドル（ベーシック）、月額49ドル（プラス）。Solidifyは、デスクトップやモバイルデバイス向けのインターフェースを、開発のどの段階でも、スケッチやワイヤーフレームでもテストすることができます。プラス会員になると、デモグラフィック、ロゴのカスタマイズ、レポートのカスタマイズが可能になります。

UserZoom – 月々1,000ドル。UserZoomは、月額料金で一連のユーティリティを提供するという、少し変わった運営をしています。メンバーは、クリックテスト、カードソート、ツリーテスト、アンケートなど、さまざまなテストを行うことができる。

結論

モデレートされていないテストは、統計的に有意なユーザビリティの結果を短時間で得ることができます。しかし、テストが始まってしまうと、タスクや質問を修正することができないため、エラーの余地がはるかに少なくなります（せっかく費やした費用が無駄になっても構わない場合は別ですが）。

モデレートされたセッションでの対話から得られるインサイトがないため、完全な分析のためにはデータを精査する必要があることも忘れないでください。しかし、洗練された製品であれば、ユーザビリティ調査の規模を拡大するためには、モデレートされていないテストが大きな力を発揮します。

どちらが優れているかという答えは、ほとんどのデザインに関する質問と同じで、場合によります。テストはプロセスの初期に行うのか、それとも後期に行うのか。時間とお金が足りないのか？

それぞれのテストには適した場所と目的がありますが、私たちが提供できる最善のアドバイスは、ユーザビリティテストを反復的な作業として扱うことです。デザインのさまざまな段階で、モデレートされたテストとモデレートされていないテストの利点がありますので、恐れずに混ぜてみてください。

ユーザビリティテストに関する実践的なアドバイスをご希望の方は、無料の「ユーザビリティテスト・ガイド」をダウンロードしてご利用ください。このガイドでは、30種類以上のユーザビリティテストを取り上げ、それぞれのテストについてヒントや例を紹介しています。

The post モデレートありとなしの ユーザビリティテスト – どっちが良いのか？ appeared first on Studio by UXPin.