デザインを実装する上で知っておきたい！9つの原理とは

本稿は、Smashing magazineのブログ記事を了解を得て日本語翻訳し掲載した記事になります。

本記事は、UXディレクターでありデザイン本の執筆もしているTom Greever氏によって投稿されました。

 

先日、クライアントに向けたHTMLとCSSを使用してデザインを実装するための方法についての講習会で指導を行っていました。

そこでは、スタイルガイド駆動開発やOOCSS・SMACSSのような取り組み方、及びモジュール設計などの工程についての議論も行われました。最終日近く、ある人に「でも、どうやってそれが正しく行われていると判断したらいいんでしょうか？」という質問を受けました。

最初、私は混乱していました。それまで私は「正しく行う」ことだけを説明していましたが、その質問が何が主格の選択肢であるかを評価するためのより深いニーズに根ざしているのに気付きました。

例えば「他と共同して動作するクラスの数は最小限にする」というような特定のアドバイスは、モジュール性に関する幅広い認識がなければ役に立たないのです。

私たちの仕事がきちんとできているかを本当に知るために、デザイン実装の目安として使えるより高いレベルの原則が必要であると気付きました。

この溝を埋めるため、デザイン実装に関する9つの原則をまとめています。

CSSやコードを吟味するときの他にチームに志願している人への面接を行うときでも、これらの原理は特定の技術やデザインを実装する一般的な手段を超越した骨組みとして利用することができます。

 

1.構造化

文書はスタイルシート適用の有無に関わらず、意味があり論理的に書かれている。

2.効率的

デザイン実装に使われているマークアップとアセットは最小限である。

3.標準化

共通の規定があり、自由に使うことができる。

4.抽象化

ベースとなる要素は特定のコンテキストから切り離され、中心となるフレームワークを形成している。

5.モジュール化

共通して使える要素は、再利用ができるように分割されている。

6.設定が可能

ベースとなる要素を、任意のパラメータでカスタマイズできる。

7.拡張が可能

コードは簡単に拡張することができ、今後も追加されることが見込まれている。

8.文書化されている

すべての要素は、それを使用して拡張できるように他の人に説明されている。

9.正確である

最終的なアウトプットは、予定された通りのデザインとして適切な表現がされている。

 

プロジェクトに各原則がどのように適用するかを確認するため、この記事の基準として私のプロジェクトのひとつのモックアップを使用します。

これは既存のECサイト中の、デイリーディールを宣伝する特別なランディングページです。スタイルの一部は既存のサイトから継承されますが、ほとんどの要素は新しいものであるということに注意してください。上記の原則を使って、この静止画像からHTMLとCSSを生成してみましょう。

この製品の「カード」レイアウトは、新しい要素です。

 

1.構造化

文書はスタイルシート適用の有無に関わらず、意味があり論理的に書かれている。

ここでの原則は、ドキュメント(HTML)の内容がスタイル(CSS)がなくても意味を持つということです。正しい見出しレベル(heading)や順序なしリスト(ul)などを設定し、<header>や<article>といった意味のあるタグを利用するということでもあります。

aria-labelやalt属性、その他のアクセシビリティに必要な可能性があるものをきちんと使用しましょう。

見た目的に変わらないアンカータグとボタンのどちらを使うかということは、大したことには思えないかもしれません。ですが視覚的に同じであっても、これらは違う意味を伝え違う動作を行います。セマンティックマークアップはその意味を検索エンジンや補助技術に伝え、他デバイスにおいての再利用もやりやすくします。それはプロジェクトの将来性に繋がります。

 

よく構造化された文書を作成するということは、セマンティックHTMLを書くことを学び、W3Cによる標準や他の専門家のベストプラクティスを習慣づけ、自分のコードが分かりやすくなるように時間をかけることです。

スタイルシートなしでブラウザで確認するのが、一番シンプルなHTMLのテスト方法になります。

• そのHTMLはCSSがなくても使うことができるか


• 階層構造が一目で分かるかどうか


• HTML自体で意味を伝えることができるか

しっかりした構造をもつ文書を作成するにはHTMLから始めるのがよいでしょう。ビジュアル的なスタイルを考える前に、構造とそれぞれの意味のためにプレーンなHTMLを書きます。divは避け、妥当なタグを考えます。この基本的なステップが、適切な構造を作るために役立つでしょう。

<section>
 <header>
 <h2>Daily Deals</h2>
 <strong>Sort</strong><span class="caret"></span>
 <ul>
 <li><a href="#">by ending time</a></li>
 <li><a href="#">by price</a></li>
 <li><a href="#">by popularity</a></li>
 </ul>
 <hr />
 </header>
 <ul>
 <li aria-labelledby="prod7364536">
 <a href="#">
 <img src="prod7364536.jpg" alt="12 Night Therapy Euro Box Top Spring" />
 <small>Ends in 9:42:57</small>
 <h3 id="prod7364536">12" Night Therapy Euro Box Top Spring</h3>
 <strong>$199.99</strong>
 <small>List $299</small>
 <span class="callout">10 Left</span>
 </a>
 </li>
 </ul>
 </section>

HTMLのみの段階で、それぞれの要素についてよく考えることで構造化された文書ができあがります。上のコードでは、divを使わずに全体のマークアップが構成できているのが分かります。

 

2.効率的

デザイン実装に使われているマークアップとアセットは最小限である。

コードを簡潔にし、不要なマークアップやスタイルを含まないようにする必要があります。

右寄せされたブロックレベルの要素を実装するためだけに、特定のクラス名を使ったdivの中のdiv内にdivがあるというようなコードを見ることがよくあります。このようなHTMLの乱用は、CSSや基礎のフレームワークを理解していないために起こる現象です。

フレームワークに過度に依存し、divを使いすぎてHTMLとCSSが膨大になってしまった場合の例です。期待通りのデザインにするためにフレームワークをどうするかではなく、マークアップをどうするべきかについて考えてください。

マークアップやCSSの他に、アイコン・フォント・画像などの外部のアセットが必要になることがあります。カスタムアイコンフォントやSVGデータをBase64に変換して埋め込む手法などたくさんのやり方があります。

画像やアイコンなどの外部アセットに対してBase64を使うのは、効率のいいコードを書くために重要です。

プロジェクトの効率性を判断するために、2つの重要な要素があります。

• 少ないコードで同じことを実現できるか


• オーバーヘッドを最小限にするために、アセットを有効活用する一番いい方法は何か

デザイン実装を効率化させるための方法のひとつとして、要素の標準化を行い再利用できるようにするというものがあります。

そのためこの原則は、以下で紹介する「標準化」「モジュール化」と重なる部分があります。また標準のモジュールを作成しながら、mixinを作成することも効率的です。

 

3. 標準化

共通の規定があり、自由に使うことができる。

Webサイトやアプリのための標準を作るというのは、それぞれの見出しレベル・共通のガター幅・ボタンタイプのスタイルなどの大きさに関するルールを確立することです。通常のCSSではこのようなルールは外部のスタイルガイドで管理し、それに正確に適用するように気をつけなければいけません。

しかし、LESSやSassのようなプリプロセッサを使用することで、ルールを変数やmixinに保存することができるようになります。ここでの主要な取り組みは、ピクセルパーフェクトデザインを基準にするということです。

ガター幅が我々が他で使用している15pxではなく22pxであるモックアップを手にしたとき、私はこのような精密さは必要ないと想定し標準の15pxを使います。そしてすべての要素間の幅に、この基準を適用します。このようにすることでアプリ全体が一貫した整列感を持つことができるのです。

.product-cards {
 li {
 display: inline-block;
 padding: @gutter-width/4;
 color: @text-color;
 text-decoration: none;
 background-color: @color-white;
 .border;
 margin-bottom: @gutter-width/2;
 margin-right: @gutter-width/2;
 }
 }
 .product-status {
 font-size: @font-size-small;
 color: @grey-darker;
 font-weight: @font-weight-bold;
 margin-bottom: @gutter-width/4;
 }

LESSの変数あるいはmixinから算出される値を使うため、CSS自体には数値による値がありません。すべては一箇所に集められた値から継承されます。

標準化についてチェックするときには、CSSを確認してハードコードされた単位(ピクセル・HEX値・EMS・その他色々)を探します。

• これらの単位は、既存の標準値あるいは変数を使用する必要があるか


• それぞれの単位は、新しい変数の恩恵を受けるように再利用されているか


• 単位は既存の変数から算出することができるか。これは色のバリエーションに便利です。例えば結果のHEX値をハードコーディングするのではなく、基準の色から10％暗くするというように算出して使えます。

できるだけ基準値を使用し、必要なときだけ例外として新しい値を作成しましょう。もしあなたが要素のここの5px、あそこの1pxというように調整している場合、「標準化」がうまくいっていない可能性があります。

場合によっては各要素の位置を調整するために少しのピクセルを追加することも適切であるかもしれませんが、そういったケースはまれであり、その場合基準値を見直さないといけないことにもなります。

 

4. 抽象化

ベースとなる要素は特定のコンテキストから切り離され、中心となるフレームワークを形成している。

今進行しているひとつの特定のプロジェクトのためだけでなく、他の場面で使うデザインシステムについても意識しなくてはいけません。

この原則では、将来的に使うことになるような大きな共通の要素を見極める必要があります。タイポグラフィや入力フォーム、さまざまなナビゲーションデザインといった幅広い中から選ぶことになります。

もし自分のCSSがBootstrapやFoundationのようにオープンソースのフレームワークになったとしたら、どのようにデザイン要素を分けますか？どのようにそれぞれを異なったスタイルにしますか？

たとえすでにBootstrapを使っている場合でも、あなたのプロジェクト内にBootstrapにはない基本要素がある可能性があり、それをデザインシステムで利用できるようにする必要があります。

これらのデザイン要素は今のところどれも当社のECサイト内には存在しませんが、抽象化して全体のフレームワークに利用できるようにする価値は充分あります。

 

ここで重要なのはプロジェクトの特定の状況ではなく、より一般的な用語で各要素を考えることです。特定の要素を見るときは要素を分割して、それぞれの要素の役割に関係なく全体的なスタイルを与えます。

最も一般的な要素はタイポグラフィ(見出しスタイル・行の高さ・サイズおよびフォント)、フォーム、ボタンです。吹き出しや割引のフォーマットは、他のところで使える可能性があるので「フレームワーク化」される必要があります。

抽象化についてチェックするときの質問です。

• 異なるニーズを持つ別の場面で再利用するとして、どう構築するか


• アプリケーション全体で役立つようにどう分割するか

それぞれの要素の普遍的な実装を通して考えることが大事です。これらの部品は、完全に独立したクラス、あるいは最終的にCSSにコンパイルできるLESSやSassとして保存します。

柔軟なものを作らなければいけないことから生じる状況から、作業の内容を抽象化し続けなくてはいけません。

 

5. モジュール化

共通して使える要素は、再利用ができるように分割されている。

「抽象化」の原則と重複しますが、モジュールを作ることは管理しやすいデザインシステムを確立するために重要です。抽象化とモジュールの間には微妙な線がありますが、その原則の違いは重要です。

グローバルベース要素は抽象化される必要がある一方で、個々のアイテムは再利用されそれぞれの独立したスタイルで維持されなければいけません。モジュールは私たちのアプリ独自のものでも、フレームワーク全体でも必要なものではありませんが、同じコードを毎回書くことがないようにモジュールを再利用する必要があります。

 

例えば先ほどの例のランディングページからプロダクトカードのリストを実装する場合、daily-deal-productのようなクラス名ではなくproduct-cardsといった一般的なクラス名にすることで他の場面でも利用できるようになります。

コンポーネントがスタイルを取得する3つの場所です。

• 基本のCSS

タイポグラフィやガター幅、色などのデフォルト値を含んだ根本的なフレームワークです。

• CSSコンポーネント

デザイン全体を構成する抽象化された部分であり、どの場面でも使用することができます。

• 親コンポーネント

daily-deal固有のスタイルとカスタマイズを含むコンポーネント(とすべての子要素)です。

モジュール化することでこのように構成要素の間隔や位置に関するCSSのほとんどはフレームワークから継承され、簡潔に書かれた状態になります。

作成したものはできるだけ、複雑なメンテナンスなしで再利用できるようにしておきます。

 

6. 設定が可能

ベースとなる要素を、任意のパラメータでカスタマイズできる。

現在の、あるいは将来のプロジェクトに必要になるオプションについて考慮するのはデザインシステム構築作業のひとつです。規定通りにデザインを実装するだけでは不十分です。どの部分がオプションになり、異なった構成でオンオフされるかについても考えなければいけません。

例えば、私たちのデザインのコールアウトフラグは色のバリエーションが3つのみで、すべてが左を指しています。

3つ別々のクラスを作成するのではなくデフォルトのクラスを作成し、オプションのパラメータとして追加のクラス名を設定します。それに加え、他の人が別のプロジェクトでフラグの向きを右にしたいと思ったときのことも考えます。このようなオプションを頭に入れながらCSSを書いていきます。

普段使っている標準のコールアウトにはデフォルトの色が使われ、デイリーディール用のコールアウトにはランディングページのためのスタイルが適用されています。色違いや右向きのオプションも加えて作成します。

 

特定のデザイン要素について考えているときは、どのオプションが有用であるかについて考えてみましょう。その要素が再利用される他の状況について、しっかりと考えてみることが大事です。

• 外部の変数を使って設定・選択・動作させることができるのはどの部分か


• 要素の色や位置を変更することで有益に使うことができるか


• 小・中・大の大きさにすることで便利になるかどうか

BEMやOOCSS、SMACSSといった手法でCSSを構成し、これらの決定の助けになる命名規則を確立します。このような例を通して作業することが、設定可能なデザインシステムに大きな役割を果たします。

 

7.拡張が可能

コードは簡単に拡張することができ、今後も追加されることが見込まれている。

「設定可能」の原則と同様に、実装は将来的に変更する可能性があります。オプションのパラメータで構築することは便利ですが、現在進行しているプロジェクトに何が必要になるかを予期することはできません。

そのため今作成しているコードが将来の変更に対してどのように作用するか、コードを拡張しやすいように構成するにはどうしたらいいか考えることが大事です。

スケーラブルなCSSを構築するとき、私はmixinと関数を使用するためにLESSやSassのより高度な機能を使用します。コールアウトフラグは色以外はすべて同じなので、バリエーションごとに重複したコードを書くことなくそれぞれのコールアウトのCSSを生成するひとつのLESS mixinを作成することができます。

このコードは拡張を見越して作成されており、一箇所で簡単にアップデートすることができます。

@angle: 170;
 .callout {
 &.qty-left {
 .callout-generator(@color-deals, @color-white, @angle);
 }
 &.qty-sold {
 .callout-generator(@color-white, @color-deals, @angle, 2px solid @color-deals);
 }
 &.qty-out {
 .callout-generator(@color-grey, darken(@color-grey, 10%), @angle);
 }
 }

コールアウトをスケーラブルにするために、背景色・テキスト色・向き・ボーダーの値を受け付ける「.callout-generator」という名前のLESSmixinを作成します。

スケーラブルなCSSによって、色々なコールアウトフラグが作れるようになります。

.review-flag {
 .callout-generator(@color-brand, @color-white, 75);
 }

将来的に新しい案件で同様のデザインパターンが必要になったとき、そのスタイルを簡単に作成することができるようになります。

スケーラブルなデザインシステムを作成するためにはプロジェクトで共通する変更を予測し、その変更に備えられるようにコードを書きましょう。

変数やmixinを使用したり、配列に値を格納してループしたりする方法があります。

• 要素内のどの部分が変更される可能性があるか


• 将来的に簡単に変更できるようにするために、どのようにコードを書いたらよいか

 

8. 文書化されている

すべての要素は、それを使用して拡張できるように他の人に説明されている。

デザインの文書化は過小評価されており、プロジェクトで最初にカットされがちな部分です。

しかし、作業の記録を作成することによって他の人が意図されたことを把握しやすくなるだけでなく、ステークホルダー全体がデザインシステムに参加することができます。作成された文書は開発者から管理職まで、チームメンバーすべてが参照できるようにしておく必要があります。

作業を文書化する一番いい方法は、コード内のコメントから直接生成されたライブのスタイルガイドを作成することです。

 

私たちはスタイルガイドによるCSS開発文書という手法を使っています。

スタイルガイドを作成することができない場合は、手動でHTMLやPDFにするのも有効です。あくまで大事なのは、作業のすべてを文書化させるということです。

設計システムを文書化させるために、デザインがどのように実装され、どのようにそれを再生成するべきかということを他の人が理解するための手順を書きます。この情報には、要素の背後にある特定のデザイン思考・コードサンプル・動作中の要素のデモが含まれる場合があります。

• 自分の作成したコードをどのように説明するか


• 新しいチームメンバーが参加したとき、使い方をどのように説明するか


• それぞれのウィジェットが何に使われているかについて、どのように表示して説明すればいいか

CSSから直接生成されたスタイルガイドは本当に便利です。

 

9. 正確である

最終的なアウトプットは、予定された通りのデザインとして適切な表現がされている。

私たちが作り出したものは最終的に、元のデザインコンセプトと同じように見える必要があるということを忘れないようにしましょう。

視覚的なアピールが予定されていたものと合っていないデザインは認められません。目的は適切に表現されたデザインであり、ピクセルパーフェクトではないということです。

デザインの実装を完全にモックアップの通りにするためには、制約や標準化を犠牲にすることもあるからです。(それぞれのブラウザでCSSの表示が異なることも覚えておきましょう)

 

実際、レスポンシブなデザインにおいてすべてのデバイスサイズを考慮することはめったにありません。ある程度の柔軟さが必要だということです。

プロジェクトに必要とされる適切な表現がどういうものかを決定しなければいけませんが、それは仕事をしている相手の期待を満たすものであることが大事です。私たちのプロジェクトでは、クライアントと同じ考えを共有するためにピクセルパーフェクトから逸脱していることを説明します。

「デザインではデフォルトボタンはボーダー付きの青いボタンとなっていますが、代わりにボーダー無しのボタンを使用しています。」見積もりを行うことが重要なステップとなります。

最終的に実装されたものは、最初のモックアップと多少違ったものになります。必要な条件についてもいくつか実装中に変更されています。それでも、結果は正確です。

 

思考のシステム

これら9つの原則は、HTMLとCSSでデザインを実装するためのガイドになります。

素晴らしいデザインと素晴らしいコードのバランスを最大に活用するための考え方に関する規則ではありません。これらの原則を活用するには、ある程度の柔軟性が必要だということです。常にすべてを完璧に遂行することはできません。

この原則はあくまで理想であり、実際の仕事では他の原理や優先順位が存在します。それでも、デザインボードから最終的な媒体になるまで常にデザインをチェックし、努力して積極的に追求するときに役立つでしょう。

 

また、TechAcademyでは初心者でも最短4週間でオリジナルWebサイトを公開できるWebデザインオンラインブートキャンプを開催しています。

現役のWebデザイナーがパーソナルメンターとして受講生に1人ずつつき、マンツーマンのメンタリングで学習をサポートし、最短4週間でオリジナルのWebサイトを開発することが可能です。

独学に限界を感じている場合はご検討ください。