「PCで綺麗に2行に収まっていたキャッチコピーが、スマホで見ると1文字だけ改行されて崩れてしまい、不格好になってしまった」
「スマホでタップしようとしたら、隣のボタンと近すぎて誤タップしてしまい、毎回イライラする」

デザイナーやコーダーの皆さんなら、レスポンシブ対応の過程でこうしたヒヤッとする瞬間に一度は遭遇したことがあるのではないでしょうか。
画面サイズの異なる多様なデバイスに1つのレイアウトで対応するのは、思っている以上に骨が折れる作業ですよね。

Webデザインにおけるレスポンシブ設計では、あらゆる画面サイズに力技で対応しようと複雑なメディアクエリを重ねるよりも、そもそも「壊れない（破綻しない）シンプルな構造」をあらかじめ仕込んでおくことのほうが、結果的にデザインの品質と保守性を長く保つ秘訣になります。

1. なぜレスポンシブは「崩れやすい」のか？現場で起きる崩れの正体

私たちが日々Webサイトを構築する中で、デバイス間のレイアウト破綻はなぜ起きてしまうのでしょうか。

最も大きな要因は、デスクトップ（PC）用のレイアウトを基準とし、それをメディアクエリ（@media）によって縮小・調整していくという「デスクトップファースト」の考え方にあります。
PC版に配置された複雑な要素や装飾を、スマートフォンの狭い画面に収めるために、不要なものを非表示（display: none）にしたり、無理やり文字や画像を縮小して詰め込むといったアプローチは、コードを複雑化させるだけでなく、特定の画面幅で予期せぬ崩れを引き起こしやすくなります。

現代のWebアクセス、特にBtoC向けのサービスやLP（ランディングページ）、ECサイトにおいては、アクセスの80%以上がスマートフォンから行われています。
こうしたモバイル偏重の環境下では、Googleの「モバイルファーストインデックス（MFI）」への完全移行もあり、スマートフォンでの表示がすべての基準となっています。

モバイルでのユーザー体験（UX）を損なうようなレイアウトの不具合（想定外の横スクロール、タップしにくいほど小さなボタン、画像読み込み時に画面が動く現象など）は、離脱率の上昇を招き、SEO評価にも直接的な悪影響を及ぼします。

したがって、これからのレスポンシブ設計では、あらかじめ要素自体に「自己調整」のルールを持たせ、どのような画面幅になっても崩れにくい頑丈な骨組みを構築することが不可欠です。

2. CSSで防ぐ！レイアウト破綻を回避する4つのコーディング技術

CSSの実装段階で発生しやすいレイアウトのバグは、いくつかのモダンなCSSプロパティや記述ルールを徹底することで、スマートに回避できます。

100vwのスクロールバー罠と width: 100%

画面幅いっぱいに要素を広げたいとき、width: 100vw; と指定することがよくあります。
しかし、WindowsなどのPCブラウザでスクロールバーが表示されている場合、100vw は「スクロールバーを含んだ画面幅」として計算されてしまいます。
その結果、画面幅を超えてしまい、意図しない横スクロールが発生するという問題が起きます。

この現象を根本から防ぐには、width: 100vw; ではなく、親要素の幅を基準とする width: 100%; を使用するのが基本です。
さらに、パディングや枠線の幅によって要素が親要素からはみ出るのを防ぐため、あらかじめすべての要素に box-sizing: border-box; を指定しておくことが、安全なレイアウト計算の前提となります。

画像のアスペクト比崩れとCLS（累積レイアウトシフト）の防止

画像をレスポンシブ対応にする際、max-width: 100%; height: auto; とだけ指定していると、画像が読み込まれる前にブラウザが画像の高さを計算できません。
そのため、画像が読み込まれた瞬間にコンテンツが下へとガクッと押し下げられる現象（CLS: Cumulative Layout Shift）が発生します。
これはユーザーの誤タップを引き起こし、Webパフォーマンス（Core Web Vitals）の測定においても低い評価を受ける要因になります。

これを防ぐためには、HTML側で明示的に width と height 属性を記述するか、CSSの aspect-ratio プロパティを活用して、あらかじめ画像が表示される予定のスペース（アスペクト比）をブラウザに確保させることが重要です。

img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

この数行の記述により、画像が読み込まれる前でも常に正しいスペースが描画エリアとして確保され、不快なコンテンツのズレを完全に防ぐことができます。

動的ビューポート dvh によるアドレスバー問題の解決

スマートフォンでの閲覧時、画面の天地いっぱいにファーストビューを表示させるために height: 100vh; を使うと、iOS SafariやChromeのアドレスバーが伸縮するたびに、ボタンやコンテンツが隠れてタップできなくなってしまう問題が長くエンジニアを悩ませてきました。

この問題は、最新のCSS仕様である動的ビューポート単位 dvh（Dynamic Viewport Height）を使用することでスマートに解決できます。

• svh（Small Viewport Height）：アドレスバーが展開した、最も可視領域が狭い状態を基準とする
• lvh（Large Viewport Height）：アドレスバーが引っ込んだ、最も可視領域が広い状態を基準とする
• dvh（Dynamic Viewport Height）：アドレスバーの伸縮に合わせて、高さを動的に再計算する

全画面のファーストビューを作りたいときは、height: 100dvh; を指定するだけで、どのようなスマホブラウザでも画面にぴったりと収まる堅牢なレイアウトを実現できます。

メディアクエリ要らず！ clamp() 関数での流動的な文字サイズ

ブレイクポイントごとにメディアクエリを書いてフォントサイズを細かく切り替えるアプローチは、中途半端な画面幅（例えばタブレットとスマホの中間など）で文字のバランスが崩れる原因になります。

そこで役立つのが clamp() 関数です。
clamp(最小値, 推奨値, 最大値) の形で値を指定することで、指定した範囲内で文字サイズや余白が画面幅に応じて滑らかに流動変化する（Fluid Typography）ようになります。

p {
  font-size: clamp(1rem, 0.667rem + 1.667vw, 2rem);
}

この指定を行っておけば、画面幅が小さいときは最小の 1rem を保ち、画面が広がるにつれて推奨値に従って段階的に拡大し、一定の画面幅を超えたら最大の 2rem でストップします。
メディアクエリを大量に書く手間が省け、あらゆるビューポート幅に対して文字が美しく収まります。

3. コンテナクエリで実現する「自己完結型」のコンポーネント設計

これまでのレスポンシブ設計は、ブラウザのウィンドウ全体の幅（ビューポート）を基準にレイアウトを制御してきました。
しかし、コンポーネント指向の開発が進む現代においては、「画面幅」ではなく「そのコンポーネントが配置されている親要素の幅」を基準にスタイルを適応させることが求められます。

同じカード型のUIであっても、それが広いメインエリアに置かれるか、あるいは狭いサイドバーに置かれるかによって、自動的に表示形式（縦並びか横並びか）を切り替えられるのが理想です。
これを実現するのが「コンテナクエリ（Container Queries）」です。

実装は、まず親要素となるコンテナに container-type を指定し、ブラウザに対してこの要素の幅を基準にするよう宣言します。

.card-container {
  container-type: inline-size; /* 横幅を基準とする */
}

そして、その子要素であるカードコンポーネントに対して、メディアクエリ（@media）の代わりに @container を使用してスタイルを記述します。

/* 通常は縦並び */
.card {
  display: block;
}

/* 親要素の幅が500px以上になったら自動で横並びに切り替え */
@container (min-width: 500px) {
  .card {
    display: flex;
  }
}

このアプローチにより、コンポーネント自身が「自分が今どれくらい広い場所に置かれているか」を検知し、自ら最適なレイアウトへと自己調整するようになります。
配置する場所ごとの調整コードが不要になるため、レイアウト破綻を未然に防ぐ上で最も洗練された設計手法の1つです。

また、コンテナの幅を基準とする相対単位 cqw（Container Query Width）と、前述の clamp() 関数を組み合わせることで、親要素の広さに完全に連動する自己完結型の流動タイポグラフィ（例: font-size: clamp(1rem, 5cqw, 1.8rem);）を定義することも可能です。

4. キーワードとしての「スマポンシブ」設計とその特徴

複数デバイスのすべてに対してレイアウトを細かく調整するコストを削減し、最もアクセスの多いスマートフォンでのUXを究極に高めるためのアプローチとして、「スマポンシブ（スマホ特化型レスポンシブ）」という設計手法も知っておくべき選択肢です。

スマポンシブとは、スマートフォンの表示幅（概ね320px〜550px程度）を基準にメインコンテンツの最大幅を物理的に固定し、PCなどの大きなディスプレイで閲覧した際にも、スマートフォンと同様の「1カラム（縦長）のレイアウト」を維持する設計手法です。

すべてのサイトに適用できるものではありませんが、キャンペーンLPやSNSからの直接流入を狙うプロモーションサイト、BtoCのアパレル・コスメサイトなど、スマホ利用者が圧倒的多数を占めるプロジェクトにおいては極めて強力な効果を発揮します。

従来のレスポンシブデザインが「画面の広さに応じて複数カラムへとダイナミックに組み替える」のに対し、スマポンシブは「コンテンツ幅そのものを固定値に縛ることで、レイアウトの破綻を物理的に防ぐ」という割り切った考え方をします。

これにより、PC版の複雑な表示ロジックを組む必要がなくなり、開発コストや保守管理の負荷が劇的に下がります。
PC閲覧時に発生する左右の広い余白（マージン）には、ブランドの世界観を表現する背景ビジュアルや、回遊性を高めるための固定メニュー、あるいはモバイルアプリへの誘導QRコードなどを配置することで、無駄のないUI空間として再定義できます。

このスマポンシブ設計をWordPressで手軽に実現するツールとして、株式会社ベクトルが開発したブロックテーマ「SmaVeksive（スマベクシブ）」が挙げられます。
このテーマでは、専用の「Smaponsive」ブロックを用いることで、中央にモバイル基準のメインコンテンツ（SmaVeksive プレーンなど）を固定し、左右にヘッダーやフッターのカラムを自動配置して余白を有効活用できる仕組みを提供しています。

5. Figmaで仕込む！実装段階で崩れないためのデザイン設定

どれほどCSSの実装を工夫しても、その前段であるデザインデータの段階で「固定された絶対値のキャンバス」しか考慮されていなければ、エンジニアとの間で解釈のズレが生じ、実装時にレイアウトが破綻してしまいます。

Figmaでデザインを作成する初期段階から、実際のCSSの挙動（可変ロジック）をシミュレートした制約を設定しておくことが、手戻りのないスムーズな開発連携に繋がります。

オートレイアウト（Auto Layout）の正確な設定

Figmaのオートレイアウト機能は、CSSのFlexboxに非常に近い概念です。
デザインを作成する際は、単に要素をグループ化するのではなく、要素間の関係性（パディング、余白の詰め方、方向）をオートレイアウトで定義します。
特に、リサイズ設定（Resizing）を以下のように正しく使い分けることが重要です。

• Hug (コンテンツを内包): 中に入るテキストや要素の量に合わせて、自動的にフレームが伸縮する設定。多言語対応やテキストの変更があっても枠からはみ出さない構造を作れます（CSSの fit-content や max-content に相当）。
• Fill (コンテナに合わせて拡大): 親フレームの幅が広がった際に、余白を埋めるように自動で広がる設定。レスポンシブな流動要素に指定します（CSSの width: 100% に相当）。
• Fixed (固定): アイコンや特定のボタンなど、画面サイズが変わっても大きさを変えたくない要素に使用します（CSSの固定px指定に相当）。

Wrap（折り返し）とMin/Max-widthの活用

オートレイアウトの方向設定にある「Wrap（折り返し）」を使用し、個々のアイテムに対して「最小幅（Min-width）」と「最大幅（Max-width）」を事前に設定しておきます。
これにより、画面が狭くなったときに「カードが自動で次の行に落ちる挙動」や「一定幅以下には潰れない挙動」をデザインデータ上で検証できるようになります。

あらかじめデザインデータ上で可変シミュレーションを行い、破綻が起きないことを確認しておくことで、エンジニアも「どの画面幅で要素が折り返されるべきか」を迷わずに実装できます。

デザインシステムやVariables（変数）の設計に配慮しつつ、こうした可変の「制約」をデータに持たせることが重要です。

デザイナーとエンジニアが実装時の共通認識を持つためのアプローチについては、以前紹介した記事『エンジニア連携の手戻りをゼロにする。「状態（States）」考慮漏れを防ぐUI Stackと包括チェックリスト』でも、状態定義の面から詳しく触れています。

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

こんにちは！UIデザイナーのYunyです。 「案件を進めていて、デザインデータをエンジニアさんに渡そうとした瞬間に、あ、…

終わりに

レスポンシブ・レイアウトにおいてデバイス間の仕様を破綻させないためのアプローチは、もはや「画面サイズごとに細かくスタイルを継ぎ足していく」という対症療法的な作業ではありません。
モダンな技術とデザインプロセスを上手に組み合わせることで、スマートに解決できます。

今回の記事で紹介した、レスポンシブ設計における重要なポイントは以下の3点です。

• モダンCSSの積極的な活用: 100%幅の設計やdvh、clamp()関数、コンテナクエリなどを活用し、要素自体に自己調整のルールを持たせること。
• Figmaでの上流データの仕込み: オートレイアウトやWrap、Min/Max-widthを活用し、デザインデータ自体に可変の制約を事前に持たせること。
• スマポンシブという戦略的選択: ターゲットユーザーのアクセス傾向に合わせて、スマホ表示幅にコンテンツを固定し、PC表示時は左右の余白（マージン）を有効活用する設計を視野に入れること。

可変性と頑丈さの美しいバランスを探りながら、ぜひ次回のデザインやコーディングで実践してみてくださいね！

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

The post 画面崩れを根本から防ぐ。モダンCSSとFigmaで構築する「絶対に破綻しない」レスポンシブ・レイアウト設計 first appeared on デザペディア.

仕事の中で「なぜこのデザインにしたの？」と聞かれた際、うまく言葉にできずにもどかしい思いをした経験はありませんか？
デザインを言葉にする「言語化力」は多くのデザイナーが直面するハードルであり、私自身もかつては説明ができず本当に悩んでいました。

最近ではAIによるビジュアル自動生成が進化し、対話型の「AI壁打ち」も当たり前になってきています。
しかし、このAIを使いこなすためにも、私たち人間側が「何をどうしたいのか」「なぜこのUIなのか」を明確に言語化するスキルが必要不可欠です。

今回は、感覚的なデザインを論理的に翻訳し、チームの共通言語にするための具体的なアプローチや日常のトレーニング方法についてお話しします。

1. なぜ今、デザイナーに「デザイン言語化力」が必要なのか？

結論からお伝えすると、「なぜそのデザインにしたのかを言葉で説明し、合意を形成する力」の重要性自体は以前から言われていましたが、AIの急速な発達によって、その必要性がこれまで以上に極めて高まっています。

もともとデザインの意図を説明することは大切でしたが、基本的な造形や整ったレイアウトであればAIが瞬時に生成できるようになった現在、表層的な制作作業自体のコモディティ化が加速しています。
特に新卒やジュニア、駆け出しのデザイナーにとって、単に「綺麗なカンプを作れる」だけでは、チームの中で十分な価値を発揮することが難しくなっています。

だからこそ、自身の市場価値を証明し、キャリアの初期段階から成長を加速させるためにも、言語化と合意形成の能力が極めて強く求められるようになっているのです。

デザイナーが単なる「作業のオペレーター」ではなく、プロジェクトの信頼できるパートナーとして機能するためには、自らのデザイン意図を客観的かつ論理的に説明できなければなりません。

非デザイナーのステークホルダー（ビジネスサイドやエンジニアなど）と対話する際、言語化が不足していると、以下のような問題が発生します。

• 判断基準のズレ： デザイナーは「情報設計」や「認知負荷の軽減」の観点で設計しているのに対し、ビジネスサイドは「短期的な数値目標（コンバージョン率など）」、エンジニアは「実装コスト」という全く異なる基準でデザインを見ています。
• 不毛なフィードバックの繰り返し： 共通の判断軸がないため、「なんとなく違う」「もう少しおしゃれに」といった主観的で抽象的なやり取りが続き、度重なる修正作業（手戻り）が発生します。

デザインの言語化とは、単に自分のデザイン案を強引に通すための説得テクニックではありません。
お互いの「判断基準のズレ」を観察し、感覚的なイメージを論理的な言葉へ翻訳することで、チーム全体のキャッチアップコストを下げ、共創の土台を作るためのものなのです。

2. デザイン意図をロジカルに分解する「3つの軸」フレームワーク

感覚的な「なんとなく良さそう」から脱却し、誰にでも伝わる論理的な説明を組み立てるには、デザインの決定プロセスを「目的」「根拠」「オプションとトレードオフ」の3つの軸に分解して整理するのが有効です。

① 目的 (Purpose)

そのデザインが「何を解決するためのものか」、ユーザーのタスクやビジネス上のゴール（KPI）とどのように結びついているかを明確にします。

✕ 悪い例：「画面がすっきり見えるように、ボタンを右上に小さく配置しました」
◯ 良い例：「今回のターゲットユーザーは日常的にアプリを使い込んでいるため、頻繁に行う『保存』アクションへのアクセスを優先し、視線誘導の起点となる右上に配置しました」

② 根拠 (Basis)

なぜその視覚表現やレイアウトを選んだのか、個人の好みではない客観的な裏付けを提示します。
これには、色彩心理学やゲシュタルトの法則（近接、整列など）といったデザインのセオリー、あるいはユーザー行動のデータや既存のメンタルモデル（使い慣れた他社アプリの構造など）が該当します。

✕ 悪い例：「ここの余白はこれくらいがしっくりきました」
◯ 良い例：「近接の法則に基づき、関連性の高い情報群の余白を8pxに狭め、異なるセクション間の余白を32px空けることで、スクロール中も情報の区切りが直感的に伝わるよう設計しています」

③ オプションとトレードオフ (Options & Trade-offs)

デザインの決定は常にトレードオフを伴います。
「他にどのような選択肢を検討し、なぜ最終的にこの案を採用したのか」、あるいは「何を優先して何を捨てたのか」を説明できるようにしておきます。

✕ 悪い例：「このデザインが一番良いと思います」
◯ 良い例：「ナビゲーションについて、下部タブUIとサイドメニューUIの2つを検討しました。項目が3つと少なく、瞬時の切り替えが必要なため、実装工数は若干増えますが、認知負荷の最も低い下部タブUIを採用し、サイドメニュー案は見送りました」

この「3つの軸」は、日々の実務ミーティングはもちろん、新卒やジュニアデザイナーの就職活動におけるポートフォリオ作成や採用面接の場でも強力な武器になります。

「なぜこのデザインにしたのか」をこのフレームワークに沿ってあらかじめ記述しておくことで、採用担当者や面接官に対して「感覚だけで作っているのではなく、目的と根拠を持って設計できるデザイナーである」ことを明確にアピールでき、実務経験が浅くても高い信頼感を与えることができます。

また、このように要素を分解して整理しておくことで、他職種のメンバーも「何を基準に議論すればよいか」が分かりやすくなり、現場での建設的な意見交換がスムーズに行えるようになります。

3. 先進企業の事例から学ぶ「共通言語」としての言語化

多くの成長企業やデザイン組織では、デザイナーの評価基準や社内プロセスにおいて、言語化の重要性が公式に明文化されています。

これらの企業事例が示すように、シニアレベル以上のデザイナーに共通して求められるのは、単なるスタイリング能力ではありません。
「デザインを通じて事業価値をどう最大化するか」を論理的に語り、チームを巻き込んで合意を形成する力なのです。

4. 日常の業務に組み込める「言語化トレーニング」

デザインの言語化力は、生まれ持ったセンスではなく、日々の意識的な取り組みによって後天的に鍛えられる「技術」です。
特にキャリアの浅いうちは、まず「無意識に行っている選択を意識化すること」から始めましょう。

今日からでも実践できる3つのトレーニング方法をご紹介します。

① 「なぜ？」を3回繰り返す自問自答

自分のデザイン作業中に、無意識で行った選択（色、フォント、余白など）に対して、頭の中で「なぜそうしたのか」と自問自答を繰り返します。
ジュニアのうちは、上司や先輩から突っ込まれやすいポイントを先回りして考えるのがコツです。

• 「なぜここのフォントサイズを大きくしたのか？」
  → 「ユーザーが最初に読むべき見出しだからです」
• 「なぜ最初に読ませる必要があるのか？」
  → 「スクロールするかどうかの判断基準になる情報だからです」
• 「なぜこの情報が判断基準になるのか？」
  → 「前ページでの課題感と直結する結論部分だからです」

最低3回繰り返すことで、自分の感性的な判断を客観的なロジックに結びつける回路が鍛えられます。

② 既存デザインの「逆引き」トレース

世の中の優れたUI（日常的に使うアプリなど）を観察し、「制作者はどのような課題を解決するために、なぜこのレイアウトにしたのか」を逆算して仮説を立て、言葉に書き出してみます。

単に見た目を綺麗だと感じるだけでなく、「この配置になっている理由は、スマートフォンの親指が届きやすい範囲を考慮したからではないか」といった仮説を言語化することで、自分自身のデザインの引き出しが拡張されます。

③ AIを用いた高速PDCA壁打ち

近年では、AI（ChatGPTやGeminiなど）を壁打ち相手にした言語化トレーニングも非常に効果的です。

例えば、AIに対して「このような目的のUIデザイン（またはHTML/CSSコード）を作成してほしい」と指示を出します。
AIから出力された結果に対して、「もっと情報の優先度を高めるために余白を広くして」「ターゲットユーザーのメンタルモデルに合わせて配置を変更して」など、具体的な修正指示を重ねていきます。

AIは人間の「なんとなく」という曖昧な表現を理解できません。
そのため、このプロセスそのものが、自らの意図を「具体的かつ客観的な指示」に落とし込むための極めて速いフィードバックループ（PDCA）になります。

5. レビューをチームの共創の場にする工夫

組織としてデザインの品質を担保しながら言語化力を高めるためには、デザインレビュー（DR）の仕組みづくりも重要です。

特に新卒やジュニアデザイナーにとって、先輩やリーダーからのデザインレビューは「自分の作ったものが否定されている」ように感じられ、心理的ハードルが非常に高くなりがちです。
しかし、レビューは決して個人の能力を測る試験ではなく、チームでより良いプロダクトを作るための「共創の場」です。

そこで、レビューの心理的ハードルを下げ、活発な合意形成とジュニアの成長を促すために、以下のような工夫が有効です。

• 「見た目」から議論に入らないルールの徹底： レビューの冒頭では、いきなり完成したデザインデータを見せるのではなく、必ずデザイナー自身が最初に「案件の背景」「解決したい課題（目的）」「今回検証したいポイント」を言葉で説明するルールを徹底します。これにより、「好みの問題」に終始するのを防げます。
• 「2割共有」とオンデマンドな壁打ちの推奨： デザインが8割〜10割完成した段階でレビューに出すと、大きな手戻りが発生した際のダメージ（心理的・工数的）が計り知れません。新卒やジュニアこそ、ワイヤーフレームや初期のアイデア段階（2〜3割の進捗）で、「なぜこの方向性で考えているか」を気軽に言葉で先輩と壁打ちし、早めに軌道修正を図る仕組みを推奨します。
• ラジオ感覚でのオープンな聴講： レビューの場を当事者以外にもオンラインで解放し、他のメンバーが「ラジオ感覚」で聴講できるようにします。他のデザイナーがどのように自分の意図を言語化し、フィードバックを受け取っているかを聞くだけでも、ジュニアデザイナーにとっては非常に学びの多い、生きた教科書になります。

デザインレビューの場を「意図を説明し、他者の視点を取り入れてより良くする対話の場」として再定義することが、新卒やジュニアデザイナーの急速な成長とプロダクトの品質向上を両立させる近道です。

あわせて読みたい：デザインの裏側にある「意図」と「協働」

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

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

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

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

こんにちは！UIデザイナーのYunyです。 デザインデータを作り終えてエンジニアさんに渡した後、「あれ、ここの余白ちょっ…

終わりに

AIがビジュアルを瞬時に作れる時代だからこそ、人間心理に基づき「なぜそのデザインにしたのか」を言葉にする価値がかつてないほど高まっています。
最後に、今回の記事で押さえておきたいポイントをまとめました。

• 目的・根拠・トレードオフの3軸でデザイン決定のプロセスを分解する
• エンジニアやPdMなど、相手の職能の判断基準（物差し）に合わせて言葉を翻訳する
• 日常の中で「なぜ？」を繰り返す自問自答や、AIを壁打ち相手にした練習を取り入れる
• ジュニアデザイナーこそ、デザイン初期段階の「2割共有」で気軽に壁打ちする習慣を作る

最初から完璧な説明を目指す必要はありません。
まずは日々の無意識な選択に対して「なぜ？」と1回問いかけてみることから、少しずつ言語化の引き出しを増やしていきましょう。

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

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

The post 「なんとなく良い」を卒業する。デザインの意図を論理的に翻訳する「言語化力」の鍛え方 first appeared on デザペディア.

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

ボタンのホバーや無効化（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 デザペディア.

最近、FigmaのMCP連携や音声入力などを使い、AIと「対話」しながら作業を進めることが増えました。客観的なフィードバックをくれる「相棒」がそばにいると、一人で抱え込んで作るよりも、格段に視野が広がるのを感じています。

この「外部の視点を入れて、一緒にプロダクトを良くしていく」という心地よい感覚は、チームで行う「デザインレビュー」の本質そのものです。

しかし、人間同士のレビューとなると、どうしても「ダメ出しされるのではないか」「自分のセンスを否定されているのではないか」と身構えてしまうこともありますよね。

せっかく時間をかけて作ったデザインだからこそ、そこへの指摘を自分自身への攻撃のように感じてしまう。そんなレビューへの苦手意識をスッキリと解消し、プロダクトの品質を高めるための強力なプロセスへと昇華させる「受審者の心構え」と、議論をリードする高度実践的なフレームワークを見ていきましょう。

1. なぜデザインレビューは「恐怖の場」になりやすいのか？

デザインレビューで指摘を受けると、胸がキュッと痛くなったり、反論したくなったりすることがありますよね。これはデザイナーとしての能力が低いからではなく、人間の脳の自然な反応です。

ものづくりに関わる私たちは、知らず知らずのうちに「自分 ＝ 制作物（デザイン）」という同一視をしてしまいがちです。自分が時間をかけて考え抜いたデザインだからこそ、そこへの指摘を「あなた自身のスキルやセンスが足りない」という人格否定として脳が誤って翻訳してしまうのです。

この心理的な仕組みを理解し、「デザインへの指摘」と「自分自身への評価」を切り離して捉え直すことが、最初の心構えになります。

そもそも、デザインレビューの本来の目的は何でしょうか。それは、デザイナーの優劣を競うことではなく、「プロダクトの問題発見コストを最小化するための防波堤」となることです。

プロダクト開発において、デザイン段階で問題を見つけるのと、エンジニアによるコーディングが完了した後に見つけるのでは、修正にかかる時間やコストに大きな差が生まれます。IBM Systems Sciences Instituteの調査などでも、設計（デザイン）段階で不具合を解決するのに比べて、実装（コーディング）段階では約6倍、さらにリリース後の運用段階では最大100倍の修正コストがかかると報告されています。早い段階で多様なメンバーの視点を取り入れ、デザインレビューという「防波堤」で問題を早期に特定することは、プロジェクト全体のコストと時間を守るための賢い防衛策なのです。

下記記事でも紹介したように、デザインの使いやすさには明確な論理が存在します。レビューで指摘されるのは、あなたのセンスの良し悪しではなく、「ユーザーの認知負荷をさらに下げるための改善点」です。他者の目を「自分のデザインをより強くするための心強い味方」として歓迎することから始めてみましょう。

世界標準に学ぶ「伝わるデザイン」の基礎体力と、日常を整えるヒント

こんにちは！UIデザイナーのYunyです。 日常の中で、ふと入ったお店のメニューで「どれにしようかな」と迷った経験はあり…

2. 受審を自らコントロールする高度実践フレームワーク「30-60-90ルール」

レビューでよくある失敗が、「ボタンの色や細かな文言ばかりに議論が集中し、根本的な画面遷移や情報設計の議論ができなかった」というケースです。このような事態を防ぐために、受審者であるデザイナー自身が議論の範囲をコントロールするフレームワークが「30-60-90ルール」です。

これは、デザインの進捗度（30%、60%、90%）に応じて、求めるフィードバックと、あえて求めない（制限する）フィードバックをあらかじめ定義し、参加者に宣言する手法です。

30%レビュー（方向性・コンセプトの確認）

デザインの初期段階で実施するレビューです。画面はまだ手書きのワイヤーフレームや、主要なユーザーフローが記述された簡易的な資料のレベルです。

• 求めるフィードバック：解決しようとしている課題定義の整合性、大まかな情報階層、ユーザーフローの妥当性。
• 求めないこと：フォントの種類、配色、ボタンの角丸のサイズ、具体的なテキスト表現などのビジュアル詳細。

60%レビュー（構造とUX設計の確認）

骨組みが固まり、グレースケール（白黒）でワイヤーフレームや遷移図を構築した段階でのレビューです。

• 求めるフィードバック：詳細な情報設計、主要な画面遷移のつながり、一般的なエラー状態（ローディングやデータ未登録時など）の網羅性。
• 求めないこと：写真の選定、微細なインタラクションアニメーション、ビジュアルとしての美しさの評価。

90%レビュー（ビジュアルと実装詳細の確認）

ビジュアルデザインがほぼ完成し、リリースに近い状態のプロトタイプでのレビューです。

• 求めるフィードバック：ピクセル単位のレイアウト調整、最終的なコピーライト（文言）のチェック、エッジケース（テキストが極端に長い場合の表示崩れなど）の確認。

レビューの冒頭で、「今回は60%段階のレビューですので、情報設計と画面遷移に絞ってご意見をください。色やフォントは仮のものなので、ビジュアルへの指摘は次回お願いできればと思います」と受審者から宣言します。これだけで、レビューアーは「今どこに目を向ければよいか」が明確になり、議論の脱線や散らかりを防ぐことができます。

特に60%〜90%の段階では、実装上の制約を考慮することが不可欠です。下記記事でも解説している通り、早い段階からエンジニアをレビューに巻き込み、実装可能性について対話しておくことで、後工程の大幅な手戻りを劇的に減らすことができます。

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

こんにちは！UIデザイナーのYunyです。 デザインデータを作り終えてエンジニアさんに渡した後、「あれ、ここの余白ちょっ…

3. レビューを円滑に進める「受審者の3つの作法」

レビューの場でデザイナー自身がとるべき具体的なコミュニケーションの作法を3つに整理しました。これらを意識するだけで、レビューの場は「指摘会」から「建設的なディスカッション」へと変化します。

① デザインの意思決定の背景（背景の文脈）を伝える

単に「この画面を作りました」と見せるのではなく、なぜその配置やスタイルにしたのか、意思決定の背景（コンテキスト）を説明します。
「過去のユーザー調査で〇〇という課題があったため、ここでは認知負荷を下げるためにAのパターンを採用しました」といった論理的な根拠を添えましょう。

下記記事でも解説しているように、数字や認知心理学的な根拠を背景に持つことで、レビューアーとの間で「感覚的な好き嫌い」の平行線になるのを防ぎ、共通の判断軸を持って対話を行うことができます。

美しさの根拠を語れるか。数字を武器にするデザイナーの静かなる提案力

こんにちは！ UIデザイナーのYunyです。 日々の業務のなかで、「このデザイン、なぜこっちが良いと思ったの？」と聞かれ…

② 反論ではなく「まずは理解と感謝」を示す

「ここは〇〇だからこうしたんです」と、指摘に対して即座に自己防衛の反論をしたくなる気持ちはよく分かります。しかし、そこをグッと抑えて、まずは「ご指摘ありがとうございます。確かにそこは初見のユーザーにとって分かりにくいかもしれませんね」と、相手の指摘を一度そのまま受け止めましょう。
その上で、「その懸念を解消するために、実はBという選択肢も検討したのですが…」と対話を広げます。このワンクッションがあるだけで、場全体の空気は非常に柔らかくなります。

③ 次のアクションと役割をその場でクリアにする

レビュー中に出たすべての指摘をそのままデザインに反映する必要はありません。レビューの最後、または議事録の確認時に、以下の3つのフォルダに指摘を分類して提示しましょう。

• 対応する項目：次のステップまでにデザインを修正するもの。
• 持ち帰る項目：他のデータや仕様を確認した上で、後日判断するもの。
• 見送る項目：今回のリリーススコープ外とする、または別の理由で現状維持とするもの。

受審者がこの分類を主導することで、「すべての指摘に振り回されてデザインが破綻する」のを防ぎ、デザイナーとしての設計責任を守ることができます。

まとめ：レビューは「チームで勝利する」ための最高のツール

デザインレビューを受審することは、決して「自分の作品を採点される試練」ではありません。むしろ、自分一人では気づけなかったユーザーの迷いや実装上の懸念を、チームメンバーが寄ってたかって一緒に解決してくれる「最高の協力プレイ」です。

「30-60-90ルール」を用いて議論を自らコントロールし、対話の作法を意識することで、レビュー会議はデザインの質を飛躍的に高めるパワフルな時間へと進化します。

チーム全員を「自分のデザインの共同制作者」として味方につけ、より良いプロダクトを届けていきましょう！

終わりに

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

デザインレビューに対して漠然とした苦手意識や怖さを抱いていた方も、フレームワークを活用して「見せる範囲」を制限することで、少し気持ちが軽くなるのではないでしょうか。

私自身もレビューを受けるときは毎回緊張しますが、今回紹介したアプローチを意識するようになってからは、メンバーの意見を前向きに取り入れられるようになりました。

皆さんの次のデザインレビューが、より楽しく、建設的な時間になることを願っています。

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

The post 「デザインレビューが怖い」を卒業する。受審の心構えとフィードバックを自ら操る実践フレームワーク first appeared on デザペディア.

最近、Figmaの新しいAI機能を実務で使う機会が増えてきました。たとえば「この画面に合うカードUIを作って」とプロンプトに入力すると、あっという間にレイアウトが自動的に組み上がっていきます。そのスピードと便利さに「すごい！」とワクワクする一方で、ふと手が止まる瞬間があります。。。

「もしこのAIが私の意図を読み違えて、今まで整理していたコンポーネントの構造やレイヤーを勝手に壊してしまったらどうしよう？」

画面の向こう側のシステムが自分で考えて動く。この「便利だけど少し怖い、まだ完全に任せきれない」という実感は、きっと私だけではないはずです。

今回は、ただの受動的なツールから「自律する相棒」へとシステムが変わる中で、2026年の最重要デザイントレンドとして注目を集める「Agentic UX（自律型UX）」の設計思想について考えてみます。

UIからAX（Agentic Experience）へ。ツールから「自律する相棒」への進化

これまでのデジタルプロダクトにおけるUIは、基本的に「人が操作して結果を待つ」受動的なものでした。
ユーザーがボタンをクリックし、システムが画面を返す。その繰り返しです。システムはあくまで便利な「道具」であり、使い方を決めて主導権を握っているのは常に人間でした。

しかし、Agentic UXでは、システムが自ら状況を判断し、計画を立てて、複数のステップを自律的に実行する「共同作業者」へと進化します。
これは単に「プロンプトに対してテキストを返す」だけのチャットボットとは異なります。
システムがユーザーの目的に合わせて、バックグラウンドで複数のアプリケーションやデータを横断しながら、自律的に作業をこなしてくれる状態です。

この移行にともない、デザインの考え方も従来のUXから「AX（Agentic Experience：エージェント体験）」へと拡張されつつあります。
人がツールをどう使うかではなく、「人の代わりに動くシステムと、どうやって安全な関係を築くか」が問われているのです。

AIエージェントは非常に強力ですが、もしユーザーの意図を誤解したまま重要なデータを削除してしまえば、システムに対する信頼は一瞬で崩れてしまいます。
だからこそ、効率化と安全性のバランスをとるインターフェース設計が必要になります。

会話型UI（CUI）の限界と、適切な情報開示の設計

「AIに何かを頼むなら、チャットUIがあれば十分ではないか」と思うかもしれません。
たしかに、簡単な検索や質問であればチャット形式で事足ります。しかし、複雑なデザインデータの編集や、いくつもの手順を踏む業務をテキストだけでやり取りするのは、かえってストレスになります。

たとえば「売上データをグラフにして」と頼んだのに、テキストで数字の羅列が返ってきたら使い物になりませんよね。
ここで重要になるのが、内部の複雑な処理プロセスと、ユーザーに見せるべき出力結果を明確に分ける（パススルー）という考え方です。

AIエージェントの内部では、非常に高度な推論やいくつもの処理が同時に行われています。
しかし、ユーザーはそのすべての処理過程を見たいわけではありません。

ユーザーが求めているのは、最終的な結果や、途中で確認が必要な重要なポイントだけです。
システムが裏側で何をしているかをすべて画面に表示すると情報量が多すぎて混乱を招きますし、かといって何も表示しないと「本当に正しく動いているのか？」と不安になります。

内部の複雑な動きは適切に隠しつつ、要所要所で「この内容で進めていいですか？」と必要なタイミングでだけ情報を渡すUI設計が、これからのAgentic UXには求められています。

信頼を少しずつ育てる。Agentic Interface Ladder（自律性の4段階）

いきなり「今日からこのAIにすべてを任せてください」と言われても、すぐに100%信頼できる人はいません。信頼関係は、人間の仕事のパートナーと同じように、小さな実績の積み重ねで少しずつ築かれます。

このプロセスを分かりやすく整理したのが、「Agentic Interface Ladder（自律性の4段階）」という考え方です。

1. 提案（Suggest）：AIが解決策を提示するが、最終的な決定と実行は人間が行う。この段階では「なぜその提案をしたのか」という根拠の透明性が重要です。
2. 検証・承認（Verify）：AIが行動計画や下書きを作成し、実行前に人間に確認を求める。結果のプレビューを見せ、人間が手直しできる余地を残します。
3. 委任（Delegate）：日常的で後戻り可能なタスクをAIが自動実行し、事後報告だけを行う。ここでは強固な取り消し機能が必要になります。
4. 自動化（Automate）：ワークフロー全体をAIが処理し、リスクが高い例外的な場合のみ人間に助けを求める。

最初は「提案」から始まり、少しずつAIが実力を証明していくことで、ユーザーは「この作業は任せても大丈夫だな」と判断し、次の段階へと進みます。
特に、システムが自分の権限を超えたり、判断に迷ったりした時に、勝手に進めず「人間の判断を仰ぐ（エスカレーションする）」仕組みをあらかじめ設計しておくことが、失敗できないタスクでは非常に大切です。

安心感を生み出す3つの実践的デザインパターン

では、こうした信頼を画面上でどう表現すればいいのでしょうか。実務で取り入れやすい3つの具体的なデザインパターンを紹介します。

Intent Preview（意図の事前確認）

AIが不可逆な（元に戻せない）行動を起こす前に、「これからこういう作業をします」と分かりやすい表現で宣言させる仕組みです。APIや専門用語の羅列ではなく、人間の言葉で「このプロジェクトのデータをアーカイブします」と伝えることで、ユーザーは予想外のトラブルを防ぐことができます。画面上で「変更前」と「変更後」のプレビューを視覚的に比較できると、さらに安心感が高まります。

Autonomy Dial（自律性のダイヤル）

ユーザー自身が、AIにどこまで自由に動いてもらうかをコントロールできる機能です。すべてを自動で進めるモードと、ステップごとに確認するモードをユーザーが選べるようにすることで、「AIに主導権を奪われた」という感覚を減らすことができます。たとえば設定画面で、タスクの重要度に合わせて「常に確認する」「事後報告のみ」といった権限レベルをユーザーがいつでも切り替えられるようにします。

Action Audit & Undo（監査と取り消し）

「いつでも元に戻せる」という機能は、最大の安心材料です。AIが自律的に実行した作業履歴を後からタイムラインで一覧確認でき、ワンクリックで取り消し（Undo）ができる強固な安全網を用意することで、ユーザーは心理的な余裕を持ってシステムを使うことができます。

また、こうした新しいデザインパターンを取り入れる際も、基本がおろそかになってはいけません。
「UI/UXデザインのこれからのスタンダードとは？」といった過去記事でも紹介しているように、「なぜそのデザインが使いやすいのか」という根本的なアクセシビリティや認知特性への配慮を土台にすることで、ユーザーは戸惑うことなくAIの恩恵を受け取ることができます。

UI/UXデザインのこれからのスタンダードとは？AI時代に求められる「使いやすさ」4つの法則

こんにちは！UIデザイナーのYunyです。 この記事はこんな方に向けて書いています デザインに関心があり、日常のアプリや…

まとめ：これからのデザイナーに求められる「信頼設計」という役割

AIエージェントが普及し、画面のレイアウトやコンポーネントの調整といった作業の多くが自動化されていく未来は、もうそこまで来ています。
しかし、だからといってデザイナーの仕事が不要になるわけではありません。

むしろ、「どこまでAIに任せて、どこから人間が判断するか」という境界線を引く作業は、データ処理だけでは解決できない人間固有の役割です。
ユーザーがシステムに対してどのような不安を抱き、どうすれば安心して共同作業ができるのか。そこには深い共感力と、倫理的な判断が求められます。

明日からの実務でも、ただ画面を綺麗に整えるだけでなく、「ユーザーがこのシステムをどうやって信頼するか」という新しい視点を意識してみてください。2026年以降のデザイントレンドにおいて、それこそが代わりのきかないデザイナーの強みになるはずです。

終わりに

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

テクノロジーがどれほど進化し、AIがシステムを自律的に動かせるようになっても、デザインの根底にあるのは「使う人への思いやりと信頼関係」です。
明日以降、デジタルツールに触れたとき、その裏側にある配慮や「パススルー」の工夫に、少しだけ目を向けてみてもらえると嬉しいです。

これからも、心地よいデザインの探求を一緒に楽しんでいきましょう。
それでは、良いデザインライフを！

The post 「何でもやってくれるAI」が少し怖くない理由。2026年デザイントレンド『Agentic UX』が描く境界線 first appeared on デザペディア.

突然ですが、AIの進化によって「綺麗なUIの画面」を作るだけなら、誰もが簡単にできる時代になりました。
だからこそ、これからのWebデザインは「静的な見た目の美しさ」だけで他と差をつけるのが難しくなっています。

そこで今、世界中のデザイナーが注目しているのが「インタラクション（触り心地）」を通じた体験の拡張（エモーショナルな心地よさ）です。
なかでも、皆さんが毎日何千回と動かしている「カーソル」の存在を主役へと引き上げ、デジタル空間に物理的な手触りをもたらすトレンドが起きています。

かつては単なる画面上の「座標を示す矢印」に過ぎなかったカーソルですが、現在はWeb体験をリッチで没入感のあるものにするための鍵へと進化しています。今回は、最新のWebデザイントレンドとして世界中で注目を集めている「Cursor-Led Design（カーソル・レッド・デザイン）」という概念について、なぜ私たちがその動きに心地よさを感じるのか、等身大のデザイナー視点で見ていきましょう。

1. Cursor-Led Designを構成する4つの主要なインタラクション

実際のWebデザインにおいて、カーソルはどのように進化しているのでしょうか。Awwwardsなどの世界的アワードで評価されるサイトを観察すると、カーソルは主に4つのパターンで「生きた」反応を見せてくれます。

実際の導入事例・参考ギャラリー

• Awwwards Elements（「Mouse Interactions」などで絞り込み）
  世界的なWebデザインアワード「Awwwards」の公式エレメント集です。上記で紹介したような、最先端の心地よい挙動を実際にブラウザ上で多数体験できます。

ただの装飾ではなく、まるで画面の向こう側に「質感や重さ」があるように錯覚させるからこそ、私たちはこれほど心地よく感じるのだと思います。

2. なぜ今、カーソル主導の体験が求められるのか

情報があふれる現代において、ユーザーは単に「情報を読む」だけではなく、「体験に参加する」ことを求めています。

Cursor-Led Designの最大の価値は、平坦なディスプレイ越しであっても、ユーザーの手の動きにシステム側が「反応してくれている」という安心感と驚きを提供できる点にあります。マウスの動くスピードに合わせて軌跡が変化したり、ホバーした瞬間に隠れていた画像が波紋のように現れたりする演出は、ユーザーを自然とワクワクさせてくれます。

裏側を支える技術の進化

この心地よさは、決して偶然生まれたものではありません。例えばマグネティック効果の背後では、GSAP（GreenSock Animation Platform）などの技術が使われ、要素の中心点との距離をリアルタイムに計算しています。
かつてはマウスの動き（mousemove）に合わせてアニメーションさせると画面がカクついてしまうのが悩みでしたが、現在はブラウザの描画サイクルに同期させる技術（requestAnimationFrameなど）が標準化され、スマートフォンアプリのような滑らかさをWebブラウザ上で実現できるようになりました。

ブランドの世界観を伝える上で、カーソルはユーザーとサイトを直接つなぐ「最も身近な接点」になっているのです。

3. 没入感と「目印」のジレンマ（アクセシビリティへの配慮）

しかし、Cursor-Led Designを取り入れる上で絶対に忘れてはいけないのが、アクセシビリティとのバランスです。やりすぎたデザインは、ユーザーを迷わせる単なるノイズになりかねません。

実際、スウェーデンのアクセシビリティ財団をはじめとする海外のUX専門家たちは、行き過ぎたカーソル表現を「UXの犯罪（UX crimes）」と呼び、以下のようなユニークな名前をつけて警鐘を鳴らしています。（※私が勝手に名付けたわけではありませんよ！）

• The Blob Monster（巨大なスライム）： 画面を覆い尽くすほどの巨大な図形が追従するデザイン。視覚的なインパクトはありますが、背後のテキストや本来クリックすべき場所を物理的に隠してしまいます。
• The Comet Tail（彗星の尾）： アニメーションの残像が遅れてついてきすぎることで、実際のクリック判定ポイント（ホットスポット）がどこにあるのか分かりづらくなる現象です。
• The Shapeshifter（過剰な形態変化）： 意味もなく円や四角、矢印へと予測不可能に変化し続けるカーソルは、ユーザーに認知的負荷をかけ、インターフェースの一貫性を壊してしまいます。

美しいデザインと使いやすさを両立させるためには、「前庭覚障害などを持ち激しいアニメーションを好まないユーザーには、OSの設定を読み取って標準のカーソルを表示する（※CSSの @media (prefers-reduced-motion: reduce) などを活用）」といった、見えない配慮がプロの現場では不可欠になっています。

結局のところ、最高のCursor-Led Designとは、カーソルだけが不自然に目立つのではなく、「気づけば操作が心地よくて、ずっと触っていたくなる」ような裏方（うらかた）に徹したデザインなのかもしれません。

まとめ：明日からのPC作業が、少しだけ愛おしくなる

Cursor-Led Design（カーソル・レッド・デザイン）は、平らなディスプレイに「手触り」を足してくれる、とても面白いアプローチですよね。

次にPCでWebサイトを見るときは、ぜひカーソルの動きにも注目してみてください。毎日の何気ない操作が、ちょっと楽しくなるかもしれません！

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

The post Cursor-Led Design（カーソル・レッド・デザイン）とは？AI時代の「綺麗なUI」を一歩超えるWebインタラクションの最前線 first appeared on デザペディア.

最近、MCP（Model Context Protocol）サーバーを導入して、FigmaとAIエージェントの連携を触り始めました。
デザインデータとコードが目の前で同期していく様子を見るのは、新しい道具を手に入れたときのような純粋なワクワク感があります！

ただ、こうした新しい機能や便利な仕組みを試すときって、同時に「覚えることが多そうだな」「せっかく導入しても、管理が追いつかずに散らかって破綻してしまうのではないか」という不安もつきまといますよね。

実はFigmaのVariables機能も、同じような心理的ハードルから導入を一歩踏み出せずにいる方が多いのではないでしょうか。

「Variablesを構築しようとコレクションを開いたものの、何から作ればいいか分からず15分で閉じてしまった」「変数が増えすぎて適用するときに迷い、最後には数値を直接入力してしまって罪悪感を覚える」といった、デザイナーの現場ならではの挫折や悩みもよく耳にします。

今回は、そんなVariablesへの心理的ハードルを下げ、最初から完璧を目指さずに「これならできそう」と思えるスモールスタートの設計と運用の基本ルールをお話しします。

1. なぜFigmaのVariablesは「ハードルが高そう」に見えるのか？

FigmaにVariables（変数）機能が搭載されてから、デザインシステム構築の現場では大きな変化が起きています。これまでStyles（スタイル）だけでは難しかった「モード切り替え（ライトモードとダークモードなど）」や「画面サイズに応じた数値の動的な変更」が、Figmaのネイティブ機能として実現できるようになりました。

それにもかかわらず、多くのデザイナーや開発チームが導入に二の足を踏んでしまうのには、いくつかの理由があります。

• 「Stylesとの使い分けや移行コストが分からない」
  すでにStylesでカラーや文字を管理しているため、Variablesに移行するメリットや、それぞれの役割分担が整理しきれていないケースです。
• 「3層構造（Primitive, Semantic, Component）という概念が難解」
  デザイントークンの設計手法としてよく語られる「3層構造」が複雑に見え、最初からそこまで厳密に設計しなければならないのかと圧倒されてしまいます。
• 「変数が増えすぎて管理しきれなくなるのが怖い」
  変数を作成していくうちに名前空間がゴチャゴチャになり、検索性が低下したり、デザイナーの選択ミスが増えたりする運用への不安です。

実は、Variablesは「大規模で完璧なデザインシステム」を作るためだけのものではありません。最初は少人数や小さなプロジェクトから、不要な設定を削ぎ落として「整理整頓の箱」を作る感覚で始めていけば、決して難しくはありません。

2. 【一歩目】StylesとVariablesの「境界線（使い分け）」をスッキリ整理する

導入にあたって最初に行うべきは、StylesとVariablesの役割分担をシンプルに整理することです。ここが曖昧なままだと、デザインデータを操作する際に迷いが生じてしまいます。

使い分けの判断基準は、そのデータ構造が「単一値」か「複合値」かという点にあります。

Variables（単一値）で管理するもの

Variablesは、カラーのHex値、スペーシングや角丸の数値、特定のテキスト文言（文字列）など、それ以上分解できない「単一のデータ値」を保持します。

最大の特徴は、Mode（モード）機能によって、Light/Darkテーマのように状況に応じた値を保持できる点です。

• 管理対象: ソリッドカラー（不透明度含む単一色）、スペーシング（余白の数値）、角丸（Border Radiusの数値）、コンポーネントの表示切り替え（真偽値）など。

Styles（複合値）で管理するもの

Stylesは、複数のプロパティが組み合わさった「パッケージ」です。

• 管理対象: タイポグラフィ（フォントファミリー、サイズ、ウェイト、行間、文字間隔のセット）、グラデーション（複数の色と位置の組み合わせ）、複雑なエフェクト（ドロップシャドウやブラーの重ね掛け）など。

「カラーはVariablesで一元管理し、タイポグラフィはStylesで管理する」という基本ルールにするだけで、迷いは一気に解消されます。

特にタイポグラフィに関しては、フォントサイズや行間を個別にVariablesで適用しようとすると、デザイナーが毎回テキストレイヤーに対して複数の変数を選択することになり、作業ミスや認知負荷が増大してしまいます。

そこで、Text Stylesという「器」を従来通り提供しつつ、そのスタイル内のフォントサイズや行間の設定値に対してのみ、背後でVariables（数値変数）を割り当てるという「ハイブリッドな連携方法」が最も実用的です。

3. 【設計】破綻を防ぐ「シンプルな階層構造」の作り方

デザインシステムやトークン設計の文脈では、よく「プリミティブ（Primitive）」「セマンティック（Semantic）」「コンポーネント（Component）」の3層構造が推奨されます。

しかし、これから導入する段階でこれらすべてを一度に構築しようとするのは、ハードルが高すぎます。最初は、最も重要な「2つの階層」だけを作り、エイリアス（参照）で繋ぐスモールスタートをおすすめします。

Tier 1：生の値の箱（Primitiveトークン）

すべての具体的な値を定義する階層です。ブランド名やコンポーネント名、画面上の用途は含めず、純粋な色の名前や数値として定義します。

• 命名例: color/blue/600
• 値の実装: #2563EB
• 注意点: この生の値は、次のセマンティック変数の「参照先」としてのみ使用し、実際のUIコンポーネントに直接適用してはいけません。直接適用すると、ダークモードなどのテーマ切り替えが機能しなくなります。

Tier 2：役割の箱（Semanticトークン）

「その値をどこで、何の目的で使用するのか」というデザイン上のルールを定義する階層です。デザイナーがUI作成時に直接選択するのは、このセマンティックトークンです。

• 命名例: color/surface/brand
• 値の実装: color/blue/600（Primitiveを参照するエイリアス）

カラー以外のスペーシングや角丸といった数値データについても、同様の考え方で整理できます。

以前公開した記事「Material Design 3入門：UIデザインの「感覚」を「ロジック」に変える」でも詳しく触れたように、システムの中に「役割」という抽象的な階層を一枚挟むことで、デザインの変更や多言語展開に対する柔軟性が格段に高まります。

Material Design 3入門：UIデザインの「感覚」を「ロジック」に変える

こんにちは！ UIデザイナーとして日々画面と向き合っていると、ふと自分の決定に自信が持てなくなる瞬間はありませんか？ 「…

なお、コンポーネント専用の「Tier 3（Componentトークン）」については、最初は作る必要はありません。ボタンや入力フォームの背景色を個別に変えたくなったときに、初めてセマンティック変数を参照する形で追加すれば十分です。

4. 【運用のコツ】デザイナーを迷わせない「ガバナンス」設定

Variablesを作った後に起こりがちな問題が、「変数リストが膨大すぎて、設定したいプロパティに合う変数がどれか分からなくなる」という混乱です。

これを防ぐために、Figmaが用意している「ガバナンス機能」を初期設定の段階で活用しましょう。

スコープ（Scope）設定で不要な変数を非表示にする

スコープ機能は、変数を「どのプロパティパネルに表示させるか」を制限できる設定です。

例えば、角丸の数値変数は「Corner radius」のみにスコープを設定し、余白の数値変数は「Auto layout」のみに設定します。

これにより、デザイナーが角丸を設定しようと選択画面を開いたときには、パディングやフォントサイズなどの無関係な変数が自動的にフィルタリングされ、必要な変数だけがスッキリと表示されます。選択の手間が省け、人為的な入力ミスも未然に防ぐことができます。

「非公開（Hide from publishing）」で生の色を選択肢から隠す

デザイナーがUIを構築する際、Primitiveトークン（生の色）を直接選べないように制限をかけます。

Figmaでは、コレクション名やグループ名の先頭に _ （アンダースコア）または . （ドット）を付けるだけで、そのグループ全体をライブラリのパブリッシュ（公開）対象から一括して除外できます。

これにより、他のファイルからライブラリを使うデザイナーのカラー選択画面には、目的が明確なSemanticトークン（例: color/surface/brand）だけが表示され、間違って生の色（例: color/blue/600）を選択してしまう事故を防ぐことができます。

こうしたデザインシステムにおける「選択肢の制限」がもたらす効果については、「デザインハーネスとは？無数の選択に疲れた日々を軽くする「適度な制約」の知見」という記事でも、チーム内の認知負荷を下げるための制約デザインとして詳しく紹介しています。

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

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

5. 【発展】開発実装（Handoff）や自動化・AI連携も視野に入れよう

Variablesの設計が整うと、その恩恵はデザイン作業の効率化だけにとどまらず、開発チームへのハンドオフ（引き渡し）の自動化や、AIを活用した新しいプロダクト開発（AI駆動開発）の基盤としても大きな強みを発揮します。

• コードフレンドリーな命名規則
  Figma上の変数名は、そのままプログラムの変数（CSS Variablesなど）として出力されることを考慮し、大文字やスペースを避け、スラッシュ / で階層化した小文字・ケバブケース（ハイフン繋ぎ）で記述します（例: color/surface/brand）。
• Code syntaxの登録
  FigmaのDev Mode（開発モード）に搭載されている「Code syntax」を利用し、Figmaの変数名と、実際のコードベースでのCSS変数名（例: var(--eds-color-surface-brand)）を紐づけておきます。これにより、エンジニアが開発画面でインスペクトした際、脳内翻訳することなく、コードをそのままコピー＆ペーストして使用できます。
• W3C規格と自動化パイプライン
  W3Cの「Design Tokens Community Group（DTCG）」標準に準拠した形式で変数を管理することで、FigmaからJSON形式で書き出したトークンデータを、エンジニアリング側のCSSやSwiftUI、Androidの各コードへCI/CDを通じて完全自動で変換・同期する仕組み（Style Dictionaryの活用など）を導入しやすくなります。
• AI駆動開発における構造化データの価値
  近年、コーディングAIエージェントを用いて画面を実装する手法が広がっています。FigmaのVariablesによってデザイン上の意思決定がJSONデータとして構造化されていれば、AIエージェントはその意味（コンテキスト）を正確に読み取り、「ここは単なるグレーではなく、背景の役割を持っている」と解釈した上で、非常に正確でメンテナンスしやすい実装コードを自動生成してくれます。

完璧な自動化パイプラインを最初から構築する必要はありませんが、Variablesを正しく設計しておくことは、将来的にチーム全体が圧倒的な開発スピードを手に入れるための、最初の大切な一歩になります。

まとめ：最初はスモールスタートでOK

Figma Variablesは、一見すると設定項目が多くて難解な機能に見えるかもしれません。しかし、その本質は「デザインと開発の意思決定を一貫したルールで整理整頓するための道具」です。

破綻を防ぎ、スムーズな運用を始めるためのステップをおさらいしましょう。

1. カラーはVariables、タイポグラフィはStylesという使い分けから始める
2. 生の値（Primitive）と役割（Semantic）のシンプルな2層からスタートする
3. スコープ設定と非公開設定（_アンダースコア）でデザイナーの選択肢を適切に絞り込む
4. スラッシュ / を用いたコードフレンドリーな命名を徹底する

最初から完璧なシステムを求めず、まずはプロジェクトのメインカラー数色や、よく使うスペーシングから少しずつ変数化してみてください。小さな整理整頓の積み重ねが、いずれチーム全体を支える堅牢なデザインシステムへと成長していくはずです。

終わりに

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

FigmaのVariables機能は、単なるデザインツールのアップデートではなく、デザインとエンジニアリングの境界線をゆるやかに繋ぎ、ものづくりの進め方を面白く変えてくれる可能性を秘めています。

最初は「ちょっと色をいくつか変数にしてみよう」くらいの軽い気持ちから、まずは一歩を踏み出してみませんか？

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

The post もう怖くない！Figma Variables（変数）のハードルを下げて破綻させないための設計ガイド first appeared on デザペディア.

最近、打鍵感にこだわって少し高めのメカニカルキーボードを新調しました。キーを「カチャッ」と押し込むときの、あの指に返ってくる反発と心地よい音。用もないのに、つい無駄にタイピングしてしまうほど気に入っています。

物理的なスイッチを押す気持ちよさって、理屈じゃなく本能的に惹かれるものがありますよね。

最近ではスマートフォンの画面でも、こうした「触る気持ちよさ」を持ったUIを見かけるようになりました。
たとえば、語学アプリの『Duolingo』を使ったことがある方は、ボタンを押したときに「ぷにっ」と沈み込むような独特の弾力を感じたことがあるかもしれません。

あの操作感は、画面の動きだけでなくスマートフォンの細かな振動機能（ハプティクス）とも連動していて、本当に柔らかい物理ボタンを押しているような錯覚を生み出していますよね。

Squishy UI（スクイッシーUI）とは？
画面上の要素にあえて物理的な「ぷにぷに感（質量と弾力）」を持たせるデザイン手法のことで、2026年現在、新たなトレンドになりつつあります。

本記事では、この新しいデザイン手法がなぜ私たちに心地よさを与えるのか、その仕組みや法則を解説していきます！

1. 2026年のデザイントレンド「Squishy UI」とは？ 効率化された画面に足された手触り

今のアプリやウェブサイトは、フラットデザインがすっかり定着し、無駄が削ぎ落とされて本当に使いやすくなりましたよね。

その洗練された使いやすさをベースにしつつ、さらに「触る楽しさ」をプラスしようとするのが、触覚的マキシマリズム（Tactile Maximalism）と呼ばれるアプローチです。
これは、画面の中の図形が、単なる平坦な色面ではなく、ゼリーや粘土のような「体積」を持っているかのように振る舞うデザインのことです。

• これまでのデザイン：効率的で整理されており使いやすい反面、物理的な手ざわりはない。
• 新しい潮流：ユーザーの操作に合わせて、画面上の要素が物理的にへこんだり、跳ね返ったりする「生きた」反応を返す。

あわせて読みたい
効率化されすぎた「完璧なUI」の反動から生まれている2026年のトレンドについては、以下の記事でも解説しています。

【2026年 デザイントレンド】完璧なUIに疲れたら。「Future Medieval（未来の中世）」を取り入れた新しいWebデザイン

こんにちは！UIデザイナーのYunyです。 「最近、Webサイトのメインビジュアルや特集バナーをデザインしていると、レイ…

2. なぜSquishy UIは「触って気持ちいい」のか？ 感情を動かすUI/UXデザイン

Yunyの視点：Squishy UIのボタンを触っていると、子供の頃にお気に入りのおもちゃのボタンを何度もカチカチと押したときの、あの素朴な安心感に似ているなと感じます。

なぜ私たちは、画面がぷにぷにと動くことに心地よさを感じるのでしょうか。
そこには、はっきりとした心理学的な理由があります。

本能的な安心感

私たちがボタンを押したとき、それが物理的に「へこみ、跳ね返る」という反応を返してくれると、脳は「自分の操作が正しく受け付けられた」という強い確証を得ます。
これがデジタル特有のストレスを和らげ、安心感に繋がるのです。

親しみやすさを生む形状（数値の根拠）

Squishy UIでは、20px〜40pxという非常に大きな角丸（要素の角の丸み）がよく使われます。
このぽってりとした丸みが、どこかホッとする親しみやすさを生んでいるんです。

3. Squishy UIはどう作る？ 心地よさを生み出すアニメーションとCSSの法則

あのように柔らかく動くボタンも、実はCSSやアニメーション設定での数値計算によって作られています。
「なんとなく柔らかい」のではなく、そこには心地よさを生むための明確なルールが存在するのです。

体積を保存する法則

画面上のボタンが指で押し潰されるとき、「サイズのピクセル値と角丸のピクセル値の合計を一定に保つ」という計算が行われています。
これにより、ボタンがただ小さくなるのではなく、本物のゴムのように横に少し広がりながら押し潰される「リアルな物理法則の錯覚」が生まれます。

「完璧なバネ」のスイートスポット

アニメーションを設定する際、バネの強さを決める剛性（Stiffness）を400、揺れの収まり具合を決める減衰（Damping）を15といった数値に設定するのが、ひとつのスイートスポットとされています。
これにより、無駄に揺れすぎず、指に吸い付くような完璧な弾力感が表現できるのです。

あわせて読みたい
UIから「質量」や「手ざわり」を感じさせる実装アプローチに興味がある方は、こちらの記事も参考になります。

画面から質量を感じる日。Apple HIGの深層「メンタルモデルと流体UI」を実装する

こんにちは！UIデザイナーのYunyです。 仕事でiOSアプリのUIデザインやWebの画面設計をしている時、「機能はちゃ…

4. Squishy UIをデザインに取り入れる際の注意点・アクセシビリティ

触って楽しいSquishy UIですが、どんな場面にでも使っていいわけではありません。
適材適所の見極めが重要になってきます。

適している場面

毎日の習慣をサポートするウェルネスアプリや、学習ツールなどに最適です。
ユーザーの不安を取り除き、「もっと触りたい」という前向きな気持ちを引き出します。

避けるべき場面

逆に、金融機関のアプリや業務用システムなど、大量の情報を素早く処理する場面には不向きです。
UIがぽってりしすぎていると、「自分のデータが真剣に扱われていない」という不信感を与えてしまう危険があります。

また、柔らかさを表現するために淡い影などを多用するため、文字と背景のコントラスト比（推奨値は4.5:1）を満たしにくくなる点にも注意が必要です。
見た目の楽しさとアクセシビリティのバランスを取ることが、プロのデザイナーの腕の見せ所ですね！

まとめ：Squishy UIがもたらす次世代のデジタル体験

今回ご紹介した内容を振り返ると――

• Squishy UIは、単なる見た目の流行ではなく「触る楽しさ」の実用的なアプローチ
• 物理的な「へこみ」や「バネ感」が、ユーザーに本能的な安心感を与える
• 心地よさの裏には、CSSやアニメーションの緻密な数値ルールが存在する
• 美しさと同時に、情報を取り扱う信頼感やアクセシビリティへの配慮が必要

この4点に集約されます。

Squishy UIは、効率化が進んで単調になりがちなアプリに、確かな「手ざわり」を取り戻してくれます。

明日、スマートフォンを触るとき。
お気に入りのアプリのボタンが、どんな風に指を押し返してくるか、少しだけ意識してみてください。

普段使っているアプリの動きに少し注目してみるだけで、毎日のスマホ操作がちょっと楽しくなるかもしれませんね！

さらに深掘りしたい方へ（参考リンク）

実際にSquishy UIを採用しているサイトをご紹介します。ぜひ、お手元のスマートフォンなどで触って、その「心地よさ」を体験してみてくださいね！

• Duolingo（デュオリンゴ）
  学習アプリの代表格です。ボタンを押した際の立体的な沈み込みや、バネのような反発がSquishy UIの最も分かりやすい例と言えます。
• Family（ファミリー）
  暗号資産ウォレットのアプリです。前述の通り、金融関連など信頼性が求められるサービスには不向きとされがちですが、あえてSquishy UIを振り切って採用することで「親しみやすさ」を演出し、競合優位性を生み出している好例です。UI全体が非常に柔らかく、タップやスワイプに対する触覚的な反応（バウンスやスクイーズ）が徹底されており、触っているだけで楽しくなるデザインに仕上がっています。

終わりに

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

UIデザインの世界は、見た目だけでなく「触り心地」まで工夫されるようになってきて、ますます面白くなっていますね。
今回の記事が、皆さんの日々のデザインワークのヒントになれば嬉しいです。

これからも、素敵なデザインを見つけたらどんどんシェアしていきますね。
それでは、また次回の記事でお会いしましょう！

The post 触って気持ちいいUIの正体。2026年デザイントレンド「Squishy UI（スクイッシーUI）」とは？ first appeared on デザペディア.

「最近、Webサイトのメインビジュアルや特集バナーをデザインしていると、レイアウトや文字組みが綺麗に整えば整うほど、逆に『どこかで見たような、無難で味気ないグラフィック』になってしまうことに悩むことがありました。」
AIが画像を簡単に生成する2026年の今、私たちデザイナーだけでなくユーザー自身も「完璧さ」に対して、少しノイズのある「手触り」を求めるようになっているのを感じます。

最先端のWebデザインの世界でも、これと似た現象が起きています。
それが、2026年のUI/Webデザイントレンドとして海外を中心に注目を集めている「Future Medieval（未来の中世：フューチャー・メディエヴァル）」です。

本記事では、この少しダークで重厚なトレンドの魅力と、実務での取り入れ方を解説します。

1. 2026年のデザイントレンドに「Future Medieval」が浮上した理由

2026年現在、デザインの世界では極端なミニマリズムからの脱却が始まっています。
海外のデザインコミュニティやPinterestなどでも、「ヴィンテージ・マキシマリズム」や「中世コア」といった、古い時代の重厚感を求める声が急増しているのを感じます。

なぜ私たちは今、わざわざ中世の美学に惹かれるのでしょうか。

人間は、予測可能で均質なパターンよりも、少しのノイズや「時間の経過」を感じるものに無意識に安心感を覚えることがあります。

重厚で歴史的なデザインを見ると、なんだかホッとするのはそのためかもしれません。

2. Future Medieval（フューチャー・メディエヴァル）を形作る3つのデザイン要素

では、具体的にどのようなデザインが「未来の中世」を作っているのでしょうか。
大きく3つの要素に分解できます。

このトレンド特有の、赤黒のデュオトーンやクロームの甲冑、重厚なゴシック体が入り混じった実際のグラフィックは、こちらのPinterest画像を見るとイメージしやすいはずです。

出典：Pinterest

出典：Pinterest

出典：Pinterest

① 歴史と精度のハイブリッド（タイポグラフィの対比）

読みにくく重厚なゴシック体（ブラックレター）の見出しに、読みやすくて現代的なサンセリフ体の本文を意図的に組み合わせる手法です。
この「古さと新しさのギャップ」が、画面の目を引くアクセントになります。
実務の観点から言うと、本文までクセの強いフォントにしてしまうと可読性が落ちてUIとして機能しなくなるため、あくまで「大きな見出し」や「背景の装飾」に留めるのが、デザインを破綻させないリアルなコツです。

② アナログの質感と未来の輝き（テクスチャの重ね合わせ）

インクの滲み、羊皮紙の粗さ、あるいはリソグラフ印刷やハーフトーンといったアナログでざらついたノイズを強めに敷き詰め、その上にクローム（金属質の甲冑など）やネオンの光といった未来的なハイライトを重ね合わせます。

ピクセル単位で作られた完璧なデジタルデータに、あえて「古いポスターのような印刷の劣化」を加える。これによって、ガラスの画面越しにもザラッとした触覚や、パンクでアグレッシブな生々しさが生まれるのが面白いところです！

③ 整然としたレイアウトの骨格（シンメトリーな構造）

表面のテクスチャがどれほどカオスであっても、配置自体は左右対称（シンメトリー）で幾何学的に整えられています。
この厳格なルールがあるからこそ、情報の見やすさと荘厳な雰囲気が両立できているのです。

私自身、最近のプロジェクトで「UIは整っているけれど、少し冷たい印象を受ける」と感じたことがありました。
そこで、この「Future Medieval」の考え方をほんの少しだけ取り入れ、背景にわずかなノイズ（ざらつき）を加え、見出しのフォントに少しクラシックな要素を混ぜてみたのです。すると、それだけで画面が一気に垢抜け、親しみやすさが生まれました。
トレンドを丸ごと真似しなくても、こうした「ノイズ」のエッセンスを少し取り入れるだけで、デザインの質感が大きく変わります

3. UI/Webデザインへの応用：デジタル空間に「重厚感」を実装する

この「Future Medieval」の考え方は、実際のWebデザインやUIにおいて、トレンドをそのまま「丸ごと」真似するのではなく、ブランドの個性を際立たせるためのエッセンスとして活用されることが多くなっています。

• ゲームでの世界観を活かすための活用
  例えば、ダークファンタジー系ブロックチェーンゲーム『SERAPH: In the Darkness』の公式サイトでは、ベースとなるUI自体は非常に未来的でスッキリしていますが、そこに中世のアイテムや重厚なグラフィックを「アクセント」として自然に同居させています。UIの羅列に、こうした中世の「神秘的な意味」を部分的に乗せることで、ユーザーを引き込む独自の世界観を作っています。
• 日常的なプロダクトにおける「個性」としての活用
  ゲームの世界にとどまらず、ブランドの「強烈な個性」を出すための手法としても使われています。例えば、米国の飲料水ブランド『Liquid Death』は、ただの「日常的な水」でありながら、重厚なブラックレターフォントやダークな世界観をUIの一部に大胆に取り入れることで、他社にはない個性を放っています。また、ラグジュアリーブランド『Chrome Hearts』のサイトに見られるような、モダンなレイアウトの中に重厚なゴシック様式とクローム（銀色）の質感を部分的に融合させるデザイン手法は、ライフスタイルの領域でも確固たる支持を得ています。

4. まとめ：2026年のデザイントレンド「Future Medieval」を取り入れるヒント

AIで完璧なグラフィックが簡単に作れる今だからこそ、あえてデジタル画面に「あたたかみ」や「親しみやすさ」を持たせるアプローチが求められています。

すべてのデザインをこのトレンドに合わせる必要はありませんが、今回ご紹介した「アナログなノイズ」や「タイポグラフィの対比」といったエッセンスを少しだけ自分の引き出しに持っておくと、のっぺりとしたデザインから抜け出す良いスパイスになるはずです！

こちらの記事もおすすめです！
「綺麗すぎる画面」からの脱却についてもっと知りたい方は、こちらの記事もおすすめです！

Dial-Up Delightとは？洗練されすぎた画面に疲れたZ世代が選ぶ、2026年のWebデザイン

こんにちは！UIデザイナーのYunyです。 最近、最新スマホのカメラを使わず、あえて画質の粗い「オールドコンデジ」で写真…

無機質な画面に散りばめられた、私だけの小さな余白。2026年「トリンケット・デザイン（Trinket Design）」がもたらす新しい心地よさ

こんにちは！Yunyです。 「部屋をすっきりさせよう」と家具だけを置いたものの、なんだかよそよそしくて落ち着かない。結局…

ぜひ、日々のデザイン業務のヒントとして参考にしてみてくださいね！

これからも、心地よいデザイン作りを一緒に楽しんでいきましょう。
それでは、良いデザインライフを！

The post 【2026年 デザイントレンド】完璧なUIに疲れたら。「Future Medieval（未来の中世）」を取り入れた新しいWebデザイン 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 デザペディア.