UI インベントリー

ウェブサイトやアプリケーションの開発や運営においては、一貫性のあるユーザーインターフェース (UI) を採用し、維持することが、ユーザビリティ上重要になります。UI の一貫性を保つためには「UI インベントリー」を用意し、プロジェクト関係者の間で共有しておくと便利です。

「インベントリー (inventory)」は英語で「目録」の意味ですが、UI インベントリーとはすなわち、サイトやアプリを構成する UI 部品の一覧です。「インターフェースインベントリー」「UI パーツリスト」「スタイルガイド」などと呼ばれることもあります。

UI インベントリーの内容

プロジェクトによって UI インベントリーに含まれる内容は様々だと思いますが、主な構成要素としては以下が挙げられます。

UI インベントリーは、プロジェクトに関係する様々な立場の人たち (開発者、デザイナー、サイトオーナー、更新担当者、など) にとってわかりやすく利用しやすいことが重要です。マルチデバイスでの表示やインタラクションの挙動が体感的に確認できると関係者の実感が高まるので、その意味ではウェブページの形で開示するのがよいかなと思います。

また、個々の UI 部品についての言及だけでなく、全体的なデザインガイドライン (デザイン原則、カラースキーム、タイポグラフィ、その他ブランド表現、など) も併せて押さえられるようにしておきたいものです。UI インベントリーの中に (イントロダクションとして) 盛り込んでもよいでしょうし、別ドキュメントとして用意してもよいでしょう。

UI インベントリーのメリット

UI インベントリーを用意し、プロジェクト関係者の間で共有することには、以下のメリットがあります。

UI インベントリーと画面設計、どちらが先か?

いざ UI インベントリーを作ろうとすると、どういうプロセスで作ろうか、迷うことがあるかもしれません。「UI インベントリーを先に作ってから、画面設計に入るべきか」あるいは「画面設計を基にして、そこから UI 部品を抽出してインベントリーを作るか」という「鶏と卵」な問いです。UI 部品定義が先に固まっているほうが画面設計はスムーズでしょうが、かと言って、(ユーザーのゴールやコンテキストを考慮せずに) いきなり UI 部品から作るというのも心許ない気がします。

私の場合、実際には UI 部品定義と画面設計を同時並行で進める (お互いを行ったり来たりしつつ両方を固めてゆく) ことが多いですが、その際の取っ掛かりとしては、まずラフにページパターンを想定し (たとえば、ホーム、メニューページ、リストページ、詳細情報ページ、記事ページ、FAQ、問い合わせ、など…)、各ページパターンごとにどんなコンテンツ項目や機能があるかをざっと洗い出すようにしています。

ここで言う「ページパターン」と「コンテンツ項目や機能」は、互いに粒度の異なる UI、と考えることもできます。以下に詳述しますが、「ページパターン」は、いわば「器官 (organisms) レベル」の UI、「コンテンツ項目や機能」はいわば「分子 (molecules) レベル」の UI、と捉えることができると思います。

UI の単位 (粒度) を意識する

ところで、UI には様々な単位 (粒度) があります。UI インベントリーを整然とまとめるためには、この単位 (粒度) の違いを意識しておくとよいでしょう。私は Brad Frost 氏が2013年に提唱した「Atomic Design」の考えかたを参考にすることが多いです。

原子 (atoms) レベルの粒度

個々の HTML 要素で表現される UI 部品の最小単位。たとえば :

分子 (molecules) レベルの粒度

原子レベルの UI 部品を組み合わせて表現される、機能的なまとまり。たとえば :

器官 (organisms) レベルの粒度

分子レベルの UI 部品を組み合わせて表現される、ページ内のセクション。たとえば :

なお、Atomic Design の概念体系には、さらに大きな粒度である「テンプレート (templates)」や「ページ (pages)」も含まれますが、これらは UI インベントリーというよりは、ワイヤーフレームやモックアップで具現化するものと考えてよいでしょう。

アクセシビリティの担保について

UI 部品を定義し、UI インベントリーとしてまとめるにあたっては、アクセシビリティの担保もぜひ押さえておきたいところです。

特にソースコードの記述は重要で、以下を徹底しておきましょう。

また、以下についてもあらかじめ UI 部品定義の中にあらかじめ盛り込んでおきましょう。

UI インベントリーをまとめる段階で、アクセシビリティをしっかり担保しておくと、後工程 (画面設計、開発/制作、さらには公開後の運営フェーズでも) において、アクセシビリティが「当たり前」のものとして維持されやすくなることが期待できます。