こんにちは！
UIデザイナーのYunyです。
- エンジニアへのデザイン引き渡し時に「ここの挙動はどうなる？」と聞かれることが多い方
- 開発フェーズに入ってからの仕様考慮漏れによる手戻りを減らしたい方
- Figmaでのコンポーネント設計や状態管理（States）の整理方法を知りたい方
「案件を進めていて、デザインデータをエンジニアさんに渡そうとした瞬間に、あ、ここのステート（状態）を考えていなかった……と冷や汗をかいた経験はありませんか？」
ボタンのホバーや無効化（Disabled）といった基本的なものは作っていても、データの読み込み中（Loading）や、入力エラー（Error）、あるいは検索結果が0件のとき（Empty）など、動的プロダクトに欠かせない「状態」はついつい見落としがちになります。
この「状態」の考慮漏れは、開発フェーズにおいてレイアウト崩れや手戻りを引き起こす最大の原因の一つです。
見た目は1枚のシンプルな画面でも、ユーザーのアクションや通信状態によって、システム上は数十パターンの挙動が存在します。
今回は、手戻りを未然に防ぐための体系的フレームワーク「UI Stack」と、実務ですぐに使える包括的なステートチェックリストをご紹介します。
エンジニアとの連携をスマートにし、手戻りゼロの開発体制を一緒に作っていきましょう。
- 1. なぜ「状態（States）」の考慮漏れは減らないのか？
- 2. 考慮漏れを網羅する「5つの基本状態（UI Stack）」
- ① Ideal State（理想状態）
- ② Empty State（空状態）
- ③ Error State（エラー状態）
- ④ Loading State（読み込み中状態）
- ⑤ Partial State（部分的なデータ状態）
- 3. Figmaで実践する「状態」の見える化とコンポーネント設計
- 4. 手戻りをゼロにする「UI状態」包括チェックリスト
- UI状態 包括チェックリスト
- 5. エンジニアとの認識齟齬をなくすためのコミュニケーション術
- Figmaに直接「仕様メモ」をテキストで記述する
- デザイン確定前に、エンジニアに「壁打ち」する
- 「受け入れ条件（Acceptance Criteria）」を共に定義する
- まとめ：状態設計が手戻りを防ぎプロダクトの品質を支える
- あわせて読みたい関連記事
1. なぜ「状態（States）」の考慮漏れは減らないのか？
状態の考慮漏れがどれほど手戻りを生むか分かっていても、なぜこの問題は一向に減らないのでしょうか。
その理由は、デザイナーが普段作業しているFigmaなどのデザイン環境 of 特性にあります。
デザイナーが向き合うFigmaの画面は、基本的に「静的なアートボード」です。
ヘッダーがあり、綺麗な画像が並び、ダミーテキストが美しく収まった「理想的な1枚の絵（理想状態）」を基準にデザインを作ります。
しかし、実際のアプリやWebサイトは、ユーザーのアクションやデータの通信状況によって常に変化する「動的なシステム」です。
この「静的な絵を作るツール」と「動的なシステムを組むコード」のズレが、考慮漏れが減らない根本的な原因です。
私たちは、どうしても画面上にオブジェクトを綺麗に配置することに意識が向きがちで、データ通信が途切れた瞬間や、フォームのバリデーションエラーが起きた瞬間など、ツール上に現れない「目に見えない状態」を頭の中だけで想像して網羅することが難しいのです。
このようなツールとシステムの乖離によって、開発の後半になってエンジニアさんから「ここ、どう動きますか？」と聞かれて初めて漏れに気づく、というループが繰り返されてしまうのです。
あわせて読みたい
エンジニア連携をスムーズにするFigmaの命名規則やレイヤー整理については、以下の記事で詳しく解説しています。
2. 考慮漏れを網羅する「5つの基本状態（UI Stack）」
プロダクトデザイナーのScott Hurff氏が提唱した「UI Stack」というフレームワークを使うと、UIデザインにおける状態の考慮漏れを劇的に防ぐことができます。UIデザインを進める際は、すべての画面やコンポーネントにおいて、以下の「5つの状態」を網羅できているかを確認しましょう。
① Ideal State（理想状態）
すべてのデータが正常に存在し、最も美しく表示されている状態です。デザイナーが最初に作る、いわゆる「看板となるデザイン」がこれに当たります。
② Empty State（空状態）
データがまだ何もない状態です。ユーザーがアプリを起動した直後や、お気に入り登録が0件のとき、検索結果に何も引っかからなかったときなどが該当します。この画面で「何もない」ことを伝えるだけでなく、「次にとるべきアクション（例：新規追加ボタン）」を配置して次のステップへ促すことが、UXの観点から非常に重要です。
③ Error State（エラー状態）
何かトラブルが発生した状態です。必須入力項目が抜けているとき、通信エラー（オフラインなど）でデータを読み込めなかったとき、フォーム送信に失敗したときなどが含まれます。ユーザーを焦らせず、「何が起きたか」と「どうすれば解決できるか（例：リトライボタン）」を分かりやすく親切に表現する必要があります。
④ Loading State（読み込み中状態）
データを通信中で、画面の表示を待っている状態です。処理に時間がかかる際、ただの真っ白な画面のままだと、ユーザーは「フリーズしたのかな？」と不安になって離脱してしまいます。スピナーを表示したり、実際のレイアウトに近い「スケルトンUI」を配置してローディングアニメーションを流すことで、体感の待ち時間を軽減させることができます。
⑤ Partial State（部分的なデータ状態）
データはあるものの、ごく一部しか登録されていない、またはデータ量が多すぎる状態です。例えば、自己紹介文が1行しかない場合や、逆に極端に長い名前のユーザーが登録されて文字がはみ出しそうな場合など、境界値（エッジケース）における表示バランスを想定したデザイン調整が必要です。
3. Figmaで実践する「状態」の見える化とコンポーネント設計
「状態」を網羅した後は、それをエンジニアが正しく実装できるように、デザインデータ上で整理して引き渡さなければなりません。
そこで役立つのが、Figmaの「Component Sets（コンポーネントセット）」と「Variants（バリアント）」の活用です。
コンポーネントごとに「Default（通常）」「Hover（ホバー）」「Focus（キーボード操作時）」「Active（クリック中）」「Disabled（無効）」といった状態をVariantsとしてまとめて登録しておきます。
ここで大切なのは、Figmaのプロパティ命名規則を、エンジニアが使用するコードの仕様（ReactのPropsやCSSの疑似クラスなど）と揃えておくことです。
例えば、「disabled」というプロパティ名をそのままFigmaのプロパティ値として設定しておくことで、エンジニアは「デザインデータをそのままコードに落とし込める」ようになります。
また、個々のパーツだけでなく、画面全体の「状態遷移」も合わせて明記しましょう。
「どのボタンを押すとどのローディング状態に入り、成功したらどの画面へ遷移するのか」をFigmaの「プロトタイプ」機能で繋いでおくか、デザインの横に状態遷移のフローを簡潔に並べておくと、エンジニアは頭の中でシステム全体の動きを立体的に把握しやすくなります。
4. 手戻りをゼロにする「UI状態」包括チェックリスト
実務での考慮漏れをなくすために、引き渡し前に確認できるカテゴリ別のチェックリストを用意しました。
案件完了までのセルフチェックツールとしてご活用ください！
なお、このチェックリストを実務に適用する際は、「制作しているプロダクトがWebか、あるいはネイティブアプリ（iOS / Android）か」によって考慮すべきステートに差分があることを意識しておきましょう。
例えば、Webサイトではお馴染みの「404（ページが見つからない）」や「500（サーバーエラー）」といったエラー専用の独立した画面は、ネイティブアプリでは存在しないことがほとんどです。
アプリの場合、画面を切り替えずに「一時的な通信エラー」としてトーストやポップアップでメッセージを表示し、画面自体は前回のキャッシュデータ（ローカル保存データ）をそのまま表示し続ける、といった設計が多く採用されます。
また、アプリ特有の考慮として、スマートフォンのOS設定でフォントサイズを極端に大きくしているユーザー（Dynamic Typeなど）に対してレイアウトが崩れないか、あるいはアプリがバックグラウンドに移行して復帰した際の「セッションタイムアウト」をどう扱うか、などのアプリに特化した状態変化も存在します。
プラットフォームによる違いを意識して、チェックリストを柔軟に調整してみてください。
UI状態 包括チェックリスト
| カテゴリ | 対象となる具体的な状態 / 考慮すべき挙動 |
|---|---|
| ① 要素単体（インタラクション） | – Default（初期通常状態） – Hover（カーソルが乗った状態、※PCのみ） – Active / Pressed（クリック・タップしている瞬間） – Focus（タブキー操作などによるフォーカス状態、※アクセシビリティ対応） – Disabled（何らかの理由で操作が無効化されている状態） – Selected（選択済み・トグルオン状態） |
| ② 入力フォーム | – Placeholder（未入力・案内表示） – Focused / Typing（カーソルが当たり、入力を行っている最中） – Filled（入力が完了した状態） – Success / Validated（入力規則をクリアし、正しい値が入った状態） – Error / Invalid（入力規則エラー、およびリアルタイムの警告文表示） – Bulk Delete / Select All（複数選択時の挙動） |
| ③ 一覧・リスト表示（データ量） | – Ideal（データが綺麗に入っている状態） – Empty（データが0件、検索結果が0件の状態。初期導入時の案内やアクションボタンの有無） – Partial (Few)（データ数が少なく、余白が目立ってしまう場合の表示） – Overload (Too Many)（データ数が多すぎて、改ページや「もっと見る」ボタンが必要な場合の処理） – Truncation（テキストが長すぎて表示枠からはみ出す場合の「…（三点リーダ）」省略処理） |
| ④ システム・通信環境 | – Loading（読み込み中。スピナーやスケルトンUIの表示） – Offline（ネットワーク切断時の挙動、オフライン通知） – Session Timeout（セッション切れによる再認証画面） – 404 / 500（ページが見つからない、サーバーエラーの画面表示） – Permission Denied（権限がないユーザーのアクセス制限画面） |
5. エンジニアとの認識齟齬をなくすためのコミュニケーション術
チェックリストを使ってどれほどデザインを網羅しても、実際にコードを書くエンジニアとの意思疎通が不十分であれば、認識齟齬による手戻りは発生してしまいます。
開発チームでの手戻りをなくすために、以下のコミュニケーション習慣を意識してみましょう。
Figmaに直接「仕様メモ」をテキストで記述する
デザインデータ内に、言葉で挙動のルールを直接書いておきましょう。
「※ここのエラー表示は、送信ボタンを押したタイミングで発生します」
「※入力文字数は最大50文字で、超えた場合は入力できなくなります」
といったテキストメモがFigma上に1行添えられているだけで、エンジニアの質問コストと確認の手間が劇的に減少します。最近だとアノテーション機能もあるので便利ですよね。
デザイン確定前に、エンジニアに「壁打ち」する
デザインを完全に作り込んで確定（FIX）させてしまう前に、「この画面遷移やインタラクション、実装的に何か問題はないですか？」と、初期のラフ段階でエンジニアに見せる習慣を作りましょう。
技術的な制約や懸念点を早いフェーズで吸い上げることで、「時間をかけて作ったデザインが、実装不可能なため全てボツになる」という最悪の手戻りを防ぐことができます。
「受け入れ条件（Acceptance Criteria）」を共に定義する
「Aボタンを押したら、ローディング画面になり、通信が成功したらB画面へ遷移する」というように、画面の振る舞い（受け入れ条件）をエンジニアと一緒にテキストで書き出してみましょう。
これは実装の仕様書になるだけでなく、開発完了後に「正しく動いているか」を検証するテスト観点にもなるため、品質向上にもダイレクトに貢献します。
あわせて読みたい
ボタンの各状態（Hover, Active, Disabled）の優先度設計やサイズ基準については、以下の記事で詳しく解説しています。
まとめ：状態設計が手戻りを防ぎプロダクトの品質を支える
UIデザインにおける「状態（States）」の考慮は、単に画面のバリエーションを増やす作業ではなく、開発全体の手戻りを最小化し、ユーザー体験の破綻を防ぐための重要な設計工程です。
実務で考慮漏れを防ぐための要点は以下の3点です。
- UI Stackの5状態（Ideal / Empty / Error / Loading / Partial）を初期設計から想定する
- FigmaのVariantsプロパティ名を実装コード（Propsや疑似クラス）と一致させる
- データ引き渡し前にチェックリストで境界値やエラー表示の振る舞いを確認する
初期のワイヤーフレームやデザイン設計の段階から状態を網羅しておくことで、開発終盤の仕様確認コストを大幅に削減できます。ぜひ今回のチェックリストを実務のセルフチェックや開発チームとの仕様共有に役立ててください。
