【OOUI】を使ってサービス比較をしてみた話

UIデザイナーの方にはだいぶ浸透してきた『OOUI』。
最近ではOOUIのトレーニングサービスなどもあるようで、学べる機会も増えてきていますよね。
私自身、初めてこの考え方に触れた時はとても感動しました。

まだまだ学習不足なのですが、ソシオの上野さんの解説を参考にしながら理解を深めている最中です。※ここを最初に通るべし！

ソシオメディア | OOUI – オブジェクトベースのUIモデリング

そんなOOUI。
学習を進めているうちにある壁にぶつかりました。
『OOUIのサンプルは、情報がシンプルなアプリが多い』

カカクコムや楽天などに従事し、膨大な情報量のサービスに関わって私には少し距離感のある話に聞こえていました。
(現在も支援するのは、情報量が多く規模感のあるサイトが多いので)

そこで、
「情報が複雑化したWebサービスにOOUIは利用できるのか？」
と疑問に思いました。

そんな疑問に少しでも答えるため、
OOUIを使って、情報が複雑化したサービスを比較してみる事に。

OOUIを使ったサービス比較の目的

1. 複雑な情報のサービスをモデリング>比較したら何が見えるのか
2. 実務として使えるのか、考慮すべき事はあるのか
今回は上記を目的とし、サービスの主観的良し悪しの判断はしない事にします。

今回のスコープ

・ホテルの予約サイトを3サービス比較(じゃらん、楽天トラベル、一休)
・ホテルのコレクションとシングルビューに絞って比較
※厳密には、オブジェクトのプロパティ比較が正しいタイトルですね。。

なぜホテルのビューなの？

私が関わってきた多くのサイトは、
 ・トップ > ジャンル(商品一覧) > 商品詳細 >  カート 
 ・トップ > エリア(店舗一覧) > 店舗詳細 > メニュー > カート
のような構成がほとんどでした。

そこで重要となってくるのが店舗(今回はホテル)のコレクション、シングルビューというわけです。

実施したこと

今回は下記3点の作業を行いました。
1. コレクションビューのプロパティの抽出
2. シングルビューのプロパティの抽出
3. コレクションビューの視覚的情報が強いものを抽出

1.コレクションビューのプロパティの抽出

下記3サイトの画面から、オブジェクト(ホテル)に関するプロパティを抽出。
→今回は目視レベルで確認できる要素のみになります

モデリングすると要素の違いが一目瞭然ですね。
Propertyの抽出に合わせて、データタイプも記載しました。
(DBなどとは関係のない主観的定義)
合わせて、オブジェクトに対してのアクションも記載。

2.シングルビューのプロパティを抽出

同じようにシングルビューからのプロパティを抽出してみます。

途中で心が折れかけてきたので抽出情報の粒度バラバラかもです。。

こうやって見ると、保持しているデータの多さがよくわかります。
見えてない情報も含めるとかなり膨大になるのでしょう。

3.コレクションビューの視覚的情報が強いものを抽出

ここで独自に視覚的な情報を加えたいと思います。
この目的は、どの項目をユーザーが認識しやすいかを見るためです。
視覚的に強い情報には＊をつけておきました。
加えて1画面(iPhoneX)あたりの最大オブジェクト表示数も記載しました。
これはスクロールに対するアクションコストを比較するためです。

強弱の基準ですが、
・画像
・明度彩度が高い色
・フォントサイズのジャンプ率
のような観点で抽出しました。
→その他、数人インタビューし視覚的に入ってくるものをヒアリング

これだけでもだいぶ特徴の違いが見えてきましたね。
差別ポイント、改修ポイントは色々ありそうですが、サイト個々に関しての感想は今回控えておきます。
というのも、こういった歴史のあるサイトはユーザービリティ観点以外にもシステム観点、クライアント観点(toB)、マーケ観点など多くの事業事情が重なっている場合が多いからです。
外野がチャチャを入れるのは簡単ですが、中は思ってる以上に大変なんですよね。。

やってみた感想

よかった点
・ER図やUI設計書を見なくてもデータの概要が掴める
私はサービスに従事した場合、なるべくER図を見せてもらうようにしています。データの把握がサービス改善には不可欠だからです。(外部支援の場合は省略していますが。。)
ただ、複雑なER図を読むのは大変です。
このような抽出作業を通す事でデータの把握がスムーズになります。
また、UIデザイナーとエンジニアのコミニケーション向上に多いに役立つのではないかと思いました。

・視覚情報に頼らず、構造的にサービスを見れる
UXの5段階モデルに記載されているように、視覚情報は最終的な設計になります。

OOUIを通す事で、構造 > 骨格と順を追ってサービスを理解するのに役立ちます。(今回は全体的なオブジェクトの整理は行いませんでしたが)

・ER図などと組み合わせ、不要データの整理などに役立ちそう
実際に保持しているデータと活用されているデータを付け合わせる事が容易になるので、バックエンドの整理に繋がるのかなと。

・ユーザーへの訴求ポイントが客観的に見れる
今回独自に視覚的な強調ポイントを追加しましたが、これは結構良いなと思いました。
サービスの運用が長くなってくると、要素は増えるばかりで減らす事はあまりありません。Propertyとして記述する事で今までとは違った観点から、UIを判断できるようになりました。

考慮が必要な点
・複数人で使用する場合は、情報の粒度/定義をしっかりする必要がある
ご覧いただいた通り、ホテルのシングルビューでは多くの情報が表示されています。運用目的に応じて、もう少し情報を抽象化して丸めても良いかもしれません。
これは実際のサービスで使用してみながら模索したいところです。

・コンテキストによって、表示が異なる場合などを意識して作業する必要がある
同じページでもユーザーの状態などによって表示が異なる場合があるので、サービスを深く理解している方にレビューしてもらうといいかもしれません。
今回は、2ページのみでしたがサービス全体で実施するとかなりボリュームになりそうなのでプロパティの抽出作業は作業範囲を明確にしておいた方がいいかもしれません。

・誤ったリデザインに繋がる可能性がある
初期の段階から、構造をしっかり捉えて設計されたUIならばいいのですが、途中からこのようなプロセスを取り入れ場合は注意が必要かなと思いました。
UXプロセスが流行った時と同様、導入したプロセス自体に重きを置きすぎて偏った判断がなさせる可能性があります。
特に既存ユーザーがCVの割合を多くしめている場合などは慎重に判断したいところです。
良くも悪くもそのサービスを学習しているので。

私自身UIデザインを専門にしているわけではないのですが、サービスを設計する上でとても重要な考えただと感じまし、大規模なサービスでも活用できると思いました。
Propertyの着目ではく、大規模サイト全体のオブジェクトを整理作業を実施して見たいと思います。