コーディング時のデザイナーとのコミュニケーションについてガイドラインを作成してみました

vivit株式会社でアウトドアメディア:hinataの開発をしています河村です。 今回はコーディング時のデザイナーとのコミュニケーションについてガイドラインを作りましたのでそのお話を書こうと思います。

きっかけ

以前からデザイン改修やLP実装などの開発案件が入る際、フロントエンドエンジニア・デザイナー間で細かい部分の仕様のやりとりが増えていたという問題が発生していました。 簡単な例ですが、以下のような一覧の要素があったとします。

f:id:Kawam:20201001093052p:plain

この内容が3行を超えた場合はどうなるでしょうか?

(4行に高さが延びる場合) f:id:Kawam:20201001093054p:plain

(3行で収めたい場合) f:id:Kawam:20201001093057p:plain

エンジニア側としては4行目に達することも想定して実装をしなければならないため、その場合にどちらのデザインで実装すべきなのかは把握しておく必要があります。 こういった一つ一つについて確認のやりとりが発生すると、結構なコミュニケーションコストになります。

作成したガイドライン

そこで、デザインが納品される際にどのようなことが明確であれば開発がスムーズに行えるのかという点を洗い出してチェックシートを作成しました。 内容は以下の通りです。

  • モニターサイズによる可変

    • PCのウインドウサイズが変わった場合やSPでデバイスの画面サイズが違う場合の表示
  • カラーコードの指定

    • カラーコードは既存通りのものなのか、別に指定しているのか
  • アニメーションの挙動

    • モーダル・サイドメニュー・スクロール固定ヘッダーなどのアニメーションについてはデザインに落とし込むのが難しいため、参考サイトのURLを載せておくなどして対応しています。
  • クリックon,off、マウスオーバー時、disabledのデザインパーツは用意されているか

  • 文字数が表示領域を超える場合、要素が増える場合、要素が一つもない場合の想定をされているか

  • フォントサイズの指定(h1,2,3,本文)ごとにルールが決まっているか

  • フォントの指定はあるか

  • マージンのルールが決まっているか

  • 文字の視認性が保たれているか

  • 機能デザインがあれば仕様が固まっているか

    • 一画面の中にフォームのエラー表示や決済・画像アップロードなどの完了の文言を表示する場合に、デザインが用意されているか
  • pxは2で割り切れるか?

    • retina対応で倍のサイズに書き出す必要がある場合、実際の表示サイズ指定は半分になるのでその指定ができるようになっているか。
  • テキストに誤字・脱字・スペルミス・機種依存文字macの絵文字とか)がないか

  • 意図的ではない表記のゆれがないか

    • 例:WEB・Web・ウェブなど
  • 文字の表記が統一されているか

    • 半角・全角、日付の表現など

項目としては少々多いかもしれませんが、項目追加などでは既存のデザインに合わせる場合などもあるので毎回全てが当てはまるわけではありません。

やってみた結果

こちらのガイドラインを導入してみた結果、体感的にではありますが確認のやりとりは少なくなりました。 また、デザイナー側からもエンジニアが実装する上でどんな情報が必要なのかが理解できて、やりとりがスムーズなったというフィードバックもいただきました。

まとめ

毎回同じようなやりとりをしているのであれば、確認事項は先にわかっていた方がお互いに健全に仕事ができます。 特にエンジニアは仕様が不明確だと実装時に不安になってしまうものなので、こういったガイドラインがあるとよいアウトプットができるようになると思います。