Atomic Design 導入前に知るべき事【Brad Frost氏の記事翻訳】

Atomic Design 導入前に知るべき事【Brad Frost氏の記事翻訳】

Atomic Design に興味があり、あれこれと情報を集める中で、Brad Frost氏 (Twitter) の書籍が大変参考になったので、翻訳を残しておきます。
Webでも閲覧できますが、納得させられる素晴らしい内容ですのでぜひ購入も検討してみては?

購入はこちら!

少しずつ、意訳・要約をしていけたらと思っております!

※英語全然喋れないので、うまく意訳できているか分かりませんが参考になると嬉しいです

まずは、Atomic Design を学ぶ前に知っておくべき事(主にスタイルガイドについて)や心構えの書いてある章がありましたので、そちらから。

本編はこちら
 

ページの変遷

4000年前から続いていた紙媒体の概念はWorldWideWebへと引き継がれ、より簡単に共有できるドキュメントが確立された。
この紙媒体におけるページという概念(名前)をWorldWideWebにおいても活用することにより、世間一般にこの新しい仕組みをうまくナビゲートすることができた。
既存の概念によるナビゲートの例として、ブックマークという機能(名称)においても同様にすでに習慣的に用いられていた概念を利用することで、新しい仕組みをマスターするのに役立たせる事が出来た。

Webの初期段階では印刷物をそのままWebのコンテキストに落とし込もうとする事が多かったために悩みどころが多くあった。
Webにおける「ページ」という概念と実社会での紙媒体との実態に差異があり、Webのコンテンツ(ページ)が流動的で相互作用的なものであるにも関わらず、紙媒体のように定量的に捉えられてしまうのも問題であった。

例えば「ホームページを作る」といっても紙媒体のように文言だけであればすぐに終わるが、背景画像や配色・タグ配置やインタラクションなどにこだわれば、数ヶ月かかる事さえある。
逆に3000ページあるホームページを作るとしても、構成がシンプルであり、流し込むデータが用意されているのであれば、即座に作り終えてしまうこともある。
つまり、ホームページを作る労力はページ数ではなく、構成や要素によって決まる事の方が多いと言える。
前述の「ページ」という言葉にみるような既成概念を利用した呼びまわしは、Webを浸透させるために多大な貢献をしてきた。
しかし、多数のデバイスに提供されることが前提になった今、使いやすいインターフェースを実現するために、私たちはこの概念を超えていかなければならない。
 

ページの概念を超えていく

多くのチャットツールはWeb上で効果的に会話を成り立たせるためによく作られている。「会話ごとにポップアップする」というコンセプトはWebエクスペリエンスとしてすでに成功を納め、既知の概念となっている。
この共通認識として再利用可能な状態が、モジュール性というものである。

モジュール性はWebよりもはるかに長く存在しており、産業革命下では交換部品などにその性質を見て取る事ができた。この交換部品(モジュール性を持った部品)を活用した事でフォードの組み立てラインが確立し、この自動車製造プロセスは今でもなお利用されている。

初期の自動車製造では一台一台が個別に製造され、保守性と安全性が皆無であった。
フォードは自動車を部品単位に分解し、組み立てのプロセスをモジュール化した。その結果、均一で信頼性・保守性の高い自動車製造が現実となり、製造時間も大きく短縮されたのである。

その後コンピュータ時代が訪れたわけだが、コンピュータ科学者たちは問題の分離や単一責任原理のようなモジュール概念を確立し、オブジェクト指向プログラミングを習得していった。
こうした世界からWorldWideWebが生まれたので、モジュール設計がすぐにWebアーキテクチャの設計原則となったのは驚くことではない。

やがてこれらの設計思想はゆっくりと、しかし確かに、Webデザイナーのワークフローに入り込んできている。

2000年代初めに、YUIやjQuery UIのようなライブラリが開発に導入され、ウィジェットやパターンのツールキットが提供された。これにより一貫したユーザーインターフェイスが作成されはじめた。
「ではそれを使ったらいいじゃないか」
と思うかもしれないが、モジュール性はこれまで以上に重要になっている事をまず認識すべきである。
なぜなら、今現在でもデバイスの量と多様性は多大であるが、今後それを利用する人の増加に伴い、多様性も爆発的に増していく事は明らかだからである。
この現実に対処するために一歩踏み込んで、これらの多様なデバイスに対応するタスクをより小さく、管理しやすい塊にすることが絶対に必要である。

この試みは実はすでに人々が行っているものであり、モジュール性の活用は組織の戦略・プロセス・コンテンツ・設計・開発に、すでに大きな影響を与えている。
 

管理可能なストラテジー

大体の企業は、「3〜8年ごとにWebサイトを作り直す」という作業が、もっとも適切な処置ではないと感じているはずである。
確かに、潔く古きを捨てて新しきを得る事は素晴らしいことかもしれないが、以前のインターフェースを何年も学んで利用していたユーザからすれば、困惑する事は必須である。

ユーザ体験を大幅に変更して再設計した場合、ユーザはインターフェースの学習に対して多大な時間とストレスを抱える事になる。
ユーザへの混乱に加えて、この手の再設計は何の問題の解決にもなっていない。プロセスの改善をしない限り、今日新しくしたものがやがて古くなった時、再度ユーザへの負担を抱えなければならなくなるのである。それどころか、改善点に対して開発側が麻痺してくることすらある。

上手く回っているスタートアップのような小規模組織を見ればわかるが、最小限の機能で製品をリリースし頻繁にユーザ体験を改善していくことで、ユーザの反応をフィードバックし、絶えず変化するWebのトレンドにも対応していく事は可能なのである。
 

反復プロセス

真にアジャイルなプロセスを導入する事は難しいが、試験的な試みを行ったり、より早くかつ頻繁なリリースフローを確立し、大きな作業をより小さなコンポーネントに分割するという事は健全な考えである。
このような小規模に分解した開発プロセスは導入するに値する。
 

モジュール化されたコンテンツ:チームチャンク

デスクトップがWebの唯一のデバイスであればよかったが、今や多くのデバイスに対応しなければならない。
このようにますます多様化したデジタル環境に適切に対処するために、コンテンツの認識とそれを管理するために使用するツールを劇的に変えていく必要がある。
ありがたいことにこれは実現化されはじめており、モジュール化されたコンテンツを作成・維持するツールは進化してきている。スマートなモジュール式の考え方が主流のコンテンツ管理システムに移行してきているのである。
 

先進的なコード

オブジェクト指向はWebの他の側面にも取り入れられており、 OOCSS、SMACSS、BEMなどの方法論はWebデザイナーがモジュラーCSSアーキテクチャーを作成して維持するのに役立つように切り上げられている。
 

ビジュアルの改善

Web上のスタイルコードにモジュール性を浸透させるだけでなく、デザイナーが最新のWebデザインにどのようにアプローチするかにも革新が必要である。
デバイスの種類と環境の数が増えるにつれて、Webエクスペリエンスのすべての静的なモックアップを生成することは難しくなる。
かといって、PhotoshopやSketchのような静的なデザインツールが重要ではないと言っている訳ではない。我々はこれらのツールをもっとダイナミックに使用しなければならない。何百もの完全なコンプを作成するのは現実的ではないが、これらの静的ツールは「デザイン雰囲気」と呼ぶものを確立するためには優れていると言える。

デザインの雰囲気を早期に確立することは、プロジェクトの成功にとって非常に重要である。しかしそのために、デザイナーは完全なモックアップを生成する必要はなく、別のやり方がある。デザイナーのSamantha Warrenは、スタイルタイルと呼ばれるデザインアーチファクトを開発し、カラー・タイプ・テクスチャの探索をカプセル化された1ページャーで実演した。デザイナーのDan Mallは、Samanthaのアイデアを要素コラージュというコンセプトで構築した。
 

体系的なUIデザイン

数年前、Ethan Marcotte氏はレスポンシブウェブデザインとその3つの主要な考え方、つまり「流体グリッド」」フレキシブルメディア」「CSSメディアクエリー」という概念を紹介した。これらの3つの要素は、あらゆる画面サイズにスマートに適応する柔軟なレイアウトを作成するために必要な基盤を提供した。

マルチデバイスのWebエクスペリエンスを作成するには、スキッシュページを作成するよりもはるかに多くの作業が必要である。インターフェイスの個々の部分には、さまざまな画面サイズや環境で美しく見えるように、独自の課題がある。
どのようにしたら小さな画面や大画面で、水平リストとして表示されるナビゲーションを分かりやすく提示することができるか。ライトボックス、ブレッドクラム、カルーセルは小さなビューポートの場合どのような代替入力に変換すべきか。
これらの問題は、レスポンシブな環境で特定のコンポーネントを実行する際の様々なパターンのショーケースである。
This Is Responsiveは、これらのインターフェイスパターンが画面サイズや環境全体でどのように拡大縮小できるかを明確に示しているが、設計者や開発者はこれらのパターンを実際に実行してみる必要があり、それは思った以上に負荷が大きい。
 

理論と実践におけるUIフレームワーク

どのようなデバイスや環境でも、見た目と機能が美しく実行されるようにするために、すでにデザイナーと開発者は時間とリソースに悩まされている。
このようなデバイスの多様化に対応しプロジェクトを健全に進めていくには、Foundation by Zurb and Bootstrapのようなフロントエンドのフレームワークが必要となる。これらのユーザーインターフェイスフレームワークは、ドロップダウンやカルーセルなどのインタラクティブなコンポーネントの機能を実現するために、HTMLパターン、CSSスタイル、およびJavaScriptを事前に集めたものを提供している。本質的に、これらのフレームワークはインターフェイスを迅速に組み立てるための便利なツールキットである。

こうしたフレームワークは非常に人気があり、BootstrapはGitHub上で最も人気のあるリポジトリである。これらのフレームワークが人気である事は、デザイナーやデベロッパーがこれまでにない複雑なウェブ環境に立ち向かうための強固な基盤を模索しているという証拠となるだろう。

フレームワークの最も魅力的な側面の1つはスピードである。 Bootstrapのようなフレームワークにより、デザイナーは素早くアイデアを入手し、素早くプロトタイプを作成し、サイトを早期に立ち上げることができる。ツールキットで提供されるパターンは既にブラウザ間でテストされているため、開発者が古典的なバージョンのInternet Explorerをテストしていた時間をより重要なタスクに費やすことができる。そして、デザイナーが立ち往生した場合、これらのフレームワークのコミュニティでは役立つサポートと助言を吸い上げる事ができる。
Bootstrapのようなフレームワークは、しっかりとテストされたコンポーネントを提供する非常に一般化したデザインシステムであり、一貫したデザインとより速い起動をもたらしている。しかし、プロの現場においてはしばしば問題がある。
 

フレームワーク天国における問題

私たちは皆異なった好み、目標、欲望を持ってるものだが、ウェブ上では誰もが同じようにやりたいというジレンマに陥る傾向がある。
「すべてj-Queryで実装されていればいいのに!」
「WebKitで統一されるべきだ!」
「端末の画面サイズを統一してくれ!」
など。

ウェブプロジェクトには多様なニーズ・目標・無数の異なるソリューションとの繋がりがある。そこに時間的な制約や場所も介入するので、デザイナーや開発者はどのツールをいつ使用するか判断する必要がある。
フロントエンドフレームワークは、特定のソリューションと特定のルックアンドフィールを提供するツールである。これらのソリューションは開発のスピードアップに役立つが、結果として得られる体験は類似してくる。

誰もが同じボタン・グリッド・ドロップダウン・コンポーネントを使用すると、自然とそれらは同じように見えてくる。Nike、Adidas、Puma、ReebokがBootstrapを使用してそれぞれのサイトを再設計したら、それらはほぼ同じように見えるはずである。各ブランドはデフォルトの設計を変更して拡張することもできるが、カスタマイズはフレームワークの構造、スタイル、および機能と戦うことを意味している。

類似する問題に加えて、これらのフレームワークは不要なソースを含んでしまう問題がある。フレームワークにはあらかじめ構築されたコンポーネントや機能が豊富に用意されているが、設計者や開発者の多くはその全ての機能を使うことはないだろう。残念なことに、ユーザーはフレームワークの未使用のCSSとJavaScriptをダウンロードしなければならず、その結果、ページの読み込みや様々な欲求不満が発生する。

またありがちであるが、プロジェクトの目標を達成するために相当量のカスタムコードを作成する必要が出てくる事もある。フレームワークを使用することによる当初の利点、すなわち開発スピードが、フレームワークの修正・拡張、および修正によって損なわれる事態もよく起こる事である。
そして、コード規約などにも問題があるだろう。フレームワークを使用するという事は、他の人の構造、命名規則、スタイル規則に加入するという事である。組織にとって意味のある規約が、フレームワークとは相違していることもあり得る。
既存のコードやワークフローとフレームワークの命名規則の差異は、フレームワーク導入前に適切に議論されるべきだろう。

ここではフレームワークについて踏み込んだが、概念的にはこれらのフレームワークが非常に重要であることを認識してほしい。一貫性を促進し、開発時間を短縮する設計ツールキットを使用することは、優れたアイデアである。だが、必ずしもすべてのクライアントにBootstrapを使用するのではなく、できればすべてのクライアントに対して「小さなブートストラップ」を作成することが大切である。
設計システムの使用ではなく、システムを作成することが重要だ。
 

デザインシステムが明日を救う

「スタイルガイド」とは、ガイドライン、使用法、ガードレールを提供しながら、設計をドキュメント化して整理した優れた設計システムである。

ブランドアイデンティティ、文章、ボイス&トーン、コード、デザイン言語、ユーザーインターフェイスのパターンなど、スタイルガイドには多くの要素がある。この本では、スタイルガイドのすべてのカテゴリについて詳しくは説明しないが、各要素がどのように他の要素に影響を与えるか、ウェブのスタイルガイドをより大きなエコシステムにどのように適合するかを理解することが重要である。
 

ブランドアイデンティティ

ブランドアイデンティティガイドラインは、企業をユニークにする資産とマテリアルを定義する。ロゴ、タイポグラフィ、カラーパレット、メッセージ(ミッションステートメントやタグラインなど)、テンプレート(名刺やPowerPointテンプレートなど)などは、ブランドアイデンティティガイドラインに集約されて記述される。

より多くのメディア、チャンネル、タッチポイントでブランドが一貫して表現されることが不可欠である。あなたの組織のすべての人は、1つの理念の元に話し、感じる事ができているだろうか。どのPantoneカラーを使用すべきか、またブランドのロゴを正しく使用する方法を知ってるだろうか。
ブランドアイデンティティガイドラインは、これらの基本的な指針に対する回答を1つの集中型ハブで提供するものである。

歴史的に、ブランドアイデンティティのガイドラインは、ハードカバーの書籍(ページがあることを覚えておいてください)に含まれていたが、他のもの同様、ブランドスタイルのガイドはオンラインに移り変わってきている。
 

デザインランゲージ

ブランドアイデンティティガイドラインは触発的な側面を持つが、デザインランゲージのガイドラインは固定の指針を打つのが少し難しい。デザインランゲージスタイルガイドは、一般的なデザインの方向性、哲学、および特定のプロジェクトや製品へのアプローチを明示する。

より多くの製品やメディアにおいて一貫した方法でプロダクトを表現するために、Googleはマテリアルデザインというデザインランゲージを開発しました。マテリアルデザインスタイルガイドは、マージンデザインの哲学、目標、一般原則を定義するとともに、マテリアルデザインランゲージである特定のアプリケーションを示している。

デザインランゲージスタイルガイドでは、他のスタイルガイド要素の側面を組み込んで、より高度なコンセプトをより具体的なものにすることができる。

デザインガイドラインは、ブランドのガイドラインと同じように固定されていない。たとえば、Googleはマテリアルデザインに取って代わる新しいデザイン言語を開発する可能性が高いため、Googleの全体的なブランド指針はそのまま残っているが、製品周辺のデザインボキャブラリーは変化する。
 

ボイス&トーン

人々は、膨大な数のチャンネルやメディアを通じてブランドと交流する。これまで説明してきたデジタルメディアに加え、印刷物、小売り、イベント、ラジオ、テレビなどでも接する事だろう。ブランドが多様なタッチポイントを超えてコミュニケーションしなければならない場合、統一された一貫性のある方法でコミュニケーションを取ることは、ブランドの成功にとって非常に重要となる。

ボイスはブランドにとって基本的で重要な要素であるため、ブランドアイデンティティのガイドラインはブランドのボイスを参考に作られる場合もある。しかし、これらのガイドラインは通常、あまり詳細なものではない。そのため、ボイス&トーンのガイドラインが別途必要であり、重要となる。

ボイス&トーンのガイドラインは、会社のボイス&トーンをさまざまなシーンでどのように適応すべきかを明確にすることによって構成される。 MailChimpのボイス&トーンガイドラインは、ユーザーのクレジットカードが拒否されたときに、より深刻な色調を採用するよう示している事はよく知られている。
 

ライティング

Webコンテンツの台頭により、組織内の多くの人々がコンテンツを公開する事が容易になった。これは両刃の剣でもあり、多くの声を持つ組織が一貫した文章スタイルを維持することは非常に難しい。ライティングスタイルのガイドは、すべての作者にコンテンツを提供するためのいくつかのガイドラインとガードレールを提供する。

スタイルガイドの作成は、句読点や文法の詳細を定義する非常にきめ細かいものであるが、必ずしも細かく記述する必要はない。Dalhousie Universityの執筆スタイルガイドは、コンテンツ提供者が従うべき原則とベストプラクティスの簡潔なリストで構成されている。
 

コードスタイルガイド

チームが読みやすく、スケーラブルで、保守可能なコードを書くことは不可欠である。しかし、コードの一貫性を促進し強制する方法がない場合、容易にコードの質は下がり、開発者自信を苦しめるだろう。

コードスタイルガイドは、コードにどのようにアプローチすべきか、規則、パターン、例を提示する。これらのガイドラインに従う事で、チームは不要なリファクタリングを避ける事ができ、より有用な作業を集中的に行うことができる。
 

パターンライブラリ

フロントエンドスタイルガイドとして知られるパターンライブラリとは、UIライブラリ、またはコンポーネントライブラリとも呼ばれ、近年のインターフェイスデザインの基盤になりつつある。

この本の残りの部分では、どの様にインターフェースデザインをシステマチックに構成出来るか、またパターンライブラリを確立して維持するにはどうすれば良いかの方法を詳しく説明する。
 

スタイルガイドの利点

多数の画面サイズ、デバイス、ブラウザ、および環境で動作するUIを構成する事だけならば、さほど難しくないだろう。しかし、いったん他のチームメンバー、クライアント、ステークホルダー、そして組織の特徴などが関与してくると、容易さは途端に脅かされるようになる。

スタイルガイドは、設計と開発、または組織と、それぞれの観点からアプローチした際に混乱するのを防ぐのに役立つ重要なツールである。これこそ、スタイルガイドが現代のWebデザインと開発にとって不可欠なツールになった理由だろう。
 

一貫したクオリティ

スタイルガイドは、ユーザーインターフェイス全体の整合性と結合性を促進する。この一貫性は、インターフェイスの作成者とそのユーザーの両方に利益をもたらす。

私は最近、保険料を支払うためにある健康保険会社のウェブサイトを訪れた。 5回のクリックの間に、私は4つの異なるインターフェイスデザインに遭遇した。そのうちのいくつかは、1999年の終わり頃のものに見えました。この一貫性のない体験は、異なるインタフェース要素であるために、ユーザーがどこに行くべきで何をすべきなのか分からないという困惑を与えていた。私は結局支払いフォームに辿り着くまでに、諦めてしまった。

スタイルガイドは、インタフェース要素の再利用を促すことによって、これらの不整合を解消するのに役立つ。設計者と開発者は既存のパターンを参照し、作成中の振る舞いがすでに確立されている振る舞いと同等であるか確認することができる。

サードパーティのUIであっても、スタイルガイドを活用することで企業のルックアンドフィールにマッチさせる事ができる。外部で管理されている支払いのポータルやサイトなどでも、ガイドに定義されているスタイルを適用することで、組織やアプリに沿ったルックアンドフィールへとより一致させることができる。

スタイルガイドをプロセスの中心に置くことで、より統一された信頼感のあるユーザーインターフェイスが得られ、ユーザーはタスクをより迅速に実行し、インターフェイスをマスターできるようになるのである。
 

共有ボキャブラリー

「ユーティリティツールバー」とは何であるか、誰もが理解しているだろうか?

プロジェクトに取り組んでいる人の数が増えるにつれて、やりとりに支障をきたす事が多くなる。同じ組織内で異なるモジュール名を使用したり、個人の判断で独自の命名規則を作成してしまうことは珍しくない。真にコラボレーションを実現するには、チームが共通の言語を話すことが不可欠であり、スタイル・ガイドは共有された語彙を確立するのに役立つ。

スタイルガイドにプロジェクトに携わる全員との間で共有された語彙を確立する事で、組織間のやりとりをスムーズにする事が出来る。
 

教育

Anna Debenham氏の著書「フロントエンドスタイルガイド」では、スタイルガイドの多くの利点について、説明されている。

スタイルガイドは、クライアント、ステークホルダー、その他の組織に「新しいウェブサイトを作ろう!」という意気込み以外に、やらなければならない多くの作業があることを実証できる。パターンライブラリは、最終的にどのようなインターフェースにする事が出来るか、ステークホルダーが理解するのに役立つ。

組織の特定の部門が独自の問題を抱えている時、ユニークな解決策が必要になる。そんな時、デザインシステムをスタイルガイドの形で公開しておくことにより、それらの解決策がより一貫性を踏襲したものとなり、一貫性を欠いたカスタムデザインの場合、なぜそれが許可されないのか理解することができる。
 

共感的なワークフロー

優れたスタイルガイドは、教育や顧客や利害関係者にとって重要なだけではない。デザイナーや開発者にツールボックスにあるツールを知らせるのに役立ち、適切に使用するためのルールとベストプラクティスを提供する事ができる。

デザイナーと開発者は、スタイルガイドをワークフローの基礎とすることで(第4章で詳しく説明する)、その実装が設計システムにどのように影響するかを考える必要が出てくる。すなわち、乱雑な開発がより困難になり、より大きなメリットを生みやすくなる。そして、これはまさにあなたがチームメンバーになる際に望まれる事である。

スタイルガイドは、それぞれの分野について、パターンに対するそれぞれの考慮事項と懸念事項を提起するための枠を提供する。これらすべての考慮事項を1つの枠組みの下に集めることで、スタイルガイドはプロジェクトに関わる全員のハブになり、各分野が設計システムをより多くの視点から理解するのに役立つ。
 

テスト、テスト、テスト

インターフェイスをコンポーネントの部分に分けることができるため、テストが大幅に簡単になる。スタイルガイドでは、インターフェイスパターンを孤立して表示できるため、開発者はエラー、ブラウザ間の不一致、パフォーマンスの問題の原因を突き止めることが容易になる。
 

速度

この章の前半で、BootstrapのようなUIフレームワークが非常に人気を集めている主な理由の1つが、設計と開発を早く進める事が出来るからであると議論した。われわれは可能な限りすぐにプロジェクトをリリースしなければならないという圧力を受けているわけだが、独自のデザインシステムを開発することで、すぐに使えるUIツールキットと同じスピード感を得ることができる。

インターフェイスデザインシステムを考案し、カスタムパターンライブラリを作成するには、最初は多くの時間・思考・労力が必要である。しかし、パターンライブラリが確立されると、その後の設計と開発がはるかに高速になり、誰もが恩恵を受ける事ができる。

MailChimpのLead UX開発者であるFederico Holgadoは、MailChimpのパターンライブラリが、最初にアプリケーションの4つの主要画面から作成されたパターンで構成されていることを説明した。しかし、サイトの他の領域に移動してみたところ、毎回新しいパターンを生成する必要はなく、既存のパターンを使用できるようになっていた。
 

より長持ちさせるために

スタイルガイドは、チームが効果的に物事を進めるのを助けることは間違いない。しかし上質なワインのように、スタイルガイドは時間とともによりその真価を発揮する。インターフェースデザインシステムの素晴らしさは、何年もの間それらを修正し、拡張し、洗練することができる点にある。

前述したように、カスタムパターンライブラリを作成するには多くの作業が必要だが、それは反復と洗練のための構造的基礎を提供してくれる。アナリティクス、ユーザーテスト、A / Bテスト、および経験から学んだ教訓をスタイルガイドに組み込む必要があり、真実、知識、ベストプラクティスの強力なハブになり得る。

たとえあなたが大規模な再設計を行う場合であっても、構造上のインターフェースビルディングブロックの多くは同じままであることが分かるはずである。フォーム、ボタン、見出し、その他の一般的なインターフェイスパターンがあるので、全てを引っくり返す必要がない。スタイルガイドは、将来のやる事がまったく別物に見えても、将来のすべての作業について堅固な基盤を提供してくれる。
 

スタイルガイドの課題

デザインシステムを作成することのメリットは十分にある。うまくいけば、既に美しいスタイルガイドのビジョンがあなたの頭の中で踊っているはずだ。しかし、スタイルガイドの真骨頂に到達するには、まず、そこに付随する多くの危険なリスクを克服する必要がある。
 

ハードな売り込み

スタイルガイドの恩恵を受けるには、まずそれらを実現させるために必要な時間と予算を適切に考慮する必要がある。そのためには、組織として短期的な考え方を見直す必要があることを企業文化に浸透させる必要がある。

スタイルガイドが提供する長期的なメリットは、すでに長期的な開発に携わっている人にとっては明らかである。したがって、思慮深い設計システムを確立することが将来的に賢明な投資であるという事を、四半期ごとの考えに固執している短絡的な人々を納得させるのが最大の課題である。
 

時間の問題

おそらく、最も避けられない課題は、スタイルガイドが作成するのに時間がかかるということだろう。仕事に向かう時に少しもストレスを感じていない人はいないだろうし、そのストレスは当然プロジェクトにも影響してくる。残念なことに、チームに本当に必要な場合でさえ、稼働可能な限られた時間と有限である予算が、スタイルガイドを作成するために必要な労力を低下させるだろう。
 

補助プロジェクト

パターンライブラリは、最終的な製品の構成要素としてではなく、補助的なプロジェクトとして扱われることがよくある。パターンライブラリをコアプロジェクトとは別のものとして扱うとよい組織として落ち着き、いざという時一番に議題に挙げられる事だろう。

この補助プロジェクトとしての難点は、プロジェクトにアクセシビリティ組み込む際に私がよく聞くある感情を思い起こさせる。「ああ、アクセシビリティのための時間と予算があればいいのに…」というものである。アクセシビリティ(およびパフォーマンスと応答性のような他の要素)がコストのかかる余分な項目であるという考え方は誤りである。アクセシビリティにおけるパターンライブラリは、プロジェクトに明示的に組み込まれたかどうかにかかわらず、ワークフローを構築する良いアイデアとなる。
 

メンテナンスとガバナンス

スタイルガイドを作成するために時間と資金を配分されていたとしても、これらの貴重なツールはその優位性にフォーカス出来ていなければ無駄になる事がある。
スタイルガイドの成功のためには、メンテナンスとガバナンスの戦略が不可欠である。誰が管理・維持し、ハンドリングするのかなど適切な戦略を立てないと、スタイルガイドはPSDとワイヤフレームと同様にゴミ箱に投げ捨てられてしまうだろう。
スタイルガイドのメンテナンスは非常に重要なトピックであり、詳細に説明する必要があるので、第5章でメンテナンス可能なスタイルガイドを作成する方法について説明しよう。
 

オーディエンスの混乱

スタイルガイドは、デザイナーや開発者だけに役立つツールとして誤解される事があり、そのため視認性が下がったり、その有効性を限定的に考えられたりする事がある。考え過ぎかもしれないが、これではコラボレーション文化を助長するには至らないだろう。スタイルガイドは、組織の人々に水を供給してくれる蛇口として機能させるのではなく、1つの規律で守られた最高の共有物であるべきだ。

幅広い参照者を意識しないと、より技術的で曖昧になり過ぎてしまい、他の分野の規律を圧迫することになり、参照者にとって関係ないスタイルガイドであると認識されかねなくなる。
 

スタイルガイドの構造

スタイルガイドが組織の全員にとって有用なリソースであるためには、それが何であるか、なぜ重要なのかを明確に伝える必要がある。スタイルガイドは、魅力的で、視認性がよく、明確で、使いやすいものでなければならない。上記のように、参照者する全ての組織がこのスタイルガイドを見ていることを意識する必要があり、できるだけ多くの人々を歓迎し、彼らにとって有用であることを目指す必要がある。
 

文脈の欠如

設計システムを理解するためには、コンテキストが重要である。残念ながらほとんどのパターンライブラリは、コンポーネントがいつ、どのように、どこで使われたかについてのヒントを提供していない。コンテキストを提供していないと、デザイナーと開発者は特定のパターンがどこに公開されているのか明確に分からないので、アプリケーションのどのページを訪れれば良いのかわからず、変更が加えられたかどうかテストする度に質問しなければならなくなる。
 

明確な方法論がない

これらのパターンライブラリを私は尊敬しているが、その構造に欠落がある事を私には訂正する事ができない。勘違いして欲しくないが、これらのチームが体系的に考えており、UIパターンをきちんと文書化していることは本当に素晴らしいと思う。しかし、しばしば多くのパターンライブラリはモジュールの疎なスプレーだけで終わらせるには勿体無く感じる。そこには改善の余地があると思う。
 

インターフェース設計方法論の探索

私たちがこの折衷的なウェブのための体験を創造していくためには、ウェブの誕生以来私たちと一緒だったページのメタファーを超えて進化しなければならない。ありがたいことに、組織はWeb制作プロセスのあらゆる面でモジュール化を採用しており、よりスマートな作業とより持続可能なシステムにつながる事が期待できる。

デバイス、ブラウザ、および環境の数が驚異的な割合で増加し続けるにつれて、慎重なインターフェース設計システムを作成する必要性がこれまで以上に増していく。
それでは Atomic Design の世界に入っていこう。