パターンライブラリー
ウェブサイトやアプリケーションの開発や運営においては、一貫性のあるユーザーインターフェース (UI) を採用し、維持することが、ユーザビリティ上重要になります。UI の一貫性を保つためには「パターンライブラリー」を用意し、プロジェクト関係者の間で共有しておくと便利です。
パターンライブラリーとは、サイトやアプリを構成する UI コンポーネントをパターン化して再利用できるように、一覧化したものです。「スタイルガイド」と呼ばれることもあります。
パターンライブラリーの内容
プロジェクトによってパターンライブラリーに含まれる内容は様々だと思いますが、主な構成要素としては以下が挙げられます。
- UI コンポーネントの外見およびインタラクション
- 実装に用いるソースコード (HTML 要素や CSS 用の class 指定、その他各種属性値など。)
- 使用方法 (どういうケースで使うかの説明。特定のコンテキストで表示/使用される場合は、そのコンテキストも明示する。)
- UI コンポーネントの名称
- UI コンポーネントの番号 (ワイヤーフレームに UI コンポーネントをアサインする際のキーとして。)
パターンライブラリーは、プロジェクトに関係する様々な立場の人たち (開発者、デザイナー、サイトオーナー、更新担当者、など) にとってわかりやすく利用しやすいことが重要です。マルチデバイスでの表示やインタラクションの挙動が体感的に確認できると関係者の実感が高まるので、その意味ではウェブページの形で開示するのがよいかなと思います。
また、個々の UI コンポーネントについての言及だけでなく、全体的なデザインガイドライン (デザイン原則、カラースキーム、タイポグラフィ、その他ブランド表現、など) も併せて押さえられるようにしておきたいものです。パターンライブラリーの中に (イントロダクションとして) 盛り込んでもよいでしょうし、別ドキュメントとして用意してもよいでしょう。
パターンライブラリーのメリット
パターンライブラリーを用意し、プロジェクト関係者の間で共有することには、以下のメリットがあります。
- 設計、制作 (開発)、公開後の運用、といった各工程において、サイト内の UI の一貫性を保つことができる。
- UI コンポーネントの無駄な派生を予防でき、全体的に「引き締まった」「注意の行き届いた」デザインにすることができる。
- 個々の UI コンポーネントをあらかじめアクセシブルに作っておく (マルチデバイスや支援技術で利用可能にしておく) ことで、サイト全体のアクセシビリティを維持しやすくなる。
- 制作工程を効率化できる。
- QA (品質保証) を効率化できる。
パターンライブラリーと画面設計、どちらが先か?
いざパターンライブラリーを作ろうとすると、どういうプロセスで作ろうか、迷うことがあるかもしれません。「パターンライブラリーを先に作ってから、画面設計に入るべきか」あるいは「画面設計を基にして、そこから UI コンポーネントを抽出してパターンライブラリーを作るか」という「鶏と卵」な問いです。UI コンポーネント定義が先に固まっているほうが画面設計はスムーズでしょうが、かと言って、(ユーザーのゴールやコンテキストを考慮せずに) いきなり UI コンポーネントから作るというのも心許ない気がします。
私の場合、実際には UI コンポーネント定義と画面設計を同時並行で進める (お互いを行ったり来たりしつつ両方を固めてゆく) ことが多いですが、その際の取っ掛かりとしては、まずラフにページパターンを想定し (たとえば、ホーム、メニューページ、リストページ、詳細情報ページ、記事ページ、FAQ、問い合わせ、など…)、各ページパターンごとにどんなコンテンツ項目や機能があるかをざっと洗い出すようにしています。
ここで言う「ページパターン」と「コンテンツ項目や機能」は、互いに粒度の異なる UI、と考えることもできます。以下に詳述しますが、「ページパターン」は、いわば「器官 (organisms) レベル」の UI、「コンテンツ項目や機能」はいわば「分子 (molecules) レベル」の UI、と捉えることができると思います。UI の単位 (粒度) を意識する
ところで、UI には様々な単位 (粒度) があります。パターンライブラリーを整然とまとめるためには、この単位 (粒度) の違いを意識しておくとよいでしょう。私は Brad Frost 氏が2013年に提唱した「Atomic Design」の考えかたを参考にすることが多いです。
原子 (atoms) レベルの粒度
個々の HTML 要素で表現される UI の最小単位。たとえば :
- 見出し
- 段落
- 箇条書き
- コンテンツ本文内の強調
- ボタン
- アイコン
- リンク
- フォームの入力要素
- 画像
- ビデオ再生
- オーディオ再生
- データテーブル
- ...など
分子 (molecules) レベルの粒度
原子レベルを組み合わせて表現される、機能的なまとまり。たとえば :
- グローバルナビゲーション
- ローカルナビゲーション
- 検索機能 (検索窓とボタンの組み合わせ)
- 条件指定や絞り込みの機能 (ソート、フィルタリング、ファセット、など)
- パンくず
- ページネーション
- カルーセル
- タブとパネルの組み合わせ
- アコーディオンメニューと展開されるコンテンツの組み合わせ
- ヒーローイメージ (メインビジュアル) とその中の行動喚起 (CTA : Call To Action) ボタンの組み合わせ
- 見出しとリード文の組み合わせ
- 画像とキャプションの組み合わせ
- テキストと画像の組み合わせ (回り込みなどのレイアウト)
- サムネイル画像とディスクリプションの組み合わせ (メニューの項目)
- フォーム入力要素と注釈の組み合わせ
- フォーム入力要素とエラーメッセージの組み合わせ
- ...など
器官 (organisms) レベルの粒度
分子レベルを組み合わせて表現される、ページ内のセクション。たとえば :
- ヘッダー
- フッター
- メインコンテンツの種類 (ページパターンを定義づけるバリエーション)
なお、Atomic Design の概念体系には、さらに大きな粒度である「テンプレート (templates)」や「ページ (pages)」も含まれますが、これらはパターンライブラリーというよりは、ワイヤーフレームやモックアップで具現化するものと考えてよいでしょう。
アクセシビリティの担保について
UI コンポーネントを定義し、パターンライブラリーとしてまとめるにあたっては、アクセシビリティの担保もぜひ押さえておきたいところです。
特にソースコードの記述は重要で、以下を徹底しておきましょう。
- セマンティック (情報構造が意味的に適切) でマシンリーダブル (ユーザーエージェントが理解可能) なマークアップ
- 各種インタラクションに対する適切な WAI-ARIA の記述
また、以下についてもあらかじめ UI コンポーネント定義の中にあらかじめ盛り込んでおきましょう。
- 可読性の高い (コントラスト比が十分な) 配色
- キーボード操作の担保 (フォーカスの可視化、動画やオーディオの再生インターフェースの操作、JavaScript によるインタラクションの操作、など)
- 情報保障 (画像に対する代替テキスト、アイコンに対するラベル、動画に対するクローズドキャプション、など)
パターンライブラリーをまとめる段階で、アクセシビリティをしっかり担保しておくと、後工程 (画面設計、開発/制作、さらには公開後の運営フェーズでも) において、アクセシビリティが「当たり前」のものとして維持されやすくなることが期待できます。