Classiアドベントカレンダー19日目はデザイナーの@shio312が、デザイナー&エンジニアが共同作業///することで幸せになれるハックをご紹介します。

はじめに

アプリ/Webエンジニアがカンプを見て思うこと
・「せっかくDBのテーブル名、要素の名前と合わせたのにデザイン修正で構成変わって使えない….」
・「初期表示の場合は数値ハイフンなの?表示なしなの?なんなの？」
・「データがそもそもない時考慮してなくね?」
・「カンプだけじゃどういう挙動なのかわかんないからテストかけない(怒)(怒)」

あるあるですか？え、ないです？
デザイナーが上げてくるカンプの隙間隙間をエンジニアが埋めて行くように挙動を考える時、ありませんか？
開発着手直前、仕様の抜けに気がついて訊いてみたら、デザイナーが悩みだし、「やっぱ基本レイアウト変えるわ！めんご！」みたいなこと、過去ありませんでしたか？

そこで、画面設計を始める際に作業の手戻りと工数を極力無くせるような、外部設計も兼ねたデータをデザイナーとエンジニアと共同で作ってしまおうと思います。

手順

↓↓↓まずデザイナーがリードする↓↓↓

デザインカンプ（ワイヤーフレームでも可）を用意する

すごく簡単なアプリのサンプルをXDで作ってみました。

XDで作るとデザインスペックの共有やデザインの調整もXDで完結できるのでなお良いです。
異常時/状態違いのUIも言葉で説明できない場合は用意しましょう。

XDを起動する

爆速です

画面を新規ボードに貼りつける

共通UIはアートボードの外に別で貼り付けましょう。
異常時/状態違いのUIはアートボードを右側に追加してペタっ。

アートボードの外左側に仕様を記載するエリア枠を作る

こんな感じで...

UI名称を記載する

各UIの挙動を全て書きます。

添付の画像の文章はだいぶ足りてないです。
ちなみに、
　※ UIの種類（ボタン、フォーム、画像など）ごとに線の色を変えた方がわかりやすい
　※ 画面数が多い場合は、「共通定義」「機能ごと」でデータを切り分けると管理しやすい

プロトタイピングモードで画面遷移の先を繋げる

画面が複数あることがほとんどだと思うので、XDのプロトタイプモードで画面を繋げます。

バージョンをつけて保存する

バージョン管理ツールを使用するか、日付もしくはバージョン名をつけて保存しましょう。

↓↓↓次にエンジニアが動く↓↓↓

データをデザイナーからもらい、XDを起動する

爆速です（2度目）

上記デザイナーが用意した遷移、UI、挙動全て確認する

ツッコミどころいっぱいあると思います。

気になる点、足りない点はテキストツールで指摘する

デザイナーが記載した仕様の左側に指摘欄を矩形ツールで作成し、指摘だとわかる文字色で追記しましょう。

デザイナーでは書けないような外部設計や仕様について書き足す

DBなど内部仕様と関係あるような挙動がある場合は新たに欄を追加して追記してください。コピペで枠は作れます。
挙動に関わるものは詳細を書ききる方がいいです。

デザイナーに渡し、仕様を詰めていく

上記のフローを繰り返すことで、デザイナーは自身では気がつかない仕様や挙動についてデザイン時から気づき、抜け漏れのない画面設計を行うことができます。
そしてエンジニアは設計の初期段階から仕様を確認でき、機能設計やDB設計に着手することもできます。

どういうことをエンジニアとデザイナーが共同で記載したのかまとめると

画面デザイン（ワイヤーフレームでも可能）
画面を通しての共通仕様
画面それぞれの詳細な仕様（通常時、異常時、ユーザーごと、ユーザーが画面を操作することで反映される挙動も全て）
最新の仕様のバージョン

なぜXDで作るのか？

デザイン、外部設計、画面遷移、デザインスペックが１つのデータで全部見ることができる
XDでデザインすれば、最新のXDではZeppelinのようにデザインスペックを書き出すことが可能です。
※XD CC　ユーザーガイド
　
Sketchより単純明快、操作が簡単。なのにデザイナーとも親和性が高い
Sketchしか使ったことないよ〜っていうエンジニアさんも、ぜひ触って見てください。AdobeIDを登録した後、1ヶ月無料で試用できます。

というか詳細な画面仕様書を作る必要はあるのか？

完成プロダクトのイメージを共有できる
開発時スムーズに実装を仕様通り進めることができる
テストの際仕様通りに動くかの指標にすることができる
実際のプロダクトを触っても再現できないような仕様を記載することで、改修の際の手助けになる

inVisionなどのプロトタイピングツールの進化によって、実装指示書を書く手間が省けるようになりましたが、詳細な仕様を説明する機能は不十分だったりします。
XDに貼り付けた（作成した）デザインに遷移と仕様を追記することで、カンプやプロトタイピングツールだけではわからない挙動をチームで、少ないデータで管理することができます。
そして、一つの資料に情報をまとめて共有することで、チーム内での仕様の認識のズレと属人的な仕様の把握を防ぐことができます。

最後に

今回はAdobeXDを使ったチートな画面仕様書をご紹介しましたが、私自身はプロジェクトに合わせてInDesginだったりGoogleスライドを使って仕様書を書くことも多いです。
みなさんの環境にあった、画面仕様の資料をデザイナーと一緒に作ってみてください。