こんにちは、デザイナーの守谷（@emim）です。Creator's Noteは大変、久々です。
今回は、デザイナーのガイドラインとの向き合い方についての記事をまとめてみました。デザイナーって感性でなんとなくデザインをしているんじゃないんだよ！ということを言語化してみたので、なんらかの参考やキッカケになると嬉しいです。
デザイナーはガイドラインを読むのが苦手？
よく「デザイナーはガイドライン（仕様書）を読まない」、あるいは「読むのが苦手」という声を色々な立場から聞くことがあります。
ある種、この障壁を下げてくれたものに、AppleのHuman Interface Guidelines（HIG）とGoogleのMaterial Design（MD）という2大ガイドラインがあるように思います。
これらのガイドラインや世間の流れに沿って、徐々にデザイナーも「仕様を確認する」という認識が増えてきているように感じています（※ あくまで体感です）。
HIGはiOS・MacOSやiOSアプリの設計思想がまとまっていて、沿って作成をしていくと第三者の提供するサービスやアプリもAppleに準拠できるというもの。MDについてはAndroidについてだけでなくGoogle社の設計思想や設計詳細スペック例などが掲載されています。
ともに有名かつまとまっているガイドラインなので多くの人から参照されていて、時には慣習として広く認知／導入されたUIや挙動が後から取り入れられるというケースもあります。
また慣習という観点では、上記のようなガイドラインに載っていないような流行なども世の中には多々存在しています。必ずしも全ての「先進的なUIや挙動（使用感）」が後々まで残るわけではないですが、使いやすいという評価が市場で得られれば、それが後にスタンダードとなって前述の通り別のガイドラインに取り込まれて行く、という流れです。
残念ながらその狭間にある設計概念などは、競合アプリの調査やデザインのトレンド（動向）を配信しているブログなどの力を借りつつ、設計概念の整理や理解を進めることになります。いずれにおいてもデザイナーは機能に求められる要件と照らし合わせ、どういう意図を持って設計すれば、ユーザーの使用時に違和感を生まないようなUIになるか、ということを考えています。
つまりいずれの場合にも、そこに存在する「設計意図」を意識すると一本筋が通り、どうしてこういう設計になっているかが理解しやすくなります。
デザイナーは仕様書を読むことが苦手「らしい」と述べながらも、ルールと方針を照らしながらガイドラインに落とし、開発や記録に残すこともデザイナーの仕事です。次ではその方法を掘って行きます。
独自の方針に仕立て直す
前述の通り、様々な仕様を確認しつつ要件に沿った新たなガイドラインを策定していくのもデザイナーの仕事です。
中にはHIGにもMDにも載っていないような細かい指定について迷うケースがあるようで、たまに部署でのデザインガイドのレビューの際にも、「どうやってこのルールを決めたんですか？」という質問を受けたりします。
例を挙げると、
AndroidのUI設計をおこなった際に、MDに則って細かく文字サイズ等まで指定した場合に私が付与したLine heightの値はどう決めたのか？
などです。
確かにMDの文字周りの設計（The type system - Material Design）には、Letter spacingの設計はあってもLing heightの値は（ベースには）存在していません。（※ 次ページのUnderstanding typography - Material DesignにはBaselineなどの解説は含まれますが、タイトルの通り考え方の指南書となっています。）
こういった時に私がヒントとして持ち出すのは、また別のガイドライン、Web Content Accessibility Guidelines（WCAG）です。
過去にも何度かアクセシビリティ関連の記事を公開*1していますのでWCAGを持ち出してくる予感のした方もいらっしゃるかと思いますが、読み解いてみるとデザインに関するヒントも多々掲載されています。
今回のケースの場合、WCAG 2.0においては「1.4.8 視覚的提示」にて、WCAG 2.1においては「達成基準 1.4.12 テキストの間隔」にて以下のように提示されています。
行の間隔 (行送り) をフォントサイズの少なくとも 1.5 倍に設定する
2.0と2.1の違いは勧告時期の違いなので、2.1の方がよりWebやプログラミングへの知見が増えてから設計されたガイドライン……という雑な判断でそこまで齟齬はないかと思います。余談ですが、2.1の方が文字間への言及なども入っていて差分を見ると面白いです。2.2の勧告へのロードマップも公表されたので今後の動きも気になりますね。
さて本題に戻ると。
MDに則って細かく文字サイズ等まで指定した場合に私が付与したLine heightの値はどう決めているのか？
に対しては、つまり「特にMDなどでは詳しく掲載されてはいないけれどもWCAGの基準を参考にして設定しました」という回答になります。
ちょっとのセンス（判断）を織り込む
冒頭に立ち戻りますが、UI設計をする際に「機能に求められる要件と照らし合わせ、どういう意図を持って設計」するのかを考える上で、どう見られたいのか（要件）を突き詰めると、適した形が見えてきます。
WCAGでは単純に「行送りをフォントサイズの少なくとも 1.5 倍」としか書かれていませんが、すべてline-height:1.5にすればいいという話しでもありません。
例として以下で、文字サイズと数値に頼らないバランス調整での印象差を出した画像を掲載します。もとは、『吾輩は猫である』の文をタイトルと本文に見立てて並べてみたものです。
文字サイズや字面によっても雰囲気が変わる、ということを伝えたいがためのサンプルなので、左右で使われているフォントや文字サイズは変えていません。
左は「すべての行間を1.5」にしてみた例、右は「見栄えを優先してタイトル部分は行間を1.4に、本文部分は行間を1.7にした」例です。
キャプチャで文字サイズが小さくなったことによって、本文部分においては、行間が詰まりすぎていて1行ずつを認知しづらく、長い文章を読むときに負荷が掛かる、と感じるかと思います。
タイトル部分は逆に（画像をクリックで拡大していただくと把握しやすいかもしれません）、大きな文字になると行間が空きすぎると、折り返したテキストの先が把握しづらいという問題や、タイトルとしてのまとまりを感じられなくなる、という問題にあたります。
ここで確認すべきは、ガイドラインに設定された「1.5という数字は何のために明示されているか」ということ。
元の仕様においては、行間が狭くなるとロービジョンや識字障害があるユーザーが、文を追うのが困難になったり、表示を拡縮した時に可読性に影響が出ないように配慮するためのものです。
理由がわかれば、必ずしも「最小限値を守ればいい」わけでもなければ、状況によっては「これ以上開けるべき」とされた数値の方が読みづらくなることがある、ということもわかります。
ビジュアル表現的な「感性」という意味でデザインと「センス」が並べられることがありますが、私は必ずしもそうでもないと考えます。デザインは設計のことを示すので、その場合のセンスは、こういった理由やロジックの解釈を通した「判断」のことを言うのではないでしょうか。
理由を元に設計に落としていく
デザインをおこなう際、大体の場合はなんとなくではなく「要件」をもとに設計をしていっています。なんとなくしっくり来ないなーという時には、見逃して（考え損ねて）いるような部分を要件に照らしてみると、不足している仕様が見えてくるかもしれません。
また今回はHIG, MD（とWCAG）を中心にガイドラインの紹介をしましたが、最近は各社のプロダクトやサービスに沿ったデザインシステムを公開しているケースも多いです。
今回注目したテキスト周りは、AdobeのガイドラインSpectrumでは言語差によるフォントの密度などにまで言及した行間の指定例なども掲載されています。
Adobeの場合には、様々な言語で閲覧される環境をベースにしているため、このような細かい仕様を指定しているのだと予想されます。
何が正解、どれを踏襲すべき、というものは結局要件次第になってしまうので、それぞれのサービスやプロダクトに沿った設計を論理的に組み立てる、を目的に、小難しい様々なガイドラインを読むことを習慣づけてみてはいかがでしょうか。
蛇足）Chatworkのプロダクトデザイン部で話題になった「慣習」
完全に本筋から逸れますが、Chatworkのプロダクトデザイン部ではデザインに関する話題なども気軽にチャットでやり取りしているのですが、たまに冒頭で紹介したUIデザインの「慣習」について盛り上がることがあります。
必ずしも結論（最適解）が出ずに終わるものも多いですが、ここ最近で話題になったものをいくつかピックアップします。
ベタアイコンとアウトラインアイコンの使い分けについて、デザイナー内で喧々諤々していました。
アイコンにテキストを付けるべきか否か。Chatworkでも方針として筋を通す設計をすべきだと以前議論していたのですが、ソシオメディアではどういったアイコンにはラベルが必要なのかという方針の判断軸がまとめられていました
まだあまり触れる機会のないHapticの設計について知見を貯めました。
いずれも「この仕様をChatworkの正にしよう」というものではなく、考え方の種としてチャットに投下されたメッセージです。
*1:過去のCreator's Noteではアクセシビリティ関連記事の分量多めに出しています
