こんにちは、せーみです。oRo UXチームでPodcastをはじめました。この記事は、oRo UXチームが不定期に配信している「oRo UX ポッドキャスト」の第１回目の内容をテキストに起こしたものです（修正あり）。

▼メンバー
せーみ：新卒2年目（当時）のUXデザイナー
ずーなり：先輩UXデザイナー

以下ポッドキャストの内容です。

機能が多いと設計のまとまりが無くなりがち？

せーみ（以下、せ）：さっそくですが最近の悩みを話しても良いですか？UXというよりもUIの話になってしまうんですけど。

ずーなり（以下、ず）：はいはい。

せ：業務管理ツールなど機能の多いツールの設計をすることが（oRo UXチームは）多いじゃないですか。

ず：そうですね。

せ：機能が多いツールを扱う時に、どうやって設計の「まとまり」を作るのかなと思って。設計の「コンセプト」というか。設計のコンセプトがないと画面ごとの操作性は良いんですけど、画面ごとにUIが全然違ってしまって全体のまとまりがなくなっちゃうと思うんですよ。

ず：UIというかIA（情報設計）ですかね？

せ：そうですね。特に、業務管理ツールとか機能が多いサービスの開発でまとまりが無くなりがちだと思うんですが、ずーなりさんはどう思いますか？

ず：業務管理ツールってそもそもタスクベースが多いじゃないですか。業務内容をそのままシステムに起こした形になっているんで、UIのバリエーションが多くなるのはその通りかなと思いますね。一方で、UIに合わせて実際の業務が行われているところもあると思うので、リニューアル時に業務フローを整理してUIに落としていきましょうってなっても、結局バリエーションは多いままなのかなと思いますね。
リニューアル担当者には「業務フローをガラッと変えちゃって良いですよ」と言う方達も多いんですけど、無理矢理変えちゃうと現場の抵抗感はあるんじゃないかと思うんで、そのあたりがジレンマとしてはあるかなと思いますね。

オブジェクトベースは設計の「まとまり」を作れる

せ：ずーなりさんはどうやって設計の「まとまり」を考えていますか。

ず：僕の場合はまずは機能とかフローとか一回カテゴリみたいに分けてみるのと、あとはやはり画面の見せ方が多岐に渡ってしまうので、見せ方を絞るというか、ある程度（画面の）形を限定した上で画面を考えていくことが多いですね。たとえば、タスクベースをオブジェクトベースに切り替えて考えていったりしますね。

せ：最近話題のOOUIですね。

ず：OOUI、なにかわかりますか。

せ：えっと、いわゆるタスクベースっていうのは「操作」とか「動作」を基準にして考えたUIで、逆にオブジェクトベースは「操作の対象」を基準に考えているUIですよね。

ず：そうですね。基本的にはオブジェクトベースになると画面の一覧と詳細に絞れちゃうんですね。あとは特殊なものを画面として増やしていく形になるんですけど、画面自体もシンプルな形に落としやすいかなと思いますね。

せ：オブジェクトベースはまとまりを作りやすいんですね。

プロトタイピングで画面の並べ方を考える

ず：あとは、一つ一つの画面を詳細に作っていくだけじゃなくて、さっき話したようにカテゴリっていうかたまりで考えることも多くて。たとえば毎日の仕事の中で４つ画面を触ることがあったとしたら、その４つの画面をひとまとまりにしたらどうだろうとか考えますね。

せ：ユーザーの使い方に合わせていくってことですか？

ず：それもありますし、タスクベースになると入り口から４回画面を開かないといけない形になるじゃないですか。今の例で言うとね。４回入り口に戻ってもらうって結構めんどくさいと思うんですけど、１回入り口から入った時に４画面がつながってるとか、横の移動が楽だとかそういう考え方ですね。

せ：なるほど。業務管理ツールだと作業が多いけどオブジェクトってシンプルだったりしますもんね。

ず：そうですね。大体「人」なのか「数値」なのかそのあたりに集約されるのかなと思うんですけど。

せ：だいぶシンプルになりますね。

ず：あとは、精度を50％くらいでそれぞれの画面を作って並べてみて、早めにどういう画面のレイアウトやパターンがあるのかを見るっていうのはしますね。雑誌の構成に近いかもしれないんですけど。どういう手順で触るのかとか、どういう機能が近しいと良いのかを考えたりしながら、カテゴリのまとまりを動かしたりします。

せ：プロトタイピングを早いうちからいろいろ検証していく感じですかね？

ず：そうですね。

せ：私は画面をどこで「区切っていくか」みたいに考えてしまうんですけど、結構「並べていく」っていう捉え方の方が近いんですかね。

ず：そうですね。並べていく…もちろんシステム側で実現できないこと、たとえば「こういうデータの持ち方になっているのでこういう画面は作れないです」という制約もまあ多々あるんですけど、早めに画面を並べてみて「これが理想なんじゃないか」みたいなのは出すようにしていますね。その上でデータの持ち方が改善できるのであれば、そこは早めにシステム側に伝えて改善してもらうとか、そういう作り方はできるんじゃないかと思いますね。

画面の種類はあらかじめ絞っておく

せ：もう一つのポイントは「画面の見せ方」ですかね？

ず：タスクベースだと画面の形がいっぱいになっちゃうんで、（オブジェクトベースに切り替えてさらに）３つ４つくらいに最初から絞っちゃう。例えば一覧と詳細（入力画面とかカレンダーとか）にあらかじめ絞って機能を当てはめていく、みたいな考え方になると思いますね。

せ：３つくらいに絞るって、センスもあると思うんですけどどうやって絞っていくんですか？

ず：いろんなツールを触ってみてそこから参考を得ることが多いんですけど、最近のUIの傾向って一つの情報を複数の切り口で見せることが多いと思うんですよ。例えばAsanaとかClickUPって呼ばれるプロジェクト管理ツールがあるんですけど、今再設計をしているシステム（業務管理ツール）もそういう側面があって。カレンダーを使って見せるのが良いケースと、カレンダーの中の要素はテーブルで見せた方が良いケースがあったので、今回はカレンダーとテーブルと入力画面とでテンプレートを作っておいて、画面をはめていきましたね。

せ：テンプレートを粗く作って、機能をはめて成り立つのかどうか検証していくってことですね。

ず：そうですね。toBといえどtoCも参考になることがあって、例えばnotionとか結構みなさん使われると思うんですけど、notionから「こういう使い方はtoBでもアリだな」という部分を参考にしてUIにはめるってこともありますね。

せ：業務管理ツールの参考にメモツールやプロジェクト管理ツールなど一見関係のなさそうなサービスも見るんですね。参考の探し方についてはまた別の機会に深堀りしましょうか。

ず：そうですね。

さいごに

ここまでがpodcastの内容です。
再掲になりますが、音声で聞きたい方はこちらでどうぞ。初回なので雰囲気は固めです。

質問・感想ありましたらnoteにコメントをお願いいたします。ではまた次回〜👋