「これ、本当にデザイン通り？」 手戻りを防ぐ、UIデザインと実装のギャップ解消術：＠IT Techブログ PickUp（TISインテックグループ編）

「デザインをもとに実装したはずなのに、デザインと実装の小さな差異が原因で、思わぬ手戻りが発生してしまった……」という経験はありませんか？　本稿ではUIデザイナーが実務で経験した「手戻りにつながりやすいケース」を紹介し、問題点と対策法をわかりやすく解説します。デザイナーとエンジニアの協業で起こる悩みを解消し、スムーズな開発につなげたいすべての方におすすめです。

[Fintan]

注目のテックブログから「現場の知恵」をあなたに――

各社のエンジニアが発信する「テックブログ」。その熱量を＠IT編集部がピックアップ。 生成AI前提時代に向けて環境が激変する中、“隣のエンジニア”は何を感じ、何を考え、どうアクションしているのか？――試行錯誤のプロセス、成功の鍵、変化に立ち向かうマインドなど現場のリアル、ナレッジを凝縮してお届けします。

本稿はTISインテックグループが運営する、開発現場から生まれた技術ノウハウを公開するサイト「Fintan」上で2025年6月19日に掲載した記事を転載するものです。そのため、用字用語の統一ルールなどが、＠ITのものと異なります。ご了承ください。

連載目次

　アプリ開発において、「実装とデザインの乖離で手戻りが発生してしまった」という経験はありませんか？

　本稿では、UIデザイナーとして実務で直面した「デザインデータをもとにエンジニアが実装する際に発生しやすいデザインと実装の差異」についてお話しします。

　作ったデザインをエンジニアに実装してもらう中で、しばしば似た問題に直面することがありました。その内容をこちらでご紹介します。

　これからご紹介するデザインと実装の差異は、知識があれば防ぐことができるものも多くありますので、参考になれば幸いです。

Tips

UIデザイナーとエンジニアの協業では、認識のズレが思わぬ手戻りにつながることがあります。Fintanでは、実務で得た知見をもとに、協業時に意識したいポイントをまとめた記事も公開しています。本稿とあわせて、ぜひご覧ください。

UIデザイナーとの協業時に気を付けるべき7つのこと

　なお、本稿では色の違いなど細かな差異についても取り上げますが、これはデザインデータと実装を完全に一致させるべきと主張するものではありません。たとえ小さな差異であっても大きなレイアウト崩れにつながる可能性があるものや、今後の管理に困る可能性があるものを挙げています。

　差異の許容範囲などについては、デザイナーとエンジニアが都度話し合って決めることをおすすめします。

　また本稿では、デザインツール「Figma」を前提とし、「マージン」「カラーコード」などの基礎的な用語の説明を省略します。

固定位置要素の取り扱い

　フローティングアクションボタンなどは、画面内の特定の位置に要素を固定します。

　これらは、他の要素と取り扱いが異なるため問題が起きやすいです。

例1：固定するかしないか分かりにくい場合がある

　デザインデータを平面的な画像として作成するため、見た目からは固定するかしないか分からない場合があります。

　例えば、以下のような画面は、画面下部のボタンの位置が固定なのか、他の要素と同様にスクロールするのか分かりづらいです。

例2：画面に対する正確な位置が分からない

　デザインデータを作成する際、上から順に要素を並べることが多いため、画面下端のマージンの設定が漏れることや、または、曖昧になることがあります。

　例えば、以下の画像だと、画面によって画面下端の高さが異なっており、明らかに適切な設定がされていません。

　画面の下端を基準に要素を配置する場合、上記の設定漏れから正確な位置が分からなくなることがあります。

問題・影響（固定位置要素の取り扱い）

　見た目や動作について、デザイナーの想定と実装の差異が発生しやすくなり、その差異がユーザビリティに影響を与える可能性があります。

対策例（固定位置要素の取り扱い）

　「絶対位置・相対位置のどちらで要素を配置するか」や、「他の要素のうちどの要素を基準にどこに配置されるか」といった情報をデザイナーがデザインツールの機能を用いて正確に表したり、テキストや図で補足したりすることで防ぐことができます。

　例えばFigmaのプロトタイプ機能を用いると、実際にスクロールした際の動きをデザインデータのみで確認できます。

　また、デザイナーとエンジニアのコミュニケーションを増やし、お互いの認識を確認する場を設けることも有効です。

　デザイナーがエンジニアにデザインを説明する場を設ける方法や、実装されたものをデザイナーが確認する場を設ける方法があります。

テキストの折り返し

　テキストの折り返しには、テキスト入力時に改行を入れる場合と、横幅に合わせて自動的に折り返す場合があります。

　例えば、ユーザーが入力したテキストや、APIで取得した動的なテキストを表示する場合、適切に改行されていないことがあります。

　そのため、デザイナーが見た目のバランスを見て直接テキストに改行を入力すると、実装データとの乖離が生じやすいです。

　また、デザインデータでは発生しなかった折り返しが実装時に起きることもあります。

　これは以下のような原因で起こります。

• 表示フォントがブラウザやOSで変わり、文字の横幅が変化する。
• デザイン上の小数点以下の位置やサイズの調整が、実装時にブラウザなどによって整数に丸められている。
• デザイン上と実装上の横幅の計算が異なる。（例：線の幅を要素のサイズに含めるかが異なる。）

問題・影響（テキストの折り返し）

　折り返し方について認識違いが起こると、レイアウト崩れにつながります。

対策例（テキストの折り返し）

　端末のサイズやユーザー設定による文字の拡大などでどんな長さのテキストでも折り返される可能性があります。そのため、改行の有無に関わらず、テキストの表示領域の最大横幅を設定し、テキストが折り返すようにしておくと安全です。

　基本的に各要素にマージンやパディングを設定し、縦幅を可変にすると上記の内容は守られます。また、テキストの改行を安易に使用せず、改行する際はその影響に気を配ります。

　他の対策として、開発者とデザイナーで事前に取り決めを作っておくことも考えられます。決めた内容はできればテキストで残しておくと関係者が増えたときなどにスムーズです。

異なる画面サイズでの表示

　スマートフォンの画面サイズは機種により様々な種類が存在します。

　UI上の全ての要素を画面サイズによらず固定の幅とするのであれば気にすることは何もありません。

　しかし、使いやすさや美しさを考慮して、要素の縦幅の何%で設定することや縦横の比率を保ったまま拡大することなどがあります。

　各要素に対して画面サイズが変わった時の対応を変える必要があるということです。

この場合、特定の画面サイズのデザインデータからは上記の情報を推測することが難しいため、別途説明などが必要になります。

　レスポンシブ対応を行う場合、画面サイズによってレイアウトが大きく変わることが多いので、各サイズのパターンを作成することが多いと思います。

　一方で、微妙な画面の比率の違いは見逃されがちなため、注意が必要です。

問題（異なる画面サイズでの表示）

　画面サイズが異なる場合のイメージが適切に伝わらないと、画面サイズによって想定しないレイアウトになる可能性があり、ユーザビリティの低下を招く可能性があります。

対策例（異なる画面サイズでの表示）

　複数パターンの画面サイズでデータを作ると、齟齬なく伝わりやすいです。

　特にファーストビューに全ての要素を表示する場合など、細かな設定が必要な場合は、この方法が向いています。

　しかし、全ての画面について複数パターン作成すると作業のコストが大きく膨らむため、複雑でない画面は、テキストでの説明やデザインツールの設定を用いる、デザインルールとして整備するなどの工夫が必要になります。

デザイン上で指定したアイコンと実装時のアイコンの見た目が異なる

　デザインデータ上で使用しているアイコンと実装上で使用しているアイコンが異なることがあります。

　私が遭遇した事例では、デザイン上で指定したアイコンが開発時に使用しているアイコンライブラリに存在せず、代替のアイコンが使用されていました。

※画像はイメージです。

　特に影響の出やすいアイコンを取り上げましたが、UIコンポーネントについても類似の事象が発生することがあります。

問題・影響（アイコンの見た目が異なる）

　アイコンの見た目が元より大きくかけ離れると、ユーザーに意図が伝わらなくなる可能性があります。

　また、形は似ていても線の太さなどの見た目が異なると、他のアイコンの見た目との一貫性が保てず、ブランディングが損なわれる可能性があります。

対策例（アイコンの見た目が異なる）

　開発上のUIの制約があれば、エンジニアが先に伝え、デザイナーも確認することがトラブル防止に繋がります。

　アイコンの素材サイトを使う場合も、アイコンライブラリを使用する場合も、Webサイトで一覧を見ることができる場合が多いです。

　そのため、サイトのリンクを共有しておくと便利です。

OSやブラウザ特有の違い

　OSやブラウザによっては自動的に見た目が変化する場合があります。

例1：電話番号のスタイルが意図せず変更される

　例えば、iOSの標準ブラウザであるSafariでは、電話番号などの文字が自動的に青色になり、下線が引かれます。

例2：入力時に画面が拡大する

　また、iOSでは入力フォームの文字サイズが16px未満の場合、入力時に自動的に画面が拡大します。

　これらは、デザインとの意図しない違いを引き起こします。

例3：入力時に最初に入力する英字が大文字になる

　スマートフォンなどで入力フォームにメールアドレスなど英字を入力する際、一文字目が自動的に大文字になることがあります。

問題・影響（OS・ブラウザ特有の違い）

　例1は、自身の電話番号や、住所の丁・番・号など、不要な部分がハイライトされることがあり、見やすさが低下します。

　また、例2は、入力欄の周辺の情報が見づらくなり、例3は、意図しない入力が発生するため、ユーザビリティを損なう恐れがあります。

対策例（OS・ブラウザ特有の違い）

　例えば、記載した3つの例は、このように解決できます。

※今回の対応方法はHTMLの場合に絞っています。

・例1：電話番号のスタイルが意図せず変更される

　電話番号の文字の色は、HTMLのheaderに以下を追加することで対応可能です。

<meta name="format-detection" content="telephone=no">

・例2：入力時に画面が拡大する

　入力フォームの文字サイズは、16px以上に設定することで防ぐことができます。

・例3：入力時に最初に入力する英字が大文字になる

　Typeを適切に設定するか、または、autocapitalizeを設定することで防ぐことができます。

<input type="email"/>
<input type="text" autocapitalize="off"/>

　私たちが経験した問題は以上の3点ですが、他にもOSやブラウザ特有のスタイルがあります。

　考慮すればすぐに対応できるものばかりなので、事前の調査と、関係者への周知ができると防ぎやすいでしょう。

様々な細かい設定

　UIデザインにおいては部品や素材に対しての様々な設定値が存在します。

　例えば、カラーコード、マージン、角丸・文字の行の高さ、字間、影などです。

　そのため、デザイナーとエンジニア双方で設定忘れや間違いが発生することがあります。

例1：黒色

　デザイナーは黒色にしたい部分に黒に近いグレーを使用することがしばしばあります。

　#000000（純粋な黒）は、白い背景に対してコントラストが強すぎ、目の疲れにつながることなどが理由です。

　しかし、色の違いが分かりづらいため、色指定を実装に取り込む際に漏れてしまうことがあります。

例2：行の高さ

　シンプルなボタンの高さがデザインと実装で合わないことがありました。

　パディングや文字の大きさは設定していたのですが、行の高さの設定が漏れていたためです。

　設定するのは1項目だけですが、時には見た目が大きく変わります。

問題・影響（設定忘れや間違い）

　設定や値の違いが重なると、デザインの一貫性が失われます。

　また、コンポーネント化した共通プロパティでの管理を行わない場合、個別の修正を余儀なくされ、保守性が悪くなります。

対策例（設定忘れや間違い）

　デザインでも実装でも、先にどのような値を使用するか定義を作成し、定義から外れたものが無いか相互にレビューし、確認し合うことで減らすことができます。

　また、ドキュメントなどの取り決めだけでなく、デザインツールの機能やコードで定義することで、定義を使用していない部分が見つけやすくなります。

• デザイナー：スタイル、バリアブル（Figma）、ドキュメントアセット（Adobe XD）など。
• エンジニア：テーマ、値を定義した定数ファイル、カスタムプロパティ（CSS）など。

最後に

　デザインと実装の間で起こりやすい差異について述べてきました。これらは知識と適切なコミュニケーションによって防ぐことができます。

　本稿がそのコミュニケーションと理解のきっかけとなり、アプリケーションやサービスの品質向上の一助になれば幸いです。

元ブログもチェック！

元記事はコチラ。ぜひチェックしてみてください！