フォームの完了率を大きく左右するのは、機能要件ではなく細かいUI設計です。
自分がデザインレビューをする中でも、「ラベルがない」「エラーのタイミングがおかしい」という指摘はフォーム設計でとくに多いと感じます。
この記事では、現場ですぐに使えるフォームUXの基本ルールを4つの切り口で整理しました。

プレースホルダーをラベル代わりに使ってはいけない理由

フォーム設計でよく見るミスのひとつが、入力欄の外にラベルを置かず、プレースホルダー（入力欄内の薄いテキスト）だけで項目名を伝えようとするパターンです。
見た目がすっきりするように見えますが、UXの観点では複数の問題が生じます。

NN/g（Nielsen Norman Group）の調査でも、ラベルを入力欄の上部に常時表示する「top-aligned label」が、完了時間の短縮とエラー率の低下において最も効果的だと報告されています。

プレースホルダーのみにした場合の問題点は3つあります。

まず、入力を始めるとプレースホルダーが消えてしまうため、「今何を入力しているのか」が分からなくなります。
特に「姓」「名」が並ぶ項目や、複数欄が縦に並ぶ長いフォームでは、入力途中に項目名を確認したくなった際にカーソルを抜かなければなりません。

次に、「空欄」と「入力例が表示されている状態」の区別がつきにくくなります。
薄いグレーのテキストを「まだ何も入力されていないフィールド」と「例が書かれているフィールド」として即座に判断するのは、ユーザーに余分な認知コストがかかります。

最後に、エラーが発生した際の修正が難しくなります。
「半角英数字で入力してください」などのヒントがプレースホルダーに書いてあると、文字を打った瞬間にそのヒントが消えてしまい、どう直せばいいかが分からなくなります。

正しい設計は、ラベルを入力欄の上部に独立して配置し、常に表示し続けることです。
プレースホルダーはあくまで補助として、「YYYY/MM/DD」や「例：yamada@email.com」のようなフォーマットヒントに限定して使いましょう。

バリデーションのタイミング設計

バリデーション（入力値の検証）をいつ行うかは、フォームUXの体験を大きく変えます。
主に3つのパターンがあり、それぞれ適切な使い場面が異なります。

基本はフォーカスアウト（blur）時の検証を選ぶのがおすすめです。
ユーザーがその項目への入力を「終えた」というタイミングでのみエラーを表示するため、入力の途中で急かされる感覚がありません。

「送信時のみ」を選ぶと、全項目を入力し終えて初めて複数のエラーが一斉に表示されます。
どこを直せばよいかを一から探し直す必要があり、完了までの手間が大幅に増えます。

「入力中リアルタイム」は、使い方を誤るとユーザーが入力し終える前にエラーが出てしまい、必要以上にストレスを与えます。
例外として、一度エラーが出たフィールドは、修正中のリアルタイム判定に切り替えるのが適切です。
ユーザーが修正の途中で「今どこまで直せたか」を確認しながら入力できるようになり、正しく入力できた瞬間にエラーが解除されます。

パスワードの強度メーターも、入力中のリアルタイム判定が正当なユースケースです。
セキュリティ要件への気づきをサポートする目的であり、エラーではなくフィードバックとして機能しています。

エラーメッセージの書き方と配置ルール

エラーが発生した際の表示方法は、修正のしやすさに直結します。

配置の鉄則は「エラーが発生したフィールドの直下」です。
フォームの上部や下部にまとめて表示するパターンを見ることがありますが、ユーザーは「どのフィールドがエラーなのか」を探しながらスクロールしなければならず、修正の手間が増えます。
フィールドとエラーメッセージが視覚的に近いほど、ユーザーの目の動きが減り修正しやすくなります。

文言は「何が間違いか」ではなく「どうすれば直るか」を伝えます。

よくあるNGとOKの対比を整理しました。

色だけに頼らない設計も重要です。
赤いボーダーや赤いテキストはエラーの視覚的なサインとして機能しますが、色覚多様性のあるユーザーには色の区別が難しい場合があります。
赤いボーダー＋エラーアイコン（!マーク）＋テキストメッセージの3点をセットで使うことで、色に頼らない設計が実現できます。

また、エラーが出ても入力済みの内容は保持するのは基本ルールです（※セキュリティ上再入力を求めるパスワード項目などを除く）。
せっかく入力した一般項目がリセットされてしまうフォームは、ユーザーの大きな離脱要因となります。

アクセシビリティの観点では、aria-invalid="true" をエラー状態のフィールドに付与し、エラー文言要素に role="alert" や aria-describedby を紐付けることで、スクリーンリーダーへの対応ができます。
フォーム設計の際には実装チームとともに確認しておきたいポイントです。

モバイルで使い勝手を上げるキーボード指定

スマートフォンでフォームを入力する際、適切なキーボードが自動で起動するかどうかで入力体験が大きく変わります。
HTMLの type 属性や inputmode 属性を正しく設定することで、ユーザーに必要なキーボードを自動的に表示できます。

type="number" を安易に使うのは避けましょう。
数値入力欄だからといって type="number" を使うと、ブラウザが数値の増減ボタン（スピナー）を表示したり、指数表記の「e」が入力できてしまったりします。
郵便番号や電話番号、カード番号など「数字しか入力させたくない」フィールドには、type="text" に inputmode="numeric" を組み合わせるのが適切です。

実際の現場でも、type 属性の指定を忘れたまま実装が進んでiOSで全角数字が入力されてしまうトラブルを経験したことがあります。
設計の段階でFigmaの注釈（Annotation）やSpec資料にキーボードタイプを明記しておくと、実装時のミスを防ぎやすくなります。

デザイン側でできることとして、Figmaコンポーネントのプロパティや説明欄に「inputmode="numeric"」のように属性を記載しておくと、開発チームへの引き渡し時に漏れが出にくくなります。

フォームUXの5つのチェックリスト

設計が終わったタイミングで、以下の5点を確認しておきましょう。

• ラベルは常時表示されているか（プレースホルダーのみでラベルを代替していないか）
• バリデーションはフォーカスアウト時に動作するか（送信時のみ・入力中リアルタイムの乱用はないか）
• エラーはフィールドの直下に表示されているか（フォームの上部・下部にまとめて表示していないか）
• エラーメッセージは「どう直せばよいか」まで書かれているか（「エラーです」で終わっていないか）
• モバイルで適切なキーボードが起動するか（type / inputmode の指定漏れはないか）

フォームは一見シンプルな画面に見えますが、ユーザーが実際に情報を入力して送信するという「最も重要なインタラクション」が発生するUIです。
この5点を押さえるだけで、完了率が変わる実感があります。

フォームを通過するユーザーのバリデーション設計については、マイクロインタラクションの考え方とも密接に関係しています。
フィードバックの設計に興味がある方は、あわせてこちらも参考になります。

マイクロインタラクション設計入門｜4つの構成要素と200msルール

トリガー・ルール・フィードバック・ループの4要素と200msルールを中心に、UIフィードバック設計の基本をまとめました。

また、フォームのエラー状態や送信完了状態など、コンポーネントの「状態（States）」を設計段階で考慮しておくことも重要です。

ボタンのUIデザイン設計ガイド｜Primary・Secondary優先度と44pt基準

ボタンの優先度設計・44ptのタップ領域基準・Disabled状態の扱い方まで、フォームと合わせて確認したいボタンUIの基本設計ルール。

まとめ：フォームUXは細部の仕様定義で決まる

フォームのUI設計は見た目以上に「状態変化」と「仕様の詰め」が体験を左右します。
ラベルの常時表示、フォーカスアウト時のバリデーション、解決策を示すエラーメッセージ、モバイルのキーボード指定など、どれも設計段階でFigmaや仕様書に一言添えるだけで実装の手戻りを大きく防げます。

まずは次回のフォーム設計やデザインレビューで、今回のチェックリストを活用してみてください。

The post 入力フォームUI設計の4原則｜離脱を防ぐラベル・エラーUX first appeared on デザペディア.

プロダクトの機能を充実させようとするほど、画面上の入力項目やボタンの数は増えていきます。
しかし、親切心のつもりですべての選択肢を1画面に並べてしまうと、かえってユーザーを混乱させてしまいます。

自分自身も以前、業務管理画面のUI設計で大きな失敗をした経験があります。
「設定項目をすべて見せておけば迷わないだろう」と考え、1画面に20項目以上の入力欄や注釈テキストを詰め込んで提案したところ、クライアントから「どこから手を付ければいいか分からない」「威圧感があって使うのが怖い」と指摘され、全面的なレイアウト見直しになりました。

この「多機能にしたいが、画面はシンプルに保ちたい」という矛盾を解決する原則が、プログレッシブディスクロージャー（Progressive Disclosure：段階的開示）です。
今回は、情報過多を防ぐ基本概念から、実務で使える4大展開パターン、隠しすぎて失敗しないための境界線ルールまで具体的に整理します。

1. プログレッシブディスクロージャーとは？情報過多を防ぐ基本概念

プログレッシブディスクロージャーは、ユーザビリティの第一人者であるヤコブ・ニールセン（Jakob Nielsen）が体系化したインタラクション設計の標準原則です。
画面の初期状態では「80%のユーザーが日常的に使う基本的な情報・操作」だけをクリーンに表示し、残りの「20%のユーザーだけが求める高度な設定や二次的情報」は、ユーザーが能動的にクリックやタップを行ったときに初めて表示します。

この設計が極めて有効な理由は、UIデザインが常に抱えている「使いやすさと多機能性のジレンマ」を論理的に解消できる点にあります。
初心者にとっては画面がシンプルで操作を学習しやすく（Learnability）、上級者にとっては必要なときに高度な機能へ素早くアクセスできる効率性（Efficiency of use）を両立できます。

なぜ「全部並べるUI」は破綻するのか？

画面上に選択肢を無秩序に並べると、人間の脳は強い認知負荷（Cognitive Load）を感じて処理落ちを起こします。
心理学における「ヒックの法則」が示す通り、人間が選択肢の中から1つを選び出すまでの時間は、画面上の選択肢の数が増えるほど対数的に増加します。

さらに、人間のワーキングメモリ（作業記憶）が一度に保持できる情報数は、一般に「4±1個」程度と限られています。
最初から20個の設定項目を視界に突きつけられると、ユーザーは何が重要なのかを判断できず、操作を諦めて画面を閉じてしまいます。

そのため、優れたUIデザイナーは「画面に何を置くか」よりも「初期表示から何を隠し、どのタイミングで見せるか」に細心の注意を払って設計します。
必要な情報が必要な瞬間にだけ目の前に現れる状態を作ることが、プログレッシブディスクロージャーの本質です。

2. 段階的に開示する4大UIパターンと使い分け基準

プログレッシブディスクロージャーを実際の画面に落とし込む際、情報の性質や作業コンテキストに応じて適切なUIパターンを選択する必要があります。
実務で頻繁に使われる代表的な開示パターンは、以下の4つのアプローチに分類されます。

① インライン展開（アコーディオン / 詳細トグル）

同一画面のレイアウトを保ったまま、ボタンの押下によってその場（インライン）で領域が広がるパターンです。
「高度な設定を表示」「FAQの回答を見る」のように、前後の文脈を保ったまま少しの追加情報を取り出したい場面に最も適しています。

コンポーネントを設計する際は、アコーディオンの開閉状態（展開前 / 展開後）を縦並びのレイアウトで構築します。
開閉トリガーには回転するChevronアイコン（下向き・上向き）を添え、クリックで領域が展開することを視覚的に示します。
ただし、展開時にページ全体の高さが変わり、後続の要素が下へ押し出されるため、頻繁に開閉する項目を縦に何十個も連続して並べる構成は避ける必要があります。

② レイヤード展開（モーダル / ボトムシート / ドロワー）

現在の画面の上に半透明のオーバーレイを敷き、別のサーフェス（階層）を重ねて詳細情報を表示するパターンです。
複雑な絞り込みフィルターや、項目の詳細編集、確認ダイアログなど、元の画面から一時的に集中を切り替えて行う作業に適しています。

レイヤード展開を採用する場合、PCでは画面中央に浮遊するモーダル、スマートフォンでは親指で操作しやすいボトムシート（ハーフモーダル）を活用するのが実務の標準です。
作業が完了したら「保存」または「閉じる」操作で迷わず元の画面へ復帰できるため、ユーザーが現在地を見失うリスクを最小限に抑えられます。

③ ステップ式展開（マルチステップフォーム / ウィザード）

アカウント登録や購入手続き、初期設定などの長い入力プロセスを、論理的な手順（ステップ1、ステップ2、ステップ3）に分割して順番に開示するパターンです。
全30項目の入力欄が1画面に連なる巨大なフォームを、1画面あたり3〜5項目ずつに分解して提示することで、ユーザーの心理的抵抗を大幅に軽減できます。

ステップ式展開を機能させるためには、全体のステップ数と現在の進捗を示す「ステッププログレスバー」の併設が必須です。
「あとどれくらいで完了するのか」という全体像が見えているからこそ、ユーザーは途中で挫折せずに次のステップへと進むことができます。

④ オンデマンド展開（ツールチップ / ヘルプアイコン / ポップオーバー）

画面上のテキストに添えられた「？」アイコンやリンクに対して、ホバーまたはタップしたときだけ小さな吹き出しを表示するパターンです。
専門用語の解説や、パスワードの文字数条件、入力例の補足など、「知りたい人だけが読めばよい補助情報」をスマートに配置できます。

ツールチップの最大のメリットは、主要なUIのレイアウトや文字量を一切圧迫しない点にあります。
ただし、スマートフォンのようなタッチデバイスではホバー操作が存在しないため、タップで表示・枠外タップで非表示となるインタラクションを正しく設計することが重要です。

段階的開示の4大UIパターン比較まとめ

3. 隠しすぎて失敗しないための「3つの境界線ルール」

プログレッシブディスクロージャーは強力な設計原則ですが、使い方を誤ると「必要な機能が見つからない不親切なUI」に転落します。
画面をシンプルにしたい一心で重要な情報まで奥深くに隠してしまう設計ミスを防ぐため、以下の3つの境界線ルールを実務の基準として設定してください。

ルール①：80%のユーザーが必要とするPrimary情報は絶対に隠さない

プログレッシブディスクロージャーの基本は、「主要タスク（Primary）は露出させ、例外タスク（Secondary）を段階化する」ことです。
大多数のユーザーが利用する検索窓、主要アクションボタン、基本的な入力項目をアコーディオンやモーダルの奥に隠してはなりません。

自分自身も過去のレビューで、「画面をスッキリさせたい」という理由から、配送先住所の入力フォーム全体をアコーディオンの中に隠してしまったことがあります。
その結果、ユーザーテストで「どこに入力すればいいのか分からない」と全員が迷ってしまい、Primary情報の不可視化がどれほど致命的かを実感しました。
隠してよいのは、あくまで「知らなくても目的を達成できる高度なオプション」だけに限定します。

ルール②：開示トリガーのラベルは具体的に記述する

ボタンやリンクのテキストが「詳細」「その他」「設定」のように抽象的すぎると、ユーザーはその中に何があるのかを推測できません。
中身が分からないボタンをわざわざクリックしてくれるユーザーはごく少数です。

開示トリガーのラベルには、展開されるコンテンツの内容を具体的に予告する文言を用います。
たとえば、「詳細」ではなく「詳細な通知タイミングを設定する」、「その他」ではなく「配送日時の指定オプションを開く」のように記述します。
何が表示されるのかが事前に予測できるからこそ、ユーザーは目的を持って安心してクリックできます。

ルール③：展開状態から迷わず戻れる「閉じる導線」をセットにする

情報を開示するトリガーを設置したら、それと対になる「折りたたむ」「閉じる」ための導線を必ずセットで設計します。
一度展開したアコーディオンが二度と閉じられなかったり、開いたモーダルの閉じるボタンが見当たらなかったりすると、ユーザーは画面を元に戻せずストレスを抱えます。

アコーディオンであれば再度のクリックで元のコンパクトな状態に戻り、モーダルであれば右上「×」ボタンだけでなく背景オーバーレイのタップやESCキーでも閉じられる可逆性を担保します。
「いつでも初期のクリーンな状態に戻れる」という安心感があるからこそ、ユーザーは自由に画面を探索できます。

4. 次のステップ：あわせて深掘りしたい知見

プログレッシブディスクロージャーをさらに深く実務に応用するためには、関連する認知心理学の基礎理論や、パーツ設計のルールをあわせて押さえておくことが効果的です。
以下の記事でも、画面設計の根拠となる基準を詳しく解説しています。

人間が選択肢に直面したときの意思決定負荷や、情報のチャンキング原則を理論的に学びたい方は、こちらの記事も参考にしてみてください。

UIデザインに効く認知心理学の法則5選｜ヒック・フィッツ・ヤコブの実務応用

UIデザインの意思決定を感覚論から論理的な設計へ変える認知心理学の法則5選（ヒック、フィッツ、ヤコブ、ミラー、フォン・レストルフ）を解説。現場のFigma実務ですぐに使える設計基準を網羅します。

段階的開示をカードコンポーネントの中で展開する際の枠線やシャドウ、余白のバランス感覚を掴みたい方は、以下の記事で具体的な整理基準を確認できます。

カード型UIの設計ルール｜枠線・影・余白の使い分けと情報整理術

カード型UIの設計ルールと情報整理のコツを現役デザイナーが解説。枠線・影・背景色・余白の境界線4パターンの使い分けから、詰め込みすぎを防ぐ視覚階層、クリック領域のアクセシビリティまで具体的に整理します。

レイヤード展開（モーダルやボトムシート）をスマートフォン実務で破綻なく実装したい場合は、以下の使い分けマトリクスが役立ちます。

モーダル・ボトムシートの使い分け基準｜スマホで失敗しないUI選定ルール

スマホUIでモーダル、ボトムシート（ハーフモーダル）、ドロワー、画面遷移のどれを使うべきか迷っていませんか？操作の不可逆性と情報量の2軸で整理したUI選定マトリクスを現役デザイナーが詳しく解説します。

まとめ：段階的な情報開示が使いやすさと多機能性を両立させる

UIデザインにおける「親切さ」とは、持っている情報をすべて一度に差し出すことではありません。
初期表示ではユーザーの目的達成に必要な主要タスクを明快に整え、詳細な設定や補助情報を求めるユーザーにだけ適切なタイミングで次の選択肢を提供する設計が大切です。

画面が情報過多で整理がつかなくなったときは、ぜひ「どの情報を初期に表示し、何を段階的に開示できるか」という視点でレイアウトを見直してみてください。

The post 段階的開示（プログレッシブディスクロージャー）入門｜情報過多を防ぐUI設計 first appeared on デザペディア.

Figmaで画面を設計するとき、ダミーデータが綺麗に入った「理想的な画面」ばかりを作り込んでしまうことはありませんか？
自分も以前は、整ったカードやリストが並ぶ完成状態ばかりを熱心に作っていました。

しかし実際のプロダクトでは、ユーザーが最初に目にするのはデータが1件も入っていない初期画面です。
ここでユーザーが迷ってしまうと、操作を諦めてそのまま離脱してしまう大きな要因になります。

1. なぜ「何もない画面」でユーザーは離脱してしまうのか？

1-1. 理想状態（Ideal State）ばかりを作り込む落とし穴

UIデザインの実務では、どうしても情報が満たされた「理想状態（Ideal State）」から作業を進めがちです。
魅力的なサムネイル画像や整ったテキストを配置したアートボードは、見栄えも良く完成度が高く見えます。

しかし、ユーザーが新しくアプリを使い始めた瞬間は、登録したタスクもブックマークも何ひとつ存在しない状態です。
画面上に何も表示されない初期状態を考慮していないと、開発フェーズで画面が真っ白なままリリースされてしまいます。

自分も以前、ステージング環境の実機を触って初めて「最初は何もない状態だった」と気づき、慌てて追加設計した経験があります。
デザインツール上の見た目だけでなく、データが存在しない初期段階の体験まで設計することが大切です。

1-2. 「データがありません」が引き起こす3つの不安

エンプティステートで最も避けるべきなのは、画面中央に「データがありません」とだけ書かれたテキストを置くことです。
このような素っ気ない表示は、ユーザーにいくつかの心理的負担を与えてしまいます。

第一に、システムの通信障害や不具合が起きたのではないかという誤解を招きます。
第二に、自分が直前の操作を間違えてしまったのではないかという操作への不安を与えてしまいます。
そして第三に、次に何をすれば画面が進むのかが分からず、操作を諦めて離脱してしまいます。

何もない画面は、単なる空白ではなく「ユーザーが次に取るべき操作へ誘導する画面」として設計する必要があります。
画面の状態を体系的に捉える考え方については、こちらの記事でも詳しく整理しています。

モーダル・ボトムシートの使い分け基準｜スマホで失敗しないUI選定ルール

スマホUIでモーダル、ボトムシート（ハーフモーダル）、ドロワー、画面遷移のどれを使うべきか迷っていませんか？操作の不可逆性と情報量の2軸で整理したUI選定マトリクスや、親指操作・キーボード干渉を防ぐ実装の黄金律を現役デザイナーが詳しく解説します。

2. 押さえておきたいエンプティステートの3大パターン

エンプティステートが発生する状況は、大きく3つの基本パターンに分類できます。
それぞれの文脈によってユーザーの心理や求める情報が異なるため、適切なアプローチを選ぶことが重要です。

2-1. パターン1：初回利用時（First Use / Onboarding）

アカウントを作成した直後や、特定の機能を初めて開いたときに表示される初期登録前の状態です。
プロジェクト一覧、作成したドキュメント、お気に入りリストなどが該当します。

このパターンの主な目的は、機能の価値を端的に伝え、ユーザーに「最初の一歩」を踏み出してもらうことです。
単に「項目がありません」と伝えるのではなく、作成すると何ができるのかを説明し、明確な作成ボタンを配置します。

NotionやSlackなどの優れたプロダクトでは、初回画面にテンプレートの選択肢や作成ガイドを表示しています。
何もない初期画面を前にユーザーが迷ってしまわないよう、最初のアクションを後押しする設計が有効です。

2-2. パターン2：タスク完了・消去後（User Cleared / Inbox Zero）

ユーザーがすべての未処理タスクを片付けたときや、通知をすべて確認したときに表示される処理完了の状態です。
メールアプリの「受信トレイ（Inbox Zero）」や、タスク管理ツールの「今日のタスク」などが典型例です。

この状態におけるユーザーの心理は、初回利用時とは異なり「やりきった達成感」や「安堵感」があります。
そのため、エラーや未登録のような表現ではなく、前向きな達成感を伝える演出が適しています。

「すべてのタスクが完了しました」といった前向きな完了メッセージを表示します。
必要に応じて、新しいタスクの追加や、過去の履歴を確認できる控えめな導線を添えておくと親切です。

2-3. パターン3：検索・フィルター結果ゼロ（No Results）

ユーザーがキーワード検索を実行したり、絞り込みフィルターを適用したりした結果、一致するデータが0件（検索結果0件）だった状態です。
ECサイトの商品一覧や、管理画面のデータ検索などで頻繁に発生します。

検索結果ゼロの画面で最も重要なのは、ユーザーを「行き止まり（Dead End）」に追い込まないことです。
「一致する商品はありません」で終わらせてしまうと、ユーザーはその場で探索を終了してしまいます。

検索条件をワンタップで解除できる「フィルターをクリアする」ボタンを用意することが基本です。
さらに、入力キーワードの表記揺れへの対策や、人気の検索キーワード、おすすめ商品を提示すると、離脱を防ぎやすくなります。

2-4. 【重要】混同しやすい「Error State（エラー状態）」との境界線

UI設計の実務において、エンプティステートと最も混同されやすいのが通信障害や権限不足などのエラー状態（Error State）です。
一部の解説ではエラーをエンプティの一種として扱うこともありますが、UI Stackの設計体系において両者は全く異なる状態として明確に区別されます。

エンプティステートは「画面に表示すべきデータが未登録、または合致しない状態」であり、システム自体は正常に動作しています。
一方でエラー状態は「通信の切断や権限不足によって、データの取得・処理そのものが中断された障害」です。

ユーザーの心理も「最初の一歩を踏み出したい」「探索をやり直したい」という能動的な感情から、「何が起きたのか分からない」「不具合ではないか」という不安や戸惑いへと大きく変化します。
そのため、案内すべき画面要素も全く異なります。

エラー画面では前向きな新規作成CTAではなく、客観的な原因の案内と、再読み込み（リトライ）や権限申請などの復旧導線を最優先で配置する必要があります。
「データが存在しないこと」と「データの取得に失敗したこと」を混同せず、別の画面ステートとして切り分けて設計することが重要です。

3. 離脱を防ぐエンプティステート「3つの基本構成要素」

エンプティステートを機能的な画面にするためには、視覚的な階層と情報の整理が必要です。
優れたエンプティ画面は、基本的に以下の3つの要素で構成されています。

3-1. ① 状況を伝える視覚要素（グラフィック・アイコン）

画面の中央上部に配置するイラストやアイコンは、画面の状況を直感的に把握させる役割を持ちます。
ユーザーがパッと見た瞬間に「ここは検索結果の画面だな」「タスクの一覧だな」と文脈を認識させます。

注意したいのは、複雑すぎるグラフィックや過剰に大げさな表現を避けることです。
悲しげな表情のキャラクターや警告を連想させる赤いマークは、ユーザーに失敗感を与えてしまいます。

プロダクトのトンマナに合った、シンプルで清潔感のある2Dグラフィックや淡いトーンのアイコンを採用します。
主役はあくまでユーザーのアクションであるため、視覚要素が主張しすぎないバランスを意識します。

3-2. ② 前向きで明快なテキスト（見出し＋説明文）

視覚要素のすぐ下には、何が起きているかを端的に伝える「見出し（タイトル）」と詳細を補足する「説明文」を配置します。
文字情報を2層に分けることで、ユーザーは素早く要点を理解できます。

見出しは短く、事実を前向きに表現することがポイントです（例:「最初のプロジェクトを作成しましょう」）。
説明文では、なぜその状態なのか、どうすれば解決するのかを1〜2文で具体的に案内します。

「右上のボタン、または下のボタンから追加できます」のように、物理的な操作位置を補足するのも効果的です。
ユーザーが次に取るべき行動を迷わずイメージできるよう、平易な言葉で記述します。

3-3. ③ 次のアクションへ導くCTAボタン（Primary & Secondary導線）

エンプティステートで最も重要な要素が、次の行動へ直接案内するCTAボタンです。
説明文を読んだユーザーが、その場で迷わず操作を実行できるように配置します。

初回利用画面であれば「新規作成」、検索結果ゼロであれば「フィルターをリセット」が主要アクションになります。
ボタンの文言も「OK」や「送信」のような曖昧なものではなく、「最初のタスクを作成」のように具体的に書きます。

必要に応じて、補助的なアクション（例:「テンプレートを見る」）を控えめなSecondaryボタンとして配置します。
操作の優先度を保つためのボタン設計については、こちらのガイドでも詳しく解説しています。

ボタンのUIデザイン設計ガイド｜Primary・Secondary優先度と44pt基準

画面内の視線誘導と主要アクションを迷わせないボタンの優先度設計（Primary/Secondary）や、タップしやすい44pt基準の具体的なルールを解説します。

4. 実務で失敗しないための設計ルールと注意点

エンプティステートを実装するにあたって、現場で起こりがちな落とし穴と対策をまとめます。
画面設計の初期段階からこれらを考慮しておくことで、手戻りのない画面を作ることができます。

4-1. イラストが巨大すぎてCTAが画面外に押し出される問題

PC画面向けにデザインしたエンプティ画面をそのままスマートフォン画面に移植した際、レイアウト崩れが発生しやすいです。
イラストを大きく配置しすぎた結果、肝心のCTAボタンがファーストビューから見切れてしまいます。

スマートフォンなどの縦長画面では、イラストの縦幅をコンパクトに抑えることが必須です。
画面全体の高さに対して、イラスト・見出し・説明文・CTAボタンが1画面に収まるよう余白を計算します。

場合によっては、モバイル端末ではイラストを非表示にし、アイコンとテキスト主体の構成に切り替える判断も有効です。
画面サイズに依存せず、常に最も重要なCTAボタンがユーザーの視界に入る状態を維持します。

4-2. ユーザーを責めるような文言を避ける

テキストを作成する際は、ユーザー側に落ち度があるかのような否定的な言葉遣いを徹底して排除します。
「入力が間違っています」「検索条件が無効です」といった表現は、ユーザーに不快感を与えてしまいます。

常にシステム側の客観的な視点と、前向きな案内を意識することが大切です。
「入力内容をご確認ください」「キーワードのスペルを変えてお試しください」のように、次の操作への助言に言い換えます。

丁寧すぎる堅苦しい敬語よりも、直感的に意味を理解できる簡潔なトーンを心がけます。
表現を少し見直すだけでも、ユーザーの操作ストレスを大幅に軽減できます。

4-3. 迷ったときのエンプティステート設計判定フロー

新しい画面を設計する際、どのエンプティパターンを適用すべきか迷ったときは、以下の手順で整理します。

1. データが空である原因は何か？
   – ユーザーがまだ何も作っていない → パターン1（初回利用）：作成ボタンと価値説明を配置。
   – ユーザー自身がすべて処理し終えた → パターン2（タスク完了）：達成メッセージと次の一手を提示。
   – 絞り込み条件に一致しなかった → パターン3（検索ゼロ）：フィルター解除と検索補助を配置。
   – 通信や権限の問題である → 【対象外】Error State（エラー状態）：データ空画面ではなくエラー画面として再試行導線を配置。

ワイヤーフレーム作成の段階からこれらの状態を仕様として盛り込んでおくことで、エンジニア連携もスムーズになります。
ワイヤーフレームの組み立て手順については、こちらの記事もあわせて参考にしてみてください。

初心者向け！ワイヤーフレームの作り方完全ガイド｜要件整理からFigma手順まで

要件定義から情報設計、Figmaでの具体的なコンポーネント配置まで、手戻りを防ぐワイヤーフレームの制作フローを実践的に整理します。

5. まとめ：初期状態の考慮がプロダクトの離脱を防ぐ

エンプティステートは、単なる「データがないときの予備画面」ではありません。
ユーザーが新しくプロダクトに触れ、次に何をすべきかを迷わず判断するための重要な画面仕様です。

1. 初回利用時：機能の価値を伝え、最初の一歩を踏み出す作成CTAを用意する
2. タスク完了後：達成感を肯定し、次の行動を任意で選べる控えめな導線を添える
3. 検索結果ゼロ：条件クリアボタンや代替キーワードを提示し、行き止まりを回避する

これら3大パターンと「イラスト・テキスト・CTAボタン」の3大要素を押さえ、さらに通信障害などのエラー状態（Error State）と明確に切り分けておくことで、実装時の手戻りを防ぎ、ユーザーのスムーズな継続利用を支援できます。

終わりに

何もない初期状態の設計は、ダミーデータが揃った理想画面のデザインに比べて見落とされがちです。
しかし、仕様策定やワイヤーフレームの段階からエンプティステートを組み込んでおくことで、開発連携が格段にスムーズになり、リリース後の離脱も防ぐことができます。

今回整理した判定フローや画面構成のポイントを、日々のUI設計の実務にぜひ役立ててみてください。

参考リンク

• Nielsen Norman Group: Empty State Interface Design
• Material Design: Empty states guidelines

The post エンプティステートUI設計ガイド｜離脱を防ぐ3パターンと3つの構成要素 first appeared on デザペディア.

UIデザインの現場で「なぜその配置にしたのか」を問われた際、うまく言葉にできず困った経験がある方も多いと思います。
自分自身もデザインを始めたばかりの頃は、「見た目の収まりが良いから」といった感覚的な理由しか返せず、手戻りを繰り返すことがよくありました。

画面の使いやすさは、デザイナー個人のセンスや勘ではなく、人間の脳が情報を処理する認知特性のルールで決まります。
この記事では、実務のUX/UI設計ですぐに役立つ代表的な5つの認知心理学の法則と、デザインレビューでそのまま使える具体的な言語化テクニックを詳しく共有します。

なぜUIデザイナーに「認知心理学」が必要なのか？

ユーザーがWebサイトやアプリを操作するとき、画面上の情報を見つけ、理解し、行動を決定するまでに多くの脳のリソース（認知負荷）を消費しています。
操作に迷ったり戸惑ったりする原因の大半は、レイアウトの美しさではなく、人間の情報処理プロセスに対して不自然な負荷がかかっている点にあります。

認知心理学の法則を設計の土台に据えると、デザインレビューの議論が「個人の好み」から「客観的な使いやすさの検証」へと大きく変わります。
チームのエンジニアやプロダクトマネージャーに対しても、科学的な根拠を持った提案ができるため、無駄な手戻りを防ぎながらスムーズな合意形成を図ることができます。

1. ヒックの法則（Hick’s Law）｜選択肢の増えすぎを防ぎ、意思決定を加速させる

ヒックの法則とは、ユーザーが意思決定を下すまでの時間は、提示された選択肢の数と複雑さに応じて対数関数的に増加するという心理学の基本法則です。
1952年に心理学者のウィリアム・エドマンド・ヒックとレイ・ハイマンによって定式化され、人間工学や情報設計の現場で広く活用されています。

UI設計において選択肢を1つの画面に並べすぎると、ユーザーは何を選べばよいか分からなくなり、行動の停止や画面からの離脱を引き起こします。
たとえば、ドロップダウンメニューの中に数十個の項目が無秩序に並んでいたり、ヘッダーに10個以上のナビゲーションリンクが密集していたりする状態がこれに当たります。

実務での実践：松竹梅の3択設計と段階的開示

SaaSの料金プラン表や機能選択画面では、主要な選択肢を3つ程度（いわゆる松竹梅の構成）に絞り込むことが実務における標準的なアプローチです。
どうしても選択肢が多くなる場合は、最初からすべてを見せるのではなく、段階的開示（Progressive Disclosure）の手法を取り入れます。

初期表示では最も利用頻度の高い主要項目だけを提示し、詳細な設定や高度なオプションはアコーディオンやモーダルで必要なときだけ展開させます。
実際にFigmaで画面を組む際も、初期状態の選択肢を3〜4個に制限するだけで、ユーザーテストでのタスク完了時間が大きく短縮されることを実感します。

選択肢の絞り込みやあえて制約を設けるUX設計のアプローチについては、以下の記事でも詳しく解説しています。
現場での情報整理に迷ったときの指針として、ぜひ参考にしてみてください。

デザインハーネス入門｜AIのUI生成とレビュー停滞を解く4層構造【2026】

無限の選択肢による疲弊を防ぎ、あえて制約を設けることでUXを高めるフレームワークを解説。

2. フィッツの法則（Fitts’s Law）｜移動距離とターゲットサイズで誤操作をゼロにする

フィッツの法則とは、ある目標（ターゲット）に素早く到達して選択するまでの時間は、目標までの距離に比例し、目標の大きさに反比例するという法則です。
1954年に心理学者のポール・フィッツが提唱したもので、マウスカーソルの移動やスマートフォンのタップ操作における基本中の基本となる指標です。

この法則から導き出されるのは、「頻繁に押すボタンは大きく、指やカーソルに近い場所に置くべき」という極めて明快な設計原則です。
逆に、画面の端にある小さな文字リンクや、親指が届きにくい位置にある重要なCTAボタンは、操作時間を無駄に長引かせ、誤タップの原因になります。

実務での実践：親指操作ゾーン（Thumb Zone）と44pt基準

スマートフォンアプリの設計では、片手持ちの親指が自然に届く画面下部エリア（親指操作ゾーン）に主要アクションを配置するのがセオリーです。
購入ボタンや送信ボタンをページ最下部の固定ボトムバーに配置する設計は、まさにフィッツの法則に基づいた移動距離の最小化の実践例と言えます。

また、Appleのヒューマンインターフェイスガイドライン（HIG）が定める「最小タップ可能領域44×44pt」のルールも、フィッツの法則に直結しています。
Figmaでボタンコンポーネントを設計する際は、見た目のアイコンが小さくても、オートレイアウトの余白を含めたヒットエリアを確実に44pt以上確保することが不可欠です。

タップ領域の具体的な数値基準やHIGの設計思想については、以下の記事で体系化しています。
モバイルUIの操作性を引き上げるための基本ルールとして、あわせて確認してみてください。

Apple HIG実務ガイド｜タップ領域44pt・文字11pt基準とiOSの基本原則【2026】

Appleが定める44ptタップ領域や文字サイズの論理的根拠と、iOS実務への落とし込み方を網羅。

3. ヤコブの法則（Jakob’s Law）｜「既視感」を味方につけ、学習コストを最小化する

ヤコブの法則とは、ユーザーは他の無数のWebサイトやアプリで大半の時間を過ごしているため、あなたのサイトもそれらと同じように機能することを期待しているという法則です。
ユーザビリティ研究の第一人者であるヤコブ・ニールセンが2000年に提唱したもので、Web標準やデザインシステムの重要性を端的に表しています。

デザイナーが独自性や斬新さを求めすぎるあまり、一般的な操作ルールを逸脱してしまうと、ユーザーは強いストレスと学習コストを強いられます。
たとえば、ヘッダー左上のロゴをクリックしてもトップに戻らない設計や、右上に置かれるはずの検索バーやカートアイコンがフッターの隅に隠れているような構成です。

実務での実践：メンタルモデルの流用と独自性の住み分け

使いやすいUIを構築する近道は、ユーザーがすでに獲得しているメンタルモデル（頭の中の操作イメージ）をそのまま流用することです。
ECサイトであれば「右上にカート」「画面下部に固定の購入ボタン」、メディアサイトであれば「左上にロゴ」「上部にグローバルナビゲーション」といった配置を素直に踏襲します。

UIデザイナーがクリエイティビティを発揮すべき領域は、操作の基本構造ではなく、ブランドの世界観を伝えるビジュアルや丁寧なインタラクションです。
基本の導線ルールを業界標準にしっかりと揃えることで、ユーザーは使い方に悩むことなく、サービス本来の価値やコンテンツに集中できます。

4. ミラーの法則（Miller’s Law）｜短期記憶の限界「マジックナンバー7」と情報のチャンキング

ミラーの法則とは、平均的な人間が一度に短期記憶（ワーキングメモリ）に保持できる情報の数は、「7加減2（5個から9個）」程度に限られているという心理学の基本法則です。
一般には「マジックナンバー7（マジカルナンバー7±2）」という呼び名でも広く親しまれており、1956年に認知心理学者のジョージ・ミラーが発表した論文に由来します。

近年の認知心理学の研究では、複雑なUI環境においては保持できる数がさらに少ない「4±1個程度」とも言われています。
区切りのない数字の羅列や、整理されていない長大な箇条書きリストは、ユーザーの記憶のキャパシティをあっという間に圧迫してしまいます。

実務での実践：情報のチャンキングとフォームのステップ分割

この記憶の負荷を軽減するための最も強力な手法が、複数の情報を意味のある塊にまとめる「チャンキング（Chunking）」です。
クレジットカード番号を4桁ずつハイフンで区切ったり、電話番号を市外局番ごとに分ける入力フォームの設計は、チャンキングの典型的な応用例です。

また、20項目以上におよぶ会員登録やアンケートフォームを設計する際は、1画面にすべてを詰め込まず、3〜4ステップに分割して案内します。
Figma上でカード型UIをレイアウトする際も、1つのカード内に含める主要情報は3〜4要素以内に抑え、視覚的なグループを明確に分けることが大切です。

実務で注意したいのは、画面上のUIは「記憶」ではなく「視覚認識」できるため、メニュー項目などを機械的に7個以下に制限する必要はない点です。
重要なのは数を無理に減らすことではなく、関連する項目同士を適切なチャンク（塊）に整理して、スキャンしやすい構造を作ることです。

5. フォン・レストルフ効果（孤立効果）｜視覚的コントラストで最重要アクションを際立たせる

フォン・レストルフ効果（別名：孤立効果）とは、複数の似た要素が並んでいるとき、他と異なる視覚的特徴を持つ1つの要素が最も記憶に残り、注目を集めるという効果です。
1933年に精神科医のヘドウィグ・フォン・レストルフによって発見され、CTAボタンの設計や価格表のレイアウトにおいて最も頻繁に活用される理論です。

この効果をUIに応用する際の注意点は、画面内のあらゆる要素を目立たせようとして、有彩色や強いコントラストを多用しすぎないことにあります。
すべてのボタンが同じ鮮やかなブルーで塗られている画面では、強調の効果が相殺され、結果としてユーザーはどこをタップすべきか迷ってしまいます。

実務での実践：Primaryボタンの孤立化と「おすすめ」バッジ

この効果を最大限に活かすためには、画面内で最優先してほしい操作（Primaryアクション）に対してのみ、明確な視覚的差異を与えます。
たとえば、主要な「購入する」「登録する」ボタンだけを鮮やかな塗りのボタンにし、キャンセルや戻るなどの副次的なボタンは枠線（Secondary）やテキストリンク（Tertiary）に抑えます。

また、3つの料金プランが並ぶ比較表において、中央の推奨プランだけカードの枠線を太くし、上部に「人気No.1」といったバッジを付与する手法もフォン・レストルフ効果の実践です。
周囲を均一で控えめなトーンに整えておくことで、際立たせたい1点にユーザーの視線を自然かつ的確に誘導できます。

実務で使える！デザインレビューを突破する「言語化フレーズ」早見表

認知心理学の知識は、実際の画面設計だけでなく、チーム内でのデザインレビューやクライアントへの提案において大きな力を発揮します。
感覚的な指摘を受けた際に、そのまま根拠として使える実践的な言語化フレーズを以下の表に整理しました。

「なんとなく使いにくい」「自分の感覚と違う」といった主観的な指摘に対しても、心理学の法則に基づいた客観的な意図を返すことで、議論を建設的な方向へ進められます。
デザイナー自身が論理的な言葉を持つことは、デザインの品質を守り、チーム全員が納得して開発を進めるための確かな強みになります。

デザインの意図をチームやクライアントに的確に伝え、合意形成をスムーズにするための言語化スキルについては、こちらの記事でも詳しくまとめています。
レビューでの伝え方に課題を感じている方は、あわせて目を通してみてください。

段階的開示（プログレッシブディスクロージャー）入門｜情報過多を防ぐUI設計

UIの情報過多を防ぎ、シンプルさと多機能性を両立させる「プログレッシブディスクロージャー（段階的開示）」を解説。ヤコブ・ニールセン提唱の基本原則から実務の4大展開パターン、隠しすぎを防ぐ境界線ルールまで網羅します。

終わりに

最後までお読みいただき、ありがとうございます！

UIデザインにおいて認知心理学の法則を学ぶことは、表現の幅を狭める制約ではなく、自信を持ってデザインを届けるための論理的な土台になります。
画面の向こう側にいるユーザーの脳や身体の仕組みに寄り添うことで、迷いのない心地よい操作体験を生み出すことができます。

日々の制作の中で配置やサイズに迷ったときは、ぜひ今回紹介した5つの法則を振り返り、実務の設計に役立ててみてください。
これからも、論理的なUIデザインを一緒に楽しんでいきましょう。
それでは、良いデザインライフを！

The post UIデザインに効く認知心理学の法則5選｜ヒック・フィッツ・ヤコブの実務応用 first appeared on デザペディア.

画面を何十枚も一瞬で作れるようになっても、デザイナーが1枚ずつ手作業で目視確認していては、結局そこで作業が止まってしまいます。
そんな「AIが作るUIの品質やルールを、どうやってチームで守っていくか？」という悩みを解く仕組みとして、いまデザイン界隈で注目されているのが「デザインハーネス（Design Harness）」という考え方です。

1. デザインハーネスとは？「AI生成は並列、レビューは直列」の停滞を解く仕組み

デザインハーネスは、プロダクトデザイナーのこぎそ（@kgsi）氏が提唱した設計思想です。
AIエージェントにデザイン作業を任せるときに、その出力がチームのルールやブランドのトンマナから外れないよう、あらかじめ外枠で支えてあげる仕組みのことを言います。

2026年に入ってからはグッドパッチ社が支援ソリューションをスタートするなど、現場への導入が一気に現実味を帯びてきました。
この考え方が生まれた背景には、AIツールを導入したチームがほぼ確実にぶつかる「生成は並列、レビューは直列」というリアルな問題があります。

AIに指示を出すと、数十画面のUIやバリエーションがあっという間に並列で作られますよね。
でも、その画面の余白が合っているか、変な色が混ざっていないかをチェックするデザイナーの目は、画面の数だけ増えるわけではありません。

結局、デザイナーが1画面ずつ手作業で確認することになり、AIが速くなればなるほどレビュー待ちのタスクが山積みになってしまいます。
しかも「チームとして何をもってOKとするか」の基準が曖昧なままだと、レビューする人の好みで判断がブレてしまいがちです。

もともと「ハーネス（馬具）」というのは、力強い馬を人間がコントロールして、安全に目的地へ走らせるための道具です。
エンジニア界隈の「テストハーネス（テストを自動で回すための実行環境）」と同じで、パワフルなAIの出力を一定の枠組みで支える仕組みをイメージするとわかりやすいと思います。

AIに「適当にいい感じの画面を作って」と丸投げするのではなく、あらかじめ決めたルールと検証のレールを通すことで、おかしなデザインが出ないように先回りします。
自分自身も現場でAIツールを使うときは、自由気ままに作らせるより、カチッとした制約を渡した方が手戻りが圧倒的に少ないなと実感しています。

2. デザインハーネスを支える「4層構造モデル」

デザインハーネスは、何か特定の有料ツールを指すわけではありません。
AIの出力をうまくコントロールして、日々のデザイン運用に落とし込むための「4層の設計フレームワーク」として整理されています。

「AIにどんな情報を渡して、どうチェックして、どう改善していくか」という一連の流れを4つの階層に分けたものです。
それぞれのレイヤーが担う役割と具体的な要素をまとめると、以下のようになります。

まず土台となる第1層の「制約」は、AIが使っていい色やフォント、余白のサイズを最初から絞り込んでおく枠組みです。
デザインシステムに定義されていない謎のカラーコード（いわゆる野良カラー）が勝手に作られるのを、入口の段階でシャットアウトします。

続く第2層の「文脈」は、「この画面は誰がどんな状況で使うものか」という背景情報をAIに共有するレイヤーです。
ただ見た目のパーツを並べるだけでなく、前後の画面遷移やユーザーの目的をしっかり渡すことで、的外れなレイアウトが出てくるのを防ぎます。

そして第3層の「検証」では、AIが書き出したコードやFigmaデータに対して、自動テストや静的解析（lint）を走らせます。
「フォントサイズが基準値と合っているか」「コントラスト比が足りているか」といった機械的に白黒つけられる部分は、すべてここで自動判定します。

こうして機械的なチェックをパスした画面だけを、最後の第4層「評価」で人間のデザイナーが確認します。
「操作していて違和感がないか」「体験として気持ちいいか」という定性的な判断に集中し、気づいた改善点はまた第1層や第2層の指示にフィードバックしていきます。

3. Figmaとデザインシステムを「機械可読なハーネス」にする手順

「考え方はわかったけれど、実際の現場では何から手をつければいいの？」と思いますよね。
一番手軽でおすすめなのが、いまあるデザインシステムを「AIが読めるデータ形式」に整えることです。

人間向けに作った分厚いスタイルガイドを、AIエージェントがそのまま解釈できる形へ落とし込んでいきます。
現場ですぐに取り入れやすい3つのステップを見ていきましょう。

1. Figma Variablesでトークンをかっちり決める

最初の一歩は、Figma上のカラーや余白を「デザイントークン」として整理することです。
カラーコードを生でベタ打ちするのではなく、PrimaryやSurfaceといった役割ベースの変数名で管理します。

変数のルールが綺麗に整っていれば、AIに対しても「ボタンの色は --color-button-primary だけを使ってね」とシンプルに指示を出せます。
これだけで、AIが勝手なカラーコードをでっち上げるミスを一気に減らせます。

2. ルールファイル（DESIGN.md）をプロジェクトに置く

CursorやClaude Codeを使ってUIを組むときは、プロジェクトのルートフォルダに DESIGN.md というルールファイルを1枚置いておくのがおすすめです。
フォントサイズのスケールや余白の基本ルール（4px/8pxグリッドなど）を、簡潔なMarkdownでメモ書きしておきます。

AIエージェントはコードを書くときにこのファイルを自動で読み込んでくれるので、毎回プロンプトに細かな指示を書く手間が省けます。
指示文が短くて済む分、入力トークン数の節約になって生成スピードが上がるのも嬉しいポイントです。

配置場所に迷ったら、まずはプロジェクトのルート直下（./DESIGN.md）に置くのが基本ルールです。AIツールが作業開始時に一番認識しやすい場所だからです。
フロントエンドとバックエンドが分かれているリポジトリなら、フロントエンド側（apps/web/DESIGN.md や frontend/DESIGN.md）、またはコンポーネント管理フォルダ（packages/ui/DESIGN.md）に配置するのが実務上の定石です。
さらに、Claude Codeの CLAUDE.md や Cursorの .cursorrules の中に「UIの実装時は DESIGN.md のルールを参照すること」と1行メモを添えておくと、AIが確実にルールを優先して読み込んでくれます。

3. プラグインやテストで機械的に自動チェックする

画面が出来上がってきたら、Figmaプラグイン（Figma Linterなど）を使ってワンクリックでスタイル違反をスキャンします。
未登録のフォントや勝手な余白が使われていれば、その場ですぐにアラートを出して修正できます。

「1pxズレていないか」「スタイルが合っているか」を目を凝らして探す作業は、ツールに任せてしまえばいいんですよね。
機械でできるチェックを自動化するほど、デザイナーは「本当に使いやすいUIになっているか」という本質的な体験設計に時間を使えるようになります。

デザイントークンを破綻させずに運用するVariablesの設計ルールについては、こちらの記事で具体的な命名のコツをまとめています。

Figma Variables（変数）の使い方｜バリアント肥大化を防ぐ2層トークンと命名規則【2026】

FigmaのVariables（変数）を活用し、デザイントークンを破綻させずに管理・運用するための設計ルールと命名規則を解説します。

4. デザイナーの役割の変化：パーツの配置者から「ハーネス設計者」へ

デザインハーネスが浸透してくると、現場のデザイナーに求められる動き方も少しずつ変わっていきます。
これまで時間をかけていた「ボタンやテキストを1px単位で並べる作業」は、AIエージェントにどんどん任せられるようになっていきます。

その代わり、デザイナーの大事な役割になっていくのが、「AIが迷わずにクオリティの高いUIを作り続けられるよう、ハーネス（ルールシステム）を整えてあげること」です。
部屋の壁紙を自分で1枚ずつ貼る作業から、建物全体の設計図を引いて安全基準を決める建築家のような立ち位置にシフトしていく感覚に近いかもしれません。

実務では、特に次のような領域が大切になってくると感じています。

• トークンと変数のルール設計: 画面数が増えても破綻しない、すっきりとした変数構造を組み立てる。
• 品質の合格ラインの言語化: どんな状態ならチームとしてリリースOKなのか、判断ロジックを整理する。
• フィードバックによるルールの更新: AIが間違えた箇所を分析して、DESIGN.mdや指示文を微調整していく。

デザインエンジニアの台頭と、溶け合うデザインとコード

こうした流れの中で、国内外の現場でいま急速に数が増えているのが「デザインエンジニア（Design Engineer）」という職種です。

これまでは「Figmaで画面を作るデザイナー」と「それをコードに落とし込むエンジニア」で分業するのが当たり前でした。
しかし、AIツールがFigmaデータから直接コードを書き、コードからUI画面を一瞬で生成する時代になったことで、デザインと実装の境界線が一気に溶け合っています。

Figma Variablesなどのデザイントークンを理解しつつ、それをDESIGN.mdやコード側のLint・テスト（ハーネス）として落とし込める人材の需要が急増しているんですよね。
自分自身も現場で作業していて、「画面を作る作業そのもの」よりも「Figmaとコードの間でルールが破綻しないよう仕組みを整える役割」がどんどん重要になっているのを強く実感しています。

最初から完璧な仕組みを作る必要はないので、まずは普段よく使う余白やカラーのルール化から気軽に試してみるのがおすすめです。

まとめ：適切な制約が、AIとの共創をスケールさせる

デザインハーネスは、AIの自由を奪って窮屈にするためのルールではありません。
しっかりとした安全帯（制約）があるからこそ、AIは迷わずに素早く画面を作れますし、人間も安心してその出力をレビューできます。

「生成は一瞬、でも確認に追われて疲弊する」という悪循環を抜ける鍵は、レビューを人間の根性で乗り切るのではなく、仕組みで軽くしていくことです。
制約、文脈、検証、評価という4つの層を意識しながら、日々のデザインシステムをAI時代に合わせて少しずつ育てていきましょう。

まずはプロジェクトに小さな DESIGN.md を1枚置いてみる。そんな身近な一歩から、AIとの気持ちいいチームプレイを始めてみてくださいね。

次のステップ：あわせて深掘りしたい知見

デザインハーネスの土台となる「崩れないUI構造」や「OS標準のガイドライン」を把握しておくと、ルール作りの解像度がさらに上がります。
現場の実務ですぐに役立つ記事をピックアップしましたので、ぜひあわせてチェックしてみてください。

オートレイアウトを使った崩れないフレーム設計の手順は、こちらの記事でステップ順に詳しく解説しています。

Figmaオートレイアウト完全ガイド！崩れないネストと余白設計

Figmaのオートレイアウトを駆使し、崩れないネスト構造と整然とした余白設計を実現するための実践的な組み立て手順を解説します。

Appleが定めるOS標準のタップ領域や文字基準については、以下の実務ガイドで数値を整理しています。

Apple HIG実務ガイド｜タップ領域44pt・文字11pt基準とiOSの基本原則【2026】

AppleのHuman Interface Guidelines（HIG）が定めるタップ領域44ptや最小フォント基準など、iOSアプリ設計に必須の実務数値を網羅解説。

The post デザインハーネス入門｜AIのUI生成とレビュー停滞を解く4層構造【2026】 first appeared on デザペディア.