XDが人気でも便利でも、まだまだイラレでWEBものデザインをすることがあります。
デザインによっては、結局イラレを使った方がスムーズに作業できる場合もあります。
しかし、WEBものデザインの仕方を把握できていなくて、後々混乱することも。
本当なら簡単なコーディングはできる（理解している）状態でデザインをした方がいいのですが、デザイン専門でやってる人に少々酷な注文でしょう。
そういった場合の説明用記事です。
現在、内容を増補中です。デザイナーとコーダーがナレッジ共有してスムーズに進行できるために、
「イラレでデザイン展開されたとき、こういうことが気になった」
「たまにWEBデザインするんだけど、どういうことを気を付ければいいか分からない」
などありましたらご連絡ください。
目次
同じイラレでもWEBにはWEBの設定がある
イラレで新規ドキュメントを作成する
DTP組に多いのですが、普段の「A4」などでドキュメントを作成しがちです。これでは、単位はmm、CMKYカラーで解像度は300ppiになり、色が変化したり輪郭が滲んだり、あまりよろしくありません。
「モバイル」「WEB」から新規ドキュメントを作成すると、単位はピクセル（px）、RGBカラーで解像度72ppiになるのでスムーズに進行できます。
ピクセルプレビュー
ドキュメントが開いたら、「表示」から「ピクセルプレビュー」に切り替えます。
モニタで表示されるようにピクセル分割で表示されます。
イラレは基本ベクターの世界で、いくら拡大しても滲んだり角ついたりすることはありません。そのままだと、滲んでいることに気付かないままデザインを進めてしまいます。
ピクセルプレビューにすることで、WEBのピクセルベースの見え方に合わせることができます。
上の図は同じ線幅1pxで作成した四角です。ピクセルプレビューではない状態で作成した左側はピクセルに整合されていないので滲んでしまっています。
（この場合、オブジェクトを選択した状態で、クイック操作の「ピクセルグリッドに整合」をクリックするとピクセルにピタッと合わせることができます）
テキストの単位はpxに
紙ものデザインをしたりWEBものデザインをしたりしていると、まれに単位を設定し直し忘れることがあります。
「環境設定」から「単位」ですべてピクセルにします。
（紙ものデザインのときはポイントに直します。一発で切り替わると便利なんですが。。）
設定でミスるのはもったいない
上記の設定は、WEBもののデザインをするときの基本設定です。
単位mmで作成したWEBデザインをコーダーに渡していると、画像やパーツを滲んだまま書き出されてコーディングされるか、コーダーが半ギレしながらデザインデータを修正することになります。
また、他社にコーディングの依頼を出している場合は、WEBデザイン慣れしてないと見做され見積もりを多めに盛られる可能性が大です。
社内の場合はコーダーチームからどんよりしたオーラが漂ってきて、社内が不穏な空気になります。
逆にWEBデザイナーが印刷データを作成する場合に、サイズや配置場所を整数にこだわって調整したがることがありますが、意味が無いので気にしないでください。
印刷機はミリを基準にインクを載せません。
線の位置は内側に
図形の線の位置は基本的に内側に設定します。
中央だと線幅が奇数pxのときに線が、外側だと線幅が太くなったときに角が滲んでしまいます。
図の中で「単純な図形はとにかくピクセルグリッドに整合させる」と書きましたが、アイコン等を気安く「ピクセルグリッドに整合」すると、ガタガタになってくるので気を付けましょう。
このテキストはどう扱うの？
画像書き出しすれば済むバナーと違い、WEBデザインの場合、それぞれのテキスト部分をどういう使い方をするかコーダーとすり合わせる必要があります。
| デバイスフォント | プレーンテキストがブラウザで表示される際の文字のこと。端末内のシステムフォントが当てられる。 |
|---|---|
| WEBフォント | Google Fontsに代表されるやつ。見栄え良いFONTを当てられるが、多用するとページ読み込みが重くなるので、英字や見出しなどワンポイントで使うことが多い。 |
| 画像文字 | PNGやSVG等で書き出して画像として配置する。 |
社内でデザイン→コーディングする場合は約束事が確立していると思いますが、社外に出す場合は説明しないと、極端な例ですがデザイン内の文字を全て画像書き出しされて配置されるなど予想外の事故が起きることがあります。
デザインデータを渡す際に、デザイン上でどのようなFONT指定の仕方をしているか申し送りをしましょう。
以下、例です。
デバイスフォントの指定
基本的に、デバイスフォント部分にはMacではヒラギノ、Windowsでは遊ゴシックといったfont-familyで指定するFONTを当てます。
本文のテキストは基本的に字間の設定はしないと考えてください。
画像文字の指定
画像文字の部分は、データを渡す時にアウトラインを取っておけば、画像書き出すしか無いので混乱しません。
WEBフォントの指定
WEBフォント部分は、使用するWEBフォントサービスにあるFONTを当てます。
DTP組はうっかりUD新ゴやFuturaなどのMORISAWAや有料FONTを当ててくることがあります。使い慣れてますからね。
しかし、使用するWEBフォントサービス内に無い場合、コーダーから「MORISAWAのTypeSquare使うなら、契約は誰がやるの？」「代わりのGoogle Fontsを指定して」「画像文字で使うからアウトライン取ってデータを送り直して」などデザインを突っ返されることになります。
Google Fontsはフリーで使用できるので、デザインする際にダウンロードして使用するといいと思います。
その文字詰めはイラレの機能では？
慣れたデザイナーほど息を吸うように文字詰め設定をして美しく文字を整えます。
しかし、画像文字として扱うなら問題ありませんが、デバイスフォントやWEBフォントの箇所で文字詰めをされているとコーダーは困ってしまいます。
極端な例えですが、イラレのアピアランス機能をWEB上でも再現しろというようなものです。
このカッコ（約物）の問題、ずっと悩んでたんですがなんと約物専用のWEB FONTがあります。毎回これを使うのか使わないのかという問題もありますが、便利です。
また、該当フォントは限られますがCSSでfont-feature-settingsを使って文字詰めもできるようです。
文字詰め有りきのデザインで構築してスマホ端末だとどうなるんだろう？ってのは未検証です（そのうち検証します）。
デザイン上で文字が収まればいいやと変則的な配置をしないで！
例えばcard内の見出しの配置、親要素であるcardのpadding: 15px;が基本ルールだとして、たまたま文字数が一文字だけ行落ちしてしまうときに、紙もののデザイナーは自由に見出しの左右のpaddingを12pxに変更してくれてたり、その見出しだけ文字詰めをしてくれてたりします。
デザイン時はちょいちょい操作して見た目整えてスッキリなんでしょうけど、コーディング時は非常にモヤモヤします。
ユーザーはデザイナーの想定するブラウザ幅（大抵フルHD）で閲覧するとは限りません。ブラウザ幅が想定より縮まったときに一文字ずつ行落ちしていきますよ？ その場合、変則的にメディアクエリでpaddingを調整していくとか、校正で文字数変わったりとか考えるとバカバカしくなりませんか？
いいからデザイン通りコーディングしろと言うなら、せめて申し送りくらいしてほしいですわ。
閲覧者のモニタサイズは千差万別
「せんさまんべつ」で何故か変換できない→「せんさばんべつ」でした。記事を書くって勉強なるなぁ！
世の中の人は大きいモニタを使用していない
WEB業界あるあるですが、自分たちがフルHD（1920×1080）のモニタを使用しているため、世の中の人は皆大きモニタを使用していると勘違いしていることが多いです。
大きなモニタでダイナミックに表示されるデザインは素晴らしいですが、ノートPCや小ぶりのスマホ端末で見る場合のことも考えましょう。
ブラウザ枠も人によっては結構高さを食ってることがあります。
縦にカッコよく配置された文字など、小さなモニタでは一画面に収まりきらず、せっかくのデザインの良さが活かされないことも。
WEBデザインではファーストビューにどこまで収める（見せる）かが重要です。
時々ノートPCでWEBブラウシングをして、見え方のリサーチをするのをオススメします。
レスポンシブを理解する
前述の「世の中の人は大きいモニタを使用していない」の対応策にもなりますが、フルHD時のレイアウト、ノートPC時のレイアウト、タブレット時のレイアウト、スマホ時のレイアウト等、考えつつデザインをしましょう。
全てをデザインとして作成する必要はありませんが、画面幅が変わったときにこのパーツはどう移動するかなど行き当たりばったりではなく頭に入れてデザインすると、後々行き詰まったりしません。
ソリッドデザインとリキッドデザイン
昔々あるところに、PCと携帯端末がありました。
神が「ワールドワイドウェブあれ」と言うと、インターネットが世界に広まりました。
初めはインターネットはPCで見るものでしたが、徐々に携帯端末でも見られるようになっていきました。
しかし、携帯端末の画面の小ささ、パケット制限などの問題があり、PC用のWEBページとは別にテキストベースの携帯用のWEBページが用意されました。「iモード」「魔法のiらんど」など、古の記憶がある方は聞いたことがあるかもしれません。
−–後にスマートフォンが登場すると、この携帯端末は区別するために「ガラパゴス携帯」と呼ばれることとなります。
もういいかな。
図解してみました。
ソリッドデザイン
「solid」とは「固体」「堅固なさま」を意味します。
以前はWEBページのコンテンツ幅を例えば1200pxなどに固定して作成されていました。それ以下のブラウザ幅で閲覧すると、横スクロールが表示されます。
元のレイアウトを崩すことが無いため、システム系のページでは今もよく使われています。
また、古いブラウザも切り捨てない（必要な人に情報が届かなくなるなんてとんでもない！）行政のサイトなどは、今もソリッドデザインが残っています。
北海道庁のサイトはPCでアクセスすると、ソリッドデザインで表示されます。（スマホで見るとレスポンシブになるよう読み込むCSSを変えているようです）
リキッドデザイン
「liquid」とは「液体」「液状」を意味します。
スマートフォンが登場しPCと同じWEBサイトが表示可能になると、別々に用意するのは運営上かったるいことに皆が気付き始めます。
同一ソースで、PCもスマホも表示されるのならそれがいいじゃない。むしろ、それ。と、預言者Googleが「モバイルファースト」を提唱します。
こうなるとサイトのコンテンツ幅は固定ではなく可変対応を求められるようになりました。
フルHDでも、ノートPCでも、タブレットでも、スマホでも表示崩れを起こさず、整ったWEBサイトを訪問者に提供する。それがリキッドデザインです。
今はリキッドデザインが主流なので正直どこを例に出してもいいんですが、株式会社サクラクレパスのサイトはどの画面幅でも整ったレイアウトを提供しています。（PCの方はブラウザ幅を伸び縮みさせてみてください）
それでこのデザインはどっちを想定しているの？
デザイナーから上がってきたデザインを見て、ぱっとソリッドデザインかリキッドデザインか判断付かないことがあります。
- リキッドデザインで可変だとして、余白がスマホで消えてるよね？
- 横幅が狭くなったとき、カラム内で縦長になるテキストの量と縦横比が決まっていて小さくなっていく画像のバランスが考えられてなくない？
- 幅1500pxのアートボードでコンテンツ幅100%のデザインをもらったけど、フルHDになったときテキストの行が横長過ぎて読みずらくない？
- ブレイクポイント756pxとして、スマホのデザインだと750px時にデザインが気持ち悪くない？
- かといって、PCとタブレットサイズとスマホサイズでレイアウトがごりごり変化したら、コーダーの負担が半端ないっすよ。
- PCとスマホとで出し分けが増えたら、結局運営時の手間かからなりますよ？ 修正漏れが発生しやすくなるよ？
などなど。
イラレでWEBものデザインするときの注意点の範囲を超えて、WEBデザインするときの注意点になってしまいました……。
（図解で説明した方がデザイナーの皆さんは直感的に理解できると思うので、おいおい図解を作成していきたいと思います）
設計脳になる
この辺りまで細かく注文すると、「僕、もうWEBのデザインしない……」とデザイナーのやる気を削いでしまいがちなので程々に。
WEBものデザインに慣れていなくても挫折を感じることはありません。構築がややこしかったりデーターに不備があっても、デザインが良いとやっぱりコーディングしていて楽しいですよ。
間隔は設計する
デザイン的な理由もなく、sectionやページごとにpaddingやmarginがバラバラなことがあります。
これではコーダーはsectionやページごとにバラバラの数値を指定すべきか、配慮して数値を整えるべきか無駄に悩んでしまいます。
用紙に対して配置するケースとブラウザ上で配置するケースと、間隔の考え方を切り替えましょう。
大きな画像を配置したらページ読み込みが遅くなるのは当たり前
MVに幅100%で素敵な画像をスライドさせます。
ページ途中にもスライドを表示させ、魅力的なサービスが複数あることをアピールします。
写真にこだわっているので、解像度も倍にしてRetinaでも綺麗に見せます。
そりゃページ読み込みは遅くなりますわ。
カツ丼食べて、ケーキ食べて、ビール飲んで、締めにラーメン食べたら体重増えました〜みたいな話です。
印刷したら紙の重さだけのパンフレットとは違います。
大雑把にでも容量に対しての意識を持つと、デザイン提出時のアピールに一つ二つ増やせるかもしれません。
IEはデザイナーの理想を妨害する
素敵なWEBサイトを見て参考にしたりしますね？ ブラウザ用件にIEが入っている場合、その参考サイトは参考にならないかもしれません。
「IEなんて誰が使ってるの？」と思ったりするじゃないですか。実は日本ではまだまだ多いんです。
先進的な企業やサービスのWEBサイトならIEを捨てる手もありますが、クライアントの上層部はIEを使ってブラウジングしていることも（そして公開前の最終チェックで判明する……）。
IEでできる、できない、できない場合どこまで実現させるなどの選択も、ディレクター・コーダーと共に認識をすり合わせておきましょう。
番外編: クライアントへのデザインチェック
これは昔在籍していた会社でよくあったことです。デザイナーというよりディレクターの問題です。
PNG書き出ししたWEBデザインをクライアントにポンと「デザインチェックしてください」とメール添付していました。
クライアントはWEB業界でも無い人達なので、渡されたPNG画像を100%で表示をしておらず、実際にどういうサイズ感でデザインされているか理解しないままコーディングに進み、テストサーバーにアップ後に「デカ過ぎない？」と指摘が入りました。
システムも絡んでいた案件のため、デザイン調整、コーディング調整も手を入れるページが多く、工数オーバーとなりました。
この会社、不思議なことにディレクターチームで横のナレッジ共有がほとんど無く複数のディレクターが同じミスを繰り返していました。まだ繰り返してるかな……？
おまけ： めちゃ有益な参考サイト
PhotoshopでWEBデザイン
今回の記事ではIllustratorでWEBデザインする際の注意事項まとめですが、PhotoshopでWEBデザインする際の注意事項まとめ記事でよくまとまっている記事を見つけたので共有します。
使用ソフトに限らずWEBデザイン全般
この2つの記事は全WEBデザイナーが見て確認しておくべき内容だと思います！ これを知識として共有した上で、デザイナーとコーダーとディレクターがすり合わせて行く進行が理想なんでしょうね😷
