OOUX（Object-Oriented UX、オブジェクト指向UX）とは、ボタンや操作手順を考える前に、利用者が「何を扱うのか」と「それらがどう関係するのか」を整理する設計手法である。その整理をもとに、利用者にとって分かりやすい画面や操作を設計する。UXはユーザー体験を指す。
たとえば、シェフがレシピを投稿・共有するサービスを考える。「投稿ボタンをどこに置くか」から始めるのではなく、まず利用者が扱う「レシピ」「シェフ」「材料」を挙げる。次に、レシピには写真や作り方があり、シェフがレシピを作り、レシピには材料が使われる、と整理する。これをもとに、投稿や編集などの操作と、レシピからシェフや材料の情報へ進める画面を考える。
操作の流れや必要な機能から設計を始める方法もある。OOUXの特徴は、その前に「何を扱うサービスなのか」を明確にする点にある。
なぜ画面より先に情報の全体像を整理するのか
サービスの画面を一つずつ設計すると、同じ情報を扱っていても、画面によって内容や関係が食い違うことがある。たとえばレシピ共有サービスで、検索画面には「レシピ名と材料」、シェフの紹介画面には「投稿したレシピ」、お気に入り画面には「保存したレシピ」を別々に設計するとする。それぞれは成立しても、どの画面でも同じ「レシピ」を扱っているという共通の整理がなければ、表示項目やつながりを統一しにくい。
さらに、画面単位では見落としやすい関係もある。たとえば「材料から、それを使う別のレシピを探す」というつながりは、検索画面やレシピ詳細画面だけを個別に考えていては、設計の検討から抜けるかもしれない。利用者が理解している「レシピ・シェフ・材料」の関係と、サービスが提供する情報の構造にずれが生まれるのである。
OOUXでは画面ごとの設計に入る前に、「レシピ」「シェフ」「材料」という対象を定め、それぞれの情報と対象同士の関係を整理する。たとえば「レシピには調理手順と材料がある」「シェフは複数のレシピを投稿できる」と共通の前提を作る。そのうえで検索画面、レシピ詳細画面、シェフの紹介画面を設計すれば、サービス全体で情報の意味やつながりを一貫させやすい。
つまりOOUXが改善しようとするのは、ボタンの配置や操作順序だけではない。複数の画面にまたがる情報を、利用者が理解できる一つの世界として設計することである。結果として、画面間の一貫性を高め、必要な情報やつながりの見落としを減らせる。ただし、使いやすさには操作の流れも重要であり、OOUXだけで完成するわけではない。
操作の前に、扱うものを決める
OOUXでいう「オブジェクト」とは、サービスの中で利用者が情報を見たり、操作したりする対象のことである。必ずしも物体とは限らず、人や場所も含む。レシピ共有サービスなら、「レシピ」「シェフ」「材料」がオブジェクトに当たる。
レシピ交換サービスでは、画面を描く前に次の内容を整理する。
- 載せる情報を決める。 レシピには写真や調理手順、材料には名前など、表示する項目を用意する。
- 対象同士のつながりを決める。 シェフがレシピを作り、レシピが材料を含むという関係を整理する。
- 対象ごとに操作を挙げる。 レシピには投稿や編集、材料にはそれを使うレシピを探す操作を用意する。
- つながりに沿って移動先を決める。 レシピ内の材料から材料の説明へ、シェフの名前からその人の紹介へ進めるようにする。
大切なのは、開発者の都合だけで分類せず、利用者が自然に理解できるまとまりにすることである。たとえば、利用者が「材料から、それを使うレシピを探せるはず」と考えるなら、そのつながりを画面にも反映する。利用者の予想と画面の仕組みが一致すれば、迷わず使いやすくなる。
ただし、文章に登場する名詞をすべてオブジェクトにするわけではない。たとえば「露出を増やす」という目標の「露出」は、利用者がサービス内で直接扱う対象ではないため、オブジェクトにはしない。
語源・提唱者
OOUXを名づけて広めたのはSophia V. Prater氏である。2015年にA List Apartで記事「Object-Oriented UX」を発表し、操作より先に対象を設計する進め方を示した。
着想につながったのは、CNN.comで選挙速報のユーザー体験を設計した経験である。複雑な情報を複数の画面で扱うなかで、ページの構成だけを先に考えるのではなく、選挙戦や結果などの情報がどう結びつくかを整理する図に出会った。この経験から、個々の画面を設計する前にサービス全体の情報の構造を捉えるという発想が生まれた。
2016年の続編では、サービスの設計を文にたとえて説明した。「利用者が（主語）」「投稿する（動詞）」だけでは、何を投稿するのかが分からない。「レシピを（目的語）」まで明確にすることが重要だという考え方である。
似ているOOUIとは何が違うのか
OOUXとOOUI（Object-Oriented User Interface、オブジェクト指向UI）は、どちらも利用者が扱う「もの」を重視する。違いは主に、何を設計するかにある。OOUIは、ものを選んでから操作する画面の作り方に着目する。一方、OOUXは画面を作る前に、ものの種類・情報・関係・操作を整理する。
たとえばレシピ共有サービスでは、OOUIは「レシピを選び、編集や削除をする」といった画面上の操作に注目する。OOUXはその前に、「レシピとは何か」「どんな情報を持つか」「シェフや材料とどうつながるか」を考える。対立する考え方ではなく、一緒に使える。
整理すると、OOUIが主に「利用者が対象をどう選び、操作できる画面にするか」に着目するのに対し、OOUXは「画面をまたいでも対象の意味や関係が一貫するよう、サービス全体の構造をどう捉えるか」を重視する。両者は対象を中心に考える点で重なっており、対立する手法ではない。
OOUXでデザインはどう良くなるのか
たとえば、レシピに載っている材料名を選ぶと、その材料を使った別のレシピも探せる。シェフの名前を選べば、その人が投稿したレシピを見られる。このように対象同士のつながりを画面に反映すると、利用者は今見ている情報を手がかりに次の情報へ進める。
設計チームにとっても、「何を扱うか」を共通認識にできる利点がある。また、レシピなら「投稿・編集・保存」、材料なら「関連するレシピを探す」というように対象ごとに操作を考えることで、必要な機能の見落としを減らせる。
ただし、挙げた操作をすべての人に表示する必要はない。たとえば、レシピの「編集」は投稿した本人だけに表示するなど、利用者の権限や対象の状態に応じて変える。
画面を描く前に一覧にする
OOUXは、画面設計などの既存の工程を置き換えるものではなく、その前段階で使える。扱う対象、それぞれの情報、対象同士の関係、できる操作を一覧や図にまとめる。こうすると、画面を描く前に必要な機能や設計の複雑さを把握でき、作業量の見積もりにも役立つ。
別の例として、音楽配信サービスを考える。曲・アルバム・アーティスト・プレイリストを、それぞれ情報や操作を持つ対象として整理できる。LogRocketの解説記事はSpotifyの構成をこの考え方で紹介しているが、Spotifyが実際にOOUXの設計手順を採用したという意味ではない。
この構成を参考に画面を設計するなら、次の順で検討できる。
- 表示する項目を決める。 アルバムには名前・公開日・ジャケット画像、曲には長さやジャンルを用意する。
- 所属やつながりを整理する。 曲はアルバムに属し、アーティストが作る。プレイリストは曲を含むものとして整理する。
- 画面の行き来を考える。 曲からアルバムへ、プレイリストから曲へ進めるように、整理した関係を移動先に反映する。
- 対象ごとの操作を一覧にする。 曲を再生する、プレイリストに曲を追加するなど、何に対する操作かを明記する。
こうして対象と操作を整理してから、ボタンの配置や押した後の流れを設計する。「どのボタンを置くか」ではなく「利用者は何に対して何をしたいか」を出発点にするのがOOUXの考え方である。
関連用語
- オブジェクト指向UI（OOUI）
- コンテンツモデリング
- オブジェクト指向プログラミング
- サイトマップ
- タスクフロー
