はじめに

デザイン&エンジニアリング部に所属するUIデザイナーの川端です。
本稿では、私のチームが実際に経験した事例をもとに、デザインデータをもとにエンジニアが実装する際に発生しやすいデザインと実装の差異についてお話しします。

UIデザイナーとして、作ったデザインをエンジニアの方に実装していただくという経験を何度も重ねてきました。
経験を重ねる中で、しばしば似た問題に直面することがありました。
その内容をこちらでご紹介します。

これらの差異は、知識があれば防ぐことができるものも多くありますので、参考になれば幸いです。

対象読者

  • 以下のどちらかに当てはまる方
    • FigmaやAdobe XDなどのデザインツールを用いてUIデザインを行った経験がある
    • FigmaやAdobe XDなどのデザインツール上のデザインを実装した経験がある

本稿では、「マージン」「カラーコード」などの基礎的な用語の説明は省略しています。

前提

差異の取り扱い

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

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

デザインツール

本稿で使用しているツールはFigmaです。

固定位置要素の取り扱い

フローティングアクションボタンなどは、画面内の特定の位置に要素を固定します。
これらは、他の要素と取り扱いが異なるため問題が起きやすいです。

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

デザインデータを平面的な画像として作成するため、見た目からは固定するかしないか分からない場合があります。
例えば、以下のような画面は、画面下部のボタンの位置が固定なのか、他の要素と同様にスクロールするのか分かりづらいです。

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

デザインデータを作成する際、上から順に要素を並べることが多いため、画面下端のマージンの設定が漏れることや、または、曖昧になることがあります。
例えば、以下の画像だと、画面によって画面下端の高さが異なっており、明らかに適切な設定がされていません。

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

問題・影響

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

対策例

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

また、デザイナーとエンジニアのコミュニケーションを増やし、お互いの認識を確認する場を設けることも有効です。
デザイナーがエンジニアにデザインを説明する場を設ける方法や、実装されたものをデザイナーが確認する場を設ける方法があります。

テキストの折り返し

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

例えば、ユーザーが入力したテキストや、APIで取得した動的なテキストを表示する場合、適切に改行されていないことがあります。
そのため、デザイナーが見た目のバランスを見て直接テキストに改行を入力すると、実装データとの乖離が生じやすいです。

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

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

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

問題・影響

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

対策例

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

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

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

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

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

UI上の全ての要素を画面サイズによらず固定の幅とするのであれば気にすることは何もありません。
しかし、使いやすさや美しさを考慮して、要素の縦幅の何%で設定することや縦横の比率を保ったまま拡大することなどがあります。
各要素に対して画面サイズが変わった時の対応を変える必要があるということです。

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

レスポンシブ対応を行う場合、画面サイズによってレイアウトが大きく変わることが多いので、各サイズのパターンを作成することが多いと思います。
一方で、微妙な画面の比率の違いは見逃されがちなため、注意が必要です。

問題

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

対策例

複数パターンの画面サイズでデータを作ると、齟齬なく伝わりやすいです。
特にファーストビューに全ての要素を表示する場合など、細かな設定が必要な場合は、この方法が向いています。

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

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

デザインデータ上で使用しているアイコンと実装上で使用しているアイコンが異なることがあります。
私が遭遇した事例では、デザイン上で指定したアイコンが開発時に使用しているアイコンライブラリに存在せず、
代替のアイコンが使用されていました。

※画像はイメージです。

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

問題・影響

アイコンの見た目が元より大きくかけ離れると、ユーザーに意図が伝わらなくなる可能性があります。
また、形は似ていても線の太さなどの見た目が異なると、他のアイコンの見た目との一貫性が保てず、ブランディングが損なわれる可能性があります。

対策例

開発上のUIの制約があれば、エンジニアが先に伝え、デザイナーも確認することがトラブル防止に繋がります。
アイコンの素材サイトを使う場合も、アイコンライブラリを使用する場合も、Webサイトで一覧を見ることができる場合が多いです。
そのため、サイトのリンクを共有しておくと便利です。

OSやブラウザ特有の違い

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

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

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

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

また、iOSでは入力フォームの文字サイズが16px未満の場合、入力時に自動的に画面が拡大します。
これらは、デザインとの意図しない違いを引き起こします。

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

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

問題・影響

例1は、自身の電話番号や、住所の丁・番・号など、不要な部分がハイライトされることがあり、見やすさが低下します。
また、例2は、入力欄の周辺の情報が見づらくなり、例3は、意図しない入力が発生するため、ユーザビリティを損なう恐れがあります。

対策例

例えば、記載した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）など。

最後に

デザインと実装の間で起こりやすい差異について述べてきました。これらは知識と適切なコミュニケーションによって防ぐことができます。
本稿がそのコミュニケーションと理解のきっかけとなり、アプリケーションやサービスの品質向上の一助になれば幸いです。