デザインデータをコーディングする際に、よく発生する問題があります。
（１）デザイン通りにコーディングされない
（２）デザインの統一に一貫性がなく、細部での調整が必要のためコーディングに時間がかかる
こういった部分で、修正・調整で時間を取られることが多くありますが、これは（２）のデータ自体、または依頼方法に何かしら問題があると考えられます。
全てを解決することは難しいですが、大半はデザイナー側の配慮で防げることも多いです。「美意識」といった観点からも、デザインルールを決め、コーディングの無駄な負荷を軽くできるようにしましょう。
※弊社では基本XDでの制作になるため、XD想定でマニュアルを作っています。
【目次】
（１）カンバスサイズ
（２）テキストサイズ
（３）各要素の余白
（４）配色
（５）使用フォント
（６）特殊フォント
（７）文章など内容が長くなった時のデザイン
（８）オブジェクトに枠（境界線）をつける場合
（９）オブジェクトは整数で
（10）オブジェクトのグループ化
（11）リンク時のHover、Active
（12）サイトの実装方法を想定する
（13）コーディング依頼書を作成する
（14）XDの開発プレビューを共有する
（15）事前の認識合わせ
まとめ
（１）カンバスサイズ
現在は以下の数値で統一。ここは他制作会社の動きと、時代の流れに合わせて適宜変更していきます。
PC：1400px
SP：375px
（２）テキストサイズ
本文で使用するテキストサイズのルールをサイト内で統一し、css設定のベースを決めましょう。
・基本テキストサイズ（本文）
・見出し
・注釈 etc…
（３）各要素の余白
各コンテンツの間の余白がバラバラ、見出しと本文の間の余白がページごとに違うなど、ミスなのか、それとも意図的なものかわからない場合があります。基本は統一させましょう。
意図的にイレギュラーが発生する場合は、しっかりコーダーさんに伝えます。
（４）配色
サイト内で使用する色は主に下記種類になります。色の組み合わせは補色または反対色を使うのか、類似色や同系色にするのかでユーザーに与えるイメージが全く異なります。
特に公共性が高いサイトなどはカラーユニバーサルデザイン（CUD）も考慮しつつ配色を決めましょう。
1.メインカラー
2.ベースカラー
3.アクセントカラー
4.本文テキストカラー
5.強要素（強調したい）テキストカラー
6.弱要素（主張を抑えたい）テキストカラー
図のように、基本となる1.2.のカラーを軸として、配色を決めていくと失敗が少ないかと思います。基本カラーを決めることでサイト全体の統一感はもちろん、css設定も明確にしやすくなります。
（５）使用フォント
理想的なのは、font-familyの指定をそのままコーダーさんに伝えてあげることです。Windows、Macintosh、Android、iOSで同じ見え方になるフォントを選びましょう。
webフォントを使用する場合は、設定の仕方やwebフォントのリンク先をコーダーさんに伝えてあげるとベターです。webフォントの埋め込みはサイトの読み込みが遅くなる可能性があるため、必要な場合以外は極力避けたいところです。
モリサワやFONTPLUSなど有料のものについては、クライアントの許可を取りましょう。
【記入例】
font-family: “Helvetica Neue”,Arial,”Hiragino Kaku Gothic ProN”,”Hiragino Sans”,Meiryo,sans-serif;
Webフォント：Noto Sans CJK JP（Google Fonts）
https://www.google.com/get/noto/#sans-jpan
（６）特殊フォント
デザイン性の高い特殊なフォントは、コーダーさんに書体を提供する、または文字をアウトライン化してオブジェクトにする、といった形で提供します。このようなフォントはWebフォント非対応、もしくは有料が多いため、コーディング時にどのような対応が必要か考え、コーダーさんに伝えましょう。
（７）文章など内容が増減した場合のデザイン
文章が長くなったり、内容量が増えた場合を考慮し作成しましょう。一覧ページのような可変要素が複数ある場合は、内容が増えた場合、高さがガタガタになってしまうので、その場合はどうするべきかなどカンプでわかりやすく表現します。
テキスト数が多い場合はテキスト数の制限など設け、見やすく整えるのも一つの方法です。
（８）オブジェクトに枠（境界線）をつける場合
オブジェクトに枠（境界線）をつけるときには、オブジェクトの「内側」「中央」「外側」のどこに線を引くかが選択できます。しかし「中央」「外側」を選んでしまうと、コーディングの際、オブジェクトの線幅を考慮し計算しなければなりません。
シンプルで計算しやすいデザインデータにするために、オブジェクトの「内側」に枠（境界線）をつけるようにしましょう。
（９）オブジェクトは整数で
半端な小数点以下の数字は、画像を書き出した時に端がぼやけてしまいます。画像に限らずオブジェクトは整数になっているかどうか確認しましょう。ぼやけたままのオブジェクトは、ユーザーに「不揃い・汚い・信頼性が低い」といったネガティブな印象を与えてしまいます。
XDのプラグイン「Remove Decimal Numbers」を使用すると効率よく調整できます。
（10）オブジェクトのグループ化
アイコンやイラストなどを制作した時、特に複数の線や図形で描画することが多いと思います。最終的にはsvgとして書き出しやすいよう、グループ化をしておきましょう。
（11）リンク時のHover、Active
忘れがちなのがHover、Activeのデザイン。ボタンやテキストの場合で挙動が違うので、忘れずに用意しましょう。
特にアニメーションがつく場合は、デモ画面URLやサンプルソースなどを提示するようにし、イメージの行き違いが起こらないように配慮します。
（12）サイトの実装方法を想定する
レスポンシブ、リキッドデザインの場合は、ブレイクポイントによってPCからTB、SPにどう変化させるかなど想定してデザインするようにしましょう。実装不可能なデザインにしてしまうと、コーディング時に行き詰まり、デザインの後戻り修正が発生してしまうなど、余計な時間がかかってしまいます。
アニメーションなど、「ここをこういう風に変化させたいけど、大丈夫かな？実装できるかな？」と不安に思ったら、コーダーさんに相談するようにして、デザインデータを渡す際はどう変化させたいのか説明しましょう。
先に複雑なPCカンプを作っておくと、SPの作成が効率良くなります。
（13）コーディング依頼書を作成する
デザインカンプができたら、コーダーさんに渡す前に「コーディング依頼書」を作成しましょう。数ページの簡単な小規模サイトなら口頭でも完結可能な場合がありますが、中・大規模サイトになると、膨大な情報量を覚えておくことができません。ドキュメントを残しておけば、口頭での説明を忘れてしまった時にも見返す資料になります。また、他社にコーディングを依頼するときも、補足情報としてスムーズに意思を伝えることができます。
コーダーさんに気をつけていただきたいポイントや、イレギュラーな箇所も記載し、コーディング時に無駄に悩ませないよう配慮しましょう。
（14）XDの開発プレビューを共有する
XDにはデザインスペックを共有する便利な機能があります。「共有」画面から開発プレビューリンクを作成し、コーダーさんと共有しておきましょう。オブジェクトを選択するだけでサイズやマージン、cssなどの設定を確認することができます。
（15）事前の認識合わせ
デザインデータ・コーディング依頼書を渡すだけでは、デザインの意図や可変部分、アニメーションなど、うまく伝わらないことが多くあります。コーディングをお願いする際に最低1回はコーダーさんとの打ち合わせをして、お互いの意図があっているかどうか確認しましょう。
まとめ
上記はあくまで最低限の基本デザインルールです。複雑なプログラムが入る場合には、更に気をつけなければならない箇所がさらにあります。1人でプロジェクト工程すべてを行うわけではないので、「チームメンバーの負担を軽くする」と意識し制作をすると、信頼関係が構築され、チーム内の作業も円滑になるのではないでしょうか。
大きな目で見ると、それは結局まわり巡って自分も助けてもらえることになりますので、「ペイ・フォワード」の姿勢でチームメンバーと連携をとっていきましょう。
業務に追われていると、次工程への配慮が行き届かなかったり、「これでいいや」となってしまったりしがちですが、戒めも込め、毎回デザインデータのチェックをして、よりスムーズに着手できるようアップデートしていきたいものです。
