インターフェースのチュートリアル
アプリのUIデザインを実践的に学ぶ方法
まずユーザーのタスクを1つ決め、それを相互につながる少数の画面に落とし込みます。このアプリデザインのチュートリアルでは、ブラウザで進められる手順と、下書きを共有する前に確認すべきポイントを紹介します。
事前準備
画面を描き始める前に、対象ユーザー、デバイス、タスクを具体的に決めましょう。ユーザーが達成したいこと、必要な情報、成功したと判断する基準を書き出します。
番号付きの手順
ユーザーの行動から画面構成、視覚的な細部へと進めます。テストでわかりにくい選択肢が見つかったら、いつでもこれらの手順を繰り返せます。
-
1
主な操作の流れを定める
支出を記録する、保存した記事を見つけるなど、達成したい結果を1つ選びます。ユーザーの出発点、行う操作、期待する確認表示を挙げましょう。必要な情報を特定し、副次的な機能は最初の操作の流れから外します。こうすることでアプリデザインの焦点が定まります。結果に近づく助けにならない画面は、この下書きには不要かもしれません。
-
2
画面と選択肢を整理する
操作の流れを実現できる最小限の画面をスケッチします。戻る経路や間違えたときのやり直し方も含め、画面遷移を矢印で示しましょう。カテゴリーの選択や変更の承認など、判断が必要な箇所も書き留めます。UIを整える前に、自分で矢印をたどってみてください。次にどこをタップするか迷わず、目的を達成できますか？
-
3
大まかなレイアウトを作る
見出し、操作部品、コンテンツ、ナビゲーションを大まかなブロックとして配置します。主要な操作は位置を統一し、ラベルを明確にしましょう。関連する入力項目をまとめ、説明が必要な選択肢の近くにヘルプを置きます。選んだデバイスの画面サイズで作成し、情報が多い状態も確認してください。アプリデザインでは、何もない画面が整っていることよりも、実際に近いコンテンツが入っても使えるレイアウトのほうが重要です。
-
4
視覚的なルールを適用する
文字サイズ、余白の間隔、色は、それぞれの役割を明確にして少数に絞ります。同じ操作や状態には同じ表現を使い、画面をまたいでもパターンを認識できるようにしましょう。コントラスト、文字の読みやすさ、タップ対象の間隔、色だけに頼らなくても意味が伝わるかを確認します。視覚的な一貫性はUIを見やすくしますが、不明瞭な操作の流れまでは解決できません。
-
5
タスクを使って確認する
計画を知らない人に、つながった画面の下書きを見せましょう。助言せずに最初に決めたタスクを完了してもらい、立ち止まった場所、間違った方向に進んだ場所、フィードバックを見落とした場所を記録します。問題の原因となったラベルや操作の流れを修正し、もう一度試してもらいましょう。各回の確認結果は、色の好みを決める投票ではなく、次のアプリデザイン上の判断に役立つ根拠として扱います。
よくあるエラーと修正方法
画面は完成しているように見えても、重要な動作が未解決のままになっていることがあります。これらのチェックで、ビジュアルの磨き込みにさらに時間をかける前に、抜け漏れを明らかにできます。
理想的な経路だけを設計する
洗練されたモックアップでは、フィールドが空欄のとき、検索結果がないとき、リクエストに失敗したときに何が起こるかはわかりません。こうした状態がなければ、見た目上のユーザージャーニーは最初の中断で行き詰まる可能性があります。
代わりにすべきこと
主要タスクについて、空の状態、エラー状態、成功状態を追加します。それぞれの状態で提示する次のアクションを書き出し、タスクに戻る経路をたどります。
どこでもレイアウトが機能すると想定する
ブラウザー上の下書きだけでは、すべてのデバイス、向き、キーボード、支援技術でどのように表示・動作するかを確定できません。テキストの折り返し方が変わったり、十分な間隔があるように見えるコントロールが使いにくくなったりすることがあります。
代わりにすべきこと
現実的なテキストを使って、狭いレイアウトと広いレイアウトを確認します。実際にサポートする予定のプラットフォームで、フォーカス順、ラベル、操作性を確認します。
下書きを動作する製品と取り違える
画面は意図した動作を伝えるものですが、データ保存、認証、通知、プラットフォーム固有のインタラクションを実装するものではありません。アプリデザインだけでは、技術要件が実現可能かどうかを確認できません。
代わりにすべきこと
影響を受ける画面の横に前提条件を記し、フローを実装計画として扱う前にエンジニアと確認します。
使いやすさではなく見た目の好みをテストする
UIを気に入ったかどうかを尋ねても、なぜユーザーがタスクを完了できないのかはほとんど明らかになりません。慣れや色の好みが、ラベルの不足や予想外のナビゲーション手順から注意をそらすことがあります。
代わりにすべきこと
意見を尋ねる前に、レビュアーに目標を与え、行動を観察し、混乱した時点を記録します。一度に1つの問題を変更し、再テストします。
高度なヒント
主要な経路が機能するようになったら、より長いテキスト、中断されたタスク、再訪するユーザーを想定して確認します。同じアクションがすべての画面で同じ名前になっているか、重大な選択を取り消せるか、確認メッセージが何が起きたかを説明しているかをチェックします。アプリデザインの作業と並行して、決定事項と未解決の前提条件を簡潔に記録しておきます。App Designから、次の段階を試せるブラウザーワークフローに移動できます。特定の機能を前提にする前に、そこで利用できるツールとアクセス条件を確認してください。
画面の下書きをブラウザーワークフローに移す
- 明確に定義したユーザータスクを1つ、次の下書きに引き継ぎます。
- 画面をさらに追加する前に、別の状態を確認します。
- 想定するデバイスで動作を検証します。
チュートリアルのよくある質問
対象ユーザーと、そのユーザーが行うタスクを一つずつ選び、タスクの完了に必要な画面を整理します。最初は色を作り込むより、ラフなレイアウトから始めましょう。視覚的なデザインを整える前に、画面をたどる流れが自然か確認してください。
先にフローを定義すると、各画面の役割が明確になります。開始点、判断が必要な箇所、結果を簡単に図示すれば、足りない手順を見つけやすくなります。その後、フローの各段階に合わせてコンテンツと操作要素を配置できます。
ブラウザーベースの進め方なら、デスクトップへのインストールを前提とせずに、インターフェースの計画、下書き、レビューを行えます。リンク先の製品で具体的に何ができるかは、その製品のサイトで確認してください。完成したUIは、対応予定のデバイスやプラットフォームで検証する必要があります。
開始から完了の確認まで、中心となるタスクを示すのに十分な画面に加え、不可欠な判断や問題からの復帰に必要な画面を含めましょう。画面数に共通の正解はなく、何が必要かはタスクによって決まります。アプリデザインを充実して見せるためだけに画面を増やすのは避けてください。
下書きを見たことがない人に、どこをタップするか教えずに、具体的なタスクを完了してもらいましょう。手が止まる箇所、間違った操作、見落とされたフィードバックを観察し、それぞれの原因を修正します。優れた見た目の下書きは、単に統一感があるだけでなく、次に何をすべきかが分かるものです。