OOUI の概念モデリングから、議論の起点を作る

こんにちは、UIデザイナーの水澤です。
前回の記事「プロダクトを観察・理解するための、OOUI の概念モデリング」では、概念モデリングがチームの目線合わせにも活用できる話に触れました。

今回はそこから少し深掘りして、概念モデリングからチームの議論の起点を作る話をします。

「概念モデリングからチームの議論の起点を作る」とは

概念モデリングを進めていく中で、判断に迷うところや疑問が出てくるところがあります。
それらは内容によってはチームで議論する余地があるものです。特に「プロダクトとしてどうあるべきか」の観点に分類される疑問点は、デザイナーひとり判断できることではないため、チームに提示して議論の起点にする必要があります。

概念モデリングでは、コンセプト・提供価値・ユーザーの要求・ビジネス戦略など、さまざまな前提情報を踏まえた上でプロダクトに最適と考える定義・設計をしていきます。それらの情報をもとにモデル化を通して「プロダクトとしてどうあるべきか」を検討していくため、設計するために足りない情報や議論し切れていないところが見えてきます。

こんなとき、どのような議論の起点が作れるか

具体例として、タクシー配車サービスプロダクトを挙げてみます。

このプロダクトでユーザーが達成したいことは、タクシーの予約です。ユーザーが配車をリクエストする→リクエスト内容に応じて車が予約・確保される、という主要タスクがあります。

このプロダクトを概念モデリングしたとき、抽出したオブジェクト「配車予約」について、そのままひとつのオブジェクトとするか、配車予約のリクエストを表す「リクエスト」と配車予約の確定を表す「予約」に分けるか悩んでしまったとします。

概念モデルのオブジェクトは、プロダクトで扱う目当て・ユーザーの関心対象を示します。
この例の場合、統合・分割のどちらでオブジェクトを定義してもユーザーの関心対象・目当てとして誤りではありません。

ここでプロダクトが扱うオブジェクトをどう定義するべきかを検討し、概念モデルをブラッシュアップすることは、ユーザーにとってわかりやすいプロダクト設計につながります。
この例では大きな違いが見えないため、どちらにすべきか悩んでいる状態とします。

似ているオブジェクトをどう切り分けるかは個人的によくある悩みなのですが、原因のひとつに「プロダクトとしてどうあるべきか」の情報把握が不足していたり、議論し切れていないことが考えられます。

そのためデザイナー自身が把握している情報で判断できない場合は、まだ把握していない情報がないかヒアリングしたり、なければチームで議論したりする必要があります。

今回の例では、まずはサービスの料金プランや実際の具体的な配車の仕組みなど、オブジェクトの切り分けのヒントになりそうな情報を改めてヒアリングするところから始めます。詳しい情報が増えれば、オブジェクトをどう切り分けるべきかの判断材料が増えるからです。

例えば、ヒアリングの中でビジネスサイドから「今回からリクエスト時点での手数料（マッチング料）と予約確定後の料金（配車サービス料）を分けようと思っている」という話が新たに出てくるかもしれません。その場合はリクエストと予約で異なるプロパティを持つため、オブジェクトは分割する方が良いと判断できます。

また、実装のデータ構造を参考にすることもひとつの方法です。
概念モデリングとデータベースのテーブル設計は厳密には異なるものですが、概念モデルはデータ構造を表すものでもあり、プロダクトがどのようなデータ項目を持つのかは設計のために理解する必要があります。

ただし、テーブル設計のモデルの切り分け方は「データベースの運用管理の手間と一貫性のバランスをどう設計するか」という観点であり、概念モデルとは目的が異なるため、混在しないように注意します。

疑問点をチームで議論すべきか迷ったら、対象を切り分ける

概念モデリングを進めていく中で出てきた疑問点は、内容によってはチームで議論する余地があるとお話しました。

もしチームで議論すべき内容か判断に迷ったら、出てきた疑問の対象、または疑問を解消するために必要なものから切り分けて整理するようにしています。

例として、タクシー配車サービスプロダクトの概念モデリングで「ドライバー」と「車両」のオブジェクトを抽出したとき、「どちらに多重性があるものと記述すべき？」という疑問が出てきた場合、どう切り分けるでしょうか。

疑問点の対象がフレームワークのとき

対象がフレームワークのとき、「どちらに多重性があるものと記述すべき？」の解消には「具体的な記述方法の理解」が必要です。プロダクトの仕様やタクシー会社の運用がどうなっているかは理解できているが、概念モデル図の適切な記述方法がわからないというパターンです。

このパターンはフレームワークの適切な記述方法を復習するなどで自己解決できるため、チームの議論の起点にはなりません。

疑問点の対象がプロダクトのとき

対象がプロダクトのとき、「どちらに多重性があるものと記述すべき？」の解消には「プロダクトの仕様・会社側の運用の理解」が必要です。適切な記述方法は理解しているが、プロダクトについて知らないことがあるために判断できないというパターンです。

もし仮に「タクシー車両は、日によって異なるドライバーが運転する」という情報を知っていたら、「ドライバー」と「車両」のオブジェクトのどちらにも多重性があると判断できる状態です。

このパターンは情報を知らない限りは判断できないため、チームの議論の起点にします。既に仕様・運用として決まっていることもあるかもしれませんが、単にまだ検討できていない可能性もあります。いずれにしても、認識を揃えるためにチームに提示することが重要です。

終わりに

今回は、OOUI の概念モデリングから議論の起点を作る話を書いてみました。

概念モデリングを進めていく中で判断に迷うところや疑問が出てくることがありますが、それらは設計のために足りない情報や議論し切れていないところが見えているのかもしれません。それらはチームに提示して、議論の起点にすることでプロダクト開発の前進につながると考えています。

Gaji-Labo では、UI設計をいきなり画面から作るのではなく、現状のヒアリングを踏まえた上で概念モデリングから始めることを基本としています。このプロセスを行うことで、見落としや手戻りを回避することが目的のひとつです。

もし仕事の具体的な進め方・内容などが気になったら、ぜひ一度カジュアル面談でお話できると嬉しいです。ご連絡をお待ちしています。

Gaji-Labo UIデザイナー向けご案内資料