全画面カンプを作ってる人へ。デザインガイドラインを作ろう！
ゆいです。こんにちは！暑いですがみなさん水分とっていますか？お茶を飲みながら書くので、好きな飲物を飲みつつ読んでください。
今日はこんな方に向けて書きます✍
デザイナー・企画・PM・ディレクターさん
- 同じようなページを何ページも作っている・確認している(TT)
- すべてのページのデザインカンプを納品物に定義している・されている
- 動的に変わる要素（テキストデータ）もデザインカンプですべて作成しチェックしている
- デザインガイドラインは受託には関係ないでしょう？ と思った方
実装（エンジニアさん・コーダーさん）の方
- １ページごとにデザインの数値を確認しています
- 各ページで数値が違い、実装時に戸惑うことが多い(-_-
- フェーズ・ページによってパーツに差分があり微調整が無限にある
この辺の問題をサクッと解決するのが「デザインガイドライン」です。
デザインガイドラインとは？
デザインガイド / 実装指示書 / デザイン指示書…など呼ばれるものです。
この記事では「デザインガイドライン」と統一します（他に呼び方があったら教えて下さい）。
デザインを意図通りに実装してもらうためにデザイナーが作成するドキュメントです。
ガイドラインは、設計したUIをデザインカンプに落としたあとに実装者に引き渡すタイミングで必要です。図は「開発」となっていますが「実装」と捉えてください。
最近ではデザインの数値確認をZeplin / Figma で行うことが一般的だと思うのですが、1ページずつの数値を確認するだけではなく全体のルールを明記することで双方の効率化を高めることができます。
デザイナーはUI設計したワイヤーをもとに、全体のレイアウトをパターン化し、UIデザインのルールを策定します。それにより画面すべてをカンプに起こす必要はなくなります。必要なのは全体を網羅するUIコンポーネントの作成と、デザインルールを整理し明確にすることです。レイアウトがユニークなページやコンポーネントのテンプレートとなるページはカンプを作成します。どのページをカンプとして作成するかは、ステークホルダーと握って決めていました。
つまりデザインガイドラインの内容は、大きく以下の３つの項目となります。
①全体の共通ルール
・各種デバイス対応の定義
PC / スマホ / タブレット、レスポンシブ、オートレイアウト時や縦横切替したときの挙動を想定しどこを固定にしどこを可変にするか書いておきます。スクロール時の挙動・フッターヘッター固定など、を考慮します。デザイナーがすべての挙動を先回りし完璧に想定することは難しいです。実装の方とコミュニケーションを取りながら決めていくイメージです。対応ディバイスについても、ステークホルダーと相談しつつ握っていくと作業範囲が抑えられます。
・動的コンテンツの制御
・エンプティ表現（コンテンツが空のとき）をはじめ、ページング、ログイン時、ログアウト時などの想定も共通項目です。ダイアログなどは標準コンポーネントを使うか、エラー表現をどうするかも実装の方と握っておきます。
想定する動的コンテンツについては以下の記事に詳しく載っています。
上記記事を参考に項目を決めると大体網羅できると思います。
・デザインルール
マージンルール、フォントルール、代表的な余白、タイトル(H1,2…)、本文など、全ページ共通で決まっているものは、意味を明確にしつつ整理できます。ホバー表現、オンマウス、タップ表現、活性、非活性、ボタン表現、色や挙動の指定も含まれます。
②コンポーネントリスト
UI設計（ワイヤー）と表層デザインとの紐付けです。使っているコンポーネントとレイアウト・UIパーツの当てはめ方を明記します。私はワイヤーに書き込んでいました。
ところで、ワイヤーはUIデザイナーが書く、についてびっくりされることがあったのですが、私はワイヤーはUI設計だと捉えています。なのでUIデザイナーのお仕事ですね。
③数値確認
ZeplinやFigmaを利用し、実際のカンプからページごとの数値指定を行います（今は昔、Photoshop時代ではInkやmarklyを使っていましたね）。
カンプで作成した実際のページで細かな数値を確認してもらうことで全体のデザインルールとコンポーネントリストを立体的に把握することができます。
デザインガイドライン作成時に気を付けていること
ドキュメントはまとめる
FigmaやSketchはPagesを1ページつくりスライド風に使いうことで上記の①〜③は一緒に渡すことができます。ドキュメント作成した当人は、何にどの内容が入っていたか把握できますが、渡された人はドキュメントの把握が大変です。相手の負担は減らしたいですね。
なおカンプとドキュメントページは、きっちり分け、違いがわかるようにしたほうが混乱が少ないです。
サンプルをつける
やってほしい挙動があればサンプルを必ず付けましょう。例えば
🙅 ＜ボタンをホバーしたときにふわっとしてください
🙆 ＜http://ianlunn.github.io/Hover/ の fadeと同じにしてください
CSSが書ける人は、CSSでしていたほうがいいと思います。このあたりは実装の方とコミュニケーションをとって進めたほうがうまくいくことが多いです。デザイナーができるのは絵に餅をしっかり描くことです。ユーザーに美味しく食べてもらうために、どんなドキュメントにしたらわかりやすいか、実装の方とのコミュニケーションの道具としてガイドラインを作るというという側面もあります。デザインガイドラインはステークホルダーやエンジニアさん、とのコミュニケーション・ツールの一つですので、相手に伝わりやすいかを意識して、わかり易く作るようにしていました。時間が許す限り加筆し、疑問を減らすように努めていました。
デザインガイドライン自体のメリットは、独学でUIデザインはじめた方へ。デザインガイドラインについて語ろう！という記事で散々語っています。こちらで書いているガイドラインも基本的には一緒のメリットが上げられます。ガイドラインを自分のデザインに対して作成することで、
- 自分のデザインを客観的に整理し整合性をとれる
- ユーザーの集中力を乱さない・混乱させない
- 実装者を混乱させない
- 運用も安心
など、工数の削減以外にも良いことがあります。
後輩を育てている方は、デザインルールとコンポーネント作成をしたら後輩にパターン展開をしてもらうのも良さそうです。または後輩にガイドライン作成を頼んでみても良いかと思います。私は1年目にガイドライン作成を任されたときに、階層ごとのページレイアウトの種類、コンポーネントの使い方、情報のグルーピングの仕方、マージンのリズム、などがわかり大変勉強になりました。先輩に感謝です。
終わりに
今回の裏テーマは「今までより短くサクッと要点をアウトプット」でした。2018年のイベント登壇資料をもとにしたリライト記事ですが、実装の方とのコミュニケーションについて加筆しています。現職の事業会社でコーディングやってくださる方が菩薩的な察し力で歩み寄ってくださったこともあり、コミュニケーションの大事さを実感したのでその旨を反映しました。もとの資料も供養に貼っておきます。
最後に
納品物の定義にもよりますが、ページ数での金額見積は闇です（先日のOOUIの勉強会でもそういう話をしていました）。
カンプ量産作業に割いていた時間を大幅に削減し、サービス設計、コンセプト設計、導線設計といった低層工程にリソースを集中するためにもガイドラインは必要ですね。
プロダクトの価値に正しく貢献し、チームで良きプロダクトを作っていきましょう〜〜
2020/08/31追記 Figma Community
Figmaの新しい機能（？）で、各社Guidelineが共有されています。命名規則、ページの作り方、説明…などとっても参考になるのでぜひぜひチェック！
サポートしてくれたら嬉しいです。書いてる間のコーヒー代にしたいです。