はじめに
この記事では私が普段使っている、グリッドシステムを使ったレスポンシブなデザインカンプのフレームワークを紹介します。主にデザイナー初心者や1~2年程の経験者向けの内容です。
フレームワークを作成した経緯
私は仕事で主に所謂Web制作と言われるWebサイトのデザインと実装を両方やっており、業界的に納期が短い中でいかに高いクオリティのものを作るのかが課題だと感じています。深夜や休日も使ってなんとか仕上げることも業界全体の傾向では少なく無いと感じますが、どうしても限界があるので何かしら効率的なものが必要だと思いました。
そこでデザインカンプを作成するときにデザインの情報としての配置にデザイン4原則を取り入れて、ロジックに則ったレイアウトを設計できるフレームワークを作り、レイアウトに迷う時間を短縮しようと考えました。フレームワークを元にすることで、そのサイトならではのコンセプトを体現したレイアウト調整に加えて装飾や演出に多くの時間を充てようという想いから作成しました。
レスポンシブ対応について
このフレームワークを作成するにあたって、大事なのはレスポンシブ対応です。というのも、Webの思想や特性・私自身の過去の経験からレスポンシブの様々な問題を解決することが結果として効率的にサイトを作成できると感じているからです。
Web制作ではデザイナーがPC/SPのデザインカンプを作成して、コーダーがそのデザインを再現する流れが多いのではと思います。しかしコーダーが再現する時はあらゆるブラウザのサイズに対応する必要があります。例えば、PCは幅1920pxのモニターや幅1280pxのノート型、SPは幅360pxや幅829pxの二つ折り、それ以外にも幅1024pxのタブレットなど多岐にわたります。そして特にPCでは誰しもがブラウザをデバイスの画面全体に開いている保証はありません。そのような状況をはじめ、あらゆるブラウザのサイズに対応する理由は大きく五つあると考えています。
- 【アクセシビリティ】Webは様々なユーザーが様々デバイスや環境からアクセスするため、主に視覚的な手段でWebを閲覧する人にとってもできるだけ多くの環境に対応することがアクセシビリティにつながります。
- 【瞬間的な印象】Webサイトには見やすさ使いやすさは勿論、目的によってはコンセプトや世界観などを瞬間的に伝えるスタイリングが必要になります。そこで特定のサイズだけを反映した場合は、そのサイズ以外の時には没入感が削がれスタイリングの魅力を落としてしまいます。
- 【Web制作の流れ】クライアントの担当の方やパートナーの代理店の方・決裁権のある方など、規模によっては多くの方が各々のデバイスでチェックするので、特定のターゲットを狙う想定でなければ、幅に関係なく最適な状態を表示できる方が効率が良いと考えています。
- 【デバイスのシェア率】ユーザーが使っているデバイスのシェア率というデータも圧倒的な差は少なく多種多様なサイズに分布しています。また、仮にシェア率が高いデバイスのサイズに合わせるとしても、これから特定の会社が発売するデバイスに翻弄され続け、過去制作したサイトが適合されなくなるリスクがあります。
- 【VR/AR/MR（XR）】既に一部のデバイスではVR空間にブラウザを表示できており、近い将来にVRでユーザーの任意のサイズのブラウザを表示させたり、ARで特定のオブジェクトに合わせたサイズのブラウザを表示させたりする必要があると個人的に推測しています。
フレームワークの目標
デザインカンプのフレームワークを作成するにあたって、前述したWebサイトのデザインにおける課題を解決させるために以下の点を目標に立てました。
- デザインの選択肢を普遍性から判断して、できるだけ時間を短縮できるものであること
- Web制作を中心に多種多様なデザインに適用できること
- デザイン4原則（近接/整列/反復/対比）を取り入れてレイアウトに根拠と普遍性があること
- フレームワークを元にサイトの目的に応じてカスタマイズできること
- レスポンシブに対応できること
普遍性について
この記事における「普遍性」は、視覚や心理といった人間の特性や、歴史から導き出されたデザインの法則など、時代を問わず多くの人にとって共通するものと位置付けています。例えば、デザイン4原則・黄金比・ヤコブの法則などが該当します。
このフレームワークでカギとなる普遍性の要素は文字です。読みやすい文字の大きさや行間や余白などは人間の視覚や知覚に基づいているので、数年・数十年といったスパンで変わることはないでしょう。Webサイトには基本的に読ませる目的の文字、いわゆる本文というものが存在します。この本文の文字の読みやすさをフレームワークの基礎にします。
本文について
前述した本文の文字の読みやすさについて、具体的にどれくらいの数値なのかを記載していきます。
私が参考にしたのは、ウェブタイポグラフィ─美しく効果的でレスポンシブな欧文タイポグラフィの設計という書籍です。その中の一節を引用します。（この本はタイポグラフィについてかなり詳細に書かれているのでオススメです！）
可読性の高い段落は、行間、カラム幅、文字サイズの3つの要素が組み合わさってできています。
本書では欧文の行の長さ（カラム幅）は45文字から75文字の範囲が好ましいとしています。和文ではこれらの文字数の半分強、24文字から40文字程度を目安にするとよいでしょう。
同じサイズの欧文と和文を並べると、ほとんどの場合は和文の方が文字が大きく見えます。そのため和文はより広い行間を非強いうとします。本書では欧文のline-heightの調整は1.4から始めるようアドバイスしていますが、和文では1.7程度から始めるとよいでしょう。
ここから本文のサイズ感の目安をつけました。
- 文字サイズは目と画面の距離30cm~45cmから算出した欧文の16pxからやや縮小した14px
- 行間は機能的なものは1.75~2程度、情緒的なものは2.5~3程度
- カラム幅は14×24~40=336~560px程度
これらを目安に、和文が本文の様々なWebサイトと比べたり、実務でも取り入れてみたりしました。その結果概ねこの数値が可読性が高いことを感じました。目安については勿論書体や閲覧する人によって変わるのですが、このフレームワークでは可読性のある明朝体やゴシック体を使用する想定で、ブランディングやキャンペーン等のWebサイト制作の傾向を軸にしました。
文字スケールについて
本文の文字サイズが確定したことにより、そのサイズを基準に文字の強弱の種類であるスケールを定義することができます。スケールを決めるにあたり、汎用性があること・近似値でもサイズの違いが分かること・サイズの差が大きくなりすぎないことを観点に考えた結果、音楽、数学、タイポグラフィの記事に書かれている「フィボナッチ数列」を採用しました。フィボナッチ数列の単位は本文のサイズを半分にした7pxにして、必要であれば算出した数値の中間点（必要であればさらにその中間点）を追加したスケールしています。
余白について
文字を含む要素間の余白のスケールについても、文字スケールの中でより明確に差が分かるもの、フィボナッチ数列の中間点の無いもの（14, 21, 35…）を採用します。どの余白を選択するかは、基本的に下記の判断基準で選択します。
- 【要素のサイズ】余白をつくる要素の大きさ（文字であればその行間やカラム幅も含む）
- 【要素の階層】近接の原理に基づいた要素のグループの階層
- 【周囲の要素】近接/整列の原理に基づいた周りの要素やグリッドシステムの距離
- 【トンマナ】制作物の印象を変えるいわゆるトーン&マナー
近接に基づく余白
判断基準で特に余白のスケールとの関連あるものは、要素のサイズと要素の階層です。要素のサイズは、文字であればその文字サイズもしくは行間以上の余白を選定します。傾向として、情報の羅列や1行程度の文章であれば文字サイズと同じ余白、複数行の文章は文字サイズより一つ上のスケールの余白になることが多いと感じています。アイコンやタグなどの要素の場合は、要素のサイズを文字スケールに視覚的になるべく合わせて、それと同じもしくは半分程度の余白を設けると安定しやすいと思います。機能的な役割を持つ画像などの要素の場合は、近接の原理でまとめられた要素のグループの階層に応じて余白を設けます。ここで、具体的な余白の適用例を紹介します。
上記画像では、要素のサイズと要素の階層に基づいて余白が設けられています。要素のサイズで一番大きい17.5pxの複数行の可能性がある文章（タイトル）に基づき、その一つ上のスケールの余白である21pxをいわゆるカード型グループである同階層の余白に選定しました。その階層内にあるタグの階層では、タグの高さの半分である7pxにしています。また、カード間の余白はカードの階層より上のスケールの35pxにして、明確にカードの区別ができるようにしています。
整列に基づく余白
近接の原理の他にも、整列の原理に基づいて余白が設けられる時もあります。整列の原理では、要素同士を左揃えや上揃えといった表層に現れていない線に合わせて配置します。その要素間に近接の原理を用いて余白が取られることが多いですが、ここでは不可視のブロックに基づいた余白の生じ方を説明します。不可視のブロックとは、要素のグループを複数まとめた領域を指します。ブロックの大きさは、要素の大きさに基づくものとは違い、コンテンツ枠もしくはそれを分割したグリッドのカラムの大きさになる場合が多いです。そのブロックに沿わせるように配置することで要素間に余白が生じ、ブロックに対して整列させることによって要素をグループに紐づけます。要素の配置箇所は、各要素の濃度や重心・ブロック内の重心バランス・周りのブロックからの流れ・機能的/情緒的な役割など判断基準は多岐にわたります。ここで、具体的な余白の適用例を紹介します。
例では左部の「セクションのタイトル」と「複数行に渡るタイトル」の距離がそれぞれの紐づくグループより近いですが、それぞれが別ブロックかつ別のグループだと判別できます。特に縦スクロールの場合、要素の配置が縦より横の方が要素の紐づきが強い印象を感じます。ブロックを薄い青色の枠で可視化してみます。
可視化することで上下のブロックや要素間の距離が分かりました。ブロックをより明確に見える形で分けたい場合は、線や背景の色などで領域を区切るなどの手法があります。また、下部の画像のようにコンテンツの幅が変わっても、グリッドシステムを採用することで配置の意図を変えることなく対応しやすいと思います。
グリッドシステム
このフレームワークではグリッドシステムを採用します。その理由は、ブラウザのサイズに関わらずその領域のx割を要素やグループと定義することで、バランスを維持しながらレスポンシブ対応ができるからです。このシステムは単純なモジュールの縦積みを発生させてスタイリングが単調なものになると思われがちですがむしろその逆で、整列による情報の認知負荷を下げるとともにグリッドによる余白を入れることでリズムやコントラストを入れることもできて、さらにグリッドからあえて外した要素がよりダイナミックな印象を与えます。グリッドシステムはグラフィックデザインの時代には既に様々な研究がされており、Webデザインにも取り入れられています。
グリッドのガター
グリッドシステムでは、まずグリッドのガターを制定します。余白のスケールを元にグループを判別できる幅を制定します。グループが入れ子構造の前提で考えると、グループ内のグループも判別できる余白以上が必要です。例えば、あるグループ内に本文14pxとそれに付随するタイトル17.5pxがある時は、その間に必要な余白は21pxとなり、そのグループが並列で並んでいる場合に21pxの次のスケールである35pxをグリッドのガターに選択します。さらにそのグループが内包されるグループが存在すればグリッドのガターは順当には56pxになりますが、それはグリッドシステムを適用しているコンテンツの幅に左右されると考えています。というのも、コンテンツの幅が狭ければグループの入れ子の階層も上がりずらい側面があると思います。狭い領域に入れ子が複数層になる時点でかなり情報が詰まった印象になってしまう可能性が高いです。また、コンテンツの幅に対して大きすぎるガターは間延びした印象を与え、スクロールする方向である縦のグループと差別化された、横に並んだグループの結びつきを弱めてしまう側面もあると感じています。ただ、勿論これはデザインする対象物によって見方が変わることも大いにあります。
そこで、一定範囲のコンテンツの幅に対してガターの大きさを変えることにしました。変える判断基準については、余白のスケール・カラムの最低幅・コンテンツ幅を参考にします。まず最小のコンテンツ幅を定義します。グループ内に21pxの余白があることを想定して、グループ間を区切るガターを35pxとします。また、カラムの最低幅は縦書きの1行タイトルが入る21pxと仮定します。そして、コンテンツ幅がスマホのサイズ周辺である360px辺りを元に、カラムの数を選定します。カラム数を約数の多い汎用的な数値である6と仮定すると、カラム21×6+ガター35×5+左右の端マージン35×2=371となり、スマホのサイズ周辺である360pxをカバーすることができます。371px以下のブラウザに対しては、本文の値をブラウザの幅に合わせて14pxから縮小することで、本文サイズと連動する文字や余白などの全てのサイズを縮小することで対応できます。例えば、360pxのブラウザの幅の時は、本文が13.58pxになり、余白や文字のスケールもそれを元に縮小（13.58×1.5=20.37, 13.58×2.5=33.95…）されます。これで、371pxをブラウザの最低幅と定義して、ガターを56pxにしたときのコンテンツ幅まではガターを35pxにします。ガターを56pxにしたときは、カラム56×6+ガター56×5+左右の端マージン56×2=728がブラウザの最低幅になります。カラム幅を56にした理由は、6つのガターを3つに分けた時に文字幅をできるだけ確保しつつ、後述するカラム数を12にした時と同じカラム幅にすることでデザインカンプのスタイリングの流用を容易にする狙いがあります。結果、728pxを区切りにガターを35pxと56pxに分けるようにしました。
デザインカンプ
グリッドのガターを元に、デザインカンプのサイズを制定します。カンプは4つを制作する前提で、案件の期間よっては3~2つに減らすことも可能な設計にします。そして、デバイスサイズのシェア率は参考程度に留めて、特定のシェア率の高いデバイスサイズには依存しません。
| カンプサイズ | ガター | カラム | マージン | 高さ |
|---|---|---|---|---|
| 371 × 539 | 35px | 6 （21px） | 35px | カラム9 + マージン |
| 728 × 728 | 56px | 6 （56px） | 56px | カラム6 + マージン |
| 1148 × 602 | 56px | 12（35px） | 56px | カラム6 + マージン |
| 1400 × 728 | 56px | 12（56px） | 56px | カラム6 + マージン |
全ての要素のサイズは本文サイズに準拠して、本文サイズは371~1400の間は14pxで、371未満はブラウザの幅に応じて縮小され、1400以上は拡大される想定です。縮小と拡大に至る判断には、本文の見やすさの普遍性である目と画面の距離を参考に、ブラウザサイズの大きさと共に画面との距離が離れていくことを想定したためです。この手法であればデジタルサイネージやVR/AR空間などに対して、ある程度の距離は本文の見やすさを担保できると考えています。また、1800px程度の幅のワイドモニターでも18pxと可読性担保の汎用性もあります。
| ブラウザ幅 | 1rem | 1.5rem | 2.5rem | 4rem |
|---|---|---|---|---|
| 360（例） | 13.58px | 20.37px | 33.95px | 54.32px |
| 371 | 14px | 21px | 35px | 56px |
| 1400 | 14px | 21px | 35px | 56px |
| 1800（例） | 18px | 27px | 45px | 72px |
グリッドに基づく余白
先に述べた余白のスケールでグリッドを分ける56pxのスケール以上の余白には、グリッドのガターを活用します。例えば、1カラムを挟んだ2つのガターの距離を56pxの次の余白スケールにします。そうすることでカラムに対して全ての幅を満たす要素間で、縦の余白に対しても横の余白と同じ距離を確保することができます。1カラム2ガター以上の距離は最低でも91pxはあるので、7のフィボナッチ数列の56の次である91以上なことが担保され、スケーリングの階層を維持することができます。1カラム2ガターの次は、2カラム3ガター、3カラム4ガター…と増えていきます。
まとめ
唐突なまとめで恐縮ですが、ここまで書いて思った以上に記事が長くなってしまったため、概念やベースを紹介したところでひとまず公開しようと思いました。次の記事で、この記事の補足や具体的な例をもっとご紹介できたらと考えています。
改めてになりますがフレームワークはあくまで型であり、要件次第でその型からどう変えていくのかという明確な判断をする基準だと感じています。そして、私自身はこのフレームワークでテンプレート的に使って制作物の数をこなすというよりは、少しでもコンテンツの目的・思想・哲学を読み込み伝える時間を増やしたいという思いで設計しています。
参考文献
12/06更新 メモ追加
Discussion