モバイルアプリのUIから着想を得て、設計ブリーフに変える方法

1. 設計上の問いから始める

閲覧を始める前に、誰のどの場面を設計するかを一文で書きます。例えば「初めて自炊する人が、平日の夕食用のレシピを選び、次に何をすべきかを理解する必要がある」です。次に不確かな点を挙げます。難しいのは選択肢の見渡し方か、おすすめへの信頼か、複数手順のレシピを始めることか。

その問いが検索範囲を決めます。どのプラットフォーム、プロダクトの領域、タスクが重要かを判断します。初回利用の体験ならオンボーディング事例を、プラン選択ならペイウォール画面を、データ入力ならフォームのパターンを調べます。ScreenKitsでは実際のアプリ画面をカテゴリ別に閲覧できます。有用なアプリをブラウザのブックマークに保存し、情報をまとめる際にその画面に戻れるようにしましょう。

• 想定する利用者は誰で、何を達成しようとしているか。
• 不確かな設計上の選択は、情報の階層、順序、ナビゲーション、コンテンツ、フィードバックのどれか。
• プラットフォーム、アクセシビリティ、端末サイズ、ビジネスルールなど、どの制約が重要か。

2. 少数の目的ある事例を集める

同じタスク、または近いタスクを扱う事例を数件集めます。直接進む経路、案内付きの経路、エラーや空状態を扱う例など、複数の方法を含めましょう。候補ごとにアプリを保存し、後で見返したい画面や場面を記録します。絞り込んだ少数の事例のほうが、無選別に集めたアイデアボードより比較しやすくなります。

根本の課題が共通するなら、カテゴリをまたいで探します。予定管理アプリと買い物アプリのどちらも、日付を選んで変更を確定する支援が必要かもしれません。有用な共通点は表面上のテーマではなく、判断の構造です。利用者層や業界が似ているだけで、そのインターフェースが自分たちの課題を解く証拠だとは考えないでください。

• 「選択肢を変えると要約がどう変わるかを示している」など、言葉にできる理由で事例を選ぶ。
• 最初に見た磨き上げられた事例が既定の答えにならないよう、異なる解決法を含める。
• ブリーフを書く際も比較できるよう、選んだアプリをブラウザのブックマークに保存する。

3. スクリーンショットだけでなくフローを読む

孤立した画面からは、ある瞬間の配置、色、テキスト、コントロールが分かります。しかし、そこに至る過程、タップ後に起こること、タスクが成功するかは分かりません。関係する画面を順にたどり、入口、判断、操作、フィードバック、次の状態を記録します。入力検証のエラー、閉じる操作、選択の編集に戻る動作など、タスクに影響する別の状態も含めましょう。

観察と解釈を分けます。「主要操作が三つの手順で下部付近に置かれている」は観察ですが、「これなら使いやすいはずだ」はまだ証明していない主張です。スクリーンショットは仮説のヒントになりますが、ユーザビリティの証明にはなりません。NN/gは、プロトタイプ化とユーザーテストを、潜在的な使い勝手の問題を見つけ、提案されたインターフェースとの関わり方を学ぶ方法として説明しています。

4. 観察を独自のブリーフに変える

事例が役立つようになるのは、情報をまとめる段階です。「確定前に選択の結果を見えるようにする」のような、別の場面にも応用できる原則を取り出します。そのうえで、タスク、コンテンツ、制約に基づき、その原則を自分たちのプロダクトでどう実現するかを決めます。魅力的な事例にあるからという理由だけで、ブランド固有のイラスト、文言、特徴的なレイアウトをコピーしないでください。

レシピの例では、事例集から、時間の条件を早めに示し、フィルター選択による変化をプレビューすることが示唆されるかもしれません。独自のブリーフには、短い夕食計画の経路、見える時間制約、明確なフィルターの状態、保存前の確認手順を指定できます。これらの判断はプロダクトの目標に応えるもので、他のアプリの画面を再現するものではありません。

• 対象者と文脈：誰が必要とし、どこで、いつ使うか。
• 利用者の目標と成功：何を完了、または理解できるべきか。
• フロー：主な手順、判断、重要な別の状態は何か。
• 設計原則：インターフェースは何を分かりやすく、簡単にすべきか。
• 制約と未解決の問い：何が満たされる必要があり、何を調査すべきか。
• 評価計画：プロトタイプを使う人にどんなタスクを与え、何を観察するか。

5. プロトタイプ化、アクセシビリティ確認、改善

見た目を磨く前に、ブリーフを大まかな画面フロー図にします。重要な判断とそのフィードバックをプロトタイプ化し、想定利用者を代表する人に現実的なタスクを完了してもらいます。ためらい、予期しない選択、エラーを観察しましょう。フローを修正して繰り返します。NN/gの調査ガイドは、反復的な設計とプロトタイプの評価を学習の一部と捉え、最初の案で完成したとは考えません。

その作業と並行してアクセシビリティも確認します。AppleのHuman Interface Guidelinesは、知覚でき、適応可能な操作と、さまざまな入力方法への配慮を重視しています。文字の拡大、コントラスト、コントロールの大きさと間隔、明確なラベル、意味が色だけに依存していないかを確認します。長いテキストにフローが適応し、支援技術でも理解できることも確認しましょう。Androidの慣習に沿うプロダクトでは、Material Designのアクセシビリティガイドも役立ちます。

• インターフェースの案内ではなくタスクを提示し、利用者が進めるかを観察する。
• 構造を変えやすい段階で、早期の粗いバージョンをテストする。
• 対応する端末とデザインシステムに関係するプラットフォームのガイドを確認する。
• 事例に戻るのは疑問を調べるために限り、見た目の類似を証拠の代わりにしない。

事例からブリーフへのチェックリスト

ブリーフを引き継ぐ前に、単なる雰囲気を集めたボードではなく、プロダクト上の判断が記されているか確かめます。事例を集めていない人にも、想定タスク、提案するフロー、未解決の選択、設計が機能するかをチームがどう学ぶかが理解できるべきです。

• 元の利用者とタスクが明示されている。
• すべての事例に、どの問いやパターンを調べる助けになるかというメモがある。
• 観察と推測、ユーザビリティに関する主張が分けられている。
• ブリーフに独自のフローとプロダクト固有の理由が記されている。
• アクセシビリティ、プラットフォームの動作、重要な別の状態が含まれている。
• プロトタイプのタスクと、観察に基づくレビュー計画が定義されている。