Webサイトに一貫性を持たせて、管理しやすくすることは、大規模な組織が直面するもっとも大きな悩みの１つです。幸いにも、このときパターンライブラリが役に立ちます。
大規模なWebサイトが直面する特有の問題に対するソリューションとして、気付けば私はパターンライブラリの作成を提案することが増えていました。それは、クライアントがNestleのような大企業であろうと、ストラクスライド大学のような高等教育機関であろうと、あるいは国境なき医師団のような大きな慈善団体であろうと同じです。
では、パターンライブラリとは何でしょうか？ なぜそれが必要なのでしょうか？ 作成するにはどうしたらいいのでしょうか？
パターンライブラリとは
パターンライブラリとは、UIデザイン要素を集めたものです。UI-Patternsでは、こうしたUIデザインパターンを次のように説明しています。
パターンライブラリとは、デザインに共通する問題を解決するとき、繰り返し使えるソリューションです
まだよくわからないのも無理はありません。Webデザイナーは、実際よりも複雑に聞こえるように話すのが好きですから。
パターンライブラリは基本的に、サイトに何度も登場するデザイン要素を集めたものです。その代表例には次のようなものがあります。
- スライドショー
- ナビゲーション
- ソーシャルメディア機能
- ニュース一覧
- 関連リンク
- カルーセル
パターンライブラリはこうしたすべてのパターンまたはモジュールの資料集であり、各パターンがどう機能するか、どのような見た目か、どうコードされているかを定義します。
パターンライブラリは、さまざまなWebサイトで再利用できそうなデザイン要素を集めたものです。
チェックするべきパターンライブラリの例には、次のようなものがあります。
もちろん、パターンライブラリは自然にできあがるものではありません。作成する必要があるもので、それには労力が要ります。では、なぜパターンライブラリの作成に時間を費やすことに価値があるのでしょうか？
パターンライブラリが必要な理由
Webサイトが一定のサイズに達し複雑になると、パターンライブラリを支持する声は圧倒的に多くなります。たくさんのサブサイトを含む場合はなおさらです。パターンライブラリのメリットは３つあります。
一貫したUIを実現する
大規模なサイトは、異なる人々によって長い間開発され、定期的に見直されています。そのため一貫性を確保する何かがなければ、ほぼ確実に統一感がないバラバラなUIになります。
大規模なサイトをどれでも１つ訪れれば、統一感がないサイトの実例を見ることができます。ナビゲーションの位置がバラバラで、フォームの要素は別々に設定され、タイポグラフィさえも変わってしまっています。こうしたことが起こるのは、過去にどのように体系づけられたかを調べるより、ボタンが実際どう見えるか推測するほうが簡単だからです。パターンライブラリがあれば、サイトのあらゆるページに既に存在するデザインや機能を簡単に複製できるので、こうした状況が改善されます。
規格を制定するパターンライブラリが存在しない場合、大規模なサイトでは矛盾が生じやすくなります。
再利用しやすくなる
大組織では、複数のWebチームが会社全体で働いて、異なる部署に報告することがよくあります。こうしたチームが個別で取り組んでしまい、結果的に多大なコストを費やしてサイトを１から開発していることが多くあります。
中心となるパターンライブラリがあれば、こうしたWebの専門家たち全員の間に連携が生まれるので、組織は機能とデザインを再利用でき、コストダウンに繋がります。
あるWeb開発者が、担当している分野である要件に関する新しいパターンを作成すると、これをグループ全体で共有できるようになり、今後のプロジェクトに永続的に活用することも可能になります。
パターンライブラリがあれば、前もって決められたレゴブロックで何かを作り上げるように、既存の要素から構築できるようになります。
新たなサイトを作成するための大部分のパターンが既に存在する、またはサブセクションがこうしたパターンを組み合わせるだけになるとなると、毎回ほぼ同じやり方で、既存のレゴブロックを使って構築することができます。
メンテナンスが簡単になる
全員が利用する、一貫したパターンライブラリがあることで、管理も簡単になります。同様に、要素をコーディングする際、開発者が他人のコードに取り組むのもとても簡単です。また、新しい開発者がやってきたときも、パターンライブラリを見ることで、より早く追いつくことができます。
以上でパターンライブラリを構築する価値がわかったのではないでしょうか。それでは、最後の疑問です。パターンライブラリはどのように構築するのでしょうか？
Googleは長い間、別々のチームが作った多くの製品の一貫性を保つのに苦戦してきました。パターンライブラリを導入したことで、この問題に対処することができました。
パターンライブラリを作成するためのヒント
上記の例からわかる通り、パターンライブラリに特別なものはありません。原則的に、要素、関連するコード、いくつかのメモを集めたものです。
どのようなパターンライブラリを実装するかは、完全にあなた次第です。しかし、私がパターンライブラリに取り組む際に発見したいくつかのヒントを共有すれば役に立つかもしれません。
最初からパターンライブラリを考える
一度サイトを構築してしまったあとで、パターンライブラリを作りたい衝動に駆られることは多くあります。しかし、それではパターンライブラリを所有する意味が大きく失われてしまいます。
私がパターンライブラリの作成に取り組むときは、誰かがコード行を書く前に、そのあらすじを組み立てます。まだプロトタイピングの段階であっても、個々のパターンのワイヤーフレーム、パターンの機能の仕方に関するメモ、その他の考察を盛り込んでライブラリを作成します。これによって、ライブラリは開発の要点がまとめられた、ある種の機能仕様書として作用し、デザイナーや開発者の助けになります。
開発者がコードを書き始めると、こうしたパターンは最終的なデザインや関連コードによって肉付けされます。この手法は、最後にすべてを組み立てるよりも非常に簡単です。また、サイトを構築する際にパターンを再利用することもできます。
パターンライブラリに最終的なコードやデザインは必要ありません。その代わり、いくつかのワイヤーフレームに取り組む段階で早めに始めましょう。
レスポンシブなパターンにする
現在では言うまでもありませんが、パターンが複数のデバイスでどのように反応するか、慎重に考慮しましょう。パターンの外観を表示する際、別のサイズではどのように表示されるか実際に試しましょう。
これは、モバイルデバイスだけでなく、さまざまなコンテキストでパターンを使用する際にも有効です。たとえば、ページの本文にニュース一覧が表示される場合、一覧にはサムネイルが含まれるかもしれませんが、より狭いサイドコラムに表示されるときには、サムネイルは省略されます。
関連リンク：How to adopt an iterative approach to UI design
パターンの構成要素を定義する
パターンの多くは、複数の構成要素から構成されます。たとえば、ニュース一覧には次のようなものが含まれるでしょう。
- 題名
- ディスクリプション
- サムネイル
- 日付
- 執筆者
パターンを定義するとき、こうした構成要素やそれらが必要かどうかをリストアップすることが重要です。たとえば、ニュース一覧に詳細文は必要でしょうか？ もし必要でない場合、詳細文を表示しないとデザインはどうなるでしょう？
こうしてさまざまに並び替えるときは、慎重に検討しないときわめて複雑になってしまうので、注意深く考慮する必要があります。
パターンがどのように機能するか説明する
パターンライブラリが開発者にとって機能仕様書にもなるなら、パターンがどう機能するかどうかについて真剣に考える必要があります。フィールドに入力するためのデータのソースはどこですか？ ユーザーがボタンやリンクをクリックすると何が起きますか？ モバイルデバイスではカルーセルはどう動きますか？
パターンを実装する際には、こうした実践的な問題が重要です。これらの問題に答えるためには、デザイナーと開発者が意見をすり合わせて密接に連携することが不可欠なので、デザイナーがデザイン以外を丸投げしてしまうことを防ぐことができます。
誰もがパターンを利用できるようにする
Webアプリケーションの分野において、アクセシビリティは忘れられてしまいがちです。だからこそ、私のパターンライブラリでは、アクセシビリティを常に考慮に入れています。パターン定義の中には、パターンがキーボードで利用できる、もしくはスクリーンリーダーで読み取り可能であることが、つねに明記されています。
コードの保存場所について考える
多くのパターンライブラリでは、コードがその内部に表示されます。しかし、これは良い考えだとは思いません。コードは、つねに最新の状態が保たれた１つのレポジトリにあるべきで、そのレポジトリは常にソースとしてコントロール可能な状態にあるべきだと思います。コードがさまざまな場所にあることで、より多くのメンテナンスが必要になり、誰かが誤ったコードスニペットをパターンに使用する可能性が増えます。
Astrumはコードのソースを１つに保つためのツールです。最新のパターンライブラリを動的に維持するのに役立ちます。
Astrumは、コードをソースとして管理できますが、依然としてそのコードはパターンライブラリに表示されています。しかし、この問題を解決するための最終的な決断をするのはあなたです。すべてのパターンに正式なコードのソースが１つ存在するようにし、それを最新の状態に保ちましょう。
どれだけカスタマイズ可能か考える
最後に、パターンがカスタマイズ可能なものか、そしてどの程度まで可能なのかを考えましょう。これは、ブランドの運営方法に依存します。ブランドが１つの一貫したものなら、カスタム化について提案すべきことはほとんどないかもしれません。しかし、BBCのように複数のブランドを運営しているなら、パターンの外観は、さまざまな美しさの目標に合うようにカスタマイズできることが重要です。
BBCは、ブランドごとにパターンが異なって見えるような、１つのパターンライブラリを所有しています。
私のお気に入りのツールの１つ
実を言うと、私はパターンライブラリの大ファンです。クライアントと共に取り組むプロジェクトの大半において、私はパターンライブラリにこだわります。組み立てるのには確かに手間がかかりますが、最終的には手間に見合う価値があるものです。
