マークアップを依頼する前に「ディレクター」が注意すべきポイント

私は普段マークアップをメインに活動しているつもりですが、Webディレクターとしての引き合いを貰うこともあり、「クライアント」「デザイン」「マークアップ」の橋渡しすることも多いです。
ディレクターの立場でマークアップの仕事を依頼する際に気を付けているポイントがいくつかあるのですが、そういったポイント全く押さえられてない雑なマークアップ依頼を受けることも多々あります。
そういった経験を踏まえ、押さえておかないと「思ってたのと違う」ものが出来上がってしまいがちな、注意すべきポイントをまとめてみました。
本記事は

・「コーダー」「デザイナー」を経験していない専業ディレクター
・「コーダー」に指示を出すことが多いフリーのデザイナー

の方に読んでいただくと、クライアントからのクレームや工程の手戻りなどが少なくできるのではないかと考えています。

画面幅を変えた時の見え方は指定していますか？

モバイルレイアウトではあまり気にするポイントにはなりませんが、特にBtoB向けサイトでは、「PCレイアウト」を重視されることも多いです。
その場合、「デザインカンプを作った解像度」とは異なるブラウザサイズの見せ方を決めておかないと、「なんかデザイン確認した時と違うなぁ…」という出来上がりになってしまいがちです。

ブラウザサイズがデザインファイルよりも大きいときの見せ方

マークアップ時に支給されるデザインデータ（PSD等）は、
「コンテンツ幅が1000px前後」で、
「余白や背景等を含めた全体の解像度が1280pxくらい」
というデータが多い印象です。

外部モニターを接続して全画面表示すると1920px幅くらいが一般的な解像度になりますので、「1280px～1920pxの場合どうするの？」ということを決めておく必要があります。
特に問題になると思われる下記2点について指示が無いことが多いので注意しましょう。

・幅いっぱいの画像を「上下も広げる」か「高さ固定で幅だけ広げる」のか
・左右どちらかに寄せているコンテンツを「コンテンツエリア付近よりは左右に寄せない」か「画面幅いっぱいまで寄せる」のか

私が指示する場合はどちらも「前者」を選択することが多いですが、デザイン意図にもよると思いますので予めちゃんと合意しておきましょう。
個人的には「デザインデータを1920px」で作るが制作としての最適解だと思っていますが、1920pxのデザインカンプは左右の余白が間延びした印象になってしまいますので、「クライアントに見せるカンプは1280px」「コーダーに渡すデザインデータは1920px」と分けることができるとモアベターな印象です。

ブラウザサイズがデザインファイルよりも小さいときの見せ方

こちらは「大きい」場合よりも「問題が起きると尾を引いてしまう」ことが多い印象です。
特に指示をしない場合「min-width：コンテンツ幅」のように設定され、ブラウザサイズが小さい場合は右から見切れていくように記述されることが多いと思います（マークアップとしては圧倒的に楽なので）。
ですが、テストアップ後にクライアントから「リキッドレイアウトが良い！」という謎の拘りを頂戴することもあり、コーダーからは「今さら言われても全部組み直しなんだけど…」
となり、費用で揉め始めること請け合いです。

方針としては、下記4つが考えられます。

・最小幅を決めて右から見切れていく
・最小幅を決めて左右均等に見切れていく
・文字サイズは変えずに画像サイズを相対的なサイズにする
 （画面を小さくするとテキストの折り返しが増えて縦に伸びていく）
・文字サイズも画像もすべて相対的なサイズにする

それぞれの対応については、
１つ目が「特に指示しない場合のデフォルト」
２つ目が「費用をかけずに後から対応できる限界」
３つ目が「最初から言ってもらわないと困る」
という壁が存在する印象です。
4つ目を採用することは稀だと思いますが、過去の経験だと「3つ目にしたかったけどレイアウト的に無理」な場合にこのように対応したことがあります。（最終請求費用は見積もり時の倍以上になりました）

支給される画像の解像度は十分ですか？レイヤーをラスタライズしていませんか？

マークアップをするときに地味に困るのが、「画像の解像度が足りない」ことです。
特に、PCのデザインだけ支給されて「モバイルレイアウトは良い感じで。よろ。」というケースで問題になるのですが、
・PCでは250pxくらいの画像を表示
・モバイルでは幅100%で画像を表示
としたいようなケースで、250pxの画像を無理やり拡大表示して粗くなってしまうことがあります。
スマートオブジェクトを埋め込んでおいてもらえれば、書き出す時に拡大するといった対応が可能ですが、レイヤーがラスタライズされていると「拡大してもただ大きくて粗い画像になる」だけですので、大きな元画像を別途手配してサイズを加工して…と本来のマークアップには含まれないような雑作業が増えてコーダーのヘイトが溜まります。

また、「画面幅を変えた時の見え方」にも関連しますが、デザインデータ上1280pxの画像をブラウザサイズ1920pxで100%に拡大して表示して、最も目を引おいてほしいメインビジュアルが粗いという悲しいことも発生しがちです。

「乗算」で透過していませんか？

クライアントから透過素材がもらえなかった等の理由で、「乗算」で仮想的な透過としてデザインされることがあると思います。
デザインカンプの確認までは問題になりませんが、コーダーは画像を書き出したときに「あれ、透過にならない…？」と混乱することでしょう。
（マークアップ後半にならないと気付かないこともあります）
そうなると、コーダーは「透過素材」をくださいとディレクターにオーダーしますが、デザイナーはそもそもトリミングが面倒だから乗算にしているでしょうし、トリミング作業が追加になることを嫌がること請け合いです。

IE後の世界ではCSSで乗算できるようになりますが、あと1年はちゃんと透過素材を用意するように注意が必要です。

デザインデータのフォントを脳死でヒラギノにしていませんか？

デザイナーさんのMac率は非常に高いですし、ヒラギノがクオリティの高いフォントだということも相まって、デバイスフォントでマークアップする箇所に「ヒラギノ角ゴ」が使用されているケースは多いです。
マークアップ担当がWindowsユーザーであれば気を使って何かしら対応してくれることもあるのですが、「デザインもマークアップもMac使いの時が最も悲惨」な結果を招きがちです。
クライアントは多くがWindowsユーザーなため、確認してもらった後に

・フォントがデザインと全然違う
・改行位置がデザインと全然違う

とクレームになり、ディレクターが「またか」と思いながら必死に説得するケースは珍しくありません。
ブラウザ確認した時にデザインとの差異を極力小さくするためには

・noto sansなどのWebフォントを使用してデザインする
・MacとWindowsともにインストールされている游ゴシックを使う

という対応になります。
ほんの少し前までは前者が最適解だったと感じているのですが、「Core Web Vitals」後の世界となった現在は「日本語Webフォント使うとPSIスコア悪すぎ」問題が顕著ですので、SEOを意識する現場では後者を選択するシチュエーションは増えるのではないでしょうか。
「フォントは環境によって異なることをあらかじめ了承してもらう」もディレクターがちゃんとクライアントとコミュニケーションをとれる状況であれば悪くない対応です。

Andoroidに明朝体インストールされてないけど大丈夫？

明朝体フォントを使用したデザインは全く珍しくありませんが、明朝体を使用する際に忘れられがちなのは「Andoroidに明朝体はインストールされていない」ということです。
特にiOSユーザーは、普段「Andoroidというものがある」ということすら忘れていることが多いので、「Andoroidで動作確認されず、明朝体が表示されてほしい箇所がゴシックで表示された間抜けなデザイン」が世界に公開されてしまう悲劇が起きます。
前述した「インストールされたフォントの違い」では游ゴシックという救世主がいましたが、この問題を解決するためには「noto serifなどの明朝体のWebフォントを使用する」以外の解決策はありません。
Appleユーザーから見るとAndoroidはカスかもしれませんが、モバイルにおけるAndoroidのシェアは、PCにおけるMacのシェアよりも全然高いシェアを占めていますので、「全く対応しない」という対応は難しいでしょう。

モバイル用のデザインデータの文字サイズは大丈夫？

前提として、モバイルデザインをマークアップする際のデザインデータは、「解像度2倍」で作られていることが多いため、コーダーの思考のデフォルトは「解像度が2倍のデザインデータが支給される」です。
アートボードが380px程度であれば「解像度は等倍」という認識でマークアップしますが、アートボードが750px等であれば完全に「2倍」で理解します。
「解像度が2倍」のデザインデータを実際にマークアップする際、フォントのサイズは「デザインデータの半分」に設定します。
例えばデザインデータ上14pxが設定されている場合、実際のブラウザでは7pxという「誰が読めんねん」文字サイズが設定されてしまい、クライアント確認時にディレクターが怒りの矛先になってしまうことでしょう。
（個人の偏見ですが、特にDTP出身のデザイナーさんに多いような）
小さすぎて読めない問題を別にしても、ブラウザによっては「表示可能な最小サイズ」が設定されていますので、7pxや8pxは全て10pxで表示され、デザイン意図とは大きく離れたものが出来上がるでしょう。

テキストとしてマークアップしてほしい箇所のフォント設定は適切ですか？

デバイスフォントを使用したい箇所に明確な指示がない場合、コーダーは「ヒラギノ」や「noto sans」等のフォントをテキストとしてコーディングし、「それ以外のフォント」は画像としてマークアップする判断をします。
タイトルやメニューといった装飾を施したい箇所に「見出しゴ」等のデフォルトではインストールされていないフォントが設定されている場合、
方針としては

・画像として表示する
・別の一般的なフォントで表示する

の2択を選択することになります。
個人的な感覚では、「見た目が違うじゃないか！」や「改行位置が違うじゃないか！」という聞き飽きたクレームを懸念して前者の選択がされてしまうことが多いように思います。
「テキストとしてマークアップしたい箇所にはこのフォントを使用する」という取り決めは、マークアップ前だけではなくデザイン前にチーム内で認識を合わせておくと後半の工程で問題の発生する可能性は下がります。

リンクに対する指示は明確ですか？

カード型のレイアウトの記事一覧ページ等をマークアップする際等に、リンク範囲（クリッカブルな範囲）を「カード全体にするか」「詳しくはこちらボタンだけにするか」等を決めておくことは大切です。
ボタンがあると「ボタンがクリックできれば良い」と進めてしまうコーダーは多いと思いますが、後から「カード全体をリンクしたい」といわれると地味に面倒な作業が発生します。
CSSのセレクタの当て方によっては構造の変化で組みなおしということもあり得ますし、コーダーとしては結構イラっとするポイントです。
対象範囲が多い場合はお金の話になる可能性は十分にあります。

他にも、

・ホバーした時の挙動はどうするか
・リンク先を指示しているか
・訪問済みリンク（:visited）は未訪問と同様で良いか
・別タブで開く必要があるか

など、意外と支持されないまま進んでしまうものは多いです。
リンク先を指示されない場合、href属性は全て「#」で納品されるでしょうし、訪問済みリンクの指示をしていなければ昔ながらの紫リンクが表示されるかもしれません。

最後に

本記事に挙げさせていただいた内容は「デザイナー」でも「コーダー」でもない専業ディレクターの場合は作業のイメージも湧きにくいでしょうし、「問題になるまで気づかない」ことも多いのではないでしょうか。
特に代理店でディレクター業をやっていると、「社内に制作チームが無いのでそんな情報知り得ないとい」うこともあると思いますし、
ディレクターにとっては「当たり前」と思っていることも、「指示されなければ楽な（望まれない）方法」で納品されてしまうことも多いと思います。

デザイナーがマークアップの指示を出す場合、「画像」や「フォント」に関してはコーダーよりも圧倒的に知識が豊富なケースが多いと思いますので、デザイナーが予め主体的に決めておくとコーダーとの良好な関係が築きやすいでしょう。

制作に関わる担当者全員が「ある程度担当外作業について知識がある」ことが理想ではありますが、職域が不明確になる原因にもなりますので、担当者が気づきにくいことを先回りできるディレクターは「良いディレクター」の一例と呼べるのではないでしょうか。
ディレクター職の標準的なデバフになってしまう「残業」「ストレス」「クライアントの叱責」等とは距離を置いた精神的な安息を勝ち取るために、本記事に挙げた内容が参考になれば幸いです。