「案件を進めていて、デザインデータをエンジニアさんに渡そうとした瞬間に、あ、ここのステート（状態）を考えていなかった……と冷や汗をかいた経験はありませんか？」

ボタンのホバーや無効化（Disabled）といった基本的なものは作っていても、データの読み込み中（Loading）や、入力エラー（Error）、あるいは検索結果が0件のとき（Empty）など、動的プロダクトに欠かせない「状態」はついつい見落としがちになります。

この「状態」の考慮漏れは、開発フェーズにおいてレイアウト崩れや手戻りを引き起こす最大の原因の一つです。
見た目は1枚のシンプルな画面でも、ユーザーのアクションや通信状態によって、システム上は数十パターンの挙動が存在します。

今回は、手戻りを未然に防ぐための体系的フレームワーク「UI Stack」と、実務ですぐに使える包括的なステートチェックリストをご紹介します。
エンジニアとの連携をスマートにし、手戻りゼロの開発体制を一緒に作っていきましょう。

1. なぜ「状態（States）」の考慮漏れは減らないのか？

状態の考慮漏れがどれほど手戻りを生むか分かっていても、なぜこの問題は一向に減らないのでしょうか。
その理由は、デザイナーが普段作業しているFigmaなどのデザイン環境 of 特性にあります。

デザイナーが向き合うFigmaの画面は、基本的に「静的なアートボード」です。
ヘッダーがあり、綺麗な画像が並び、ダミーテキストが美しく収まった「理想的な1枚の絵（理想状態）」を基準にデザインを作ります。

しかし、実際のアプリやWebサイトは、ユーザーのアクションやデータの通信状況によって常に変化する「動的なシステム」です。

この「静的な絵を作るツール」と「動的なシステムを組むコード」のズレが、考慮漏れが減らない根本的な原因です。
私たちは、どうしても画面上にオブジェクトを綺麗に配置することに意識が向きがちで、データ通信が途切れた瞬間や、フォームのバリデーションエラーが起きた瞬間など、ツール上に現れない「目に見えない状態」を頭の中だけで想像して網羅することが難しいのです。

このようなツールとシステムの乖離によって、開発の後半になってエンジニアさんから「ここ、どう動きますか？」と聞かれて初めて漏れに気づく、というループが繰り返されてしまうのです。

あわせて読みたい
デザイナーとエンジニアが互いの職能を理解し、一歩踏み込んで協働していくための考え方については、こちらの記事もぜひ参考にしてみてください。

デザインハーネスとは？無数の選択に疲れた日々を軽くする「適度な制約」の知見

こんにちは！UIデザイナーのYunyです。 朝の服選びや、仕事で渡された真っ白な企画書。「自由に選んでいいよ」と言われる…

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状態 包括チェックリスト

5. エンジニアとの認識齟齬をなくすためのコミュニケーション術

チェックリストを使ってどれほどデザインを網羅しても、実際にコードを書くエンジニアとの意思疎通が不十分であれば、認識齟齬による手戻りは発生してしまいます。
開発チームでの手戻りをなくすために、以下のコミュニケーション習慣を意識してみましょう。

Figmaに直接「仕様メモ」をテキストで記述する

デザインデータ内に、言葉で挙動のルールを直接書いておきましょう。
「※ここのエラー表示は、送信ボタンを押したタイミングで発生します」
「※入力文字数は最大50文字で、超えた場合は入力できなくなります」
といったテキストメモがFigma上に1行添えられているだけで、エンジニアの質問コストと確認の手間が劇的に減少します。最近だとアノテーション機能もあるので便利ですよね。

デザイン確定前に、エンジニアに「壁打ち」する

デザインを完全に作り込んで確定（FIX）させてしまう前に、「この画面遷移やインタラクション、実装的に何か問題はないですか？」と、初期のラフ段階でエンジニアに見せる習慣を作りましょう。
技術的な制約や懸念点を早いフェーズで吸い上げることで、「時間をかけて作ったデザインが、実装不可能なため全てボツになる」という最悪の手戻りを防ぐことができます。

「受け入れ条件（Acceptance Criteria）」を共に定義する

「Aボタンを押したら、ローディング画面になり、通信が成功したらB画面へ遷移する」というように、画面の振る舞い（受け入れ条件）をエンジニアと一緒にテキストで書き出してみましょう。
これは実装の仕様書になるだけでなく、開発完了後に「正しく動いているか」を検証するテスト観点にもなるため、品質向上にもダイレクトに貢献します。

あわせて読みたい
画面遷移やボタンを押した瞬間の「微細なインタラクション」の設計とその心地よさの追求については、こちらの記事も参考にしてみてください。

触って気持ちいいUIの正体。2026年デザイントレンド「Squishy UI（スクイッシーUI）」とは？

こんにちは！UIデザイナーのYunyです。 最近、打鍵感にこだわって少し高めのメカニカルキーボードを新調しました。キーを…

終わりに

今回は、開発現場での手戻りをゼロにするための「状態（States）」の体系的整理と包括的チェックリストをご紹介しました。

UIデザインは、静的なビジュアルを作るだけの仕事ではありません。
ユーザーの様々なアクションや、デバイスの状況、サーバーの応答といった「動的な世界」をいかにスマートに設計するかが、プロフェッショナルなUIデザイナーとしての大きな腕の見せ所です。

「あ、ステートが漏れていたな」と気づいた次の瞬間から、ぜひ今回のチェックリストを開いて、エラーやローディング、空の状態へと思いを巡らせてみてください。

ほんの少し「状態」への意識を広げるだけで、あなたが手掛けるデザインの品質が高まるだけでなく、開発チーム全体の連携が驚くほど滑らかになるはずです。
チームメンバー全員が同じ認識を持ち、前向きにプロダクト開発に熱中できる、そんな快適なものづくりの環境を一緒に目指していきましょう！

それでは、良いデザインライフを！

The post エンジニア連携の手戻りをゼロにする。「状態（States）」考慮漏れを防ぐUI Stackと包括チェックリスト first appeared on デザペディア.

デザインデータを作り終えてエンジニアさんに渡した後、「あれ、ここの余白ちょっと違うな…でも今更修正お願いするの悪いし、機能は動くから今回は我慢しようかな…」と、1pxのズレや微妙な動きのニュアンスを飲み込んで妥協してしまった経験、ありませんか

これまでの開発現場では、デザイン担当と実装担当の作業が完全に分かれており、もどかしい思いをすることが少なくありませんでしたよね。

しかし最近、デザインツールのすぐ隣にAIがいるのが当たり前になりました。AIがデザインデータから実装のコードを即座に生成してくれるようになり、ふと気づけば、UIデザイナーである私たちの働き方そのものが大きく変わり始めています。

AIの普及によって、デザイナーとエンジニアといった「職種の境界線」は急速に曖昧になってきました。

かつては完全に分業されていた役割が接近し、いまや共同でひとつのものを作り上げるスタイルへと変化しています。

今回は、現場で働く私自身の視点から、作る側の環境が今どのように変化しているのか、そしてデザイナーとエンジニアの働きやすさやマインドがどう変わっていくべきかについてお話しします。明日からのものづくりがもっと面白くなるような、現場のリアルな裏側を覗いてみましょう。

1. 「バケツリレー」から「同じテーブルでの対話」へ

結論からお伝えすると、ツールとAIの進化により、これまで分断されていた職種が同じ画面上で共同作業できるようになりました。

以前の開発現場では、デザインを作ってからエンジニアに「あとはお願いします」と渡す、一方向のバケツリレー方式で仕事をするのが一般的でした。冒頭でもお話ししたように、この方法だと細かなニュアンスがうまく伝わらず、お互いに気を遣ってしまうことが多々あったのです。

しかし現在の開発現場では、Figmaの「Code Layers」機能や「Figma MCP」の登場により、デザインデータとコードがAIを介して常に同期するようになりました。

デザインを変えればコードが追従し、コード側の制約がデザインにもすぐに反映されます。つまり、同じ画面を見ながら「ここ、もう少しこうしようか」と対話しながら作れるようになったのです！

この変化は、数字にも明確に表れています。
知人のエンジニアがいる会社で聞いた話によると、従来は1画面あたり 2〜3時間 かかっていた実装作業が、AIの支援によってわずか 15〜30分（75%〜90%の工数削減） へと大幅に短縮されたケースもあるそうです。

この余白の時間ができたからこそ、私たちは単なる「作業」ではなく、より本質的な「使いやすさ」の議論に集中できるようになったと言えますね。

2. プロダクト全体を導く「共通言語」へと進化するデザインシステム

次に重要な結論として、デザインシステムはもはやデザイナーだけのものではなく、職種を越えてブランドの「らしさ」を守る指針になっています。

デザインシステムとは、余白のサイズ、色、文字のルールなどをまとめたものです。
少し前までは単なるUIのルールブックでしたが、現在ではマーケターやセールスなど、「ノンデザイナー」も含めた全員が頼りにし、大事に育てていく基準へと進化しています。

なぜ、これが私たちの体験を豊かにするのでしょうか？

誰もが迷わず使える共通のルール（デザインシステム）があることで、「このボタンの余白はいくつだっけ？」といった確認の手間が省け、本来集中すべき「ユーザーにどんな価値を届けるか」を考えることに時間をかけられるようになるからです。チーム全体で一貫した基準を持つことで、最終的なプロダクトの品質が安定するのです。

例えば、セールス担当者が提案資料を作る際にデザインシステムのカラーパレットを参照したり、マーケターがLPを作る際に公式のコンポーネントをそのまま活用したりするケースが増えています。
一部の専門家だけが管理するのではなく、組織全体で大事にしていく「共通言語」になりつつあるのですね。

3. 「作業」から「体験の追求」へ。AIが変える時間の使い方

職能の境界線を越える「デザインエンジニア」の存在が、より深いレベルでものづくりに向き合うマインドを生み出しています。

最近では、デザイナーが直接コードを触って動きを調整したり、エンジニアがUIの細かなレイアウトを微調整したりするような、領域横断的な開発が当たり前になりつつあります。

では、彼らがこだわる「動き」や「光り方」といった細部の調整に、なぜこれほど時間をかけるのでしょうか。

それは、単に「見た目が綺麗だから」ではありません。
ボタンを押したときの自然な沈み込みや、画面が切り替わるときの滑らかさは、私たちの「視線が自然に誘導されるスピード」や「指の動きと画面の反応にズレがないこと」という、極めて人間工学的な理由（認知モデルとの一致）に基づいているのです。

定型的なUIパーツの配置や作成は、AIが瞬時に行ってくれるようになりました。だからこそ、人間の作り手は「Figma Motion」などを用いて、こうした人間の感覚に訴えかける微細な手ざわりの設計に、全力で集中できるようになったのです！

4. 個人のこだわりを組織に広げる環境（DesignOps）

近年、「PdMとUXデザイナーの違い」が曖昧になり、両者を兼務するようなキャリアパスが増えているのと同じように、デザイナーとエンジニアの境界線もまた、ツールとAIによって消えつつあります。

しかし、どれほど優れたツールや領域横断的な働き方があっても、それを活かす「組織の仕組み」がなければ本質的な価値は生まれません。

ここで注目されているのが、「DesignOps（デザインオプス）」という考え方です。

組織が拡大してもデザインの品質とスピードを落とさないために、専門の仕組み化を行う動きが高まっています。
Nielsen Norman Group（NN/g）などの提唱でも、単なる業務遂行の効率化だけでなく「他部署との協働」や「組織への影響創出」といった多角的な視点（3次元モデル）で組織の仕組みを設計する重要性が語られています。

DesignOpsは、評価制度を透明にしたり、専門性を極める道とマネジメントの道（デュアルキャリアラダー）を両立させたりすることで、デザイナーが本来の「良い体験づくり」に100%集中できる環境を整える仕組みです。

以前はデザインが完成してからエンジニアに「ここ、実装的に難しいから直して」と言われて手戻りが発生することが多く、お互いに疲弊していました。
しかし最近では、ツール上で初期段階からエンジニアと一緒に構造を考えられるようになったため、「これは実装しやすいね」「ここ工夫すればもっと滑らかに動くよ」という前向きなやり取りが増え、無駄な作業が圧倒的に減ったと実感しています

個人の「ここをもっと良くしたい」という強いこだわりを、組織全体で肯定し、後押しする環境があるからこそ、それが最終的に良いプロダクトとしてユーザーへ還元されていくのです。

あわせて読みたい：デザインとビジネスが交差する時代のキャリア

デザイナーの役割が大きく変化する時代において、チームでどのように体験を作り上げていくかについて、こちらの記事も参考にしてみてください！

デザインハーネスとは？無数の選択に疲れた日々を軽くする「適度な制約」の知見

こんにちは！UIデザイナーのYunyです。 朝の服選びや、仕事で渡された真っ白な企画書。「自由に選んでいいよ」と言われる…

なぜ私たちは「使いにくい」に気づけないのか。感覚を言葉にする、UXリサーチと知見共有の習慣

こんにちは！UIデザイナーのYunyです。 日常のふとした瞬間に感じる違和感。例えばスマホアプリで、目立つ色のボタンをつ…

5. AI時代におけるキャリアと役割分担の未来

ここで、最近現場でもよく話題に上がる「PdMとUXデザイナーの違いや、エンジニアとの境界線はどう変化していくのか？」というテーマについて、私個人の考えを少しお話しさせてください。

従来の「誰がどこまでやるか」という明確な役割分担は、今後さらに曖昧になっていくと感じています。「PdMだから」「デザイナーだから」と領域を限定して兼務するようなフェーズを越えて、まだない名前の職種が生まれていくのではないか、と個人的には思っています。

互いの専門性がAIによってシームレスに繋がることで、これまでの枠組みには収まらない、新しいものづくりのプロフェッショナルが誕生する時代がすぐそこまで来ているのかもしれません。

まとめ：これからのプロダクト開発のリアル

生成AIの登場によって、誰もが簡単にそれなりの画面を作れる時代になりました。だからこそ、「何を、なぜ作るのか」という根本的な問いに向き合い、細部にこだわる人間同士の協力が、今まで以上に大きな意味を持つようになっています。

普段私たちが何気なく使っている使いやすいアプリの裏側でも、今まさに職種の壁を越えた新しいものづくりが起きています。

皆さんの現場でも、ツールやAIの進化をきっかけに、ぜひチームのエンジニアやデザイナーと「どう作るか」ではなく「何を作るか」について、もう一歩踏み込んだ話をしてみてはいかがでしょうか。

皆さんの日常の景色が、少しでも新鮮に映るようになれば嬉しいです。
これからも、新しい時代のデザインのあり方を一緒に探求していきましょう。

それでは、良いデザインライフを！

The post AI時代におけるデザイナーとエンジニアの協働。デザインとコードが近づくことで変わる、私たちのマインドセット first appeared on デザペディア.