とあるコーダーが夢みるデザインカンプ(*´∀｀*)

デザインカンプのファイル形式、もらって嬉しい順

ずばり、以下の順番です。

Figmaのデザインカンプを受領した頻度が低いので、今はやや苦手気味ですが、慣れればきっと好きになりそう。AdobeXDとともに、いずれもディスプレイで表示するプロダクトのデザイン制作を目的に作られたソフトなので、コーダーにとって（おそらくWebデザイナーにとっても）使い勝手がよいです。

AdobeXDについては、コーダーの立場からは、以下の3点が嬉しいポイントです。

コーディングに必要な情報を取得しやすい

インターフェースがスッキリしており、あちこちのパネルを開いたり閉じたりしなくても、カラーやテキストのプロパティなどはだいたいワンクリックで、テキスト要素自体も少ないクリック数で取得できます。

サイト全体の構成要素を俯瞰しやすい

使用しているカラーやフォントの情報を登録する「アセット」というパネルがあり、もろもろ登録済みのデザインカンプをいただけると、コーディングの取っ掛かりが本当にらくちん。

判別しにくい色が複数使用されている場合、特定の色を全く異なる派手な色に変えて、コーディング時に識別しやすくしてしまうこともあります。Sass変数やカスタムプロパティで色を管理していればウェブページの側でも色の一時的な変更が簡単にできるので、奇抜な配色で作業を進めて色の指定ミスを減らすようにもできます。

色やフォントだけでなく、「コンポーネント」すなわちサイト全体で使い回す部品を登録することもできます。それゆえ、コンポーネントを意識してWebデザインを作ることができ、「ページによって仕様がバラバラ」というコーダー泣かせの状態にはなりにくくなっている気がします。

1ファイルにサイトの全ページのアートボードを配置できる

1ファイルにサイトの全ページ（数十ページくらい大丈夫そう）のアートボードを配置したとしても、IllustratorとPhotoshopのようにファイルが重くなりません。全てのページが1ファイルに収まっていると、サイト全体の俯瞰がさらにしやすくなります。
AdobeXDの場合、全体がほぼ出来上がった状態でデザインをいただけることが多いのですが、デザイナーの方にとっても作業効率がよい仕様なので、制作期間が短縮できているゆえかもしれません。

IllustratorとPhotoshopでのWebデザイン制作をそろそろやめて欲しい問題

AdobeXDに慣れた後では、こういった機能がないIllustratorとPhotoshopのデザインカンプから作業をするのが殊のほか億劫に感じるようになってしまいました。とはいえ、AdobeXDでIllustratorとPhotoshopのファイルを開くこともできるので、情報取得のためだけにAdobeXDでファイルを開いて、XD形式で保存しておくこともあります。

PhotoshopについてはZeplinというサービスを利用すると、AdobeXDのデザインスペックと同様のものをブラウザ上で閲覧できるようになります。というか、デザインスペックより使いやすいので、AdobeXDでデザインを支給された場合でも、このサービスを利用することがあります。

ちなみに、Zeplinには2倍サイズで制作されたデザインを等倍で表示する機能もあるのが神。Photoshopのデザインカンプ受領時には利用しない手はありません！（とはいえ、画像はスマートオブジェクトで埋め込めば劣化しないから、2倍サイズで制作する意味ってもはやないんじゃない？と思ったり…）

とりわけIllustratorのデザインカンプを受領するのがあまりにイヤ過ぎるので、かなり以前から割増料金を設定していますが、近頃はPhotoshopもそこそこイヤになってきて、来年辺りからPhotoshopにも同様の対応をしようかと思っています。

コーダーの都合ばかりを述べてきましたが、AdobeXDには、スタック・リピートグリッド・コンポーネントの管理・プロトタイプの作成など、Webデザインの制作のために追加したとしか思えない便利な機能が次々と搭載されているので、デザイン制作ツールとして採用すれば、IllustratorやPhotoshopよりもデザイン制作の効率も格段に上がる気がします。

テキストのアウトライン化

最近は、見出しなどのテキストを画像として表現するWebサイトは減ってきているのですが、まったくないワケでもありません。もし画像として書き出す要素にテキストが含まれている場合、テキストはアウトライン化しておいていただきたいです（アウトライン化してほしくないヒトもいるらしいので、あくまで筆者の場合）。コーディング作業を行うPCに該当のフォントがインストールされていないと、デザイン通りの画像を書き出すことができないからです。

印刷物用データ納品時の慣習かと思いますが、Illustratorユーザーの方は_ol等のサフィックスをつけてファイルに含まれるオブジェクト全てをアウトライン化したデータを同梱されることが多いようです。ですが、あくまで必要な箇所（画像化するテキスト）のみをアウトライン化していただきたいです。

_ol付き、_olなしのデザインカンプが2種類あると、コーディングするときに似たような見た目の複数のファイルを開く必要があり、作業が煩雑になります。また、オブジェクト全てをアウトライン化するとファイルサイズが極端に大きくなり、ファイルを開くのに余計な時間がかかって、イライラすること必至。Illustratorがますます嫌いになること請け合い…

数年前までとは異なり、Webページに表示する要素に画像で表現されたテキストを表示する機会は著しく減っています。バナーなど画像自体に何らかのメッセージを表示したい要素のみに限られることが殆どで、アウトライン化が必要な箇所はほぼありません。「全体をアウトライン化」などという横着なことは、Webのデザインカンプに於いてはそろそろやめていただきたい、というのが正直な思いです。

デザインカンプの支給順序

AdobeXDやFigmaのデザインカンプの場合、サイト全体のデザインを一気に支給していただけることが多くなってきました。

とはいえ、デザインができたページから支給され、自転車操業的にコーディングを進める、なんてことも、未だに無くはありません。そんな場合でも、支給順序を以下のようにしていただけると、効率的に制作を進められます。

ワイヤーフレーム

ワイヤーフレームとともに、デザイナーがデザイン制作の元にする資料（サイトマップ・テキスト原稿等）と同じものを支給していただければ、デザインFIXを待つまでもなく、マークアップと大まかなレイアウト、下層の空ページの作成、ひいてはCMS実装を先行して進めることすらできます。デザインとコーディングを同時に進められるため、制作期間が大幅に短縮できるはずです。

階層によってヘッダのデザイン等が変わるものがある場合、ワイヤーフレームに詳細を明記していただけば、先に出力内容の分岐をしておくことができます。

コンポーネント一覧

複数のページで使い回す要素（コンポーネント・モジュール・パーツなど会社によって呼び方はイロイロ）があれば、それをまとめたデザインカンプをまず頂きたいです。ワイヤーフレームから適用するコンポーネントが判断できる場合は、コンポーネントのclass名も含めてマークアップ作業を行っていきます。下層ページにコンポーネントのみで構成されているページがあれば、下層ページが着々と仕上がっていきます。

コンポーネント一覧の中に下層ページの基本的な構成要素（下層のページヘッダ、パンくずリスト、コンテンツ幅等）も含まれていると、より正確に仕上げていけます。

下層ページ

下層ページの支給順序は、CMSで制作するサイトの静的コーディングのみをお任せいただく場合は、動的なページ（カテゴリアーカイブ、記事アーカイブなどの一覧ページ、カスタムフィールド等を使用するページ）のデザインを先にしていただくと、全体の制作フローが効率化できるのではないでしょうか（とはいえ、「コーディング→CMS実装」という順での制作よりも、「CMS実装→コーディング」の方が作業効率の点でお勧めです）

なお、テキスト原稿を流し込むだけの構成が単純なページは、おおよその仕様説明とテキスト原稿があれば十分で、デザインカンプは不要です。
テキストを転記するだけのデザインカンプを作るのは無駄でもありますし、転記の際にミスが発生する恐れもあります。無駄な作業は極力省き、ミスの発生を減らすフローを作って、どの役割のヒトも幸せになれたらよいのに、と思います。

トップページ

トップページはイレギュラーな要素が多く、下層ページのコンポーネントを使い回している場合もあるため、コーディングを行う際は最後にした方が作業効率がよくなります。とはいえ、何故だかトップページのデザインをいの一番にいただくことも未だにあって、そういうときは、いささかゲンナリします…。

なんかのセミナーで「トップページなんてむしろなくてもいいじゃん」と大胆なことをおっしゃったスピーカーの方がいました。
確かに、トップページは下層ページのアーカイブとしての役割しかなく、見た目が派手な割には内容がスカスカなことも多い気がしますし、なくてもいいというのは言い過ぎにしても、それほど重要視しなくてもいいのではーという気はします。

実際、筆者がサイトを閲覧する場合も、トップページをじっくり読み込むなんてことはホボありません。検索でたどり着く場合は下層ページが多いですし、検索結果に下層ページの情報も表示される場合はそちらをクリックすることが大半です。

クライアントの要望もあるのかもしれませんが、トップページを重要視し過ぎるあまり、その見た目をまずは仕上げてなんとなくデキタ感を示す、なんて制作フローはそろそろやめてもいいんじゃないかなーと、個人的には思っています。

デザインカンプ以外に支給していただきたいもの

ブレイクポイント

ブレイクポイントは敢えて指定してくる方は殆どいないため、指定がなければ今の所768pxモバイルファーストとしています。

下記のようにmixinを設定しておき…

//_setting.scss
$bk_md: 768px;

@mixin mq {
  @media only screen and (min-width: $bk_md) {
    @content;
  }
}

画面サイズごとにルールをまとめるのではなく、ルールセットごとに記述していくと、ファイル内を行ったり来たりしなくてよいので、運用がらくちん。

@use "../foundation/setting" as s;

.c-title {
  font-size:20px;
  @include s.mq {
    font-size:30px;
  }
}

font-family

発注元に「ウチの理想のfont-family指定順」というものがある場合は先に伺っておきます。

Webフォントを使用する場合は、それに準じて記述します。本文中で英数字と全角文字でフォントを使い分けたい場合は、欧文フォント→和文フォントの順での指定となります。

筆者自身は、読めさえすれば文字の形は何でもいいと思っているので、特に指定がなければ個々のデバイスのデバイスフォントで表示されるよう、sans-serifのみを記述します（sans-serifのみだとWindows環境でのシステムフォントが游ゴシックの場合に細身になってしまうので、游ゴシックとsans-serifを指定することが多い）。

Webフォントの情報

Webフォントを使用する場合は、必ず、どのフォントサービス（Googl Fonts、Adobe Fonts、その他の有償サービス）のどのフォントを使用するのか情報が必要です。大抵のフォントサービスには該当のフォントの情報を記載したWebページがあるので、そのページのURLをご案内いただきたいです。

なお、Adobe FontsをWebフォントとして利用する際は、制作者ではなく、クライアント自身がAdobeのライセンスを所有している必要があり、クライアント自身に埋め込みコードを発行してもらう必要があります。

以前、頂いたデザインカンプに手書き風フォントが使われている箇所があり、てっきり画像化するのだろーと思ってアウトライン化を依頼したところ、「そこはWebフォントなんで」と返されたことがあります。デザイナーの方であれば、フォントを見ればそれがどこそこのサービスのWebフォントであるとひと目で分かるのでしょーか？？？「Webフォントなんで」トカ言われても、文字の形に無頓着な筆者は、情報を添えていただけなければWebフォントなのかどうかは判別できません(O_O)

デザインスペック（AdobeXDのみ）

デザインスペックというのは、AdobeXDで制作したファイルをブラウザで閲覧できる状態にしたものです。UIはファイルそのものよりもスッキリしており、デザインスペックからの方がコーディングに必要な情報を素早く取得できます。

アニメーション・JS等、動的部分について

hoverエフェクト、スクロールに伴うアニメーション、ナビゲーションのカレント表示、及びJS実装が必要な箇所があれば、指示書、または実装サンプル・プロトタイプをデザインと同時にいただきたいです。コーディングがある程度進んだ後に指示書を出されると、マークアップを大幅に変更しなければならない場合がありますし、後付で修正を加えていくと、思わぬところで不具合が発生し、細々とした調整が必要となります。

デザイナーの方はデザイン作業で手一杯でそれどころではないのか、もしくは社内のコーダーとは都度相談してよしなに実装してもらえ、初めから事細かに指示書を作る必要がないのでしょうか、何度依頼しても、こういう情報を細々と後出しにされ、煮え湯を飲まされ続けたことが結構あります(O_O)

レスポンシブ対応の詳細

レスポンシブ対応が当たり前になってきた今日このごろ。一口にレスポンシブと言っても、実は対応方法はイロイロあります。
通常は「ブレイクポイント未満、ブレイクポイント以上～コンテンツ幅未満はリキッドレイアウト、コンテンツ幅以上は固定レイアウト」というケースが多いのですが、時折「PC表示時は固定レイアウト」といった要望もあります。後から変更するのは結構大変なので、早い段階で伺っておきたい情報のうちの一つです。

ディスプレイサイズがアートボードサイズと異なるときの挙動

とりわけアートボードの横幅（もしくは高さ）全体に広がる要素がある場合、アートボードよりディスプレイサイズが大きいとき、小さいときのそれぞれの挙動についての指示書を支給していただきたいです。

例えば、横幅いっぱいに広がる画像がある場合、アートボードの幅を最大幅として左右に余白を付ける、横幅はディスプレイいっぱいに広げて縦横比は固定にする、または高さを固定にする、等。

ディスプレイの高さいっぱいに配置する要素があるときは、縦横比が大きいディスプレイ（極端に横長）ではその要素の中身がディスプレイからはみ出してしまう恐れがあります。

だいたいはコーダーの裁量で、どんなディスプレイでも途切れなく要素が表示されるよう最善を尽くしますが、後から「そうじゃないんだけどー」トカ言われるとつらいので、ディスプレイサイズの変化に伴うレイアウトの変化に関して想定している事柄があれば、デザイン提出時に指示書を同梱していただきたいです。

リンク要素のhref属性に記述するURL

内部リンクはだいたい予測できますし、外部リンクはググれば見つかる場合もあります。ですが、予め全てのリンク要素に関してURLを明示していただけば、お互い確認の手間が省けます。

デザインデータでは隠れている部分のテキスト原稿

トグルパネルやアコーディオンパネル、タブパネル等を使用する箇所があり、かつそれぞれのパネル内の要素にスタイルの違いがないときは、隠れている部分全てを表示した状態をデザインで再現して頂く必要はなく、テキスト原稿をそのまま支給していただけば結構です。

フツーはそんな感じで原稿を頂いているのですが、一度だけ、パネルが閉じているとき、開いているときをそれぞれ別のアートボードとして作成し、かつ中身のテキストも逐一入れてあるデザインカンプを頂いて仰天したことがあります。パネルの開閉をプロトタイプで表現していたわけでもありませんでした。こういうところこそ、デザイナーの方が作業を端折って楽できるところなのに、ナゼ…。

余程時間が余っているのならこのようにしていただいても構わないのですが、原稿を転記するのはコーダーにやらせればいいことなので、繰り返し要素のテキストまでデザインにしっかり作り込むのは、無駄な作業としか思えません。ヘンに細部まで作り込まれたデザインよりは、要点を押さえたシンプルな制作物を素早くいただけたほうが余程嬉しいです。

ちなみに、原稿として提出していただくのは、.txt, .mdまたはGoogle Document、Dropbox Paper等、どこでも誰でも開ける軽めのファイル形式で支給していただきたいです。Word、RTF等は特定のソフトが立ち上がって開くのに時間がかかってイライラしますし、Wordなんかはこのごろ全く使わないので、今後インストールしなくなる恐れもあります。

alt属性用テキスト原稿

テキストのアウトライン化を行った場合、そのテキストの量がそこそこ多く、そのテキストをalt属性に記述する必要がある場合、そのテキスト原稿をご提供いただきたいです。

ファビコン用画像

これらのファイルをpsd、aiなどのファイル形式のまま同梱される方がいらっしゃいますが、テキストのアウトライン化ができていない、画像のリンク切れ、ライブラリのリンク切れなどのトラブルがあり得ますし、ファイルサイズの大きいものをばかすか送られると迷惑だったりします。

書き出し済みの画像ファイルを送っていただけば、転送の手間、開く手間、書き出す手間がことごとく無なくなります。

OG画像

全アートボードの画像

仕上がりの最終確認として、出来上がったページのスクリーンショットとアートボードを書き出した画像を重ねて比較する作業を行っています。

デザインカンプで使用されているフォントがインストールされていない環境でファイルを開くと、そのテキスト周りには当然ズレが生じます。また、Macで製作したデザインカンプをWindowsで開いたとき、line-height等にズレが発生することがありました。

ですので、必ず使用フォントが全てインストールされている環境、すなわちデザインを制作した担当者の制作環境に於いて書き出した全アートボードの画像を支給していただくことにしています。

Photoshopについてはテキスト周りのズレはほぼないのでこの限りではありませんが、書き出しの手間が減るので、なにはともあれ同梱していただければ助かります。

以前、上記の旨を申し述べて書き出しを依頼したら「ウチのデザイナーも急がしいんで」と、なんだかびっくりする返しをされ、断られたことがあります。そう細かいところまで合わせなくても結構、と重ねて伝えられたため、目視で調整を行ったら、後から実に実に細かい調整依頼が来てしまい、なんか最初と言ってること違いますよね、と異議を唱えて追加料金を請求しました。
いくらデザイナーが忙しかろうとも、たかだか10数ページ分の書き出しを行うのに10分もかからないんじゃないでしょうか？一方、その多忙なデザイナーが細かい修正出しをするのに、恐らくその何倍もの時間がかかっていたと思われます。初めから書き出し画像を送っていただけば、お互い費やさずに済んだ時間なんで、急がば回っていただきたい、ホントに。

デザイン制作時に気をつけていただきたいこと

デザイン制作ツールの基本設定

Illustratorでもプリセットのアートボードを選べるようになったため、「ピクセルビュー」になっていないデザインカンプはさすがに見かけなくなりましたが、未だにカラーモードがCMYKになっているモノを渡されて、ぎょっとすることがあります（プリセットを使わなかったのかしら？？？）。

オブジェクトのサイズが整数でない場合、画像として書き出したときにモヤっと表示されたり、ヘンな隙間ができる原因となります。AdobeXDでは「Remove Decimal Numbers」というプラグインを使用すると、オブジェクトの小数点以下を切り捨てることができます。

Photoshop、Illustratorを使用する場合、モバイルのデザインを2倍サイズで制作される方が多いですが、AdobeXDの場合は等倍で制作していただいて大丈夫です。単純にプリセットのアートボードを選べばOK。オブジェクトのサイズが実寸になるので、コーディングもらくちん。

なお、2倍サイズでデザインカンプを制作する場合は、以下のことに注意していただきたいです。

デバイスごとにデザインカンプを用意する場合

ヘッダ・フッタなどの共通要素、モバイル用のグローバルナビゲーション、レイアウトが複雑な箇所やモバイルとPCで著しくレイアウトを変えたい箇所のみ、モバイル用のデザインカンプを制作いただき、その他の部分はPCサイトのデザインを元に、こちらの裁量にまかせていただくと、制作費を抑えられます。

モバイル用のデザインを頂いてしまうと、頂いた以上はそれを忠実に再現する必要性が生まれ、「書き出し画像とページのキャプチャを重ねて表示確認」する工程がいちいち発生してしまいます。また、コーディングの経験がないデザイナーの方がデザインカンプを制作する場合、コーディングの都合をとことん配慮しない自由過ぎるレイアウトを作ってしまうことがあり、余計な手数がかかってしまう場合がしばしばあります。手数がかかる分、当然制作費は上乗せとなります。

なお、メインビジュアル等デバイスによる画像の出し分けが必要となる箇所については、それぞれの画像データをご用意いただければ対応します。

テキスト

フォントの統一・指定

テキスト周りについては、実は注文がたくさんあります。まずは、デバイスフォント（またはWebフォント）で表現するテキストについて。

先に、画像化するテキストはアウトライン化しておいて欲しい旨を述べましたが、そうはいっても、対応しておいていただけない場合の方が多く、こちらから改めてアウトライン化の依頼を出さなければならないことも少なからずあります。
アウトライン化が必要なフォントは、どの環境にも存在するような汎用的なフォントではなく、装飾性の高い特殊なものであることが多いです。AdobeXDでは「環境にないフォント」としてハイライトできるため、判断は容易に行えます。

ところが、そういった判断をしようとしたとき、困ったことがありました。テキストのフォントがまったくもって統一されていなかったのです。どういう状況かというと、本文にヒラギノ角ゴ、游ゴシック、小塚ゴシック等が規則性もなく散りばめられていました。その上、英数字にも何種類かのフォントがまぜこぜで使われていたのです。果たして地の文にどのフォントを使いたいのかさっぱりわからないのもさることながら、「環境にないフォント」が幾種類も散見されるワケで、アウトライン化が必要な箇所の見極めのためのノイズになってしまいます。

このようなデザインカンプを受け取ってしまったその後、テキスト周りの注意事項として、こんなモノを追加しました。

デザイナーの方の環境はMacであることが多く、当たり前のように本文等がヒラギノ角ゴになっていることが多いですが、筆者の制作環境はWindowsで、当然フォントのライセンスなんぞを購入しているワケもなく、「ヒラギノ角ゴ」は「環境にないフォント」扱いです。筆者の環境のみならず、世の中に出回っているPCでの閲覧環境はWindowsの方が多いので、Webフォントを使用しなければヒラギノ系のフォントは表示できない場合が多いワケです。であるならば、初めから一般的なWindows環境で表示されるフォントを使っておいたほうが、デザインと出来上がったページの印象の相違が少なくなるはずですし、筆者の作業負担も少なくなります。

厳密に言うと、「游ゴシック」もWindowsとMacでフォント名が異なります。Mac環境で「游ゴシック体」を指定したファイルをWindowsで開くと「環境にないフォント」扱いとなります。とはいえ、Windows環境でこれを「游ゴシック」に置き換えたとしても、フォントの形状は変わらないため、レイアウトが著しく崩れるということは起こりません。またAdobeXDで「環境にないフォント」扱いとなっているテキストはファイル全体でハイライト表示できるため、デバイスフォント使用箇所が一覧できてかえって好都合なのです。Webフォントを使用せず、かつfont-familyの指定にこだわりがない案件の場合は、「游ゴシック」を使用していただくのが、筆者にとっては最も都合がよいワケです。

フォント属性の統一

テキスト周りの注文は、まだまだあります。

コーディングの知識がないデザイナーの方にありがちな傾向で、印刷物と同様に多種多様のフォント属性を使いまくり散りばめまくるというのがあります。本文のfont-sizeが16pxだとすると、リード文を15pxにしてみたり、17pxにしてみたり…。デザインの素人からすると、思い切って18px、20pxにするならともかく、たいして印象が違わないfont-sizeに敢えてする意味ってあるの？？？と疑問に思ってしまいます。そんなこんなで、サイトで使用しているfont-sizeが10種類以上に登るなんてことも…。微妙な大きさの違いはプロパティパネルでいちいち数値を取得しないと判別できず、手数が増えること必至です。line-height、letter-spacingについても同様です。
本当に必要なら、値を取得してデザイン通りに表現するのもやぶさかではありませんが、あまり意味もなく、印刷物のデザイン制作の慣習で、なんとなくイロイロ散りばめた感満載のデザインカンプにする前に、もう少し考えて、値の統一を図ってもらいたいトコロです。

font-weightについては、ヒラギノ角ゴのW3～W6のウェイトが混在したデザインカンプを受け取ったことがあり、W4が適用されたテキストに対して「太字になっていない」と叱られたことがあります。W4って、太字か細字か判別し難いウェイトじゃね？？？と著しく困惑しましたが…。ちなみに、ヒラギノ角ゴをWebフォントとして指定されていたワケではないので、本文の表示はデバイスフォントでなされることとなり、W3～W6のウェイトを区別できるワケもありません。そんな事もあったので、デバイスフォントで表現するテキストに使用するフォントに対して、ヘンに細かくウェイトを指定できる「ヒラギノ」は「使用禁止」する措置を打ち出すきっかけにもなりました。font-weightを細かく指定したいなら、Webフォントを使用してくださいよ、と付け加えて。

厳密に言うと、WindowsやMacにプリインストールされている游ゴシックにもfont-weightが何種類かあるのですが（リテール版ではfont-weightの種類がもっと多い）、MacとWindowsで表示のされ方が異なったりイロイロと複雑で、結局Webサイトでの使用に耐え得るウェイトは2種類しかないので、確実に細字か太字か判別できるものを使用していただけば大丈夫です。

最近は和文フォントとしてGoogle FontsのNoto Sansを指定されることが多く、font-weightは100～900とよりどりみどりなので、喜び勇んでいろんなウェイトが使われたりしています。ですが（とりわけ和文フォントは）ウェイトの種類が多ければ多いほど、ページの読み込み速度に影響するので、ほどほどの使用に留めておいたほうが無難なのではーと思います。

テキストと親要素の関係

次に、テキスト量とそれを外包する要素の関係について、次の点に注意していただきたいです。

また、よくあるカードコンポーネントでは、カードに内包されるテキスト量の増減によって、レイアウトが変化する可能性があります。
あまりよく考えらてていないデザインカンプでは、コンポーネントが並べられた記事一覧のようなページの場合、ダミーテキストの量が同一の、見た目が全く同じモノが並べられていたりします。ところが、実際にWebサイトを運用するときは、コンポーネント内のテキスト量が多かったり少なかったりします。ですので、コーダーは言われなくてもテキスト量を極端に少なくしたり多くしたりして挙動を確認しながらマークアップします。

縦書きのテキストを配置するときは、画面サイズによってレイアウトの崩れが発生しないかどうか十分に吟味してデザインしていただきたいです

CSSで表現する色

CSSで表現する色については、以下のことを守っていただきたいです。

なお、筆者はだいたい次のように色の変数名を割り当てています。

AdobeXDのカラーパレットは、デフォルトではカラーコードがその色の名称となりますが、変更することもできるので、上記の名称をつけておいていただけると、コーディング時のカラー情報の取得がより素早くできるようになります。

画像

背景画像

困るのは、明らかに繰り返しパターンのように見えるのに、パターンの境界がわからない場合。すなわち、パターンを敷き詰めた「背景A」のような状態の画像をそのまま貼り付けてあったり、レイヤーがラスタライズされていて、パターンの元の画像を取得できなくなっている状態。そうなると、画像を最大限に拡大して目視で境界を探すか、それも難しい場合は巨大な画像をそのまま使うしかありません。

レイヤーの整理

マスク処理

Photoshopでは、アートボードからオブジェクトがはみ出していたとしても、アセット生成機能で書き出しを行うとはみ出した部分は除外された状態で書き出されますが、AdobeXDの場合ははみ出している部分も含めて書き出されてしまいます。
書き出し時のことを意識して、アートボードからはみ出る要素があれば、アートボード外の部分が書き出されないようにマスク処理してあると、たいそう助かります。

PCサイトのRetina対応

PCサイトでの画像のRetina対応は、明示がなければ基本的には行いません。
以前「PCサイトのRetina対応はして当たり前、世界の常識」と思い込んでいるデザイナーの方に、対応していないことを咎められたことがあります。以来、こちらでは基本的に対応しない旨を最初に伝え、対応が必要であれば明言してもらうようにしました。
ちなみに、その案件のディレクター兼クライアント自身は、Retina対応に関してはどうでもよいと思っていたようで、単にデザイナーがご自身の思い込みをなんとしても通したいだけだったように見受けられました。

デザイナーの中には、ご自身のRetina対応ディスプレイで完璧にキレイに表現されるWebサイトに仕上がらないと我慢ならない方が一定数いらっしゃる気がします。とはいえ、世の中のディスプレイ全てがRetinaディスプレイでもなく、画像の美しさよりも表示の速さが優先される場合もあります。対応は案件に応じて、クライアントやディレクターの方針に従って、というのが正解である気がします。

SVGで書き出す画像について

近頃は、ベクター情報を持っている画像要素はSVG形式で書き出すことが多くなってきました。SVGだと画像の劣化がないので、上記のRetina対応がハナから不要という利点もあります。

こんな感じで、PhotoshopのデザインカンプからSVG書き出しを行うのは大層手間がかかるので、該当オブジェクトが多数ある場合は、今後は更なる割増料金を請求しようかと思っております。別にオカネ儲けがしたいワケではなく、手間がかかる分の作業代金をいただくだけのことで、手間がかからないファイル形式でデータをいただけたほうが余程助かります。SVGで書き出す要素が大量にあるときは（というよりもWebのデザインカンプを制作するときはそもそも）、AdobeXDかFigmaの使用を検討していただきたいものよ、とつくづく思った一件でした。

リンク要素

リンク要素はアクセシビリティ的にも注意を要する要素ですが、デザイン時に意外とおざなりにされていることもあるカモ、と感じています。

リンク要素は、そうであることがわかるようなデザインに

オシャレ感を優先するためでしょうか、リンク要素がリンク要素であるとひと目で分かるようになっていない場合もあったりします。たとえば本文中のテキスト。リンク要素だけ色が変えてあるが、下線がないと、色の識別に問題があるユーザーにはリンク要素かどうか見分けられないかもしれません。必ずしも下線を付けなくてもよいですが、色を変えるだけという仕様にするのであれば、コントラスト差等に配慮して、誰でもリンクテキストであることを識別できる状態にする必要があります。もしくはクリックできる要素であることが判断できるよう、矢印アイコン等で補足してもよいかもしれません。

リンクエリアはドコ？

時折、リンクエリアがどこなのか判別しづらいデザインを受領することがあります。よくあるのが、記事一覧ページにカード状のオブジェクトが並んでいる場合。

過度なhoverエフェクト

hoverエフェクトは何のために付けるかというと、ソコにリンクエリアがあることをユーザに知らせるためであり、派手な動きや奇抜な動きをいくつもいくつも付ける必要はない、と筆者は思っています。余計な動きが加わることで却って気が散ってしまう恐れもありますし、むしろ下品な印象を与えるかもしれません。どうしてもそういう感じのモノを実装したいという依頼があったとしたら、prefers-reduced-motion（過度な動きをデバイスの方で制限しているかどうか検知するメディアクエリ。過剰な動きが閲覧の妨げになるユーザーが設定していることがある）の使用を勧めるかもしれません。

hoverエフェクトの指示がコーディングがほぼ終わってから後出しされ、マークアップをそこそこ変更しなきゃならないうえに、筆者にとっては過剰としか思えないほど多数のエフェクトが指定されており、うきーーーー(ー_ー+) ！！！！となった事例を一点紹介します。

次の図は、ボーダーの内側がリンクエリア、テキスト要素は全てテキストでマークアップしてあります。そして、このうち、いくつのCSSプロパティをhover時に変化させるよう、指示されたと思いますか？

なんと5つです＼(^O^)／

• 「Kame’s Life」のcolor
• 「Kame’s Life」のletter-spacing
• 「かめの生活を詳しく見る」のcolor
• 「かめの生活を詳しく見る」の先の矢印の長さ
• 「かめの生活を詳しく見る」の先の矢印の後ろの緑の形状の大きさ

こんなにもこまごまと、どこもかしこも動かさなくても、リンクがあることはわかるのに…。
そもそも、「詳しく見る」というテキスト自体が不要である気がします。「詳しく見る」と言うからには、遷移先のページの概要の記載があることが前提になるはずなのに、このコンポーネントには見出しと、それを英語に翻訳？したアルファベット表記があるのみです。つまりリンク先の情報として提供されているのは、実質見出しのみ。リンク先の情報が見出し以上に詳しいのは当たり前なので、敢えて「詳しく見る」と告げる必要は…ないですよね。

ニホンゴの文字より目立っているアルファベットも、もう少々小さくてもいいような…。ちなみにこのアルファベットは初めは背景として画像を表示させていたのですが、後出しでletter-spacingを変化させる旨を告げられたため、テキストとしてマークアップし直しました。更には、テキストとしてはニホンゴユーザーには不要な情報である上、スクリーンリーダーユーザーにとっては情報のノイズになりかねないため、aria-hidden=”true”を追記しました。

「詳しく見る」系リンクテキスト

そもそもの話ですが「詳しく見る」等の文字列のみをリンクテキストとしては使わないほうがよいのでは、と筆者は思っています。