1. はじめに：デザインデータは完璧。でも、なぜか手が止まる
実装を進めていて「一見、完璧に見えるデザインなのに、手が止まる」──
そんな瞬間は少なくありません。
見た目は整っていても、「この状態のときは？」「クリック後は？」と、仕様の抜けを判断しないと先に進めないケースが現場ではよくあります。
これは、デザインが悪いという話ではなく、Figmaなどの静的デザインでは表現しきれない“状態”や“変化”の情報が不足しているだけのこと。
たとえば、ボタンのアクティブ状態が描かれていない、リストが3つしか想定されていない、入力中やエラー時の画面がない――そんなケースです。
本記事では、フロントエンド実装者の視点から、
「静的なデザインがなぜ実装の手間を増やしてしまうのか」
「どんな補足があると実装がスムーズになるのか」
について、実務での経験を交えて具体的に解説していきます。
2. 実装者が“判断に迷う”デザインの具体例
デザインツール上では綺麗に見えるのに、実装段階になると「どう作ればいい？」と立ち止まる。
そうした場面の多くは、「状態変化」「動的な量」「非理想パターン」が考慮されていないことに起因します。
ここでは、実案件で実際に経験した、代表的な4つのケースを紹介します。
❌ Hover・Active状態の指定がない
よくある状況：ボタンのデザインはあるが、hover時や押下時の見た目が未定義。
実装者の困りごと：hoverやactiveはユーザーの操作に対するフィードバックなので、ないと“無反応”に見えてUXが損なわれる。
勝手に決めることもできず、デザイナー確認で時間が止まるケース。
❌ テキストの長短に対する考慮がない
よくある状況：見出しが1行できれいに収まっているが、実データでは2行・3行になる可能性がある。
実装者の困りごと：行数が増えた時にレイアウトが崩れるかもしれないため、余白や高さ調整が必要になる。
しかも、「1行で切れてもいいのか？」「2行以上OKか？」が不明確なため、判断が止まる。
❌ リストやタブなどの「繰り返しUI」が1パターンしかない
よくある状況：カードが3枚並んでいて美しく見える。が、実際には5枚、6枚になる可能性もあるUI。
実装者の困りごと：カード数が増えたときの折返し・横スクロール・レスポンシブ対応などをどうするか判断が必要。
仕様がないため、見た目と実データのギャップが原因でレイアウトが崩れやすい。
❌ エラーメッセージや入力中状態のUIが設計されていない
よくある状況：フォームが用意されているが、「エラー時」「送信中」「成功時」などの状態がまったく考慮されていない。
実装者の困りごと：これらはユーザー体験のカギとなる部分なのに、仕様がないと判断に困る。
メッセージの出し方やタイミング、レイアウトを一から考え直す必要が出てくる。
こうした状態が“意図されていない”のか、“見落とされている”のかが分からないまま、
確認が必要になり、開発スピードや品質に影響を与えてしまいます。
3. 実装しやすいデザインには“動き”と“変化”の視点がある
実装がスムーズに進むデザインには、共通点があります。
それは、「静止画として整っている」だけでなく、実際に使われるときの状態変化や繰り返しに対する“余白”があるということです。
ここでは、実務で「これは非常に実装しやすかった」と感じたケースをもとに、どんな視点が設計に含まれていたかを紹介します。
✔ 通常・hover・active の切り替えが設計されている
例：ボタンやリンクの3状態（ n）がすべて定義されているデザイン。
効果：ユーザー操作に対して自然なUI挙動が実現しやすく、開発時に余計な確認が不要に。
アニメーションの有無も含めて、意図がはっきりしていると実装の精度が一段上がります。
✔ 長文・短文どちらも想定されている
例：見出しやラベルで、「2行になった場合」「翻訳で文字が長くなった場合」の余白や配置が考慮されている。
効果：レスポンシブ対応や多言語展開が前提になっている現場では非常に助かります。
事前に文字量バリエーションのモックがあると、崩れにくい実装が可能になります。
✔ カードやリストが複数パターンで設計されている
例：カードが「1件のみ」「3件」「6件」といった複数状態でレイアウト検討されている。
効果：実データによる変動に強く、「見た目は揃っているのに、現実には崩れる」問題が起きにくい。
並び方や折返し、スクロールの有無などを前もって意識して設計されていることで、実装者は迷いなく作業に入れます。
こうした配慮があると、実装側で判断を保留することなく、そのまま“意図を汲んだ形”でコードに落とし込むことができます。
4. 静的デザインでも“ここを伝えてもらえると助かる”ポイント
すべての状態をFigma上に描くのは現実的ではない、というのは実装者側も十分理解しています。
ただ、いくつかの“意図”や“使われ方の想定”を伝えてもらえるだけで、実装の精度は大きく変わります。
ここでは、静的デザインであっても補足してもらえると非常に助かる4つの視点をご紹介します。
❓ このパーツは「動的に増える／減る」のか？
カードやリスト、タブなどが「固定3件」なのか、「CMSやAPI連携で動的に変わる」のか。
この違いは、レイアウト設計やCSSの柔軟性に直結します。
→ 例：「最大6件まで増える可能性があります」といった一言があるだけで、設計はまったく変わります。
❓ この状態は「クリック後に何が起きる」想定か？
hoverやクリック後、何かが変化するのか、それとも静的なままか。
たとえば、モーダルが開く？ アコーディオンが展開される？ リンクへ遷移する？
→ 見た目が同じでも“アクション後の結果”が明確であるかどうかで、実装方針が変わる場面が多々あります。
❓ 非理想状態（エラー・読み込み中など）の想定はあるか？
理想的な正常画面だけでなく、以下のような状態はユーザーの印象に大きく関わります。
- フォーム送信中のローディング表示
- 入力ミス時のエラーメッセージ
- 通信エラーや空データ時の画面
→ これらが設計されていないと、実装者側が勝手にUIを決めることになり、トンマナや意図のズレが生じる可能性が高まります。
❓ 「これはダミーです」「実際は〇〇になります」という補足
デザインの中にあるテキストや画像、数値が仮データなのか、実データを想定しているのか。
「このテキストは管理画面で編集可能」「この数値は動的に切り替わる予定」などの一言で、実装側の判断材料になります。
特別なドキュメントや仕様書がなくても構いません。
Figmaのコメントやチャットでの共有でも、ほんの少しの補足が実装工程の精度を劇的に上げてくれます。
5. ディレクターに伝えたい3つの視点
静的なデザインだけでは伝わらない要素があることを、現場の実装者はよく実感しています。
ただ、それはディレクターにとっても「気づきにくい領域」であることも事実。
ここでは、私が実務を通じて「ここを意識してもらえるとプロジェクトがうまく進む」と感じた視点を3つに絞ってご紹介します。
1. 「仕様がないものは、実装者は勝手に判断できない」
見た目に描かれていないことは、“仕様として決まっていない”と解釈されます。
そのまま進めると、誤った実装・思い込みによる動作ズレ・後戻り修正につながるため、
実装者は慎重にならざるを得ません。
→ 意図が曖昧な部分こそ、事前に共有してもらえると非常に助かります。
2. デザインが静的でも、UIは常に“動的な存在”
Webは「状態が変化する」ことが前提のメディアです。
画面幅、文字量、クリック、通信状況…これらすべてがUIを変化させるトリガーになります。
→ 静的デザインはあくまで「スナップショット」であり、変化を前提とした設計・共有があるだけで破綻が防げます。
3. 設計段階で「どう変化するUIか」を共有してもらえると、無駄な修正が減る
「このボタンは状態に応じて表示が変わります」「このリストはデータによって件数が変わります」
そんな一言の共有があるだけで、実装者は“変化に強い設計”を最初から組むことができます。
→ 結果として、後から発生しがちな「修正コスト」や「動作の不一致」が減り、納期や品質も守りやすくなります。
6. まとめ：「見た目の完成度」だけでは、Web画面は完成しない
Figmaや画像で見ると完璧に見えるUIでも、実装に入ると「これはどうなる想定？」と手が止まることが多々あります。
その理由は、状態・動き・繰り返し・エラーといった“動的な側面”が設計から抜け落ちているためです。
一方で、すべての状態をデザインとして描く必要はありません。
要点だけでも補足していただけると、実装者はより柔軟で再現性の高いコードが書けます。
「完成された1枚絵」ではなく、
「変化に耐えうる設計」こそが、UIの質とプロジェクトの完成度を高める土台になります。
次回のVol.7では、「“ただ組むだけ”では通用しない ─ HTML/CSSに設計が必要な本当の理由」をテーマに、
なぜマークアップにも設計視点が欠かせないのか、そして実装者が日々意識している“裏側の設計力”について解説します。
どうぞお楽しみに！
