ワイヤーフレームの注釈の書き方：予約フォームで学ぶ実践例

ワイヤーフレームの注釈は、静止画だけでは分からない動作を説明するものです。対象の操作のそばに番号を置き、初期状態、変化のきっかけ、その後の結果を短く書きます。時刻がすでに選ばれているのか、いつエラーが出るのか、次へ進むだけで予約が成立するのか。読んだ人が別途質問しなくても判断できる注釈が役立ちます。

注釈は、説明する画面の横に置きます。一つの画面の意味ではなく、画面間の移動が分かりにくい場合は、Pixsoのプロトタイプ作成機能で流れを示します。注釈でルールを伝え、実際に操作できるプロトタイプでその結果を確かめてもらいます。

図だけでは決まらないことを注釈にする

「メールアドレス」というラベルがあれば、入力欄の内容は分かります。そこに「メールアドレス欄」と書き足しても情報は増えません。「次へ進むときに必須。空欄の場合もほかの入力は保持する」であれば、枠とラベルでは表せない動作を説明できます。

実際の画面から生まれる疑問を起点にします。どの値が初期値なのか、操作同士に依存関係があるのか、何を選べるのか、どの条件でエラーになり、その後どこで修正するのか。あらゆるピクセルを仕様書にするのではなく、その作業に関わる判断を書きます。

利用者に見せる文言と、制作チームへの説明も分けます。画面には「時刻を選択」と表示し、注釈には「初期状態では時刻を選択しない」と書きます。前者はUIの中へ、後者は外へ置きます。混在させると、設計上の指示が利用者に表示されるコピーだと誤解されます。

予約画面の例：一つの作業を六つの注釈で説明する

30分間のデザイン相談を予約する画面を考えます。サービス概要、5月14日を表示した日付選択、三つの時刻、メールアドレス欄、「予約内容を確認」ボタンがあります。利用者の作業は、日時を選び、内容を確認してから予約を確定することです。

時刻は10:00、11:00、14:00で、14:00は予約できません。初期状態ではどの時刻も選ばれておらず、メールアドレスも空欄です。次の注釈で、この初期状態と主要な依存関係を明らかにします。

サービスに複数の所要時間があるなら、その選択肢を追加し、空き状況への影響も説明します。日付を変えたときに選択済みの時刻を残すかどうかは、実装に渡す前に決めます。見慣れたカレンダーの形だけでは、その判断は伝わりません。

きっかけと、確かめられる結果を書く

注釈05を「フォームを更新する」とするだけでは曖昧です。以前の時刻を残すのか、最初の空き時刻を自動で選ぶのか、すべての入力を消すのか分かりません。「日付が変わったら、選択した時刻を解除し、メールアドレスは保持する」なら、確認できる結果に絞れます。

基本の書き方は、何が起きたら、何を変え、何を残すかです。毎回三つをそろえる必要はありません。修正の途中で連絡先が消えるなど、影響の大きい誤解を防ぎたいときに、保持する情報を明記します。

エラーの注釈も具体的にします。条件、メッセージ、修正方法を示します。時刻が未選択なら「予約する時刻を選んでください」、メールアドレスが空欄なら「メールアドレスを入力してください」とします。エラーの記号だけでは問題を説明できません。W3Cの入力エラーの特定に関する解説（英語）でも、検出したエラーについて、対象の項目を特定し、テキストで内容を説明することを求めています。

メッセージの位置が重要なら、初期状態の横にエラー状態を一つ描きます。このフォームでは、次へ進めなかったときに、最初の不正な項目へキーボードフォーカスを移すと定めます。これは実装へ引き継いで検証する設計上の判断です。静止画の枠に色を付けるだけで、動作を示せるわけではありません。

説明を追いやすい位置に置く

番号はラベル、値、タッチ領域を覆わないように、対象の操作のすぐ外側へ置きます。注釈はフレーム横の一列にまとめ、画面を読む順序に沿って並べます。対応が曖昧な場合は短い線で結べますが、六本の線がフォームを横切ると、UI自体より注釈のほうが読みにくくなります。

同じ操作を別の状態で説明するときは、番号も共通にします。エラー状態でも、04はメールアドレスを指すようにします。番号が安定していれば、「04の修正方法が分かりにくい」と伝えられ、キャンバス上の位置を説明する必要がありません。

プロトタイプに表示する予定のない注釈は、画面のフレーム外へ置きます。画像を書き出して共有する場合は注釈の列も含め、実際に読む大きさで文字を確認します。大幅な拡大が必要なら、文字を縮めるのではなく、全体図と一つの操作の拡大図に分けます。

注釈・プロトタイプ・コメントを使い分ける

チームで保持すべきルールには注釈を使います。実際に試してほしい手順にはプロトタイプを使います。まだ判断が必要な質問や議論にはコメントを使います。

予約画面なら、「日付を変えると時刻の選択が解除される」は残すべき注釈です。利用者が解除に気付くかどうかは、操作しながら確認するのに向いた問いです。「両方の日付で空いていれば、時刻を保持してもよいか」は議論であり、合意済みのルールではありません。

議論がまとまったら、注釈と対象の画面を更新します。承認した動作がコメントの奥に埋もれ、ワイヤーフレームには古い判断が残る状態を避けます。成果物を選ぶときも、構造を確かめるのか、見た目を比較するのか、動作を試すのかに応じて、ワイヤーフレーム、モックアップ、プロトタイプを使い分けます。

Pixsoで注釈付きの予約画面を作る

Pixsoのデザインファイルに、読めるラベル、時刻の選択肢、メールアドレス欄、確認へ進む操作を配置します。フレームの横にテキストの注釈を一列に並べ、小さな番号で六つのルールと操作を対応付けます。注釈には通常のデザインオブジェクトを使えば、文言も配置も編集しやすくなります。

画面を複製し、メールアドレスが空欄のエラー状態と、日付を変更した状態を作ります。日付変更後の画面ではメールアドレスを残し、時刻の選択だけを解除します。注釈05の結果を、読む人が想像だけに頼らず確認できます。

操作を絞ったプロトタイプでは、入力済みのフォームの「予約内容を確認」を確認画面につなぎます。確認画面には相談内容、日付、時刻、メールアドレスを表示し、別に確定操作を設けます。Pixsoでは画面間のリンクやデザイン上のコメントを利用できますが、この予約の流れで各操作が何を意味するかは、画面と記述したルールで定めます。

Pixsoで注釈付きワイヤーフレームを作る →

最も誤解されやすい変更を確認する

口頭で説明せずに、同僚にワイヤーフレームを読んでもらいます。「10:00を選び、メールアドレスを入力しました。ここで日付を変えると、何が残り、何を選び直す必要がありますか」と尋ねます。画面と注釈05だけで答えが分からなければ、説明を増やす前に、その二つを直します。

番号付きの注釈は、自分がその場にいなくても答えが伝わるようにするためのものです。どのフォームにも当てはまる一般論を一ページ書くより、適切な操作に結び付いた六つの具体的な注釈のほうが役立ちます。