プロダクト責任者
チームは顧客の課題を把握しているが、その機能への入口や完了までの経路について合意できていない。まずはアプリデザインから始める。経路を描き、足りない画面を特定し、個々の操作部品を磨く前にタスク全体を確認する。
共通のフローがあると、チームは何を作るべきかをより明確に判断できます。より難しい問いが体験をどう評価するかであれば、リンク先のガイドで、より広い範囲を比較してください。
対象範囲の比較
アプリデザインとUIデザイン：どこから着手すべき？
アプリデザインとUIデザインの違いは対象範囲です。UIデザインはユーザーが目にする操作要素や視覚的な状態を形づくり、アプリデザインはそれらの画面をタスク、ナビゲーション、製品全体の体験につなげます。
まず結論：決めるべきことに合わせて範囲を選ぶ
既存の画面の見た目や動きを改善するなら、UIデザインを選びましょう。どの画面が必要か、画面同士をどうつなぐか、ユーザーが何を達成できるかを決める必要があるなら、アプリデザインを選びましょう。
項目別に見る：タスクから画面まで
両者を区別するには、1つの機能を目的から目に見えるインターフェースまでたどるとわかりやすくなります。
-
1
タスクを定義する
誰がその機能を使い、何を完了する必要があり、その過程でどんな情報が必要かを書き出します。これはアプリデザインの課題です。洗練されたボタンでも、手順の欠落や行き先の不明確さは補えません。予約機能なら、最終的な画面を描く前に、ユーザーが選択肢を比較したり、詳細を確認したり、予約を変更したりする必要があるかを決めます。
-
2
操作の流れを描く
タスクの完了に必要な画面、画面間の遷移、判断が必要な箇所を特定します。アプリデザインでは、入口、ナビゲーション、ユーザーが操作を間違えたときに戻る方法を考えます。この段階では、ブラウザー上で作るシンプルなレイアウトでも、アイコン、色、余白の値をすべて決めずにフローの抜けを発見できます。
-
3
各状態を整える
その操作の流れに沿って、UIデザインを操作要素やフィードバックに適用します。情報の階層、ラベル、フォームの入力欄、コントラスト、フォーカス、読み込み中、空の状態、エラー状態を整えましょう。主要な操作が見つけやすく、その結果が明確かを確認します。そのうえで、フロー全体を見直します。魅力的な画面も、ユーザーがタスクを完了できてこそ成功です。
対象範囲の概要
両者の境界は明確に分断されているわけではありません。どちらも使いやすさに影響しますが、最初に答えるべき問いと、そこから生まれる判断は異なります。
| App Design | UIデザイン | |
|---|---|---|
| 最初の問い | アプリはユーザーが何をできるようにする必要があり、各部分はどうつながるのか？ | 個々のインターフェースでは、操作と状態をどのように伝えるべきか？ |
| 対象範囲 | 機能、画面、ナビゲーション経路をまたぐ一連の体験。 | その体験に含まれる画面、コンポーネント、または操作の状態。 |
| 主な検討事項 | 機能の優先順位、画面の順序、情報構造、タスクの流れ。 | 視覚的な優先順位、操作部品、タイポグラフィ、余白、フィードバック。 |
| 初期の成果物 | タスクの概要、フローマップ、またはつながりを示す大まかな画面案。 | 画面構成、またはコンポーネントとその状態を検討した案。 |
| よくある問題 | 目標までの経路が不完全、わかりにくい、または不必要に長い。 | 適切な操作は用意されているが、見つけにくい、理解しにくい、または使いにくい。 |
| 有効なレビュー方法 | 開始から完了まで、現実的なタスクをたどって確認する。 | 読みやすさ、操作部品の動作、意味のあるすべての状態を確認する。 |
| 着手する場所 | 機能やナビゲーションがまだ決まっていない場合は、ここから始める。 | フローは決まっているが、画面をさらに磨く必要がある場合は、ここから始める。 |
それぞれが適する場面
役職ではなく、次に決めるべきことに基づいて選ぶ。1つのプロジェクトでも、この2つの対象範囲を何度も行き来することがある。
インターフェースデザイナー
機能の導線は承認されていますが、フォームのラベルが分かりにくく、エラーメッセージもユーザーを行き詰まらせています。UIデザインに焦点を当て、入力項目の階層、エラー時の案内、次に取るべき操作の分かりやすさを改善しましょう。
アプリ全体を設計し直さなくても、既存の導線をたどりやすくできます。画面ごとのインターフェース設計の進め方は、リンク先のチュートリアルをご覧ください。
少人数チームの創業者
初期段階のコンセプトには、協力者と話し合えるだけの構成が必要ですが、細部の見た目を磨くにはまだ早い段階です。まずはアプリデザインの基本となる問い、つまり対象ユーザー、中心となるタスク、つながりのある最小限の画面から考えましょう。
まずブラウザー上でラフ案を作れば、ツールや詳細なコンポーネントシステムを決める前に、コンセプトについて話し合えます。リンク先の比較記事では、別の始め方とそれぞれのトレードオフを紹介しています。
開発チーム
実装が近づき、主要な導線も決まっていますが、引き継ぎ資料にはデータの読み込み中やリクエストの失敗時に何が起こるかが書かれていません。まずはそうした状態のUIデザインに作業を絞り、その後でフロー全体を通して確認しましょう。
開発者は実装すべき動作をより明確に把握でき、チームは不足している手順をコードになる前に発見できます。リンク先のソフトウェア向けガイドでは、プロダクトチームのワークフローにおける設計上の判断を扱っています。
進め方の切り替え：対象を広げるか、絞るか
UIデザインから始めた場合は、その画面の前後で何が起こるかを確認しましょう。実際にありそうなタスクを試し、行き先が欠けていないかを確かめてから、アプリデザインのフローを修正します。全体のフローから始めた場合は、重要な画面を1つ選び、操作要素、フィードバック、例外的な状態を具体的に決めましょう。App Designは、こうした判断を検討するためのブラウザーから始められる手段を提供しています。必要な機能があるかどうかは、目的とするワークフローで確認してください。
比較に関するよくある質問
アプリデザインでは、アプリの構造と目的を考えます。これには、タスクを完了するためにユーザーが画面間をどう移動するかも含まれます。UIデザインは、ユーザーが操作するインターフェースに焦点を当て、そのレイアウト、操作要素、視覚的な階層、フィードバックを扱います。UIの設計はアプリ制作の一部ですが、それだけで体験全体の流れが決まるわけではありません。
UIが何を支える必要があるか分かるように、タスクと画面の遷移を十分に計画します。画面を検討する前に、すべての機能を決める必要はありません。また、画面の検討によって計画の欠点が見つかることもあります。アプリデザインとUIデザインは、固定された引き継ぎではなく、反復的なプロセスとして捉えましょう。
分かりやすいラベルと目に見える操作手段は、画面内の使いにくさを減らせます。しかし、存在しない遷移先を作ったり、別の場所にある不要な手順を取り除いたりはできません。タスク全体をたどってフローの問題を特定し、そのうえでUIデザインを使い、必要な各手順を分かりやすくしましょう。
最も不確かな点から始めましょう。ユーザーが主要なタスクをどう完了するか説明できないなら、アプリデザインのフローから始めます。フローは明確でも、特定の画面でユーザーがつまずくなら、その画面のインターフェースと状態に注力します。
はい。タスクの概要をまとめ、つながりのある画面をラフに配置したうえで、別の段階で1つの画面の操作要素、情報の優先順位、フィードバックを検討します。これにより、どこまで詳細を詰めるか決める前に、フローの問題とインターフェースの問題を区別できます。