「Figmaでは完璧に見えたのに、実装したら崩れた」——デザイナーとエンジニアの間で最も頻繁に起きる摩擦です。ピクセルパーフェクトなモックアップが、実際のブラウザでは微妙にずれている。テキストが長くなるとレイアウトが崩れる。ダークモードに切り替えると色が意図通りにならない。
よくある失敗パターンは「実装を意識せずにデザインする」ことです。固定幅のコンテナ・ハードコードされた余白・フォントの絶対指定・コンポーネントの状態が未定義——これらは「Figmaでは動く」が「コードでは壊れる」設計の典型です。デザイナーが実装の制約を知らず、エンジニアがデザインの意図を理解しないまま実装すると、最終的なUIは誰も意図しない形になります。
デザインと実装の乖離は、品質低下だけでなく、修正コストを膨らませます。「実装してみたら違った」を繰り返すたびに、デザイナーとエンジニアの信頼関係も損なわれます。最初から「実装可能で、変更に強い」設計をすることが、チーム全体の生産性を高めます。
1. 原則の定義
デザインと実装が壊れない設計（Design & Implementation Durability）とは、コンポーネントの状態・余白のトークン化・フォントスケール・レスポンシブ対応・コンテンツの可変性を設計段階から考慮し、実装時に意図通りに再現でき、コンテンツや環境の変化にも崩れない耐久性のあるUIを設計する原則。
本質は「デザインは実装の設計図である」ということです。建築の設計図が「施工できない構造」を描いてはいけないように、UIデザインも「実装できない・維持できない」形で描いてはいけません。デザイナーとエンジニアが同じ「設計言語」（デザイントークン・コンポーネント仕様）を共有することで、デザインと実装の乖離を防ぎます。
2. いつ使うか（適用場面）
特に重要になるケース
- コンポーネント設計時: ボタン・カード・フォームなどの再利用コンポーネントを設計するとき。すべての状態（通常・ホバー・押下・無効・ローディング）を定義する。
- 余白・色・フォントの定義時: ハードコードされた値（
margin: 24px・color: #3B82F6）ではなく、デザイントークン（spacing-6・color-primary）で定義する。 - レスポンシブ設計時: デスクトップのみのモックアップではなく、モバイル・タブレット・デスクトップの各ブレークポイントでのUIを定義する。
- コンテンツが可変な箇所: テキストが1行の場合と3行の場合、画像がある場合とない場合——コンテンツの変動に対してUIが崩れないか確認する。
トレードオフが起きる場面
- 設計の柔軟性と一貫性: トークン化・コンポーネント化を徹底すると、個別の画面での「ちょっとした調整」がしにくくなる。「例外」を作るコストと、一貫性のメリットを比較する。
- 設計速度と品質: すべての状態・ブレークポイントを設計すると時間がかかる。MVP段階では主要な状態のみ設計し、後から補完する戦略も有効。
3. なぜ重要か（設計判断の核）
デザインは「見た目の設計図」ではなく、「実装の仕様書」だ。実装できないデザインは、デザインではない。
設計判断の基準
- 「このデザインは、エンジニアが仕様書なしで実装できるか？」→ できなければ、状態・余白・フォントの定義が不足している。
- 「このUIは、テキストが2倍の長さになっても崩れないか？」→ 崩れるなら、固定幅・固定高さの設計を見直す。
優先順位の考え方
- 1. コンポーネントの状態定義（最優先）: すべての状態が定義されていないコンポーネントは、実装時に「未定義の状態」が発生し、エンジニアが独自判断で実装する。
- 2. デザイントークンの使用: ハードコードされた値をトークンに置き換えることで、テーマ変更・ダークモード対応が容易になる。
- 3. コンテンツの可変性への対応: 実際のデータ（長いテキスト・画像なし・大量アイテム）でUIが崩れないか確認する。
例外条件
- ワンオフのランディングページ・キャンペーンページなど、再利用を前提としない単発のUIでは、トークン化・コンポーネント化の優先度を下げることができる。
4. 具体の設計ルール（チェックリスト）
最低ライン（Must - これ守らないと危険）
これがないと、実装時に必ずデザインと実装が乖離します。
理想ライン（Better - できると強い/プロの品質）
「実装できる」を超えて「変更に強い」状態です。
5. UI例
同じ「カードコンポーネント」でも、耐久性設計の有無でコンテンツの変動への対応は大きく変わります。
改善プロセス
- 固定サイズをやめる:
width: 200px; height: 180pxを削除し、コンテンツに合わせてサイズが変わる設計にする。 line-clampで制御する: テキストが長い場合はline-clamp-2で2行に制限し、省略記号（…）で切る。情報は失われるが、レイアウトは崩れない。- 画像なし状態を設計する: 画像がない場合のフォールバックUIを定義する。真っ白な空白ではなく、プレースホルダーを表示する。
6. 関連リンク
- 関連リファレンス（理論）: 制約 (Constraints), 防衛的デザイン (Defensive Design), フィードバック (Feedback)
- 用語集（定義）: デザインシステム
- 関連するUI原則（横）: ルール化して再利用する (Design System Thinking), 状態と例外を先に設計する (States & Edge Cases), 多言語/i18n 前提のUI (Internationalization UI)
7. まとめ
今日から直せる一手
担当しているサービスの主要なカードコンポーネントに、実際の最長テキストを入れてみてください。レイアウトが崩れるなら、今日中に固定高さを削除してline-clampを追加してください。
チームに共有するなら一言 「デザインは実装の仕様書だ。実装できないデザインは、デザインではない。」
