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

ウェブ制作において、デザイナーとコーダー（フロントエンドエンジニアを含む）が円滑に共同作業をする上でもっとも重要なのが、デザイナーからコーダーへのデザインデータの受け渡しです。

現在までに約3万PVを集めている人気記事、『コーディングを助けるためにデザイナーができること』（執筆：高島）は、まさにその具体的なノウハウをまとめたものでした。

今回の記事はそれに追加する形で、私が気を付けているポイントをご紹介します。

1. クリッカブルエリアの指定

ウェブサイトには、テキストリンクやボタン、フォームなど、ユーザーが操作できるインタラクションが存在します。多くの場合は、要素の外郭がクリック/タップできる領域（クリッカブルエリア）となりますが、デザインによっては、あえて要素の外郭＝クリッカブル領域としないことで、使い勝手が向上することがあります。

しかし、デザインデータにクリッカブルエリアの指定がないと、コーダーはそれを読み解くことができず、デザイナーが意図したクリッカブルエリアにならないことがあります。

そのため、以下のようにデザインデータを作り、どこまでがクリッカブルエリアになるか、明確に伝えるようにしましょう。

例：メニュータイトル

下記のようなケースの場合、デザイナー側からの指定がないと、Aのテキストリンクだけがクリッカブルとしてコーディングされてしまいがちです。しかし、Bのように写真エリアや説明文のエリアまで領域を広げた方が、特にスマートフォンでは使い勝手が向上するでしょう。そのような場合、「ここまでがクリッカブルエリアです」と、デザインデータ上に明確な指定を入れておくといいでしょう。

引用：https://kanda-square.com/

例：目次（アンカーリンク）

記事ページで、冒頭に目次のアンカーリンクが入る場合、Aのテキスト要素のみをクリッカブルエリアにするより、Bのようにクリッカブルエリアを広げた方が、よりクリック/タップしやすくなります。このような部分も、デザイナー側からクリッカブルエリアを明確に指定しておきたいところです。

引用：https://hybridwork.cybozu.co.jp/condition/digital-divide/

例：ラジオボタン、チェックボタン

Aのようにフォームパーツ部分のみをクリックさせるより、ラベル（テキスト）までをクリッカブルにした方が、使い勝手は向上します。これに関してはわざわざ指示をしなくても反映してくれるコーダーは多いですが、経験の浅いコーダーと仕事をする際には、しっかり明示してあげるようにしましょう。

引用：https://kanda-square.com/contact/facilities/

2. 状態変化

デザインツールでビジュアルを制作するときは、各要素を「見栄えがする理想的な分量」で制作することが多いと思います。しかし実際にコンテンツが入ると、理想通りの分量にはならず、見た目が崩れてしまうことが多いです。そのため、「各要素ごとでどういう見え方になるのか？」を検討したうえで、コーディングで工夫すべき箇所は、そのことがコーダーに伝わるようにしましょう。

空の状態

検索結果や履歴など、表示データがないことが起こる場合は、空の状態（エンプティステート）のビジュアルも作っておきましょう。できればメッセージを表示させてユーザーの行動を促すようなUIを検討し、それもコーダーに伝えるようにしましょう。それをしないと、エンプティステートの時に空白がぽっかりあいたようなUIになってしまうことが起こります。

引用：https://www.ninben.co.jp/search/

部分変化

文字量の変化によって表示を変える必要があったり、表示要素/非表示要素が変わったりすることがあります。こうしたことも、ビジュアルの段階で、実際に挿入されるデータを想定したパターンを制作しておき、コーダーに渡すようにしましょう。

例：見出しの文字数が増減する

格納されている文字量に合わせてパネルの高さを決めるようなコーディングをしてしまうと、文字量の違いによってパネルの高さが変わり、ガタガタした印象になってしまうことがあります。こういった場合は、左右に並ぶパネルの高さを揃えることを明確に意図したデザインデータを作り、コーディング後にガタガタとした見た目になることを回避するようにしましょう。

引用：https://hybridwork.cybozu.co.jp/

例：表示件数の増減

重要なお知らせなどでは、運用する中で想定以上に文字が入ってきてしまうことがあります。事前に何件や文字数の制約を加えるか、あるいは制約を加えなくても破綻しないUIにあらかじめ設計しておき、情報の増減に対応できるコーディングができるよう、デザインデータに指示を含めておきましょう。

例：表示要素の有無

コンテンツによって、表示する要素と表示しない要素が混在する場合は、どの要素がそれにあたり、それぞれが抜け落ちることでどのような見た目になるのかを検討し、明確にコーダーに分かるようにしておきましょう。以下の例だと、「補足情報と購入ボタンは、データなしの場合があるので、購入ボタンの位置は常に固定でお願いします」と一言添えておくと、コーダーには意図が伝わるでしょう。

引用：https://www.ninben.co.jp/product/tsuyu_tare/

ロード中

データ取得に時間がかかることが想定される場合、体感する待機時間を短くする工夫が必要になります。例えば、スケルトンスクリーンといって、UIの枠組みだけ先に表示しておき、描画される画像の容量が重たい場合に、色を敷くことも可能です。このような時も、それが分かるようなデザインデータの作り方をするか、データの受け渡しをする時に明確に意図を伝えるようにしましょう。

引用：https://mailwise.cybozu.co.jp/column/

エラー

お問合せフォームなどで入力エラーが発生するのに、エラー表示のビジュアルを用意し忘れることは、よく起こります。フォームのデザインを作る時は、エラー表示の状態も必ず制作し、コーディングしてもらうようにしましょう。

引用：https://kanda-square.com/contact/facilities/

3. ブラウザの横幅による変化

ウェブサイトは、ユーザーによって閲覧時の画面幅が異なるのが大きな特徴です。そのため、起点となる画面幅（ブレイクポイント）によって「どのように見た目が変化するか？」を、きちんと設計しなければなりません。そしてそのことを、コーダーに明確に伝える必要があります。

例：ヘッダとグローバルナビゲーション

ヘッダには通常グローバルナビゲーションが格納されますが、画面幅によって、すべてのメニューを表示するのが難しくなることがあります。そのため、ブレイクポイントごとのヘッダの状態をビジュアル化しておくといいでしょう。

引用：https://kanda-square.com/hall/

例：画面幅が大きくなる時のメインビジュアル

PCサイトの場合、画面幅が2000pxを超える場合もあります。そのような時にどのように見せるのかも明確にしておき、画面幅の伸縮に対する明確なルールを、コーダーに伝えるようにしましょう。

引用：https://kanda-square.com/hall/

例）改行

下記の赤枠のように、ある画面幅ではbrタグを使って強制的に改行をしたいが、ある画面幅になると、1～3文字だけの行が発生し、不格好なレイアウトになることがあります。

これはCSSでコントロール可能なので、「○○pxより幅が狭くなったら改行なしでお願いします」のように、コーダーに明確に伝えるようにしましょう。

引用：https://hybridwork.cybozu.co.jp/condition/

4. ブラウザの高さによる変化

ウェブサイトは画面幅以外に、ブラウザの高さも意識してデザインする必要があります。ページによっては、ファーストビューの表示要素によって、コンバージョンや直帰率が変わることもあります。

以下の場合、ファーストビューの下にも要素が続くことを明示し、スクロールを誘発させたいため、代表的な画面の縦横サイズでファーストビューがどのように表示されるかをビジュアルで表現した上で、コーダーにデザインデータを渡しています。

引用：https://www.ninben.co.jp/

引用：https://kanda-square.com/hall/

5. アニメーション

アニメーションを適切に用いると、ウェブサイトに心地よい操作感を与えることが可能になります。ただし、アニメーションはビジュアルでは表現しにくいため、コーダーに対して丁寧に意図を伝えないといけません。

AdobeXDなどでは簡単なアニメーションが作れるため、それを活用してもいいでしょう。またアニメーションを作るのは手間がかかるので、ちょうどいい参考サイトがあれば、そのURLを提示するだけでもOKです。

アニメーションは、実際に当てはめてみると煩わしかったり使いにくく感じたりすることもあります。ブラウザ上の実際の動きを見て、コーダーと何度もやり取りしながら、仕上げていくようにしましょう。

さいごに

総じていえることは、コーディングを担当する方に余計な手間をかけないという観点で、デザインデータを作り、コミュニケーションを丁寧にすることが大事です。

経験豊富なコーダーだと、最低限のデザインデータでよしなに作ってくれることも多いですが、すべてのコーダーがそうできるわけではありません。コーダーによっては、アニメーションが苦手ということもあります。デザイナーは自分の頭でイメージできてても、他の人にはそうイメージできないこともあります。

大事なのは、自分だけでなく、プロジェクト全体で考えることです。デザイナーである自分自身の手間が増えたとしても、コーディングの手間が減ることでプロジェクト全体の手間が減るなら、デザイナーとしては積極的に関与していくべきです。

目先の自分の仕事だけではなく、プロジェクト全体で判断し、後工程のスタッフからもありがたがられるデザイナーになれば、デザイナーとしての価値はより一層高まるのではないかと思います。