実践まとめ：アジャイル開発におけるBサイドインタラクション設計プロセス

本から学ぶことは常に表面的なものです。本当に理解するには、自分で実践しなければなりません。この記事は実際の経験からまとめたものです。

[[211653]]

このプロセス全体を通して、インタラクション デザイナーは率先してプロジェクトの進行を促進し、積極的にコミュニケーションを取り、全面的に協力する必要があります。需要フェーズでニーズを十分把握し、設計フェーズではプロダクトマネージャー（需要側）や関係者（ビジュアル、開発など）と継続的にコミュニケーションを取り、開発フェーズでは設計目標や効果を積極的に伝え、変更をタイムリーに通知します。チーム全体で可能な限り情報を同期させることによってのみ、高品質のアジャイル開発を実現できます。

1. 要件の理解

もっと質問し、ニーズを十分に理解し、不合理な点を見つけたらすぐにコミュニケーションをとる

a.さらに質問する：要求の信憑性と価値を確認する

B サイド製品に対する需要は、通常、製品マネージャーまたは顧客やユーザーとの営業面談から発生するため、インタラクションの機会はほとんどなく、需要は主に製品マネージャーからインタラクションに伝えられます。この伝達プロセスでは、表面的または個人的なニーズ、あるいはプロダクトマネージャー自身があまり明確に認識していないニーズがしばしば存在します。したがって、「なぜ」をもっと問うことが重要です。まず、大きなエラーによるやり直しを回避し、次に、需要の背景をより深く理解するのに役立ちます。

この機能はなぜ必要なのでしょうか?この需要はどのようなシナリオに基づいていますか?需要の源と量はどれくらいですか?現在解決したい主な問題は何ですか?今後の方向性はどうなると予想されますか?現在の問題は将来の方向性と矛盾していますか?等々。この一連の問題を解決し、要求の信憑性と価値を検証したら、次のステップに進むことができます。

b.ニーズを完全に理解する - 深いニーズを探る

B サイド製品は複雑なビジネスを伴い、設計時にはビジネス ロジックに対する要件が非常に高くなります。設計前にこの段階のニーズを十分に理解し、設計目標を明確にしておくと、小さな設計に焦点を当てるのではなく、設計段階で問題をより包括的に検討できるようになります。同時に、誤解による不満足な解決も回避できます。

実際の作業プロセスでは、プロダクトマネージャーが提供する要件が不完全であることがよくあります。背景や理由を簡単に説明するだけです。しかし、暗黙のより深い（またはより独創的な）背景の理由や条件によっては、インタラクション デザイナーが常に要求者のことを考え、要求者とコミュニケーションを取ることが求められます。ニーズを十分に理解しておらず、ユーザーの操作手順がここからそこまでであることしかわかっていなくても、その手順の背景や理由が明確でない場合は、ニーズを誤解するだけでなく、ニーズを深く掘り下げることができず、最適なソリューションを設計することはできません。

紀元前不合理な問題が発見された場合は速やかに連絡する

需要伝達の全過程において、製品マネージャーが提起した需要は必ずしも独自の需要ではありません。いくつかは処理または推測されます。不合理な要求があることが判明した場合は、タイムリーに関係者に質問し、コミュニケーションを取る必要があります。 「偽の問題」によって引き起こされた一連の「実際の問題」を発見するために、設計時まで待たないでください。もちろん、この段階でのやり取り中に良い/改善できるニーズが見つかった場合は、製品マネージャーとの話し合いのためにそれらを持ち出すこともできます。

時々、製品マネージャーは「市場はこうなっている」や「この部分は理解する必要がない」などの理由で、潜在的に欠陥のある要件を回避することがよくあります。このとき、あきらめずに原因を理解し続け、初期のミスによって後の段階で作業負荷が増大する無駄を最小限に抑えます。

2. 需要分析

設計目標を明確にし、ビジネスプロセスを整理し、情報を合理的に分類する

a.設計目標を明確にする - 設計全体を支える最も重要な要素

シナリオベースの要件に基づいて、ユーザーの最も重要なニーズを分析し、既存のリソースと組み合わせて、このバージョンの設計目標をまとめます。

例えば、「企業間のアクセス状況を可視化する（リスクを可視化する）」という要件であれば、ユーザー心理を分析した結果、「異常なアクセスをタイムリーに検知し、タイムリーに対処できること」が必須要件となるはずですが、既存のリソースと組み合わせると、セキュリティ上の問題への対処にはまだ不十分な点があるため、最終的には「ユーザーがセキュリティ上の問題をタイムリーに発見し、安心感を得られるよう支援する」ことを設計目標としています。

b.ビジネスプロセスの整理 - プロセス設計

ビジネス プロセスを整理するときは、共感を持って、ユーザーがこのタスクを実行したい理由、このタスクを実行する動機となるタッチポイントは何か、タスクにはどのような手順が含まれる可能性があるかを分析します。プロセスを設計するときは、最初にメインラインを設計し、次にブランチラインを設計してロジックを完結させ、設計する必要があるページにマークを付けます（後でプロトタイプを描くときにページが欠落しないようにスケッチを描きます）。

フローチャートを描くときは、タッチポイント、各タスク ステップ、タスクの終了ポイントにのみオブジェクトを書き込みます。ソリューション（特定の対話形式）をプロセスに組み込まないでください。たとえば、「ユーザーは子オブジェクトを親オブジェクトにドラッグする」という解決策は、「ユーザーは子オブジェクトを親オブジェクトに追加する」に変更する必要があります。 「追加」の動作については、「マウスでクリックしてドラッグする」か、「追加ボタンをクリックしてオブジェクトを選択する」か、「子オブジェクトを選択してから親オブジェクトを選択し、自動的に移動する」かなど、ページを設計するときに制約されないように、プロセスで説明するのではなく、スケッチのデザインで提示する必要があります。

紀元前情報を合理的に分類する - 情報アーキテクチャ設計

B サイド製品には多くの情報が含まれ、構造が複雑になっていることがよくあります。したがって、情報を合理的に分類し、適切な情報アーキテクチャを設計することが非常に重要です。最も重要な点は、合理的で一貫した標準に従うことであり、この標準は、設計目標、ユーザーに最も注目してもらいたい点、製品に最も解決してもらいたい問題に基づいている必要があります。まず、ユーザーが製品を理解しやすく、一目で製品を簡単に理解できます。 2 つ目は、将来的に新しい機能が追加されたときに、元の仕様を踏襲できる点です。

まず、すべてのタスクを完了するために必要な情報をプロセスに従って整理し（優先順位を付けます）、次に、合理的な仕様（できれば情報アーキテクチャでマークする）に従って分類して組み合わせます。

たとえば、設計目標が「ユーザーが xx の問題をタイムリーに発見し、効率的に解決できるようにする」である場合、分類基準は「問題の発見」、「問題の分析」、「問題の処理」、「問題の予防」などのいくつかの次元に分割して情報を分類できます。

3. プロトタイプ設計

まずスケッチを描き、次にプロトタイプを描きます。最終バージョンのデザイン。常に設計目標を中心に設計します。各デザインにはソースが必要です。反復するときは、以前のバージョンとの統合に注意してください。

a.まずスケッチし、次にプロトタイプを作成する

フローチャート内で描画する必要のあるページをマークし、スケッチを描いた後、社内のスタッフや製品マネージャーと全体的なアイデアについて話し合うことができます。アイデアを素早く表現して効率を向上できるだけでなく、計画に逸脱があった場合に埋没コストが高くなり、計画を断念せざるを得なくなることも防げます。スケッチが承認されると、プロトタイプの大まかな枠組みは基本的に完成します。こうすることで、プロトタイプに疑問点があったとしても、範囲を絞り込み、具体的にどの部分を変更する必要があるかを把握しやすくなります。

b.最終版のデザイン

場合によっては、時間的制約により、一部のソリューションは途中までしか実装できず、その半分の効果は、現在の時間とリソースでは最適なソリューションではないことがよくあります。したがって、いくつかのインタラクションにより、現在の状況に合わせたデザインの中間バージョンが作成されます。 (はい、それは以前の私です) しかし、実際には、そのような設計は将来に何の利益ももたらしません。むしろ、その後の開発と変更の作業負荷が増加するだけです。

正しいアプローチは、最終バージョンのみを設計することです。開発に十分な時間がない場合は、現在のバージョンの優先度をマークします。開発が難しく、価値が低い機能の一部は、次のバージョンで実装される予定です。

紀元前常に設計目標を中心に設計する

デザイナーがプロトタイプの設計を行う際、たいてい誤解に陥ります。つまり、設計中にそもそもなぜそれをしたのかを忘れてしまい、細かいことにこだわりすぎて当初の設計目標を忘れてしまうのです。実際には、それほど多くのことをする必要はありません。デザインがデザイン目標を中心に据えられているかどうかを常に振り返ることで、不必要なデザインを多く作成することを防ぐことができます。

d.すべてのデザインにはソースが必要です

これらの手順がなぜ必要なのか、バックグラウンド ロジックを実装できるかどうかを理解する必要があります。仮定に基づいて設計することはできません。これらのステップの起源を理解することで、ユーザー心理学をよりうまく組み合わせて、ユーザーの心に沿った、より効率的なデザインを作成できます。背景ロジックを理解することで、論理的に実装するのが極めて難しい設計を避けることができます。

たとえば、「ユーザーの携帯電話番号の背景確認」は、「ユーザーが確認コードを取得するためにクリック」したときに確認するべきでしょうか、それとも「確認コードを入力して [OK] をクリックした後」に確認するべきでしょうか?ユーザー エクスペリエンスの観点から見ると、「クリックして確認コードを取得」は基本的に、ユーザーが自分の携帯電話番号を正常に入力したことを確認できます。この時点でいくつかの手順が省略され、ユーザー エクスペリエンスがより効率的かつ自然になります。しかし、背景のロジックについて詳しく知ると、まだ多くの問題があることに気付くかもしれません。

e.反復するときは、以前のバージョンとの統合に注意する

製品とは全体です。バージョン反復で新しいモジュールが追加される場合は、このモジュールと他の以前のモジュール間の接続を考慮する必要があります (優れた情報アーキテクチャは、この問題を事前に解決するのにも役立ちます)。以前の製品の通常のインタラクション形式はどのようなものか。同じタイプの機能間の接続はどのようなもので、統合できるかどうか。以前の製品との一貫性を保つ必要がある領域など。

4. 多者間レビュー

最終レビューの前に、段階的にレビューする関係者を探します。計画を提示する際は、上から下まで表現すること、会議のテーマを明確にすること、そして議事録をきちんと残すことに注意を払います。

a.最終レビューの前に、段階的にレビューを実施するための関係者を見つける

需要分析フェーズでは、メインの製品マネージャーを探して、作成したデザインのアイデア、全体的なプロセス、その他の主要な方向性に問題がないか確認する必要があります。設計段階では、社内スタッフや製品マネージャーとのコミュニケーションを維持し、メインのプロトタイプ ページを確認してから、詳細を改良し、メインの製品マネージャーとコミュニケーションを取る必要があります。このプロセスでは、要件と設計コンセプトもビジュアル チームと開発チームに同時に積極的に伝える必要があります。

これにより、関係者との頻繁なコミュニケーションと情報同期を維持できるため、最終レビュー時に孤立して作業することで発生する大量の手戻りを削減できるだけでなく、チームメンバーが事前に理解して準備できるため、チームの効率が向上します。

b.計画を提示するときは、上から下まで表現することに注意する

まず全体像について話し、次に細かい部分について話しましょう。まず最初に、当社の製品目標と設計目標について簡単に説明し、その後、当社が解決した主な問題についてお話しします。それでは、メインクエストから始めて、時間があればサイドクエストまで、プロセスについてお話ししましょう。ページについて話す前に、まずそのページがどのようにして作成されたのかについて話す必要があります。ページについて話すときは、内容の詳細に立ち入らず、具体的な詳細ページと比較しながら話すと、参加者が理解しやすくなります。各ページを詳しく説明するときは、何を、なぜ、どのようにという点を個別に説明します。

説明する際に、プライマリとセカンダリを区別します。重要なポイントや大きな変更点について最初に議論する必要があります。一部のコンテンツは詳しく説明する必要がなく、質問や疑問が生じたときに詳しく説明されます。

紀元前会議のテーマを明確にする

会議のテーマを明確にすることは、会議の効率を向上させるための主な指標です。会議の前にトピックを明確にし、議論を具体的なものにするようにしてください（予備的なアイデアがいくつか出揃った後にのみ会議を開催してください）。つまり、アイデアを示すには実際の図表を用意するのが最善です。そうしないと、全員の議論が空虚な考えに基づくものになり、たとえ合意に達したとしても、全員が同じ考えを持つとは限らないでしょう。そのような会議は時間の無駄であり、意味がありません。

意見の相違や疑問が生じた場合、それが会議の議題の範囲内であれば、可能であればその場で解決する必要があります。その場で解決できない場合は、まず記録し、会議後に議論を続ける必要があります。会議のトピックから外れている場合は、きちんとメモを取り、会議後に質問をした人と話し合ってください。さらに、会議でインタラクティブなドラフトを確認する場合、参加者は詳細や視覚的な側面について質問する可能性があります。このとき、これは視覚的なドラフトではなく、インタラクティブなドラフトであることを明確にすることが重要です。主な焦点はコンテンツとロジックにあります。細かいことにこだわらないでください。具体的なスタイルやその他の内容はビジュアルの段階で上げることができます。

d.議事録をきちんと取る

現実には、インタラクティブなドラフトを一度に配信することは明らかに不可能です。需要側の要求は常に変化し、担当者がそれぞれの視点から問題をどのように見ているかにも違いがあるため、会議では意見の相違が避けられず、草案の修正が必要になります。したがって、インタラクション デザイナーがドラフトを修正した後、決定された変更を関係者と再確認できるように、会議では詳細な議事録を作成する必要があります。提起された不明確な要件については、会議後に関係者とタイムリーにコミュニケーションを取り、できるだけ早く確認する必要があります。

また、会議中にプロダクトマネージャーが突然新しい要件や変更された要件を提示してきた場合、その価値を確認する前にその場で同意してはいけません。まずは内容を詳しく記録し、会議中にそれが妥当かどうか、どれだけの価値があるかを慎重に評価することができます。提案者に再度確認した後、変更するかどうかを決定します。そして、決定を下す前に、すべての要件を製品マネージャーが調整する必要があります。プロダクトマネージャーがまだ決定していない場合は、まず対話を行うことができます。まず、インタラクションの観点から実現可能かどうかを判断します。実現可能であれば、まずスケッチを描き、予備的なアイデアを考え出してから、プロダクトマネージャーと話し合います。第二に、率先して発言力を高めましょう。

5. プロジェクトのフォローアップ

プロジェクトが完成し、開発のために納品されたとしても、詳細、実装の難しさ、時間やリソースなど多くの問題が残っているため、納品されたらすべてが順調であるとは言えません。結局のところ、最終的な開発効果がユーザー エクスペリエンスを根本的に決定します。実際のプロジェクトでは、開発者が問題に遭遇しても対話を求めず、独自の方法で問題を解決するという状況がよくあります。これは明らかに最悪のシナリオなので、最終的な体験を確実にするために、インタラクションではプロジェクトを積極的にフォローアップする必要があります。

このプロセス中に、関係者に問題が発生したかどうかを積極的に尋ねます。インタラクティブ ドキュメントに不明な点や考慮されていない点はありますか?設計を実装するのはどれくらい難しいですか?時間が限られている場合、デザインの優先順位は何ですか?

6. 修正の繰り返し

設計に軽微な変更が必要な場合は、まず関係者と話し合う必要があります。すべての関係者が明確にし、合意に達した後、変更を行うことができます。対応する変更議事録と具体的な指示をインタラクティブ ドキュメントに含めるのが最適です。最後に、関連事項をすべてのプロジェクトメンバーに電子メールで送信します。必要に応じて、関係者との会議において改めてご説明させていただきます。変更内容が大きい場合は、次のバージョンに移行されます。