デザインガイドラインのすゝめ

デザイナーは言葉を駆使できなければデザイナーではない

– 川崎和男

前回はデザインの話としてEAPのデザインポリシーについて書いたので、
今回はちょうどいいところに転がっていたEAPデザインガイドラインなるものを引き合いに
デザイナーと実装者の間に起こりうる悲劇の回避方法についてお話して行こうかと思います。

そもそもガイドラインとはなんたるか

大企業を相手に仕事をしたことのある方であれば、一度は先方からデザインガイドラインやCIレギュレーションを支給されて目を通したことがあるかと思います。
逆に、それほどの規模ではないクライアントを相手にすることが多い方には、あまり馴染みのないものかも知れません。
一般的にどういったものなのかを知りたければ、FacebookやInstagram、Google、Twitterなど有名所の企業名に「ロゴ レギュレーション」と加えて検索すれば、多くのものをWebで目にすることができます。

こういったものは、高いブランド力を持つ企業であればあるほど良く整備されている傾向にあり、それなりのブランドであるのに、CIはおろかロゴデータの扱いについてのレギュレーションも特に存在しない、となると、むしろ大丈夫なのか？とブランドに対する意識まで勘ぐられてしまうほど、ブランドやサービスを推進していく上では重要視されるドキュメントです

あえてデザインにおけるレギュレーションとガイドラインの違いを挙げるとするなら、レギュレーションは「守らなくてはならないルール」で、一方ガイドラインは「守るべきもの」で、ポリシー、指針、方針といったものに近く、こちらの方が強制力が低く、解釈に幅がある。というような理解でまずはよいと思います。

ただ裏を返せば「ガイドライン」の方が、受け取り手の判断に委ねらている部分が大きいだけ、扱う側としての責任もより重く、そこに透けて見える本質をよく理解することが肝要で、自由度と引き換えにその背景を読む力が必要とされるものでもあります。

目を通す際にはその点をしっかりと心するよう、ぜひともこころがけていきましょう。

なぜEAPデザインガイドラインを作ったのか

弊社は元々開発に重点を置いた会社で、EAPのデザインについても、最初はおつき合いの長い外部のパートナー会社に委託していました。

しかし正式リリースバージョンに向けたすべての画面デザインを作り込んでいくのはスケジュールと両社のリソース上難しく、またスピード感を持ってプラットフォームの拡張を進めていく上で、これはやはり内部でハンドリングできた方が良いだろう、ということで
デザイナー/アートディレクションの経歴のある自分が、それまでに制作いただいた分をマスターデザインとして、以後のデザイン業務を引き継ぎました。

その際に自らの理解を深めるために、マスターデザインを分析、分解しポリシーを抽出してまとめたものがEAPデザインガイドラインのひな形となりました。
さらにAndroid版のデザインも考慮しつつ、今後の機能拡張で登場するであろうエレメントや、カスタム時の要素やカラーの組み合わせの考慮や、文書構造が崩れないようなスタイリングなど、核となる共通部分のバランスを調整しつつ、合わせてデザインもアップデート、さらにガイドラインを手直しして……といった事を繰り返し、現段階では「誰でもEAPとして核のぶれない画面がデザインできる（んじゃないかな）」レベルのリファレンスにはなっていて、ゆくゆくはこれをデザインシステム化できればいいなぁ、と思ってるところです。

ですので、EAPデザインガイドラインはデザイナーに向けて書かれていますが、実は実装者にも見てもらうことを期待しています。
なぜなら、ガイドラインを把握することは、デザイナーが上げてきたデザインに込められた意図を理解する助けとなり、デザイナーと実装者の目線の高さを揃え、最終的なアウトプットの質を高めるのに役立つからです。

デザインガイドライン＝デザインの自己紹介

アプリのデザインはWebに比べて自由度が低いとは言えど、UI部分へのフォーカスが高い分デザイナーはよりシンプルな手段で画面のバランスを構成する必要がありますが、シンプルが故に細部（と思われてしまいがちな部分）は些細なものと認識され、実装の際に蔑ろにされてしまいかねません。
自分はデザインするだけでなく、これまでにhtmlコーディングも業務として行っており、デザインに意図を込める側も、込められた意図を読み解いて形にする側も経験しているので、このすれ違いによって生まれる悲劇はなるべく回避すべき、という考えを持っています。

そのために重要なことは、人間でいう自己紹介と同じく「まず大雑把な性格を知っておいてもらうこと」です。
これだけで、その人の後の発言について、受けとる側の理解度をある程度深めることができます。

現在、実装者へのデザインの共有はInVisionを正とする運用をしています。
ただInVision上だと細かなフォント情報やマージンまで確認できるのは良いものの、大量の画面デザインを行う上ではどうしても細かなピクセルのブレは発生しますし、そもそも（いつまでも解決しない）Sketchの和文テキストボックスの行間バグなど、数値を正確にトレースするだけではデザイン通りに再現できない部分もあるので、デザイナー側としては「InVision通りに作ってくれれば良い」と胸を張って言えないのが辛いところではあります。

そういう時に、デザインガイドラインに「マージンは10pt、15pt、20ptが原則」と書かれていれば、「ここのマージンは10より広いけど20はなさそうだから15ptだろう」と判断できたり、「ここはポリシーから外れているから一度確認した方が良いかも」などと、実装側からの働きかけを喚起でき、最終的に見た目に関して責任を持つべきデザイナーの意図を正しく反映することができるようになると期待できます。
差分が軽微な応用画面の場合には、デザインを用意するよりもガイドラインに沿って作成いただく方が早い場合もあります。

デザイナーと実装者の間柄におけるガイドラインの役割は、共有すべき認識のベース部分を底上げをすること、「そこには意味があるんだよ」「そこには意味があるに違いない」と言うことを、まず共通認識として持たせられるのが最大のメリットです。
毎画面0からInVisionに従って作るより、３割くらいまでをガイドラインで了解が取れている状態から始めるだけでも工数的にかなりの削減になると思います。

飛躍するまとめ「ガイドラインはかすがい」

自分は「餅は餅屋」主義者で、アプリやWeb作りは建築に似ていると思っています。
建築デザイナーは住人の希望を踏まえ、機能と情緒を設計しますが、自分で工事はしません。
柱をどんな工法で組むか、電気や水道をどう通すかなど、メンテナンス性や強度の設計は専門の業者が行います。
実際に住人が目にし、身体が接する床や壁紙の仕上がりは職人の仕事です。
しかしながら、自らが設計した家を最終的な仕上がりの確認もせずに、住人に引き渡すデザイナーはいないでしょう。

アプリについても、見た目や使い勝手に関してはデザインをした人が全般の責任を負うべきで、
そのためにきちんと意図を伝え、その通りに実装されているかを確認するところまでがデザイナーの仕事であって
実装者はそのデザインに込めた意図を理解して、助力し、きちんと形にすることが仕事だと思っています。
プロのチームは、ただ一つの目的を達成するために、できること、できないことで責任を分担し、それぞれが責任を果たす、という単純なルールでできているほど強いと言う持論があるのですが、
言葉を選ばずに言えば、ここは互いに責任を押し付けあってでも、そうすることが良い成果物につながるとさえ思っています。

そのために必要なのは、みんなが仲良くすること！
ではなく
お互いがお互いの根本と能力を理解し、そこから発生するやり取りに言葉以上の深味を見いだせる様になることなのかな、と
いっそ侃々諤々喧々囂々のはてに仲良くなっていく方が、仕事仲間としては健全なんじゃないかと思います。
まずはいい仕事をしたい、とお思いの同業者の皆さま、そのための第一歩として、まずは自己紹介（デザインガイドライン）してみてはいかがでしょうか。

編集後記

おかしい…今回はデザインガイドラインの中身について、具体例を元にその意図を解説する記事を書いていたはずなのに…
ところで一説によれば、成果物を見ればガイドラインをどう解釈したのかがまる分かり、その人の力量や性格まで把握できるんだとかできないんだとか。たしかに自己紹介したのに、全然気を使ってくれない人って評価下がりますもんね。
次回は…デザインルールの話をしたい、なあ…