個人で起業する人
設定画面やアカウント画面をすべてデザインせずに、予約サービスの構想を伝える必要があります。
まず検索、選択、予約確定の各状態をスケッチしましょう。より包括的な画面設計が必要になったら、アプリデザインソフトウェアを評価します。
概要から始める
無料のアプリデザインツールでアプリのアイデアを形にする
1人のユーザー、1つのタスク、そしてそのタスクが始まる画面から考えましょう。App Designでは、ブラウザベースの作業を始める前に、その概要を実用的なアプリデザイン計画にする方法を紹介します。
事前に用意するもの
出発点となる概要には、仕様書ほどの詳細は不要ですが、アプリ名だけでなく方向性も必要です。
対象ユーザー、完了すべき操作、アプリに表示する必要がある情報を書き出しましょう。そのうえで、作業に合った始め方を選びます。
コミュニティの主催者
ひと目で理解できるイベント参加登録の流れを作りたいと考えています。
必須項目と登録完了メッセージをリストアップし、出発点に適した無料のモバイルアプリデザインテンプレートを評価しましょう。
プロダクトチームのメンバー
機能要望にはユーザーがアイテムを保存できるようにすべきとありますが、保存後に何が起こるかは書かれていません。
より詳細なプロダクト設計に使うアプリデザインソフトウェアを選ぶ前に、保存済みと未保存の状態を整理しましょう。
学生
モバイルの習慣トラッカーのアイデアがあり、目的を絞った最初の画面が必要です。
毎日のチェックインと、記録を忘れた日の状態を定義しましょう。無料のモバイルアプリデザインテンプレートはレイアウトの参考に使い、設計上の判断の代わりにはしないでください。
最初から最後までの実例
予約アプリのアイデアを例に、大まかな要望からレビュー可能な画面構成まで、アプリデザインの具体的な進め方を示します。
-
1
ユーザーの目的を明確にする
次のように書きます。「患者は空きのある予約枠を見つけ、予約が確保されたことを確認したい」。必要最小限の情報として、サービス、日付、時刻、選択内容を確定する方法を記録します。最初の検討では管理機能を含めないでください。
-
2
画面の流れをたどる
サービス選択画面、空き状況画面、確認画面の概要を作ります。それぞれについて、主な操作と、その次にユーザーに表示される内容を明記します。空き状況画面では、空き時間のない日付も考慮してください。
-
3
各状態を確認する
選択から確定までの流れを確認します。選んだ時刻が明確に示されているか、予約できない枠には理由が示されているか、確認画面で予約内容を特定できるかを問い直しましょう。見た目の細部を詰める前に、設計の概要を修正します。
無料のアプリデザインツールは設計上の判断を始めるためのものであり、実際の運用環境でインターフェースが機能する証拠にはなりません。
1
画面案は、使いやすさが検証されたことを意味しません
もっともらしいレイアウトでも、実際のユーザーが次の操作を見つけられるか、ラベルを理解できるかは証明できません。
代わりにすべきこと
そのアイデアを知らない人に提案した画面の流れを見せ、どこをタップすると思うか説明してもらいましょう。
2
モックアップは動作を実装しません
ボタン、空き状況のデータ、入力内容の検証、確認メッセージについては、プロダクト設計とエンジニアリング上の判断がまだ必要です。
代わりにすべきこと
重要な各状態に、その状態になるきっかけ、必要なデータ、想定される応答を注記しましょう。
3
アクセス条件は異なる場合があります
ブラウザベースのツールがどれも同じ機能を備え、すべての出力を無条件で許可しているとは考えないでください。
代わりにすべきこと
特定の作業手順を前提にする前に、利用先の現在のアクセス条件とエクスポート条件を確認してください。
選択肢の比較表
この予約の例では、アプリデザイン作業を始める2つの方法を比較します。これらは計画の進め方であり、リンク先の機能について述べるものではありません。
| 白紙から始める方法 | テンプレートを使う方法 | |
|---|---|---|
| 最初に用意するもの | ユーザーのタスクと、必要な情報の簡単なリスト | 関連する画面パターンと、同じタスクの概要 |
| 最初に決めること | 画面の順序を決める | パターンのどの部分がタスクに合うかを判断する |
| 予約の例 | サービス、日付、時間を意図した順序で配置する | 予約画面のサンプルレイアウトがその順序に沿っているか確認する |
| 主な利点 | なじみのないフローを自由に構成できる | 検討して調整できるレイアウトが見える |
| 主なリスク | 基本要素の配置に時間をかけすぎる | ユーザーに不要な入力項目や手順を残してしまう |
| 次に確認すること | 各画面で次に取るべき行動が明確かどうかをテストする | 適用したパターンがまだ要件に合っているか確認する |
うまくいかないこと
洗練されたレイアウトでも、空の結果や無効な項目、タップ後に何が起こるかを隠していると、アプリデザインの計画としては不十分です。要件をブラウザのワークフローに反映し、そのうえで、結果として示された方向性を、上記に挙げた状態や判断と照らし合わせて確認しましょう。
よくある質問
アプリの対象ユーザーと、そのユーザーが達成する必要のあることを説明する文章を用意しましょう。最初の画面に表示すべき情報と、タスクが失敗する可能性のある状況を1つ追加すると、ビジュアルスタイルだけを求めるよりも多くの検討材料が得られます。
このページのワークフローは、画面と判断を計画するためのものであり、動作するアプリケーションを約束するものではありません。データ、インタラクション、テスト、実装は別の作業として残ります。
タスクや一連の流れが特殊で、その構造を定義する必要がある場合は、白紙の画面を使いましょう。パターンがタスクに非常によく合っている場合はテンプレートを使いますが、当てはまらないフィールドや手順は削除してください。
開始地点から結果に至るまでユーザーのタスクを追い、すべての画面で実行するアクションを明記しましょう。計画をフィードバックに回す準備ができたと判断する前に、少なくとも1つの空、エラー、または利用できない状態を確認してください。