モジュールデザインのすゝめ――CSSから逆算してデザインを考える|連載モジュールデザイン4

2016年6月24日

こんにちは、rdlabo.incの榊原です。
先日開催された「FRONTEND CONFERENCE 2016」で、『グロースハックを実現する「モジュールデザイン」とCSS設計』というタイトルで登壇しまして、そこで話したこと、話したらなかったことを連載形式で紹介します。

第一回 Webデザイン再考ーー紙面デザインとの対比からみるWebデザイン
第二回 UXでWebデザインを評価しようーーいいWebデザインとは何かを考える
第三回 UIデザイン再考――UIデザインの3要素と仮説精度
 
さて、前回までに、UIデザインは冗長的であるべきで、具体的には

  • 一箇所を変更して、予期しない部分まで変更が入らない
  • 一箇所を変更すると、同類型のパーツは全て変更される
  • 最小の変更は、最小の人員で行うことができる

という要件を満たす必要があることを確認してきました。UIデザインはデザインとして完成するのではなく、UXの仮説精度とコーディングの一貫した流れを見据えてPDCAサイクルを回さないといけない話です。

そこで、第二回でUXからUIを評価したように、今回はCSSからUIデザインを考えていきます。
 

CSSについて振り返ってみよう

UIデザインをコーディングしていく作業といえば、みなさんおなじみHTMLとCSSを書いていく作業です。

<style>
  h2 {
    font-size:1rem;
  }
  .title {
    font-size:2rem;
    color:red;
  }
</style>
<h2 class="title">タイトルですよ</h2>

 
のように、HTMLで文章構造をつくっていきます。ちょっと丁寧にCSSについて確認していくと、上記の例では<h2>という見出しは font-size:1rem; が規定されています。しかしながら、.title によって font-size:2rem; に上書きされています。
 
CSSは、「カスケーディング・スタイル・シート」の略語で、意訳すると「優先順にしたがって・スタイル(デザイン)を指定する言語」となり、上記は優先順にしたがって上書きされています。
優先順は、「詳細度・記述位置」などによって決まります。ですので以下の場合は、「記述位置はあとのものが優先される」というルールのもと、やっぱりfont-size:2rem;が適応されます。

<style>
  h2 {
    font-size:1rem;
  }
  h2 {
    font-size:2rem;
    color:red;
  }
</style>
<h2>タイトルですよ</h2>

 
この「カスケーディング」という概念が非常に重要になります。というのも、CSSは「文章構造とデザインとの分離」を実現するために生み出されたものだからです。
上記の例をCSSを使わずにHTML4以前の書き方にすると
 

<h2 font-size="1rem" font-color="red">タイトルですよ</h2>

 
となります。
<h2>がひとつだったらともかく、例えば100箇所でこのデザインをコピペして使ったあと、デザイン修正が入ると、その100箇所を書き換えないといけなかったのです。昔は、CMSも今ほど発展しておらず、静的サイトで100ページを作ったりとかしてたから、まぁそりゃ修羅場。
 
スクリーンショット 2016-06-24 14.26.50

似たようなデザインでもひとつひとつ修正

 
まぁ、やってられませんよね。なので、デザインだけ全部まとめて、共通化して管理しようと。それがCSSの設計思想です。
 
スクリーンショット 2016-06-24 14.32.15
 
前述した、冗長的なUIデザインを実現するために「一箇所を変更すると、同類型のパーツ(=「モジュール」)は全て変更される」必要があるという点と同じ考え方であり、つまり、コーディングにおけるCSS設計とは、「どのように共通化して管理するか」が重要となるのです。
 
ちょっと長くなりますが、以下のような例はそのひとつです。

<style>
  .btn {
    border-radius:2px; 
    background-color:red;
    color:white;
  }

  .bg-secondary {
    background-color:blue;
    color:white;
  }
</style>

<button class="btn" />
<button class="btn bg-secondary" />

 
.btnという要素は同じですが、.bg-secondary-colorによって.btnの色を変更しています。.bg-secondary-colorは背景色の定義なので、他にも使い回すことができるでしょう。これが「共通化して、管理する」ということです。
 
ちょっと極端な例ですが、以下のデザインがコーダーから嫌われるわけがわかると思います。
 

  • フォントの種類にこだわりがあるがあまり、jpgで貼り付けろと指示されてる(デザインが分離されない)
  • なんか、パーツごとに、線の太さとか間隔がまちまちで「これがこだわりのデザイン」と言われる
  • 1ページ全部が芸術作品でパーツで分類できない

 
「共通化して、管理する」ことができないですよね。私ならちゃぶ台返します。
 

本項以降、共通化されたパーツを「モジュール」と定義して記述しております。

 

「BEM」というCSS設計思想から、CSSを考える

とはいえ、CSSが完璧な言語かというと、そうではなく、webサイトの規模が大きくなり、複雑化すればするほどCSSも巨大となり、メンテナンスが困難になっていきます。
 
例えば、定義した名前を忘れたからの名前の重複。1ヶ月前に「.user-title」というclass名にスタイルをあてたのに、今日実装した時にそのことを忘れて、別のところで「.user-title」と全く異なるパーツにCSSを当てて、気づいたら別の「.user-list」が壊れているとか、コーダーをやってると1度は体験するあるあるかと思います。
つらい・・・。
 
ちょっと実感をもてない人は、WordPressのテーマ「Twenty Sixteen」でもダウンロードして、中に入ってるstyle.cssをみて下さい。
これだけ整然と書かれても、コードを追うのにうんざりすると思います。こんな感じになっていくのです・・・。
 
このように、CSS設計にはいままで多くの人が頭を悩ましてきまして、「CSS設計論」も多くでています。
有名なCSS設計論のひとつに「BEM」というのがあります。パーツをBlock-Element-Modifyの単位に分解して、その親子関係がわかる命名規則を使うやり方です。
 

.block
.block__element
.block__element--modifier
.block--modifier
.block--modifier__element

 
この考え方で、HTMLにclassをつけると、以下のようになります。
 

<div class="block">
    <div class="block__element"></div>
    <div class="block__element--modifier"></div>
</div>
<div class="block--modifier">
    <div class="block--modifier__element"></div>
</div>

 
CSS設計を学ぶ項ではないのでこれ以上は省略しますが、要は「モジュール化(パーツの共通化)」ということを前提としつつ、class名が重複するなどによって簡単に壊れないけど、モジュールの修正を容易にするための設計思想です。
 
「一箇所を変更して、予期しない部分まで変更が入らない」ための技術であり、冗長的なUIデザインは、CSS設計という土台の上に立ってはじめて行えるといっても過言ではありません。
 

モジュール単位でのデザインをしよう

といっても、理論的なところでは、なかなか腑に落ちない部分が多いと思うので、本項では海外の実例を引用しつつ考えようと思います。
 
注意してほしいのは、本稿は「仮説検証プロセスにUIデザインを乗せる」というテーマで書いてますので、キャンペーンサイトであったり、またブランディングのためにデザインであるUIデザインを決して批判するものではありません。個人的にはすばらしい技術力のある制作スタッフで羨ましいところもありつつ、ただただ、モジュール単位でのデザインと、そうでないデザインの理解のために参考にしていただければと思います。
 

デザイン事例1:非モジュール

前論を踏まえて、以下のデザインを見ていただければと思います。UX(仮説)が外れていて、どこかを修正しようと思う時、どこが修正容易でしょうか。また、仮にこれを構築したエンジニアが退職した時、誰が引き継げるでしょうか。
 
スクリーンショット 2016-06-24 15.04.31
http://www.moma.org/interactives/exhibitions/2012/centuryofthechild/
 

デザイン事例2:モジュール

前回、事例で紹介したAirLecのサイトです。パーツがそれぞれ独立しているので、パーツの入れ替えなどCSSをさわらずにHTMLの記述位置を入れ替えるだけで変更可能な場合もあります。メニューをひとつ増やす、削る、ということも簡単にできます。
各パーツを共通化することによってモジュールにして、使いまわしているのがよくわかると思います。
 
スクリーンショット 2016-06-24 15.04.47
 

デザイン事例3:非モジュール

このサイト、「メニューを1つ増やして」と言われたらどうするのか気になってしょうがないです。
 
スクリーンショット 2016-06-24 15.05.17
http://secretstudy.ca/

デザイン事例4:モジュール

弊社サイト。なんか、事例3のあとに見ると気落ちしますが、一通りモジュール化されています。
 
スクリーンショット 2016-06-24 15.05.06
http://rdlabo.jp/
 

非モジュールを考える

もちろん、webデザインの流行にも、モジュール化しないことを前提としたものがありまして。

  • 高級ペライチ
  • JavaScriptで上に右に移動するwebサイト
  • 大企業のキャンペーンサイトとかゲームサイト

は、全然一般的にwebの世界だと思っています。しかしながら、大きな予算であったり、工数であったり、徹夜とかで削れたコーダーの寿命がバックグラウンドにある場合が多く、また仮説検証に向かないので、UIデザインをおこなうにあたって、そこは当たり前だとは個人的に思ってほしくないと思っています。
 

モジュールデザインの定義

さて、ここまで「冗長的UIデザインの実現のために」というところをみてきましたが、その上で重要なことが「デザインがモジュール化されていること」であると述べてきました。
本稿では、冗長的UIデザインを実現するためのデザインワークを「モジュールデザイン」として、その定義について整理します。
 

定義1 時系列を持っている

第二回のUXでWebデザインを評価しようーーいいWebデザインとは何かを考えるで見たとおり、いいWebデザインとは仮説検証のサイクルが回されており、そのことによって、「上司・クライアントの好き嫌い」なんていう個人的で担当者が入れ替えになった途端に白紙に戻るような曖昧なものからの脱却が可能となります。
冗長的UIデザインはまさにそのためのものであり、仮説検証サイクルを時系列をもって回すというのがひとつめの定義となります。
スクリーンショット 2016-06-24 16.04.16
 

定義2 CSS設計まで見据えている

上流工程から「これコーディングして」とウォーターフォールでpsdファイルを叩きつけられて「これ、Webでやるんスカ!?」「この背景の微妙な模様ホントに重要!?」「スマホでこれ、どうレンダリングするんですか?」(引用元:こわくないいまどきのフロントエンド開発の話)なんて話はコーダー側からすると珍しくないですが、デザイナーとしては無自覚な場合が多いです。
本稿でみてきた通り、冗長的UIデザインを実現するためには、デザインのモジュール化が必須不可欠であり、そのためにはCSSの知識をデザイナーも身につけることが最低限求められます。これはコーダーからの要請にかぎらず、よりよいデザインをするために必要なものとして捉えるべきです。
 

定義3 容易に手入れを行うことができる

「その似たパーツ2つは、それぞれ別モジュールにする必要がありますか?」なんてことはありふれた話です。この定義は、よりコーダー側に寄った話ではありますが、

  • その似たパーツは別々の必要がある?(デザインワーク)
  • その似たパーツは別々のモジュールにする?同一モジュールのバリエーション違いにできない?(コーダーワーク)

という視点をしっかりもって、「容易に手入れを行うことができるように」設計することが求められます。
また、手入れという面からみると、BEMなどを使ってコードの可読性をあげるのももちろんひとつですが、それ以上にCSSスタイルガイドの整備が求められます。
 
「命名規則、こことあそこで違うくない?」「こことあそこ、同じデザインなのに、別のCSS!」「このCSSはAさんしか理解していない!」ということは現場ではあるあるですが、これを構造的に避けようと思うと、CSSスタイルガイドは必須です。
「CSSスタイルガイドって何?」という方はBootstrapのComponentをご覧ください。これがあったら、かなり容易に手入れを行うことができると思いませんか??
 

まとめ

ここまで連載をご覧いただいた方は、何となくUIデザインの、「3つの構成要素から実装、その仮説精度まで一貫して考えること」の意味がわかってきたところかと思います。そのための「モジュールデザイン」はパーツのモジュール化にとどまらずにデザインワークとしての上位レイヤーで捉えていただければと思います。
今回はモジュールデザインの概念までたどり着きましたので、次回は実務としてのデザインワークとして落とし込んで「モジュールデザイン」を考えていきたいと思います。
 
それでは、また。