コーディングを助けるためにデザイナーができること①

デザイナーの高島です。

ベイジには2019年4月に入社しました。webサイトや業務システムのUIデザインを主に担当しています。『knowledge / baigie』でも、デザイン関連の情報を発信していきたいと思います。

デザインツールで制作したデザインデータをコーディングする時、「デザイン通りになっていない」「ルールに一貫性がなくてコーディングに余計な手間がかかった」といったトラブルが起こりがちです。

しかしこれらの大半は、デザイナー側の配慮である程度防げるとも思っています。そこで今回は、私がコーディングを依頼する際にデザイナーとして気を付けていることをまとめてみました。

なお、ベイジが使用しているメインのデザインツールはAdobe XDなため、この記事もXDの使用を前提としています。ただし、ツールに関わらない話も多いはずなので、皆様が使っているツールに置き換えながら、お読みいただけるとうれしいです。

1：デザインルールの統一を徹底する

「このページではh1のフォントサイズは24pxなのに、他ページでは30pxになっている」「h3と本文との余白がページごとに違う」など、ページやコンテンツによってデザインが微妙に違っていると、コーディングする側はそれが意図的なものなのか、ミスなのかの判断できません。

そうすると、その都度デザイナーに確認する手間が発生し、スムーズな作業の妨げになります。また、本当はミスなのに、ミスと思わずにそのままコーディングで再現してしまうと、余計な設定を施した挙句に修正するなど、無駄な時間をかけてしまいます。

無駄な作業を省き、できるだけ効率よく進めるためにも、意図的な箇所以外は、デザインルールの統一を徹底するようにしましょう。

2：サイズや位置に少数点以下の端数を設定しない

画像サイズに小数点以下の端数があると、書き出した時に、強制的に整数で書き出された結果、端がぼやけてしまいます。また、画像以外でも小数点以下の数字があると、コーディングの手を止めてしまうことがあります。デザインデータを渡す際には、小数点以下の端数が含まれていないか確認しましょう。

また、XDの場合、端数を調整してくれるプラグイン（Remove Decimal Numbers）があります。それを使えば効率的に端数調整が可能です。

3：ボックス要素の境界線は必ず「内側」に付ける

XDに限らず、PhotoshopやIllustratorもそうですが、オブジェクトに1pxの境界線を付けるとき、オブジェクトの「内側」「外側」「中央」のどこに線を引くかが選べます。

しかしながら、例えば300px×300pxのボックスに線を付けると、内側であれば、線を含めて300px×300pxのままでコーディングができますが、中央の場合は301px×301px、外側の場合は302px×302pxというサイズでボックスを扱う必要が出てきます。

そうするとコーディングの担当者は、本当は300px×300pxのボックスなのに、デザイナーの設定ミスで中途半端な数値になっているのか、それともあえてそうしているのかが判断できず、手を止める要因になりかねません。

そもそも中途半端な数値は、リキッドデザインのように%指定でレイアウトする際に破綻しがちなため、デザインデータ上はキリのいい数値にしておくべきです。そのために、線は必ず内側につけるようにしておきましょう。

また、環境設定で内側をデフォルトにしておけば、意図せず外側や中央になることを避けられます。（ちなみにXDは初期設定が内側です。）

4：特殊なフォントは書体を共有するかSVGで書き出す

小見出しやデザインのアクセントとして特殊なフォントを使っている場合には、デザインを渡す際にフォントの種類も伝えるようにしましょう。

コーディングを担当する人がフォントを探す手間も省けますし、別のフォントに置き換わってしまった際の対策にもなります。また、共有できないフォントを使っている場合には、アウトライン化してSVGに書き出してデータを渡すようにしましょう。

5：マウスオーバーのサンプルも作る

デザイン作業の中で忘れがちなのが、ホバーやクリックされた時の変化について。複雑なモーションをつけたい場合は、前もってイメージを伝える必要がありますし、単純な色の変化についても、デザインサンプルを作っておくだけでコーディングがスムーズになります。また、その際にはどれがマウスオーバーのデザインなのか一見してわかるように、マウスポインターをつけておくなどの配慮をしておくと、なおいいでしょう。

6：パスは単純にし、線はアウトライン化しておく

コーディングをする人がアイコンをSVGで書き出すことを想定し、パスの「アウトライン化」と「単純化」をあらかじめしておきましょう。これらを行うことで、SVGのファイルサイズを小さくできますし、SVGをコード化した時に、CSSでの変更やアニメーション設定もやりやすくなります。

単純化というのは、例えば曲線のアンカーポイントを減らしたり、複数のパスを合体させたりすることです。複雑なアイコンになると、Illustratorを使っての作業になると思いますが、「パスの単純化」や「パスのアウトライン化」といった機能をうまく使い、SVG化しやすいアイコンを作るようにしましょう。

7：テキストの増減に合わせて複数のデザインを用意する

デザインの中には、記事タイトルや見出しなど、フォーマットは同じでもテキスト量によってデザインが変化する箇所が必ずあります。

「1行増えた分を全体的に下にずらす」のような対応で済む場合はいいですが、例えば一覧ページのように、可変する文字要素が入ったボックスを多数配置するような場合には、ボックスごとにテキスト量が変わることで、ボックスごとに高さが揃っていない、ガタガタとしたデザインになる可能性があります。

このようなデザインになった時にどうすべきかは、コーディングする人には判断できません。テキスト量によってデザインが可変する個所は、起こりえるデザインパターンも事前に用意して、コーディングを依頼すべきでしょう。

8：実装方法を想定してデザインを作っておく

レスポンシブ対応したサイトを作る場合に、スマートフォンでの表示を想定したデザインを用意しておくのは当然ですが、PC版をデザインする時でも、ブレイクポイントによってデザインがどう変化するかまで想定しておき、必要であればデバイス別だけでなく、ブレイクポイント毎にデザインを用意しておくと良いでしょう。

また、レスポンシブやリキッドレイアウトを想定して個別にデザインを作る時に、実装上不可能なデザインにしてしまうと、コーディング担当者が迷ってしまいます。怪しい箇所はその都度相談するとともに、データを渡す際に、デザイナーとしてはどのような動きになることをきちんと伝えるようにしましょう。

なお、ベイジの場合、モバイルファーストのサイトであっても、デザインはPC版から作り始めることがほとんどです。これはより複雑で難易度が高いPC版のUIを先に作り、その構造に合わせてよりシンプルなスマートフォン版のUIを作った方が整合性を合わせやすいからです。

9：事前の認識合わせを必ずする

シンプルなデザインであれば、デザイナーからコーディング担当者にデザインデータを渡すだけでいいかもしれませんが、マウスオーバーの表現やレスポンシブなどの可変表現、あるいは特殊な画像書き出しが必要と思われる個所がある場合には、デザインデータをポンと渡すだけでは、デザイナーの意図が伝わらない可能性があります。

また画像の書き出しをどちらがやるべきか、追加のデザインパーツが必要かなども、話し合って決めた方がいい場合もあります。デザインデータを渡す際には、最低一回は、こういった認識合わせの場をもっておいた方がいいでしょう。

10：システム的に実装可能かを小まめに確認する

頑張って美しいデザインを作って、それが実装できないものであれば、元も子もありません。HTML/CSSやJavaScriptは問題なくても、CMSやサーバ側の制約で実現できないデザイン、というのも存在します。そのため、事前にテクニカルな制約を聞いておくとともに、デザインを作りながらでも、分からない箇所や怪しい箇所があれば小まめに確認するようにしましょう。

また実現可能性だけでなく、想定される実装時間も事前に確認を取っておけるといいでしょう。デザイン的にはシンプルに見えても、実装するには想定以上に手間がかかる、ということもあります。デザイナーが自己判断で決めるのではなく、小まめに確認を取る癖をつけておくと、後々の大きな手戻りやトラブルを減らすことができます。

11：効率のいいデータの共有方法を協議して決める

いくらデザインデータを綺麗に作りこんでも、コーディングに必要な写真・図版などの素材が整理されていない、ファイルの置き場所がデザイナー以外にはわからない、という状態では、コーディングはスムーズに進みません。自分ではない人が見ても迷わないように、必要な素材やファイルは整理して共有する必要があります。

またすべての完成素材を最初から渡せる場合は良いですが、そうでない場合は、どこまで共有済みで、どれが後日になるのか、新規で追加した素材はどれなのか、どれが更新された素材化、ということが相手にもわかるように、共有方法をあらかじめ決めておく必要があるでしょう。

12：変更は分かりやすく伝えつつ、最小限の手間で

「コーディング後にデザインの修正依頼が来た」「実際にコーディングしてみたらバランスが悪かったのでデザインを変えたい」などの理由で、コーディングがある程度行われた後にデザイン修正が発生することは日常的に起こりえます。

こういった軌道修正をするときは、余計な手間を減らすためにも、変更箇所は分かりやすく、明確に伝える必要があります。デザインデータを変更した場合には、変更済みデータと分かるようにファイル名のバージョンを変える、どの部分を変更したかを明確に伝える、などの配慮も必要です。

私の場合は以下のように、デザインデータ上に変更箇所の説明も書きこむようにしていますが、簡単な変更であれば箇条書きでもいいかもしれません。

またコーディング済ということで、一か所の変更が複数に反映される可能性もありますし、あるいは複数の変更がCSSの簡単な変更で済むこともあります。

後者の場合は、デザインデータをいくつも作るなどの、無駄な作業をしなくていいこともあります。変更が発生した時こそ、単に変更指示を書いたデザインデータを渡すだけでなく、コーディング担当者との密な連携を心がけたいものです。

13：確認や相談をしやすい関係を作る

これは技術の話ではありませんが、デザインからコーディングまでの流れをスムーズにするためには、デザイナーとコーディング担当者が、常日頃からコミュニケーションを取り、話しやすい関係を作っておくことも大事だと思います。

すぐ確認したいことがあるのにデザイナーが忙しそうにしてて話しかけにくい、変な聴き方をしたら文句言われそう、などと思わるような関係を作ってしまうと、それだけでプロジェクトが遅延する理由になりえます。

私たちデザイナーも、コーディングを担当する人に質問する時、「的外れなこと聞いてないかな？」「こんなこと聞いて大丈夫かな？」と緊張することがあります。コミュニケーションはお互い様で、双方で良い関係作りを心掛けないといけません。

例えばデザインデータを渡す時に「分からないことがあればお互い遠慮なく聞こう」というなど、ちょっとしたことでもいいので、コミュニケーションが円滑になる工夫をしたいものです。

さいごに

「心がけたいポイント」というタイトルで、13のことを紹介しましたが、これらに配慮すればトラブルが全く起きないわけでもありません。会社やチーム、担当する人によって、ここに紹介した以外にも、気を付けるべきことはたくさん出てくると思います。

大切なのは、自分一人の担当が終わればいい、という考えで仕事をするのではなく、チームで働いている意識をもつこと。チームで働く中で、どうしたらお互いの作業がスムーズになるかを考えること。「私が楽になりたい」ではなく「あの人の仕事を楽にしてあげよう」という姿勢でコミュニケーションをとることが大事なのかな、と思います。