カンプに「極端なデータ」の画面を描いておく

デザインカンプは、たいてい「理想的なデータ」で描かれます。名前は短くきれいで、画像はすべて揃い、一覧は程よく5件。ところが本番では、0件の利用者も、1000件の利用者も、30文字を超える名前の人もいます。カンプに無い状態は、実装者がその場で判断することになり、その判断が表示崩れのバグとして報告されます。この記事では、設計フェーズでカンプに含めておくべき「極端なデータ」の画面と、確認の手順を紹介します。

なぜ極端なデータが設計段階で必要なのか

実装者はカンプを正解として作ります。カンプに描かれていない状態に出会うと、次のどれかになります。

• デザイナーに聞く（待ち時間が発生し、聞かずに進める人も多い）
• 自分の判断で決める（人によって結果がばらつく）
• 何もしない（崩れたまま出荷される）

後から直すと、デザイン・実装・テストのやり直しが発生します。設計時に1枚描いておく方が、はるかに安く済みます。

カンプに含める極端データ6種

1. 空（0件）

初めて使う人は必ずこの画面を見ます。「データがありません」だけで終わらせず、次に何をすればよいかを示します。

2. 1件だけ

一覧のつもりで作ったレイアウトが、1件だと間延びしたり、区切り線だけが浮いたりします。

3. 大量（1000件以上）

ページ分割にするのか、無限スクロールにするのか。件数表示は「1,284件」のように桁区切りが入っても収まるか。ここで決めておきます。

4. 極端に長い文字列

長い氏名、スペースのない長いURL、改行を含む本文。「折り返す」「省略して…にする」「全文を見る手段を用意する」のどれにするかを、項目ごとに決めます。

5. 欠損（画像なし・任意項目が空）

アイコン未設定のとき、代替の表示は何か。任意項目が空のとき、項目名ごと隠すのか、「未設定」と出すのか。

6. 権限が無いときの表示

見えない、押せない、押すとエラー、の3つは別物です。権限が足りない操作を、非表示にするのか、無効表示にするのか、理由を添えるのかを描きます。

デザインレビューでの確認手順

レビュー会では、次の順で確認すると漏れにくくなります。

1. 画面ごとに、上の6種のうち該当するものを一覧にする
2. カンプが無いものは、「描く」か「実装者に委ねる」かを明示する
3. 委ねる場合は、判断基準を一言で書く（例:「長い名前は1行で省略し、タップで全文を表示」）
4. 決まった内容を、実装チケットの受入条件に転記する

手間を減らすコツは、全画面を描かないことです。パターンが同じなら、代表の1画面を描き、「同じルールを適用」と注記すれば十分です。

失敗例: 長い名前で崩れたヘッダー

カンプのユーザー名は「田中 太郎」でした。本番に40文字の組織名を持つ利用者がいて、ヘッダーのボタンが画面外に押し出されました。実装者は悪くありません。カンプにその状態が無く、誰も決めていなかっただけです。「ヘッダーの名前は最大15文字で省略」という1行の決めごとがあれば防げました。

Bugoon での実践

設計で描き切っても、すべての極端データを事前に予想することはできません。実際に崩れた画面は、Bugoon のウィジェットをサイトに埋め込んでおけば、見つけた人がその場でスクリーンショットを撮り、崩れた箇所をアノテーションで囲んで報告できます。どんなデータでその画面になったのかは、操作ステップの記録から追えます。報告は GitHub Issue に連携できるので、「次のカンプに足すべき極端データ」として、そのままデザインの改善リストに積めます。

本番で拾った崩れを6種のどれに当たるか分類しておくと、次の設計レビューのチェックリストが育っていきます。