アプリのフローと個別のスクリーンショット：一連の画面をどう調べるか
アプリのスクリーンショットの一連の流れを、タスクの構造、状態の変化、画面遷移の抜けという観点で確認する方法と、個別のUI事例では把握できない操作フローの範囲を学びましょう。
個別のスクリーンショットは、レイアウト、情報の階層、視覚的なパターンを調べるのに役立ちます。しかし、プロダクト上のタスクは時間とともに展開します。利用者はどこかから始めて選択を行い、システムやアプリの状態に遭遇し、目的を達成するか、途中で行き詰まります。その体験を調べるには、スクリーンショットを順序付きの流れとして確認し、画面間の空白が何を意味するかを問いかけましょう。
スクリーンショットを並べても、それは依然として部分的な視覚資料です。すべての経路、タップ対象、アニメーション、エラー条件、利用者の結果を証明するものではありません。ScreenKitsは撮影されたアプリ画面の閲覧とパターンの比較に役立ちます。実際のフローの動作は、自分たちのプロトタイプや調査で検証してください。
主なポイント
- 利用者の目標とシナリオから始め、タスクに必要な順序で関連画面を並べましょう。
- 隣り合う画像を検証済みの操作記録として扱わず、撮影画面間の状態、判断、遷移に注釈を付けましょう。
- 証拠が欠けている箇所を記録し、動作、タイミング、別経路が重要な場合は実際のインターフェースをテストしましょう。
1. 画面の事例とフローを区別する
スクリーンショットは、撮影された一つの状態について答えます。何が目立つか、情報がどうまとめられているか、主要な操作はどのように見えるか。フローのレビューでは、さらに関係性を見ます。どんな目標でここに来るのか、どの操作で先に進むのか、その後何が変わるのか、どう戻ったり別の経路を選んだりできるのかを問いかけます。
三種類の証拠を区別しましょう。個別のスクリーンショットは静止画です。順序付きのスクリーンショットは、撮影された状態の間で起こり得る進行を示唆します。操作の録画やプロトタイプは時間経過に伴う動作を示しますが、それでも一つの経路と一組の条件しか扱っていない場合があります。画面の並びが、そのままタップ可能なフロー、完全な体験、分析記録になるわけではありません。
この区別は、スクリーンショットライブラリの有用性を高めます。ScreenKitsの事例をすべて見て視覚的な資料を集めたら、タスク、分岐、未解決の疑問を自分で図にしましょう。カテゴリで文脈を絞るか、初回利用の流れを確認するときはオンボーディング事例で絞り込んでください。
2. 画像の山ではなくタスクから始める
「商品を後で見るために保存する」「新しいアカウントの設定を終える」など、具体的なシナリオを一つ選びます。本人の言葉で目標を表現しましょう。フォームへの入力やボタンのタップは通常、目標ではなく途中の手順です。Nielsen Norman Groupは、タスク分析を、目標、手順、その順序と構造、途中で必要な情報を調べることと説明しています。これにより、レビューの分析単位をタスクとその経路に定められます。
次に、関連しそうな画面を集めて仮の順序に並べます。閲覧、選択、確認、権限の要求、成功、復旧など、何が起きているように見えるかを各画面に記します。撮影方法が分からない場合、その順序は仮説として示してください。一つの画面がタスクの複数の場面に当てはまるなら、無理に断定せず曖昧さを記録します。
より確かな図にするには、主な流れの横に別経路や条件も加えます。再訪した利用者、拒否された権限、無効な入力欄、空の検索結果、接続の切断などです。こうした分岐は、整った正常系のギャラリーだけでは答えられない設計上の疑問を浮かび上がらせます。
- 利用者、状況、意図した結果を一文で書く。
- 見た目から推測できる手順を順に並べ、その順序の根拠を記す。
- 考えられる分岐、前提条件、復旧手順を別々に記す。
3. 画面の間で何が変わるかを調べる
推論が必要になるのは画面遷移です。隣り合う画面の組ごとに、両者をつなぐと思われるきっかけ、変わったこと、その時点で利用者が理解すべきことを書きます。選択は保持されたか。保存したことがアプリから伝わるか。次の画面は新しい行き先か、一時的なダイアログか、システムの権限要求か。証拠からきっかけが分からなければ「不明」と記しましょう。
行き先だけでなく状態も追いましょう。フォームは未入力、途中まで入力済み、無効、送信済み、中断後に復元済みといった状態を取ります。購入画面にはオファー、読み込み中、エラー、確認の状態があります。ほとんど同じ二枚から意味のある状態変化が見えることも、見た目が大きく異なる二枚が別経路に属することもあります。撮影画面では証明できない因果関係を、一連の画面が示しているように見せないため、ラベルや注釈を使ってください。
ナビゲーションには現在地の把握と復帰手段が必要です。AppleのHuman Interface Guidelinesは、タブバーを最上位セクション間の移動手段として説明し、各セクションのナビゲーション状態を保つことで、利用者が場所を見失わずに切り替えられると述べています。事例でも同様に問いかけましょう。利用者は自分がどの領域にいるか分かるか、前の文脈に戻れるか、案内付きのタスクを離れられるか。静止画から操作方法を推測できても、その動作は実際に操作して初めて確認できます。
- 各遷移について、きっかけ、目に見えるフィードバック、遷移後の状態、確信度を記録する。
- 必要に応じて、戻る、キャンセル、スキップ、再試行、再開の経路を確認する。
- アプリの画面、OSのUI、外部の行き先を区別する。
4. 問いに合った証拠を選ぶ
資料の種類によって答えられる設計上の問いは異なります。まず必要十分な軽い資料から始め、実際の動作が問題になる場合は、プロトタイプ、録画、利用者の観察へ進みましょう。
| 資料 | 役立つ用途 | それだけでは確認できないこと |
|---|---|---|
| 個別のスクリーンショット | 視覚的な階層、文言、コンポーネントのパターン、撮影された状態 | その状態に至った原因、前後に起きたこと、操作が機能するかどうか |
| 順序付きのスクリーンショット | 見かけ上の進行、繰り返されるパターン、画面遷移の抜けの候補の比較 | 順序が完全であること、すべての分岐が含まれること、遷移が操作可能であること |
| 操作できるプロトタイプまたは録画 | 定められた経路、タイミング、フィードバック、操作時の動作の確認 | すべての利用者の行動、すべての経路、録画したシナリオの外での結果 |
| 観察によるタスク調査 | 利用者がどこでためらい、何を期待し、その状況でどう立て直すかを知ること | 少数または代表性のない標本からの普遍的な結論 |
5. 繰り返し使える注釈付きフローレビュー
以下のチェックリストは、短い講評にも詳しい引き継ぎにも使えます。注釈は具体的に書き、観察と推測を分けましょう。自分たちのプロダクトをレビューする場合は、図にしたタスクをプロトタイプや動作するビルドでテストし、観察した動作が異なれば図を修正します。
- 利用者、文脈、観察可能な最終目標を一つ定義する。
- 関連する撮影画面を並べ、各画面に「確認済み」「推測」「不明」のいずれかを付ける。
- 各手順について、利用者の操作、インターフェースの反応、現在の状態、次の判断を記す。
- きっかけの欠落、不明確な進捗、文脈の喪失、フィードバックの欠如、復旧経路の欠落を記す。
- スキップ、戻る、キャンセル、空、エラー、権限の拒否を含む別経路と失敗時の状態を加える。
- ラベルと情報の階層から、次の操作と現在地が分かるか確認する。
- 不確かな点をそれぞれ、プロトタイプのウォークスルーやタスク観察で確かめる質問に変える。
- 後から確認する人に図の意味が伝わるよう、証拠の出典と日付を記録する。
よくある質問
スクリーンショットの一連の流れとアプリのフローは同じものですか？
いいえ。画面の並びは、進行を示唆するように配置された静止画の集合です。アプリのフローには、操作、遷移、状態、起こり得る分岐も含まれます。操作時の動作と対象範囲を別途検証していない限り、スクリーンショットの一連の流れは部分的な視覚的証拠として扱ってください。
欠けている画面や遷移には、どう注釈を付ければよいですか？
分かっていること、推測したこと、不明なことを書き分けます。利用者の操作、予想されるフィードバック、遷移後の状態、欠けている復旧経路や別経路を記します。撮影画面だけでは解決できない疑問には、プロトタイプや観察セッションを使って答えましょう。
スクリーンショットの事例をユーザー調査に使えますか？
デザインの比較や仮説づくりには役立ちますが、参加者の行動や理解は分かりません。それを知るには、プロトタイプや動作するインターフェースで現実的なタスクに取り組んでもらい、結果を観察してください。
