UXデザインプロセスとドキュメントのガイド

公開: 2016-10-21

ドキュメントは、製品のパフォーマンスの概念化、設計、作成、および測定に役立ちます。ただし、メンテナンスのためだけに行うべきではありません。結局のところ、実際の製品の経験に似た書類の厚いスタックについては何もありません。

LeanUXの提唱者であるJeffGothelfがSmashingMagazineの記事で説明しているように、ユーザーエクスペリエンスに関する将来の参照のために作成された厚い成果物は、作成されるとすぐに廃止されます。今日のリーンでアジャイルな世界では、成果物ではなく、経験に焦点を当てる必要があります。軽量なプロセスを選択する場合でも、より詳細なプロセスを選択する場合でも、重要なのは、ドキュメントが（単なる遅れの指標ではなく）設計を前進させるのに役立つはずであるということです。

以下は、製品の設計と開発のドキュメント、個々の要素、およびそれらが属するそれぞれのフェーズの概要です。製品開発とドキュメントは会社によって異なりますが（たとえば、Spotifyでの最小実行可能製品の構築で説明されているSpotify）、以下の成果物の多くは、ほとんどの組織で何らかの形で共通しています。

最も効果的と思われる方法を選択しましたが、効果的な方法のみを自由に選択してください。

それらすべてがどのように関係するか

製品設計のドキュメントに関しては、理論と実践は2つの非常に異なるものです。私たちは皆、ユーザー中心設計の基本的な信条を知っています。私たちは、さまざまな調査方法、プロトタイピング段階、および豊富な方法論的環境での技術を文書化するプロセスを認識しています。しかし、おそらくよく自問する質問は、「実際にはどのように機能するのか」ということです。

画像ソース：設計プロセス。

簡単に言えば、それはすべて、設計プロセスを補足するのではなく、ドキュメントを補完することです。詳細に入る前に、製品の設計および開発中にドキュメントを俯瞰することが役立つ場合があります。以下に、設計ドキュメントのすべてのステップがどのように結びつくかについての実用的な説明を示します。

製品定義の初期段階では、製品と、必要なすべての利害関係者と一緒にプロジェクトを最高レベルで実行する方法についてブレインストーミングを行います。これにより、プロジェクトのキックオフプラン、無駄のないキャンバス、および構築しようとしているものの非常に初期のコンセプトマップとモックアップが作成される可能性があります。
研究に移り、あなたのチームは仮定を洗練し、空白を埋めます。この段階は、製品の複雑さ、タイミング、リソース、既存の知識のレベル、およびその他の多くの要因によって異なります。ただし、一般的には、競争力のある市場分析を構築し、顧客調査を実施することは良いことです。既存の製品がある場合は、分析、ヒューリスティック、コンテンツ、製品コンテキスト、およびユーザーテストを確認することも非常に役立ちます。
分析では、これまでに収集された製品マーケティングデータは、ペルソナ、エクスペリエンスマップ、および優先機能スプレッドシートやユーザータスクマトリックスなどの要件ドキュメントの基盤を提供します。この時点で、製品の定義、製品の優先順位、および製品計画が定義され、より正式な設計成果物の準備が整いました。 UXデザインプロセスとドキュメントのガイドで説明されているように、スケッチや図もこの期間中常に生成される可能性があります。
この出力から、シナリオ、コンセプトマップ、およびモックアップを作成して、設計フェーズに進めることができます。一般的なドキュメントには、スケッチ、ワイヤーフレーム、プロトタイプ、タスクフロー図、および設計仕様が含まれます。たとえば、調査および分析中に作成された競合分析およびペルソナは、モックアップ、コンセプトマップ、およびシナリオにフィードされます。次に、これらの部分は、ワイヤーフレーム、ストーリーボード、詳細なモックアップなどの中級および上級の成果物に影響を与えます。この概要図に示されているように、一部の企業は、調査、分析、および設計の各フェーズを1つの大きなプロセスとして扱っています。
実装中に、コードと設計アセットが組み立てられ、製品設計仕様に従った製品が作成されます。
ライブ製品の発売後、サポートチケット、バグレポート、その他の分析などのフィードバックデータは、その後の反復やアップグレードを通じて製品の改良を推進し続けます。本番モードのオファリングでは、継続的な成功を確実にするために、データを分析およびレポートの形式で継続的に生成および監視する必要があります。
パフォーマンスダッシュボードと分析を使用して、本番環境でオファリングを測定および反復することにより、継続的なデータ駆動型の製品改善が実現されます。

指導原則

各ステージが互いにどのように接続されているかを確認したので、各ステージに沿って製品を移動するためのいくつかの役立つ原則を見てみましょう。プロセスが最初にのみ定義されるのではなく、時間の経過とともに進化するように、デザインスプリントを使用する方法を説明します。

画像ソース：ソース：ユーザー中心設計。

アジャイルソフトウェアの対応物と同様に、デザインスプリントは特定の製品とデザインの問題の解決に焦点を当てた1〜3週間のスプリントです。 3PillarのUXリードであるAlokJain氏によると、スプリントを設計するための3つの重要な要素は、コラボレーション、引き継ぎの摩擦の軽減、チームの集中です。 一言で言えば、ドキュメントは共同作業であり、常にユーザー自身に焦点を当てる必要があります。各ステージ間をすばやく移動するため、勢いをつけて無駄を最小限に抑えることができます。さらに重要なのは、より小さな問題に取り組んでいるため、より多くの調査とリスクテイクが可能になることです。

完全なサイクルの非常に無駄のないバージョンはここにありますが、製品を理解し、製品を設計し、製品をリリースおよび改善するときに、この考え方を適用する方法について以下で詳しく説明します。

1.製品を理解する

製品を構築する前に、その存在のコンテキストを理解する必要があります。利害関係者、会社、およびユーザーがあなたのアイデアを前進させることに関心を持つ必要があるのはなぜですか？

画像ソース：共有理解を達成します。

Smashing Magazineによると、ビジネス要件、ユーザー要件、および両方を満たすための最適な設計ソリューションに対応するアクティビティを含める必要があります。ここでのキーワードは「アクティビティ」です。ビジネスモデルキャンバスやリーンキャンバスなどのドキュメントは重要ですが、関係者に活力を与える必要があります。そうしないと、誰もがすでに知っていることについて話している高価な人々がたくさんいるだけです。これらの活動は効率的であり、コラボレーションを招きます。

利害関係者へのインタビュー—このテンプレートを使用すると、各チームメンバーに3人の利害関係者にインタビューさせることができます。製品は顧客にどのように感じさせますか？彼らは何をすべきですか？利害関係者が顧客の考え、感じ、行動をどのように考えているかを記録することで、ユーザビリティテストやユーザー分析と比較するためのベンチマークを設定します。
要件ワークショップ—利害関係者を集め、プロジェクト計画について話し合い、概念が製品にどのように反映されるかについて話し合いを開始します。
技術的要件。空白のビジネスモデルキャンバスまたはリーンキャンバスから始めて、チームで完成させることができます。
Crazy 8s —いくつかのマーカーをつかんで、5分で8つの製品や機能のアイデアをスケッチしてもらいます。全員にそれぞれのアイデアを採点してもらい、
あなたは傾向と好みを見始めるでしょう。これは実際には、GoogleVenturesの再設計プロセスのステップ2でした。その他のアイデアについては、ブレーンストーミング活動のこのリストを確認してください。

基礎を整えたら、たくさんのユーザーと話し合ってテストし、調査と分析のための実際のフィールドデータを入手します。 UXPinのCEOであるMarcinTrederは、問題と範囲を特定した後、顧客開発とユーザビリティテストに深く関わっています。 UXPinが単なるペーパープロトタイピングツールであった頃、Marcinは、ブランドンシャウアー、ルークウロブレフスキー、インディヤングなどのUXスーパースターとの50を超えるユーザーインタビューと対面でのユーザビリティテストを（紙とビデオで）文書化しました。次に、製品チームはこれらの洞察を使用して、ペルソナを作成し、数十のユーザーストーリーを作成し、最終的に製品要件の概要を説明しました。

アマゾンでは、最初のステップが完成品の内部プレスリリースを起草するという代替の「後方作業」アプローチが使用されています。このアプローチは、顧客をアイデアに引き付けようとするのではなく、顧客から逆戻りするのに役立ちます。魅力的に聞こえるまでプレスリリースを繰り返すことにより、製品チームは即座に現実をチェックし、後の設計と開発のための簡単なベンチマークドキュメントを入手します。

2.製品の設計

最小実行可能製品のガイドで説明されているように、
製品の目的、あなたの主な目標はプロトタイプを構築することです。チームがナプキンを描くのが好きか、忠実度の高いまたは低いワイヤーフレームを作成するのが好きかどうかにかかわらず、最終的には機能的なものになります。この段階のユニークな点は、ほとんどの成果物のドキュメントがデザインであるということです。

画像ソース： UXPin 。

TwitterのデザインマネージャーであるCennyddBowlesによると、製品チームは2回先のイテレーションを調査し、1回先のイテレーションを設計し、前のイテレーションを確認する必要があります。アジャイルを維持しようとしている場合は、「プロセスよりも相互作用」を優先する方法として、忠実度の低いプロトタイプに直接飛び込むことをお勧めします。もう少し詳細になりたいが、それでもある程度軽量にしたい場合は、コンセプトマップまたはスケッチから始めて、忠実度の低いワイヤーフレームまで繰り返し、最後に忠実度の高いプロトタイプを作成できます。方法に関係なく、関係者やユーザーと一緒にテストするようにしてください。

予算とタイミングが許せば、製品がユーザーのニーズを満たしているか失敗している場所を強調するエクスペリエンスマップと、ユーザーが目標を達成するために実行するアクティビティへの洞察を提供するタスクモデルを作成することもできます。これらは設計の一部ではありませんが、製品がどこに適合し、市場に出回るかを確認する必要があるため、補完的です。興味深いことに、Yelpは、一般的なコード行を含むスタイルガイドを作成することで、設計段階をさらに一歩進め、ドキュメントを文字通り製品に組み込むことができるようにしています。

UXPinでのプロセスは、グリッド紙にシャーピーを使用してグループスケッチセッションを開催し、それを数本のワイヤーフレームにカリングして、忠実度の高いモックアップができるまで詳細を追加することです。 ユーザーテストが含まれる場合は、モックアップを忠実度の高いプロトタイプに組み込みます。 大規模な機能のリリースについては、広範なユーザーテストを実施しているため、プロトタイプを優先して比率は約70/30になります。

3.製品の構築と発売

技術的な作業を開始するときは、全体的なビジョンを理解するのに役立つドキュメントを作成することが重要です。特定の要件は、製品を改良するにつれて変更される可能性がありますが、ドキュメントは、製品が実際に使用される際の優先順位を理解するのに役立つはずです。

画像ソース： MVPキャンペーン。

RedStampのUXマネージャーであるKristoferLayonは、製品要件と技術仕様書をロードマップとして視覚化できると信じています。製品ロードマップはユーザーストーリーを示し、ユーザーストーリーを満足させるために構築する機能に優先順位を付けるのに役立ちます。場合によっては、特定の日付がロードマップに追加され、タイムラインとしても機能することがあります。ロードマップの優雅さは、構築するものに優先順位を付けるのに役立ち、製品要件と技術仕様によって定義される「方法」を補完するものになります。機能を決定するときは、狩野モデルを使用して、次の3つのカテゴリで機能を評価できます。

基本属性—これらは、製品が機能するためだけに絶対に必要です。たとえば、ラップトップの基本的な属性はキーボードまたは画面です。
パフォーマンス属性—これらはKPIとして異なる製品間で比較できます。たとえば、ラップトップはCPU速度とハードドライブの容量で判断されます。これは、多くのデータを保存できる高速なコンピューターを好む傾向があるためです。
楽しい属性—これらは顧客の好みに応じて主観的です。たとえば、Macbook Airは非常に薄く、手触りが滑らかです。適切な顧客はそれが素晴らしいセールスポイントであると感じるでしょうが、他の顧客は感銘を受けません。

このモデルに基づいて1〜5のスケールで機能をスコアリングすることにより、それらを優先順位マトリックスにプロットして、製品ロードマップがどのようになるかを想像し始めるのに役立てることができます。 アップルでは、「ロードのルール」と「アップルの新製品プロセス」が、責任、作成の段階、および開始から発売までの重要なマイルストーンを定義することにより、製品ロードマップとして機能します。実際、道路の規則は非常に真剣に受け止められているため、それを失うとすぐに終了する可能性があります（文書にも記載されています）。

4.製品の改善

製品を構築（そして最終的には発売）するとき、ドキュメントは販売やその他のKPIの定義と追跡にも焦点を当てる必要があります。結局のところ、最適化するメトリックがわからない場合、製品を改善することはできません。

画像出典：数字による製品管理。

LaunchClinicの創設者であるDaveDanielsは、立ち上げの目標（たとえば、30日間で30,000ダウンロード）を書き留め、進捗状況を文書化するための適切なツールがあることを確認することをお勧めします。メトリックツールとバグレポートソフトウェアを使用して、起動の最初の数週間以降にタブを保持するように定期的なレポートを設定できます。顧客側では、ユーザーをセグメント化し、カスタムアンケートを送信して、繰り返したい場所を判断することもできます。

Spotifyでは、反復フェーズは製品開発の最も長い段階です。製品チームは、現在のメトリックと優先順位付けマトリックス（設計段階で作成される可能性が高い）を使用して、特定の製品を「極大値」を超えて改善するメリットと努力を比較検討します。努力に値すると判断した場合は、定義段階に戻り、製品を「グローバル最大」に刷新します。

主観的環境における客観的プロセス

製品設計ドキュメントに関しては、単一の特効薬はありません。私たちの製品を使用するほとんどすべての企業は、私たちが上で説明した戦術の断片を採用しています。製品開発とUXデザインは非常に主観的なスペースですが、プロセスとドキュメントはそうである必要はありません。結局のところ、製品の最終目標は収益であり、それについて主観的なものは何もありません。

画像ソース：設計プロセスノート。

軽量化する場合でも、より詳細なドキュメントを好む場合でも、目標はすべて同じです。チームが対話して反応できるように、頭から紙（または画面）に移します。ドキュメントは、石に刻まれたルールではなく、製品の羅針盤である必要があります。私たちが議論した段階のいくつかは、わずかに異なる順序で、あるいは並行して発生する可能性がありますが、それらはすべて、狂気に方法を提供するために存在します。うまくいくものを使用し、残りを廃棄し、製品の進化に合わせてドキュメントを進化させます。

ドキュメントをデザインプロセスに組み込むその他の方法については、UXデザインとプロセスのドキュメントガイドをダウンロードしてください。アーロン・ウォルター、ローラ・クライン、イアン・マカリスター、その他数十人から専門家のアドバイスが紹介されています。 Vurb、MailChimp、Apple、Googleなどの企業の視覚的な例も示されています。