本記事は
【Advent Calendar 2025】
16日目②の記事です。
🌟🎄
16日目①
▶▶ 本記事 ▶▶
17日目
🎅🎁
「このデザイン、ウィンドウ幅が狭くなるとどうなりますか？」
「これはhover（オンマウス）で開きますか？クリックで開きますか？」
「どこをスクロール領域にしますか？ボタンはスクロールさせず固定位置にしますか？」
こんなやりとりがデザイナーと開発者の間では頻繁に行われます。
私はFigmaでデザインを作成するとき、「実装しやすいデザイン」をいつも意識しています。
「実装しやすいデザイン」を作ることで、手戻りを減らすことができ、開発スピードを向上できます。さらには品質の向上にもつながります。
ですが・・・常に完璧なデータを作るというのはなかなか難しいです。
実際開発が始まると、考慮漏れがあったり、予期せぬ開発側からの相談も必ず発生します。
そういったときにうまく開発者とコミュニケーションができないと、
開発しやすさを優先してデザインの質やユーザー体験が落ちてしまったり、
無理なデザインの実装を押し付けて開発コストが必要以上に上がってしまったりします。
UIデザイナーがある程度実装の知識を持ち、エンジニアとコミュニケーションすることで
双方が納得でき、良い品質のプロダクトを生み出せます。
今回は、私が普段から意識している「UIデザイナーとエンジニアのコミュニケーションの具体的なテクニック」を紹介します！
Figmaデータ作成編
1.Figmaに実装者向けのメモを残す
静的なデザインだけでは伝えきれない仕様は、Figma上に直接「実装メモ」として残しましょう。
口頭での説明漏れを防ぎ、エンジニアが迷わず作業を進められます。
Figmaのコメント機能は他のやり取りに埋もれてしまうことがよくあるため、
アノテーションツールを利用するか、付箋パーツのようなものを用意するのがおすすめです。
2.AutoLayoutなどを活用し、実装しやすいFigmaデータを作る
FigmaのAutoLayout機能を活用することで、
cssのFlexboxやpadding、width:100%、min-width、max-widthなどを表現でき、
実装者はデザイナーのレイアウトの意図を正確に読み取ることができます。
AutoLayout機能については過去に以下の記事でも解説していますので、よろしければご確認ください。
Figmaの便利機能「Auto Layout」の使い方！ 利用例を紹介！ - NRIネットコムBlog
その他にも、Component、Variants機能を利用することで、
ボタンのhoverやdisabled、フォームの入力中やエラー時など、考えられるパターンを網羅できます。
「この場合はどうなりますか？」という開発者からの質問を未然に防ぎ、実装の手戻りを減らせます。
AutoLayoutとComponent、Variants機能は積極的に活用しましょう。
3.スクロール範囲がわかるプロトタイプを作成する
「ヘッダーは固定で、コンテンツエリアだけスクロール」
「テーブルは横スクロールで、左側2列は固定」
といった挙動は、言葉では伝わりにくいです。
Figmaのプロトタイプでスクロール領域を分かりやすくしておくと、実装の手戻りを減らすことができます。
また、デザイナー視点としても、操作感を確認してから実装依頼できるので、
実装後になんか違う・・・ということが起こりにくいです。
特にデスクトップアプリケーションなどで、スクロールバーが画面内に複数登場する場合など、複雑な画面であるほど、プロトタイプの作成は有効です。
実装画面レビュー編
4.ブラウザの開発者ツールで原因を特定する
デザインとのズレを見つけたら、Chromeなどの開発者ツールを開いて原因を探るようにしています。
- 「このdivタグに意図しないmarginが当たっている」
- 「widthを固定幅にしてしまっているので横スクロールバーが発生してしまっている」
などを確認した上で、修正指示を出します。
CSSの完全なデバッグ作業はエンジニアに任せるべきですが、デザイナー側で大まかな原因の特定ができるとスムーズに作業が進みます。
5.画面レビューの指示は、具体的にCSSの値で示す
エンジニアが画面を実装したら、必ずデザイナーのレビューをします。
その際、実装レビューで「もう少し余白を広く」といった曖昧な指示はよくありません。
実装側としては値を指定する必要があるため、何を基準とすべきか分からず、迷ってしまいます。
Figmaと差異がある場合は「Figmaの通りにお願いします」で十分伝わりますが、
Figmaデータで伝えられないことは多々あります。
そういったときにCSSの値を伝えることができると、スムーズに意図を伝えることができます。
- 「ここのpaddingを16pxに」
- 「width:100%にして、最小幅を200pxに」
- 「text-overflow:ellipsisを使って、末尾の文字が収まらないときは省略してください」
のように、私は具体的なCSSプロパティと数値でフィードバックするように心がけています。
これはCSSの知識が必要なので結構難しいのですが、個人的にはUIデザイナーが持つべき知識だと思っています。
StorybookなどでComponentを整理している場合は、
- 「Select コンポーネントを使ってください」
- 「size は Large に修正してください」
と伝えることができると完璧です。
6.データが多い時、0件のときを考慮する
データが0件の場合（Empty State）や、文字量が多いときの考慮も重要です。
Figma上でもそういったパターンをなるべく作成するように気をつけていますが、画面レビューのときにブラウザの開発者ツールを使って、文字数を多くしてみる、カードが複数並ぶときはカードを追加してみる、などを試し、レイアウト崩れが発生していないか確認するようにしています。
文字数が非常に長いケースで、改行するのか、末尾で省略するのか、という点は特に注視しています。
7.実装が難しいと言われた時は、一緒に落とし所を探る
エンジニアから「実装が難しい」と相談されたら、なぜ難しいのかを確認し、双方が納得いくラインを探します。
工数がかかる、技術的な問題、パフォーマンスが悪くなる などなど、実装が難しい理由は様々です。
デザインで「実現したかった体験」を伝え、その上で、UIとして「譲れない部分」と「妥協できる部分」を明確にし、一緒に最適な落とし所を探る姿勢が大切です。
上記は1例ですが
エンジニア：
「Tableライブラリの制約で、一覧部分にオリジナルデザインのローディングを出すのは難しいです、すみません。」
「画面全体を暗転させて、ローディングを表示するような形であれば可能なのですが、どうですか？」
デザイナー：
「Tableライブラリの中に出すのが難しいということですよね」
「暗転は、操作を中断する印象になるのでなるべく避けたいな〜と考えています。」
「ライブラリの部分の枠を一瞬非表示にして、その間ローディングを出すのはどうですか？」
「改善案を作成してみました、こちらだと実現可能でしょうか？」
「もし難しければ、画面全体を暗転する案で妥協できます！」
エンジニア：
「ライブラリの部分の枠を非表示にする案であればいけそうです！」
といったやり取りができるといいですね。
まとめ
今回は、UIデザイナーがエンジニアと円滑なコミュニケーションをとるための7つの具体的なテクニックをご紹介しました。
完璧なデザインデータを作ることだけがゴールではありません。
考慮漏れや予期せぬ課題が発生したときに、より良い解決策をデザイナーとエンジニアが一緒に導き出せるかがプロダクトの品質を左右します。
デザイナーが少しだけ実装の世界に足を踏み入れることで、エンジニアとの間に信頼関係が生まれ、コミュニケーションは驚くほどスムーズになります。
この記事が、デザイナーやエンジニアの方に少しでも参考になれば幸いです。
本記事のようなUI/UXのTIPS集をさらに詰め込んだ私の著書、『UIデザインのアイデア帳 アプリ・Web制作の現場で使える 基本＋実践ノウハウ83』が、Amazonなど各書店で好評発売中です。
アプリやWeb制作に使えるTIPSを沢山詰め込んだ一冊となっていますので、さらにUI/UXのヒントを知りたい方はぜひお手にとってみてください！
