オブジェクトに対する操作を中心にユーザー体験を設計するOOUX（Object Oriented UX）と呼ばれる手法はUXデザインの世界で広く知られるようになってきたように思います。しかし、オブジェクトを意識してデザインしていても、「気づいたら途中からユーザーアクション主導の作り方になっていた」というケースもよくあります。デザイナー的な視点では「これって本当にオブジェクト化できるのだろうか？」という疑問が浮かんできたタイミングがこれに当たりそうです。
これは、OOUXの主軸となる「オブジェクトマッピング」をより正確に行うことで解決できるケースがあります。今回は、見逃されがちなオブジェクトを含めて、正しくマッピングするためのポイントを紹介します。
オブジェクト指向？ユーザーアクション主導？
OOUXとは、サービスが扱うオブジェクトを中心にプロダクトを設計する考え方です。これをオブジェクト指向な設計といいます。一方でユーザーアクションを中心としたプロダクトの設計を、この記事ではユーザーアクション主導な設計と呼んでいます。オブジェクト指向のUI設計であるOOUIにおいて言及される、オブジェクト指向UIとタスク指向UIの背景にある考え方としても捉えられると思います。
オブジェクト指向UI: アクション対象のオブジェクト（名詞）を中心として設計されたUI
タスク指向UI: ユーザーのアクション（動詞）を中心として設計されたUI
オブジェクトマッピングはデータベースの構造設計と同じ
OOUXにおけるオブジェクトマッピングは、システムの実装時に使用す るデータベースのスキーマにどこまで近い構造をデザイナーとして把握することができるかが鍵になっています。極端な話、プロダクトのデータベース設計が決まったらそのスキーマをエンジニアから共有してもらうというのも一つの方法かもしれません。
とはいえ、デザインより先にデータベース構造がわかるようなケースばかりではないですよね。エンジニアとデザイナーが行うオブジェクトマッピングで差が出やすい部分が「抽象的な概念をオブジェクト化できるかどうか」だと思います。
抽象的な概念とは例えば、
SNSサービスの「いいね」
ECサイトにおける商品の「配送」
カレンダーアプリの「通知」
などの私たちの目には見えないオブジェクトが挙げられます。
これらの概念をオブジェクトではなくアクションとして捉えると、ユーザーアクション主導の画面設計を行うことになり、スケーラブルではない複雑なUIに繋がってしまうことがあります。
データベース上で「いいね」はオブジェクト
ユーザー目線で見ると"いいね"は、もちろんアクション（動詞）ですよね。ただし、ソフトウェア設計的な視点で見ると"いいね"というデータの内容を変更したり、削除することができま す。つまり、「”いいね”を〇〇する」というように名詞として捉えることもできるのです。オブジェクトマッピングの際には、このようにソフトウェア的な視点で実は名詞として捉えられるものを見逃さないことが大切になります。
すべてのデータ操作はCRUDの４つだけで表すことができる
ここでは、これらの抽象的な概念もオブジェクト化できるようになるために重要な一つの視点を紹介します。それは、
ソフトウェアが行うオブジェクトに対する操作は「作成・読み取り・更新・削除」の4種類だけ
という決まりです。
これは、それぞれの英単語の頭文字を取って「CRUD」と呼ばれるデータ操作です。
ソフトウェアが扱うすべてのデータはエクセルシートとなんら変わりのないテーブル構造で管理されています。つまり、アプリやWebサービス上でユーザーが行うアクションはUIの操作を通して最終的にはテーブルのデータを更新しているだけということもできます（もちろん、データの変更を伴わないアクションは別としてですが）。
この考え方でUIを設計すると、複雑な業務管理システムなどもいたってシンプルなものとして把握するすることができるようになります。逆にいうと、UIがとても複雑になってきた（ユーザーアクション主導でしかデザインできなくなってきた）と感じた場合は、何かしらの抽象的な概念をオブジェクト化できていないという可能性があります。
既存のオブジェクトに対するCRUD操作で表現しきれないと感じるユーザーアクションがあった場合、見方を変えて「新たなオブジェクトが登場した」と考えると解決することが多いです。
例えば、「SNSの投稿にいいねする」というユーザーアクションは「投稿」というオブジェクト自体に対するCRUD操作では表現しきれないですよね。
これを新たに「リアクション」というオブジェクトを一つ作成（Create）していると考えると正しいマッピングが行えます（「いいね」自体をオブジェクトとして捉えても良いですが、より抽象化した「リアクション」とすると汎用性が高くなります）。
このように、OOUXにおいては操作する対象のオブジェ クトを正しく捉えることが大切なポイントとなります。
抽象的なオブジェクトをマッピングできると何が良いの？
もちろん、ユーザーアクション主導でデザインしたとしても最終的な結果が同じようなものになることもあると思います。では、どのようなケースでオブジェクトマッピングが役に立つのでしょうか？
例えば「いいね」をオブジェクトとして把握できていない場合、「投稿に対して"いいね"を押したユーザー一覧を表示する」という要件に対して、「ユーザー一覧を見る」というユーザーアクション主導でデザインを行うことになります。
「ユーザーがいいねを押した投稿の一覧を見る」というユーザーアクション主導の考えでこのUIを設計すると、画面のタイトルラベルは「この投稿にいいねしたユーザー一覧」のような形になりそうです。ただ、この段階では大きな問題ではなさそうですね。
しかし、例えば「いいね」に「ハート」や「びっくり」などの複数の別パターンを導入するような要件が登場したときには、
この投稿に「いいね」を押したユーザー一覧を見る
この投稿に「ハート」を押したユーザー一覧を見る
この投稿に「びっくり」を押したユーザー一覧を見る
など、たくさんのユーザーアクションが生まれてしまいます。
それぞれのアクションに対応して「この投稿にハートを押したユーザー一覧」や「この投稿にびっくりしたユーザー一覧」という画面を作っていくような流れが頭に浮かびますが、この時点で既になんだかややこしくなってきましたね... これが冒頭で紹介した「気づいたら途中からユーザーアクション主導の作り方になっていた」というタイミング です。
ここで「いいね」を投稿とは別のオブジェクトとして捉えることができれば、「いいね」した投稿一覧は「リアクション」オブジェクトのコレクションであり、そのプロパティである「日時」や「ユーザー」に関する情報を表示するデザインがイメージしやすくなります。つまり「いいねしたユーザー」の一覧という要件は、ソフトウェア上は「いいね」の一覧なのです。
ちなみにInstagramのアプリでは、この画面のタイトルラベルは「いいね！」となっており、デザイナーが明確に「いいね」をオブジェクトとして捉えていることがよくわかります。
また、先ほどのような新たな要件が登場しても、「ハート」や「びっくり」は「いいね」オブジェクトの「種類」プロパティとして捉えることができるので、それぞれの一覧はあくまで「いいね」オブジェクトのコレクションビューで、「ハート」や「びっくり」の表示にはフィルターを導入するというアイデアに辿り着くことができます。
抽象的なオブジェクトのマッピングの例として、他にもECサイトにおける「配送」や「キャンセル」という概念を見て見ましょう。「配送」をオブジェクトとしてマッピングしない場合、注文フローや注文管理画面の中で「配送が複数回に分かれることがある」という要件が出てきたときなどにUIを構造的にデザインするのが難しくなります。この場合、「配送」オブジェクトを把握できていないと「送り状番号も複数になったけど、これも注文に紐づくデータなのだろうか？」などと混乱してしまいます。
「キャンセル」についてもプロダクトデザインではよく登場する動詞なので、ユーザーアクション手動でデザインを進めてしまいそうです。しかも、一見「注文」に対する「削除」操作のようにも見えますよね。しかし、キャンセルには「キャンセル日」や「返品の有無」など紐づくプロパティも多く、オブジェクトとしてマッピングすることでキャンセル一覧や返品状況などのUIを考える際に役立ちます。
「配送」も「キャンセル」も既存のオブジェクトに対するCRUD操作では表せないという視点で見ると、マッピングしやすくなるのではないでしょうか？
OOUXは手法というよりも考え方として重要なのでは？
複雑なデータ操作を行うようなBtoBサービスのデザインなどでは、画面自体をオブジェクト指向で作成することのメリット がイメージしやすいと思います。では、コンシューマー向けのアプリなどではどうでしょうか？
このような場合にもオブジェクトを中心とした設計を「基本の型」として捉えた上で、ユーザーニーズやビジネスゴールに合わせて所々チューニングしていくような考え方を取り入れると、データ構造が明確で使いやすい設計になるのではないでしょうか？
つまり、オブジェクト指向なアウトプットを作ることにフォーカスしない場合でも、オブジェクトマッピングを行い、プロダクトのデータ構造を捉えることはUIの複雑化を防ぐために大きな役割を果たしてくれます。その際に、今回紹介したようなCRUD操作を基準としたオブジェクト化を一つの視点として取り入れてみてはいかがでしょうか？
