ブラウザから始めるデザイン
無料のオンラインアプリデザインを、画面ごとに検討する
Webページは、アプリデザインを始める実用的な場所になります。タスクを説明し、必要な画面を整理し、より大きな制作工程に進む前にビジュアルの方向性を検討できます。製品全体を一度に定義しようとせず、評価できる小さな要件から始めましょう。
アプリの構想を練る3つの方法
ブラウザからの利用は、あくまで出発点です。大切なのは、画面で何を伝えるべきか、利用者がどう操作を進めるか、タスクがうまくいかなかったときに何が起こるべきかを決めることです。
タスクから画面へ、一歩ずつ進める
最初の案は、検討しやすい範囲に絞りましょう。完成度は高くてもつながりのない画面を集めるより、ひとつのユーザータスクを最後まで設計するほうが、インターフェースについて多くのことが分かります。
-
1
ユーザータスクを書く
利用者が誰で、直近の目的は何か、画面上でどんな判断をする必要があるかを明確にします。予約の流れなら、サービスを選ぶのか、時間を選ぶのか、予約を確定するのかを指定します。その違いによって、画面に載せるべき情報が決まります。
-
2
必要な要素を配置する
主な操作は目的が明確に分かる場所に置き、関連する選択肢をまとめ、重要なラベルには意味が伝わるだけのスペースを確保します。理想的な流れ以外でも使えるレイアウトにするため、空の状態やエラー状態も要件に含めましょう。
-
3
次の操作を確認する
初めて訪れた人の目線で画面を見ましょう。最初に何が目に入るか、何を変更できるか、操作が成功したことをどう判断できるかを確認します。答えるために画面外の説明が必要なら、要件を見直しましょう。
ブラウザから始める方法の限界を知る
「オンライン」は作業を始める場所を表す言葉であり、必要になるすべての機能を表すものではありません。この比較を使って、初期のデザイン作業と成熟した製品開発プロセスで求められることを区別しましょう。
| ブラウザーを起点とした検討 | 製品デザインの全工程 | |
|---|---|---|
| 最初に必要なもの | 明確なユーザータスクと、画面の初期方針。 | 製品の対象範囲、ユーザー調査、合意済みの納品計画。 |
| 詳細度 | コンテンツ、情報の優先順位、操作を検討できる程度の構成。 | 定義された状態、再利用可能なパターン、実装の詳細。 |
| ナビゲーション | タスクを進める単純な経路から、抜けている手順が見つかることがあります。 | より広い操作フローでは、開始地点、戻る操作、例外を考慮する必要があります。 |
| アクセシビリティ | ラベルが読みやすく、操作が明確で、エラーが理解しやすいか確認します。 | 操作、支援技術での動作、文書化された要件をテストします。 |
| 検証 | 想定ユーザーにとって、そのコンセプトが理解しやすいか確認します。 | ユーザーがタスクを完了する様子を観察し、得られた知見をもとに修正します。 |
| 引き継ぎ | コンセプトとともに、決定事項と未解決の疑問を記録します。 | 製品を開発する担当者と、仕様や動作を確認します。 |
評価できる画面を作って次へ進む
オンラインで無料のアプリデザインを始めるなら、まずは1つのタスク、その完了に必要な情報、操作が失敗したときの対応を明記した概要を用意するのが有効です。その概要をもとにブラウザー上で作業を進め、出来上がったデザインの方向性を要件に照らして評価しましょう。利用できる機能やアクセス条件は、移動先によって異なります。
オンラインでのアプリデザインに関する質問
ブラウザファーストのワークフローとは、デスクトップへのインストールを最初のステップの中心にせずに、インターフェースの計画を始める方法です。まず、1つのユーザータスクと、それをサポートするために必要な画面を説明します。利用先の現在の機能とアクセス要件を確認してください。
いいえ。検索フレーズだけでは、利用先の条件や、各アクセスレベルで利用できる機能は決まりません。プロジェクトで特定の機能を利用する前に、現在の条件を確認してください。
その画面を使う人、相手が行う必要のあること、判断に必要な情報を書き出します。主なアクションと、タスクが期待どおりに進まない状況を少なくとも1つ加えてください。具体的なブリーフのほうが、完全なアプリを求める依頼よりも評価しやすくなります。
コンセプトはレイアウトや意図を伝えるのに役立ちますが、テスト済みの動作や実装上の判断の代わりにはなりません。開発前に、ナビゲーション、エラー、アクセシビリティ、そして理想的な経路以外で人々が遭遇する状態を考慮してください。