👩‍🎨

実装者が作業前にデザイナーへ確認しておくとよいこと

2020/11/02に公開

CSS

TAK(@tak_dcxi)です。

コーダーやフロントエンドエンジニア（以下実装者と呼ぶ）が作業に取り掛かる前に事前にデザイナーに確認しておくとよいことを独断と偏見でまとめました。過去に面倒臭がって聞くのを放棄して失敗した経験もあるので、自戒の念も込めています。

デザインの共通ルールを確認する

余白のサイズやフォントサイズや使用している色などはルール決めがされているとは思いますが、デザインのルールを実装時に分かりやすくしておくことで効率的かつ保守性や拡張性に強いコードが書きやすくなります。

逆に実装時にルールが分からないと、実装者がデザインカンプを見てもそのルールを理解するのに時間がかかってしまうことも多いです。余白であれば感覚で配置されてるのか、似たような箇所で17pxであったり23pxであったり…と意図が分かりかねる場合もあります。余白は原則8の倍数で行うみたいなルールが事前に実装者に伝わっていればそれがズレだと認識できるでしょう。

ただ、「これは恐らく間違いだろう」と均等化しても「ここだけちょっと仕様が違うんですよーｗｗｗ」と意図的にズラしているなんてこともあるので、意図的にルールから外した箇所があるかどうかは事前に聞くようにしておくと良いかもしれません。

最低でも、

使われているカラーコード
フォントサイズ
フォントファミリー
余白のサイズ
その他規則性があり定数となり得るもの

あたりはデザイナーから聞いておき、予めCSSの変数としてまとめておく。実装のデザインガイドにもなり、変更にも強くなります。

デザインに対してデザイナーと実装者で共通の認識を持っていれば、実装者の「それっぽく」が求められた際にも柔軟に対応できるというメリットもあります。

可能であればデザイナーの方はデザインガイドを作っておくと良いでしょう。デザインガイドは実装者だけでなくディレクターや運用・改修の担当者、そしてデザイナー自身の助けにもなります。

■参考記事：Webデザインのスタイルガイドの作り方 | UX MILK

デザインカンプのサイズを何pxで作るのか取り決めておく

デザインカンプのアートボードの横幅とデスクトップビューでのコンテナ幅を何pxで作るのかは実装コストと直結しがちなので事前にデザイナーと話し合いの上決めたほうが良いです。

スマホ向け・タブレット向け・デスクトップ向けの3種類が用意されていて、かつ実装面の不自由さ（スマホ向けのデザインなのに横幅500pxで作られているとか）が無ければお好みでって感じですが、僕の経験上次の3つのサイズがあればどうにかなります。

スマホ向け：360px(Androidの標準サイズを基準) or 375px(iPhone8を基準）
タブレット向け：768px(iPadを基準)
デスクトップ向け：1366px(ノートPCを基準) or 1920px(最も普及しているフルHDディスプレイを基準)

スマホ向けのデザインを375pxで作る人が多いですが、Androidの標準サイズの360pxのシェアも高めです。375pxでギリギリのデザインを作られるとAndroidではみ出るってことはありがちなので、375pxでギリギリのデザインを作りがちな方には360pxで作る選択肢も持たせておくとよいかもしれません…。

デスクトップ向けに関してはコンテナのサイズが1200px未満であればなんとかなります。デスクトップは画面の幅のバリエーションが激しいので、幅広め(1920px)のカンプで丁度よいデザインを作ってノートPCで潰れることが不可避だったり、幅狭めのカンプで丁度よいデザインを作って4Kディスプレイでスカスカ不可避…ってことがないように、カンプの横幅とは大きく離れたサイズのデバイスで見られた時にどうするのかは入念にデザイナーとすり合わせしましょう。

現在の主要な画面サイズはstatcounterで調べることができます。また、どんな画面幅のデバイスが普及しているのかざっくり知りたかったらSCREEN SIZ.ESで確認すると良いかと。

また、令和においては画像を倍で書き出すことさえできればデザインカンプを倍の解像度で作る意味はないです。

デザイナー側からしたらオブジェクトやフォントのサイズを偶数pxでやらないといけない意識を常に持たないといけないし、実装側からしてもわざわざ1/2に再計算して実装する手間ががかり、デメリットばかりです。可能ならば効率化のためにも等倍でデザインを作ることを依頼しましょう…。

■参考記事：もう、SP用のWebデザインを倍の解像度で作るのをやめよう - to-R

デザインカンプのサイズ以外で見られた時にどうするか？も考えてもらう

前項で少し触れましたし、以前のiPhone12についての投稿でも触れましたが、そのデザインカンプのサイズ以外の画面幅で見られた時にどうするか？もデザイナーに考えてもらいましょう。

カンプのサイズ以外の対応は実装者に「それっぽく」を求められることが多く、実装者は「どんな感じで実装するんだ…」って感想を抱きがちです。

例えば横幅320pxの対応は375px相当でデザインされたものをそのまま当てはめると大抵ははみ出たり崩れたりすることが多いです。

また、デスクトップに関しては最近はウルトラワイドモニターが流行のように、今までの画面幅より圧倒的に広いデバイスが台頭して来ている時代です。

加えて、1024px(iPad横向きやiPad Pro 12.9の縦など)のデバイスはタブレットサイズでは大きすぎてデスクトップサイズでは小さいってことも「あるある」なので、見落としがちですが気をつけて対応したほうが良いでしょう。

結論として、

320pxではどう見せたらいいか
1024pxではどう見せたらいいか
1920px以上ではどう見せたらいいか

あたりはデザイナーと入念にすり合わせして方針を決定しておきましょう。

当たり前ですが、タブレットのカンプが用意されない現場ならタブレットでの表現も確認しておきましょう。（本音を言えばタブレットのカンプも必須で作るべきだとは思いますが、それぞれの現場があるので何も言いません…）

【追記】僕は原則的に320px未満はJSでスケーリングして表示する方針に移行しました。詳しくは次の記事をお読みください。

対応範囲内のOSやブラウザで実現できない箇所はどうするかを確認する

前回投稿したデザイナーとフロントエンドエンジニアに知ってほしいWebのフォント周りのお話
の再放送ですが、OSによってデフォルトで入っている・入っていないフォントは違います。Androidでは明朝体はWebフォント使わないと表示できないし、Windowsのフォントは微妙なものばかりです。

デザイナーの皆さんはApple製品ユーザーが多いので仕方がないのかもしれませんが、基本的にMacもiOSも映るのは「美しい世界」です。ただ、Apple製品以外では美しく映らない場合も多いので、他のデバイスでもできるだけ美しく見せるようにデザイナーと相談しましょう。フォント周りは特に注意です。

あとは、ブラウザによってはCSSで実現できる・できないデザインもあります。例えば、乗算などのブレンドモードはかつてはブラウザで実現できない&書き出しに困るといった理由からWebデザインでは利用が避けられてきました。しかし、現在ではCSSのmix-blend-modeを使えばブレンドモードは実現できますし、モダンブラウザで利用可能です。

ただ、Internet ExplorerやChromiumではないMicrosoft Edgeでは利用できないため、対応範囲内のブラウザにこれらがある場合にはプログレッシブ・エンハンスメントで行くか、レガシーブラウザで綺麗に見せるために画像などで対応するか、別の手段を考えるか…などはデザイナーと相談したほうがいいです。

世間ではIE切りが海外だけでなく日本でも徐々に行われてきていますし、僕もIEとか切ってよくね？と思ってはいますが、今でもIEユーザーって多いです。クライアントの使っているブラウザが実はIEでしたって「あるある」です。そういった意味では要件定義の時に対象OS・ブラウザは確認しておかないとダメです…。

どこまで忠実にデザインを再現するかは要相談

すごい語弊があるタイトルですが、前提として僕自身はデザインを忠実に再現することは実装者として「当たり前」だと思っています。

ただ、忠実に再現しようと努力した上でline-heightの挙動の違いに生じる余白や約物の挙動の違いなど、デザインツールとブラウザでの挙動が違う箇所ってあります。そこをどうするか？つまり「ピクセルパーフェクト」が求められるか？は確認しておきましょう。

ピクセルパーフェクトはSNSでしょっちゅう論争になったりしますが、話聞いている感じだと人によっては「40px横にズレている」とか「色が全く違う」とか「フォントの太さはnormalでサイズは24pxでデザインしたのにboldで32pxで上がってきた」とかそもそもデザインを再現すらしていないことを「ピクセルパーフェクトではない」と呼んでいる人もいるので定義を統一しないと不毛な争いになるだろって感想ですね…。ちなみに僕の中でのピクセルパーフェクトとはこういった文字周りの挙動を含めて1pxもズラさずにコーディングすることだと思っています。

ICS MEDIAの池田さんの例だとNGが多いです。が、これはピクセルパーフェクト云々以前のお話だと思ったり。

一方、僕がツイートしたピクセルパーフェクトの例だと圧倒的にOKという方が多かったです。

ただ、約13%の方は許せないと回答しており、line-heightや約物の挙動の違いにおいても嫌悪感を抱くデザイナーの方は多いみたいです。なので、デザイナーの方にこういった挙動の相違をどうするかは確認しておいて、できることなら許容して頂けるようにお願いしましょう。

もし許容して頂けなかったら、line-heightのズレはひとつひとつネガティブマージンをあてて調整したり、約物のズレはYaku Hanフォントを導入して、それでもズレている箇所は1文字1文字spanで囲んで調整でしょうか？それに高いコストをかけてユーザーやクライアントにどのようなメリットがあるのかは甚だ疑問ですが。

僕はピクセルパーフェクト否定派ですが、実装者はピクセルパーフェクトできる技術は身につけておいたほうが良いとは思います。とは言ってもChrome拡張機能のPerfectPixelを導入してカンプを背景に敷いてなぞれば良いだけの話なので大した技術では無かったり。

「もしも」のデザインを確認する

コンテンツは流動的です。ローンチ時にはデザインカンプ通りであったとしても、運用するにつれてテキスト1行を想定した箇所に改行が生じたり、要素の数が増減することは「あるある」です。デザインカンプでは美しく見えるコンテンツ量だとしても、文字数が増減したりグリッドの数が増減した際に崩れるようではお話になりません。

運用担当者でコンテンツの更新をするならまだしも、WordPressのようにクライアント側でコンテンツを更新するWebサイトではどんなコンテンツの差し替えが行われるかは未知数です。できるだけ多くの「もしも」に耐えられるようにしておくためにも柔軟で拡張しやすい実装を行うことは必須です。

文章量が極端に多い時はどうするか？
逆に文章量が極端に少ない時はどうするか？
1行前提だけど溢れた時は三点リーダーで省略するか？改行するか？
グリッドが幅いっぱいに並んでいるけど、1つの場合は左揃えか中央揃えか？
コンテンツが空っぽのときにどう表示する？
要素が無くなった時に前後の余白はどうなる？
画像の差し替えでサイズが変わった時に画像の比率は固定する？オリジナルの比率のまま表示する？

ここらへんのデザインは「それっぽく」実装者の感性に委ねられる現場も多いので、デザイナーにどういった挙動をすれば好ましいか聞いておくと良いと思います。

状態変化したデザインも確認する

例えばリンクやボタンのホバーやヘッダーが追従された時にどうするか？はカンプに置いておいて欲しいですが、無かったらデザイナーに確認しましょう。

後はアニメーションもどんな感じにするか、参考サイトなどを提示してもらえれば嬉しいかなと。

オブジェクトのサイズで少数pxが出ないように依頼する

少数pxはデザインツール上では問題なくても、実装時には各ブラウザによって仕様がバラバラ（小数を反映or無視、反映する場合の切り捨てor切り上げ）だったり滲みやボケが発生したり…と描写上の問題は起こりがちです。

また、現場によってはデザインを倍の解像度で作らざるを得ないということもあるでしょう。その場合はオブジェクトのサイズはピクセル比で割り切れる数字を使用するように依頼しましょう。2倍の解像度で作るなら偶数を使い、奇数は使わない。

Webに対して知見のあるデザイナーはこのあたりはしっかり意識してくれているはず…！

【Adobe XD利用者】画像の書き出しをどうするかは要相談

Adobe XDはデザインツールとして非常に優れているのですが、一点気をつけないといけないことがあります…。それはカラーマネジメント非対応なこと。つまり、作業しているモニターによっては書き出し時に画像が変わってしまう可能性があります。

Adobe XDを利用している現場では画像の書き出しはどうするかはデザイナーと相談したほうがいいです。可能ならデザイナーに画像を別途用意してもらったほうがいいかもしれません。

実装者側の視点でデザインレビューをすることも大切

以前noteに投稿した内容の再放送にはなりますが、デザインカンプを愚痴りながらただ組みあげるのでは意味が無いです。コーディングするのに無茶があったり、規則性がバラバラだったり、そういったおかしいと思う箇所はきちんと実装側の目線から指摘してあげましょう。

Webデザインは決してビジュアルデザインの事のみを指しているわけでは無いです。ユーザーにとって使いやすかったり、ユーザーを意図するコンテンツに誘導させたり、アクセシビリティに配慮して特別な環境から訪れてくださるユーザーの機会損失を防いだり、そういった設計が多分を占めています。

実装に無茶があるデザインは~~面倒臭い~~実装コストが高くなるだけでなく、ユーザビリティが低くなったり、パフォーマンスに悪影響を及ぼしたり、HTML構造をデザインに合わせるために無茶させてスクリーンリーダーでの読み上げがおかしくなったり…とユーザーにも悪い影響を及ぼす可能性すらあります。何の意図もなく実装者の負担を増やすようなデザインは避けるべき。

例えばカルーセルを多用したデザインは経験上実装コストが高くなり、表示されていない箇所は検索エンジンに認知されなかったり、パフォーマンスにも影響を及ぼすといったデメリットが目立つ印象ですが、そのわりに2枚目以降はほとんど見られないという検証結果もあります。

■参考記事：
Appleがトップページで自動送りカルーセルをやめた理由 | Rriver
スライダー（スライドショー・カルーセル）は本当に必要？その役割と必要性について。｜スタートミーアップ合同会

僕もデザイナーやっていた頃にカルーセルマシマシのデザインをよく作っていたので反省含めてなんですが、実装コストの高いデザインについては何の為にそうしているのか？そのコスト（開発時のそれだけでなくその後の運用・保守も含めて）に見合った効果はあるのか？それでお問い合わせは増えるのか？は説明できるようにデザインして欲しいし、実装側もやんわり聞いてみるといいと思います…。

つまり、デザイナーの意見を鵜呑みにするのではなく、デザインの意向を最優先に汲みながらも実装者が持っている知識を最大限に活かして提案をしましょう。「デザイナーの作ったデザインだけが正義！」「面倒くさいと思ったら負け！」と言って思考停止でピクセルパーフェクト目指すとかそんなことよりもよっぽど大切なことではないでしょうか？

また、デザイン的に問題はないけれど気になる箇所（どうしてこの色なのか？余白の開きに差が大きいのは何故か？文字の大きさは何故このサイズなのか？など）があれば、デザインの意図を知るためにも積極的に質問しましょう。多角的な視点がWebサイトの設計には必要です。

僕はCSS設計、もっと言えばマークアップそのものが情報構造とデザインの設計を過不足なくコードで言語化することだと思っているので、デザインの設計がしっかりしていれば（実装者のスキルに依りますが）優れたコードになりますし、デザインに破綻があれば当然コードもおかしくなるよねって感想です。ですから、実装者の視点からそのデザインに設計上の問題がないか確認してレビューをすることは至極重要だし、デザインの段階（もっと言えばワイヤーフレーム作成の段階から）実装者もガンガン意見を言うべきです。分業だからと言って自分の持ち場以外は他人事ってのはダメ。

ただ、レビューする際はデザイナーなりにベストを尽くして作ったはずなので、直接的な批判は作業を円滑にしていくためにも避けましょう…。「僕はこのデザインとっても好きです！でもここだけレイアウト違ったらユーザーは困惑しちゃうかも？統一したら運用性も上がるし、初めて訪れるユーザーに学習コストを強いることなく見てもらえそうですね🌟」みたいな言い方をすればデザイナーも受け入れやすいと思います。

また、実装コストの高いデザインに対してネガティブな意見ばかり言ってしましましたが、あまりそれにとらわれすぎるとデザインの表現力を制限してしまうこともあるので、「ここコーダーさんめんどくさそうだなーｗｗｗ」って思っても、どうしてもそうしたい理由がある場合にはそのデザインにしてもOKだと思います。（ただ、実装コストが高いデザインと実装に無茶があるデザインは別物だし、デザイナーの自慰的な理由だと納得してもらえるかは分かりませんが…）

その他いろいろ

設定は必ずWeb用で。カラーはRGB。単位にptはダメ。
レイヤー整理は設計の参考（どこまでがグループなのか）のためにもやって欲しい。命名はデザイナーに任せるけど「名称未設定」とか「レイヤー 2」はやめて。いらないレイヤーは削除しておいてください。
アイコンはベクターデータでお願いしましょう。Photoshopは「シェイプ」で置いてほしい。
PNG使うなら透明部分がない画像はPNG24にしない。
鑑識眼が必要なレベルの「ほぼ同じ」は増やさない。
シェイプやテキストの色変更に「カラーオーバーレイ」は使わない。
レスポンシブで意味なくトリミング位置は変えないでほしい。

「個人的に実践しているWebデザインガイドラインまとめ」で色々まとめているのでこちらを参照してください。（宣伝）

おわりに

デザイナーと実装者、お互いの仕事に愚痴ばかり言うのではなく、成果物に対する方向性の違いで喧嘩しないためにもデザインに対して共通の認識を持つためにも事前に入念なコミュニケーションを交わすことが大切って結論です。実装者の「それっぽく」を減らすことも理由のひとつ。

実装しにくくてもデザイナーがユーザーを想って具現化したデザインであれば、それをしっかり実装するのがコーダーやフロントエンドエンジニアの仕事であり腕の見せ所だと思ったりもするし、デザイナーもクライアントの無茶な意見に苦しみながらユーザーのことを考えてなんとかデザインに落とし込んでいるので、そこはリスペクトしないといけないし考慮しないといけません。

デザイナーの方も「細かいデザイン伝えなくてもしっかりやるコーダーと仕事がしたい！」と不平不満を漏らすのではなく、しっかり細かいところは伝えましょう。1伝えて10分かる人なんてそうそういないです。

お互いの仕事についてSNSで恨み辛み言うのではなく、デザイナーも実装者も役割がどんどん変化していっている昨今、仲良くやっていけたらいいですね。

みんななかよく。