1
/
5

OOUIデザインで複雑な個人間売買サービスを整理してみる

『WEB+DB PRESS』さんの特集により再注目され始めた“オブジェクトベースなUIデザイン”。「名詞→動詞」と人の実行プロセスに沿った本質的デザインを行うための手段です。

WEB+DB PRESS Vol.107
Amazonで大竹 智也, 浦井 誠人, 平野 朋也, 村田 紘司, 上野 学, 末永 恭正, 久保田 祐史, 吉川竜太, 上野 博司, 牧 大輔, 西郡 卓矢, 桑原 仁雄, 小林 謙太, 竹馬 光太郎, 池田 拓司, はまちや2, 竹原, 長谷川 智希, 北村 壮大, WEB+DB PRESS編集部のWEB+DB PRESS Vol.107。アマゾンならポイント還元本が多数。大竹 智也, 浦井 誠人, 平野 朋也, 村田 紘司, 上野 学, 末永 恭正, 久保田 祐史, 吉川竜太, 上野 博司, 牧
https://www.amazon.co.jp/WEB-DB-PRESS-Vol-107-%E5%A4%A7%E7%AB%B9/dp/4297101726/ref=as_li_ss_tl?s=books&ie=UTF8&qid=1543209747&sr=1-1&keywords=WEB+DB+PRESS+Vol.107&linkCode=sl1&tag=kenisfriendly-22&linkId=c2419052c137ff82967328d07a2215a8&language=ja_JP

現実世界では「名詞→動詞」が当たり前ですが、いざサービスに落とすとWFをそのままビジュアル化する「動詞→名詞」のタスクベース設計になりがちです。
(恥ずかしながら、弊社サービス Ancar もタスクベースで作られてます…)

そこで、AncarをオブジェクトベースでUIデザインしたらどう変わるのか実践したので、内容をシェアしたいと思います。内容については一部雑誌の内容をカスタマイズさせて頂きながら、サービスに合わせたオリジナルフレームワークを取り入れなが進めました。

ちなみに今回シェアするのは、まだ世に出ていないリニューアルPJで実践した内容。模倣リスクはありつつも、この規模のナレッジが無いこと、もっと多くの会社に取り入れて欲しい想いから、公開に至りました。参考になれば幸いです。

今回検討にあたりアプリケーションデザイナーの 丸 怜里 / @usagimaruma さんに、オブジェクトベースの観点を取り入れた情報設計を手伝っていただきました。オブジェクトベースUIデザイン実施にあたっての基礎知識は彼の記事を参考に。

オブジェクトベースなUIデザインに取り組むための心構え|usagimaru ⌘ Satori Maru|note
オブジェクトベースなUIデザインの考え方が近頃注目されてきています。デザイナーとしてこれと向き合うに当たって、私なりに解釈した事柄を記しておこうと思います。 まえおき:デザイナーの理念 (私が)オブジェクトベースなUIデザインに取り組むにあたり、デザイナーの理念として次のことを意識しながら向き合います。 ・表現に用いる名前の一貫性 ・存在するモノや振る舞いの意味性の明示、理解 ・実装の隠蔽 ・モードレスな世界の実現 ・ヒトと情報の対話に害を与えないこと ・文化の尊重 ・プラットフォームの尊重 ・イディオム
https://note.mu/usagimaruma/n/nee69529402f6

はじめに|現状の課題感の整理

なぜAncarがオブジェクトベースUIデザインを取り入れるのか、課題を元に認識合わせを行いました。今回はリニューアル既存WFを元に大きく3点あげています。

  • WFを作ったが根拠がない状態
    • 要素がどのオブジェクトに紐付いているのか根拠付が必要
  • 構造、フローが破綻
    • Webの自由度が高い操作でも構造破綻しない設計が必要
  • 先に機能要件がある、タスクベースの状態
    • タスク縛られない自然な体験設計が必要

1.ペルソナ/CJM からユーザーフロー定義

まずは、メインペルソナ/CJM を2種類作成しました。一部を参考に共有します。
(本来は戦略・戦術策定、定量・定性調査による顧客仮説検証などを行いますが、この場での説明は割愛します。)

CJM では『買う』、『所有する』、『売る』のフローごとに、『中古車サイト経由』、『個人間売買経由』の場合の行動を整理しました。

次に行動に目的を付けていく作業をホワイトボード上で行いました。青付箋:気持ち(目的)、黄色付箋:動詞で貼り、「なぜその行動を取るのか」を議論・整理しました。

  • 買い手は『閲覧→交渉→購入』までのサイクルをいかに速く回すか
  • 売り手は『査定→出品→売却』をいかに手間なく実現するか
  • 売買の中で安く買う、高く売るは当たり前、「安心・安全な体験」が重要(ここでコア体験とその定義が明確になりました)

ここから目的を抜き取り、ユーザーフローを定義しました。

CJM 作成時に気持ち(目的)についてはサブ情報として扱いがちですが、目的ドリブンで考えると行動の根拠となるのでおすすめです。

2.オブジェクトモデル定義

次にUI設計の根拠(WFのタネ)となるオブジェクトモデル定義を行いました。

目的語(要素)を抽象化しオブジェクトに整理します。ここで売買別々に管理してた要素が統廃合されます。感覚としてはDB設計に近いです。

『商品タイトル→出品』、『出品者名→ユーザー』


3.ユーザーストーリーとオブジェクトの紐づけ

WFを書く前にストーリーごとにどの様な情報が必要か、オブジェクト単位で紐付け整理しました。

紐付けのイメージ。赤いユーザーフローに対して黄色の付箋で必要なオブジェクトを定義しています。

ユーザーフローを整理している中で商品を中心に売買が紐付いていることに気づいたため、全体構造と関係性をドメインマップで整理。ユーザーフローをWFに変換する際、どのドメインを目立たせるべきか判断軸として活用しました。


商品中心であることがドメインマップによって把握できましたが、「もしかしたらこの単位で事業KPIも決まるのでは?」という話になり、KPIツリーも作成しました。まだちゃんと整理してないので参考程度に見て頂ければと思いますが、商品を中心に成約に繋げる購入KPIと成約に必要な車の出品KPIに分かれそうだな、という感覚を掴みました。

4.オブジェクト単位でのWF作成

ユーザーフロー、モデル図を根拠に、ドメインマップの構造をベースとしたWFを作成。ホワイトボードにざっくりレイアウトとオブジェクトの付箋を貼りながら整理しました。

オブジェクト単位で作成すると、先に全体構造やフローなどの骨組みが決まります。この段階で開発側とのすり合わせもできるため、開発仕様による差戻しがなくなります。細かい要素の話は後から行えばよいだけです。

ざっくりWF作成後は、要素を入れプロトタイプに落とし込んでテスト・改善を実施し、ビジュアルデザインに落としていけば完了です。
(実際にこの整理が正しいかどうかの判断は、リリース後効果検証を行う必要があります。)

車の個人間売買だとユーザー同士のやりとりが発生する為、体験が複雑になりますが、うまく整理することができました。
個人的に気持ちよかったのは商品詳細ページ。出品オブジェクトを中心に考えた為、商品詳細と出品プレビュー・管理を1箇所に集約できたことで、構造がシンプルになり開発工数も削減できました。


ぜひこの記事を参考に、オブジェクトベースUIデザインを実務に活かして頂ければ幸いです。

Ancarでは、デザインファーストで本質的課題を解決し、安心・安全な移動体験提供を目指しています。
一緒にミッション達成したいメンバーも募集中です!

21 いいね!
21 いいね!