設計実装の9つの原則

公開: 2022-03-10
簡単な要約↬既存のプロジェクトをどのように評価できますか？ コードのレビュー、CSSの監査、またはチームの役割の候補者への面接のいずれの場合でも、適切なガイダンスを提供するいくつかの原則があります。

最初、私は混乱しました。 私はちょうど何時間もかけて、彼らが「正しく行う」ために必要なすべてのことを彼らに話しました。 しかし、それについて考えた後、私は質問が主観的な選択のセットであることが多いもの、つまり多くの異なる人々によって異なる時間に行われることがある選択を導き、評価するというより深い必要性に根ざしていることに気付きました。 一貫した命名規則やライブスタイルガイドのようなものが最終結果ですが、これらの「ベストプラクティス」は、常に明示的であるとは限らない、より深い値のセットに根ざしています。 たとえば、「別のクラスが連携するクラスの数を最小限に抑える」などの具体的なアドバイスは、モジュール性を広く理解しなければ、それほど役に立ちません。

私たちの仕事が良いかどうかを本当に知るためには、デザインを実装するための測定棒として使用できる、より高いレベルの原則が必要であることに気づきました。 CSSのような特定の言語から削除されたもの、またはそれを書くための意見のある方法が必要です。 デザインの普遍的な原則やニールセンのユーザビリティヒューリスティックと同じように、正確な方法を教えずに、デザインを実装する方法をガイドする何かが必要です。 このギャップを埋めるために、私は設計実装の9つの原則をまとめました。

プログレッシブシングルページアプリケーションの設計

ヘイドンピカリングは、CSSのトリックをいくつか使用し、JavaScriptを0.5 KB未満、そして重要なことに静的HTMLを使用することで、プログレッシブエンハンスドのシングルページアプリケーション向けの実験的なソリューションを紹介します。 関連記事を読む→

これはチェックリストではありません。 代わりに、基本的な価値を維持することを目的とした一連の幅広いガイドラインです。 実装に取り​​組んでいる人のためのガイドとして、または既存のプロジェクトを評価するためのツールとして使用できます。 したがって、コードをレビューする場合でも、CSSを監査する場合でも、チームの役割の候補者に面接する場合でも、これらの原則は、特定の手法を超えて、設計を実装するための一般的なアプローチをもたらす構造を提供する必要があります。

  1. 構造化ドキュメントは、スタイルの有無にかかわらず、意味的および論理的に記述されます。
  2. 効率的設計を実現するために使用されるマークアップとアセットの量は最小限です。
  3. 一般的な値の標準化されたルールが保存され、自由に使用されます。
  4. 抽象化されたベース要素は特定のコンテキストから分離され、コアフレームワークを形成します。
  5. モジュラー共通要素は、論理的に再利用可能な部分に分割されます。
  6. 基本要素に対する構成可能なカスタマイズは、オプションのパラメーターを介して利用できます。
  7. スケーラブルコードは簡単に拡張でき、将来の機能拡張が見込まれます。
  8. 文書化すべての要素は、他の人が使用および拡張できるように説明されています。
  9. 正確最終出力は、意図した設計の適切な表現です。
ジャンプした後もっと！ 以下を読み続けてください↓

各原則がプロジェクトにどのように適用されるかを理解しやすくするために、この記事の基礎として、私のプロジェクトの1つからの設計モックアップを使用します。 これは、既存のeコマースWebサイトでの毎日の取引を促進する特別なランディングページです。 一部のスタイルは既存のWebサイトから継承されますが、これらの要素の大部分はまったく新しいものであることに注意することが重要です。 私たちの目標は、この静止画像を取得し、これらの原則を使用してHTMLとCSSに変換することです。

この製品のカードレイアウトは、eコマースWebサイトにとってまったく新しいものです。
製品のこの「カード」レイアウトは、eコマースWebサイトにとってまったく新しいものです。 （拡大版を表示）

1.構造化

ドキュメントは、スタイルの有無にかかわらず、意味的および論理的に記述されます。

ここでの原則は、私たちのドキュメント（HTML）のコンテンツには、プレゼンテーションスタイル（CSS）がなくても意味があるということです。 もちろん、これは、適切に順序付けられた見出しレベルと順序付けされていないリストを使用していることを意味しますが、 <header>や<article>などの意味のあるコンテナーも使用しています。 ARIAラベル、 alt属性、その他のアクセシビリティに必要なものの使用をスキップするべきではありません。

大したことではないように思われるかもしれませんが、アンカータグを使用するかボタンを使用するかは、視覚的に同一であっても、異なる意味を伝え、異なる相互作用を提供するため、重要です。 セマンティックマークアップは、その意味を検索エンジンや支援技術に伝え、他のデバイスでの作業の再利用をさらに容易にします。 これにより、プロジェクトの将来性が向上します。

適切に構造化されたドキュメントを作成するということは、セマンティックHTMLの記述方法を学び、W3C標準や他の専門家によるいくつかのベストプラクティスに精通し、時間をかけてコードにアクセスできるようにすることを意味します。 最も簡単なテストは、スタイルのないブラウザでHTMLを確認することです。

  • CSSなしで使用できますか？
  • それはまだ目に見える階層を持っていますか？
  • 生のHTMLはそれ自体で意味を伝えますか？

構造化されたドキュメントを確実にするためにできる最善のことの1つは、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または基盤となるフレームワークを理解していない結果です。

肥大化したHTMLとCSSは、より効率的に書き直すことができます。
これは、肥大化したHTMLとCSSを作成するフレームワークへの一般的な過度の依存の例と、 divのケースです。 フレームワークが目的のデザインを実現するために何ができるかではなく、マークアップが何である必要があるかを考えてください。 （拡大版を表示）

マークアップとCSSに加えて、アイコン、Webフォント、画像などの他の外部アセットが必要になる場合があります。 カスタムアイコンフォントからbase64埋め込み、外部SVGまで、これらのアセットを実装するための最良の方法については、多くの優れた方法と意見があります。 プロジェクトはそれぞれ異なりますが、ボタンの1つのアイコンに500ピクセルのPNGがある場合は、効率を意図していない可能性があります。

スタイルガイドは素晴らしいですが、CSSから直接生成されたライブスタイルガイドは人生を変えるものです。
それは必ずしもファイルサイズについてではありません。 効率的なコードを作成するには、CSSでbase64のアイコンを使用することと、画像やアイコンフォントなどの外部アセットを使用することの意味を考慮することが重要です。 （拡大版を表示）

プロジェクトの効率を評価する場合、2つの重要な質問があります。

  • より少ないコードで同じことを達成できますか？
  • 最小のオーバーヘッドを達成するために資産を最適化するための最良の方法は何ですか？

実装の効率は、標準化とモジュール性に関する次の原則とも重複します。効率を上げる1つの方法は、設定された標準を使用して設計を実装し、それらを再利用できるようにすることです。 一般的なボックスシャドウのミックスインを作成すると効率的ですが、モジュール式の標準も作成できます。

3.標準化

一般的な値のルールは保存され、自由に使用されます。

ウェブサイトやアプリの標準を作成することは、通常、各見出しレベルのサイズ、一般的なガター幅、各ボタンタイプのスタイルなどを管理するルールを確立することです。 プレーンCSSでは、これらのルールを外部スタイルガイドで維持し、正しく適用することを忘れないでください。ただし、変数やミックスインに保存できるように、LESSやSassなどのプリプロセッサを使用するのが最適です。 ここでの主なポイントは、ピクセルパーフェクトなデザインよりも標準を重視することです。

したがって、ガター幅が22ピクセルのデザインモックアップを取得する場合、他の場所で使用している15ピクセルではなく、そのような精度は価値がないと想定し、代わりに標準の15ピクセルガターを使用します。 。 さらに一歩進んで、要素間のすべての間隔は、この標準を倍数で使用します。 非常に広いスペースは、ハードコードされた値ではなく、 $gutter-width * 2 （30ピクセルに等しい）になります。 このように、アプリ全体が一貫した、整列した感触を持っています。

 .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変数またはミックスインから派生した標準化された値を使用しているため、CSSには独自の数値がありません。 すべてが一元化された値から継承されます。

標準化を確認するには、CSSを確認し、ハードコードされた単位（ピクセル、HEXカラー、ems、またはほとんどすべての数値）を探します。

  • これらの単位は、既存の標準値または変数を使用する必要がありますか？
  • ユニットは、新しい変数の恩恵を受けるように再利用されていますか？ おそらく、部分的に不透明な背景を適用するのはこれが2回目であり、両方の時間で同じ不透明度が必要であることに気付いたかもしれません。
  • 単位は既存の変数の計算から導き出すことができますか？ これは、色のバリエーションに役立ちます。たとえば、標準の色を使用して計算を実行し、結果のHEX値をハードコーディングするのではなく、10％暗くします。

可能な限り、標準値を使用し、例外としてのみ新しい値を作成します。 ここで5ピクセル、そこに1ピクセルの要素を調整していることに気付いた場合は、標準が侵害されている可能性があります。

私の経験では、前処理されたCSSの大部分は一元化された変数とミックスインを使用する必要があり、個々のコンポーネントに数値、ピクセル、またはHEX値はほとんど表示されないはずです。 場合によっては、個々のコンポーネントの位置を調整するために数ピクセルを追加することが適切な場合もありますが、そのような場合でもまれであり、標準を再確認する必要があります。

4.抽象化

基本要素は特定のコンテキストから分離され、コアフレームワークを形成します。

私は当初、この原則を「フレームワーク」と呼んでいました。現在取り組んでいる特定のプロジェクトを作成するだけでなく、元のコンテキストを超えて使用できる設計システムにも取り組む必要があるためです。 この原則は、プロジェクト全体または将来のプロジェクトで使用する必要がある、より大きな共通要素を特定することです。 これは、タイポグラフィやフォームフィールドの入力から始まり、さまざまなナビゲーションデザインに至るまで続きます。 このように考えてください。CSSをBootstrapやFoundationなどのフレームワークとしてオープンソース化する場合、設計要素をどのように分離しますか？ それらをどのように異なるスタイルにしますか？ すでにBootstrapを使用している場合でも、Bootstrapが提供していない基本要素がプロジェクトに含まれている可能性があり、それらはプロジェクトの設計システムでも使用可能である必要があります。

デザインを抽象化されたCSSフレームワークと比較します。
これらのデザイン要素は現在、eコマースWebサイトには存在しませんが、それらのほとんどは、フレームワーク全体を抽象化して利用できるようにするのに十分に役立ちます。 （拡大版を表示）

ここで重要なのは、プロジェクトの特定のコンテキストではなく、より一般的な用語で各要素を考えることです。 特定の要素を見るときは、それをパーツに分割し、現在使用している特定の実装に関係なく、その要素が持つであろう全体的なスタイルを各パーツに与えます。 最も一般的な要素は、タイポグラフィ（見出しのスタイル、行の高さ、サイズ、フォント）、フォーム要素、およびボタンです。 ただし、他の要素も「フレームワーク」にする必要があります。たとえば、コールアウトタグや、デイリーディール用に設計されている可能性があるが、他の場所でも役立つ特別価格のフォーマットなどです。

プロジェクトの抽象化を確認するときは、次のように質問してください。

  • 異なるニーズを持つ別のコンテキストで再利用されることがわかっている場合、この要素をどのように構築しますか？
  • アプリケーション全体で価値のある部分に分割するにはどうすればよいですか？

各要素のより一般的な実装を検討することが重要です。 これらの部分は、完全に別個の独立したクラスとして、またはさらに良いことに、最終的なCSSでコンパイルできる別個のLESSまたはSassファイルとして保存する必要があります。

ウィジェットはおそらくすでにこのように分離されているため、この原則はWebコンポーネントまたはモジュールアプリアーキテクチャでより簡単です。 しかし、それは私たちの思考に他の何よりも多くの影響を及ぼします。 柔軟なものを作成していることを確認するために、常に派生元のコンテキストから作業を抽象化する必要があります。

5.モジュラー

共通の要素は論理的に再利用可能な部分に分割されます。

「抽象化」の原則と重複して、設計をモジュール化することは、操作と保守が容易な具体的な設計システムを確立するための重要な部分です。 両者の間には微妙な境界線がありますが、原則としてその違いは重要です。 ニュアンスは、グローバルベース要素をコンテキストから抽象化する必要がある一方で、コンテキスト内の個々のアイテムも再利用可能であり、独立したスタイルを維持する必要があるということです。 モジュールはアプリに固有のものであり、フレームワーク全体で利用できる必要があるものではない場合がありますが、モジュールを使用するたびにコードを複製しないように、モジュールは再利用可能である必要があります。

たとえば、Daily Dealsランディングページの前の例の商品カードリストを実装している場合、 daily-deal-productようなクラス名を使用してDaily Dealsに固有のHTMLとCSSを作成する代わりに、より一般的なものを作成します抽象化されたすべてのクラスを含むproduct-cardsクラスは、DailyDealsページの外でも再利用できます。 これにより、コンポーネントがそのスタイルを取得する3つの別々の場所が作成される可能性があります。

  • ベースCSS 。 これは、タイポグラフィ、ガター、色などのデフォルト値を含む、基盤となるフレームワークです。
  • CSSコンポーネント。 これらは、デザイン全体の構成要素を形成するデザインの抽象化された部分ですが、任意のコンテキストで使用できます。
  • 親コンポーネント。 これらは、 daily-dealコンポーネント（およびすべての子）です。 多くの場合、これは実際のJavaScript Webコンポーネントになりますが、デザイン全体をレンダリングするために必要なHTMLを含む親テンプレートである可能性もあります。

モジュラーコンポーネントは多くの場合、フレームワークからスタイルを継承し、レイアウトにCSSのみを必要とします。
実装をモジュール化すると、次のような構造になります。各コンポーネントには間隔や位置のスタイルがいくつかありますが、CSSのほとんどはフレームワークから継承されます。 （拡大版を表示）

もちろん、これをやりすぎる可能性があるので、判断を下す必要があります。 ただし、ほとんどの場合、作成するものはすべて、長期的なメンテナンスを過度に複雑にすることなく、可能な限り再利用可能である必要があります。

6.構成可能

基本要素のカスタマイズは、オプションのパラメーターを使用して利用できます。

設計システムの構築の一部は、プロジェクトが現在または将来必要とする可能性のあるオプションを検討することです。 規定どおりに設計を実装するだけでは不十分です。 また、どの部分がオプションであり、異なる構成でオンまたはオフになるかを考慮する必要があります。

たとえば、私たちのデザインのコールアウトフラグは、3つの色のバリエーションのみを示しており、すべて左を指しています。 3つの個別のクラスを作成するのではなく、デフォルトのクラスを作成し、オプションのパラメーターとしてクラス名を追加します。 それを超えて、誰かがやって来て、別のコンテキストにフラグを正しく向けたいと思うかもしれません。 実際、これらのコールアウトにデフォルトのブランドカラーを使用することも、デザインで特に必要とされていなくても便利です。 オプションとして左と右の両方を含め、これを説明するためにCSSを特別に記述します。

これらのコールアウトには、さまざまなスタイルを簡単に作成できるオプションがあります。
デフォルトのコールアウトは実際にはデフォルトのブランドカラーを使用していますが、特別なデイリーディールのコールアウトはランディングページに必要なスタイルを備えています。 また、別の色や右向きのヒントなど、いくつかの代替オプションを作成します。 （拡大版を表示）

特定の設計要素について考えている間、価値があるかもしれないオプションについて考えてください。 これを理解する上で重要なことは、この要素が再利用される可能性のある他のコンテキストについて批判的に考えることです。

  • どの部分を構成、オプション、または外部変数を介して有効にすることができますか？
  • 要素の色や位置を変更できることは価値がありますか？
  • 小、中、大のサイズを提供することは役に立ちますか？

BEM、OOCSS、SMACSSなどの方法論を使用してCSSを整理し、命名規則を確立すると、これらの決定を下すのに役立ちます。 これらのユースケースを処理することは、構成可能な設計システムを構築する上で重要です。

7.スケーラブル

コードは簡単に拡張でき、将来の機能強化が見込まれます。

「構成可能」の原則と同じ精神で、私たちの実装も将来の変更を予期する必要があります。 オプションのパラメータを組み込むことは便利ですが、プロジェクトに必要なすべてを予測することはできません。 したがって、私たちが書いているコードが将来の変更にどのように影響するかを考慮し、拡張しやすいように意図的に編成することも重要です。

スケーラブルなCSSを構築するには、通常、LESSとSassのより高度な機能を使用してミックスインと関数を作成する必要があります。 色を除いてすべてのコールアウトフラグは同じであるため、バリエーションごとにコードを複製することなく、コールアウトごとにCSSを生成する単一のLESSミックスインを作成できます。 コードはスケーリングするように設計されており、1か所で簡単に更新できます。

 @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という名前のLESSミックスインを作成します。このミックスインは、背景色、テキストの色、ポイントの角度、境界線などの値を受け入れます。

.callout-generatorは、背景色、テキストの色、ポイントの角度、境界線などの値を受け入れます。
その結果、任意の数の新しいコールアウトを生成できるスケーラブルなCSSが実現します。 （拡大版を表示）
 .review-flag { .callout-generator(@color-brand, @color-white, 75); }

将来、新しい要件で同様のデザインパターンが必要になった場合、新しいスタイルの生成は簡単になります。

.callout-generatorは、背景色、テキストの色、ポイントの角度、境界線などの値を受け入れます。
（拡大版を表示）

スケーラブルな設計システムを作成するには、プロジェクトで一般的な変更を予測し、その理解を適用して、作成するコードがそれらの変更に対応できることを確認します。 一般的な解決策には、変数とミックスインの使用、および配列への値の格納とそれらのループが含まれます。 自問してみてください：

  • これらの要素のどの部分が変更される可能性がありますか？
  • 将来これらの変更を簡単に行えるように、どのようにコードを書くことができますか？

8.文書化

すべての要素は、他の人が使用および拡張できるように説明されています。

設計の文書化は過小評価されており、多くの場合、プロジェクトで最初に切り取られるコーナーです。 しかし、作業の記録を作成することは、次の人があなたの意図を理解するのを助けるだけではありません。実際には、すべての利害関係者を設計システム全体に参加させるための優れた方法であり、毎回車輪の再発明を行う必要はありません。 。 ドキュメントは、開発者から経営幹部まで、チームの全員が参照できるものでなければなりません。

作業を文書化する最良の方法は、コード内のコメントから直接生成されるライブスタイルガイドを作成することです。 私たちは、スタイルガイド主導の開発と呼ばれるアプローチを、配当でそれ自体を支払うDocumentCSSとともに使用します。 ただし、プロジェクトにライブスタイルガイドを含めることができない場合でも、HTMLまたは印刷形式のPDFで手動で作成することは問題ありません。 覚えておくべき原則は、私たちが行うことはすべて文書化する必要があるということです。

設計システムを文書化するには、他の誰かが設計がどのように実装されているか、そして設計を自分で再作成するために何をする必要があるかを理解するのに役立つ指示を書きます。 この情報には、要素の背後にある特定のデザイン思考、コードサンプル、または動作中の要素のデモが含まれる場合があります。

  • コードの使い方を他の人に教えるにはどうすればよいですか？
  • 私が新しいチームメンバーをオンボーディングしている場合、彼らがそれを使用する方法を知っていることを確認するために私は何を説明しますか？
  • ウィジェットを使用するすべての方法を示すために、各ウィジェットのどのバリエーションを表示できますか？
スタイルガイドは素晴らしいですが、CSSから直接生成されたライブスタイルガイドは人生を変えるものです。
スタイルガイドは素晴らしいですが、CSSから直接生成されたライブスタイルガイドは人生を変えるものです。 （拡大版を表示）

9.正確

最終的な出力は、意図した設計の適切な表現です。

最後に、私たちが作成するものは、それが反映しようとしている元のデザインコンセプトと同じように見栄えがする必要があることを忘れることはできません。 視覚的な魅力に対する期待を満たさなければ、誰もデザインシステムを高く評価することはありません。 結果はデザインの適切な表現にすぎず、ピクセル単位で完全ではないことを強調することが重要です。 「ピクセルパーフェクト」というフレーズは好きではありません。実装がモックアップとまったく同じである必要があることを示唆するために、ピクセルごとに制約を忘れ、標準化の価値を下げることです（すべてのブラウザーがCSSを少しレンダリングすることを気にしないでください）別の方法で）。 精度を複雑にするのは、レスポンシブアプリケーションの静的設計がすべての可能なデバイスサイズを説明することはめったにないという事実です。 重要なのは、ある程度の柔軟性が必要だということです。

プロジェクトに必要な適切な表現の量を決定する必要がありますが、それが一緒に作業している人々の期待を満たしていることを確認してください。 私たちのプロジェクトでは、同じページにいることを確認するために、クライアントとのピクセルの完全性からの大きな逸脱を確認します。 「デザインは境界線のあるデフォルトの青いボタンスタイルを示していますが、標準のボタンの色はわずかに異なり、境界線がないため、代わりにそれを選択しました。」 ここで最も重要なステップは、期待値を設定することです。

実装は元のデザインとは異なりますが、それでも正確です。
実際のデータと標準化されたCSSを使用した本番環境では、最終的な実装は元のモックアップとは少し異なります。 さらに、いくつかの要件は実装中に変更されました。 ただし、結果は正確です。 （拡大版を表示）

思考システム

これらの9つの原則の目標は、HTMLおよびCSSで設計を実装するためのガイドを提供することです。 これは、優れたデザインと優れたコードの最適なバランスを最適化できるように、作業について考える方法であるほど、一連のルールや規範的なアドバイスではありません。 これらの原則を適用する際には、ある程度の柔軟性を身に付けることが重要です。 あなたは毎回一人一人で完璧を達成することはできません。 それらは理想です。 私たちが最善の仕事をすることを妨げる他の気晴らし、原則、および優先順位が常にあります。 それでも、原則は常に努力し、常に自分自身をチェックし、設計を製図板からそれが体験される最終的な媒体に移すときに積極的に追求するものでなければなりません。 より良い製品を作り、何年も続くデザインシステムを構築するのに役立つことを願っています。

デザインの実装経験についてお聞かせください。 コメントを投稿し、自分の仕事で使用している可能性のあるアドバイスやその他の原則を共有してください。