BtoBプロダクトのUI・UXの参考事例を探す方法《村田俊英の『事業をドライブさせるデザイナーの越境思考』｜Vol.10》

BtoBプロダクトのUIを考えるとき、僕が意識しているのは、「同じ業界」よりも「同じ機能や課題」から参考を探すことです。

ユーザー招待ならSlack。フィルターならStripe。テーブルの見せ方や操作ならAsana。縦ナビゲーションや通知ならNotion。こうして機能単位で見ていくと、業界が違うプロダクトからも、たくさんの学びが得られます。

「参考」を見つけるために必要なのは、検索する力だけではありません。いま自分が向き合っている課題を、どこまで抽象化できるか。その力が、探せる参考の幅を広げてくれます。

まず海外のBtoBプロダクトを見る

UIや操作体験の参考を探すとき、僕はあまり、日本国内のBtoB SaaSを見ていません。これまで自分が探した範囲では、UIの細部や操作の流れに物足りなさを感じることが少なくなく、むしろ海外の有名なBtoBプロダクトを見ることが多いです。

また、参考にしたいのは“画面のきれいさ”だけではありません。たとえば、次に何をすればよいかがわかること。操作した結果を確認できること。情報が増えても整理されていること。迷ったときに戻れること。そうした体験を、自分の中の基準として持っておきたいのです。

ただし、有名なプロダクトの設計が、今直面している仕事で正解とは限りません。良い参考を知ることと、それを採用することは、別の判断だからです。

似た業界ではなく、似た課題を探す

たとえば、在庫管理システムをつくっているとします。

「在庫管理システムのUI」と検索すれば、同じ業界のサービスは見つかると思います。ただ、それだけでは参考にする範囲がかなり狭くなります。

ここで、つくりたい機能を一段抽象化してみます。たとえば、在庫の一覧から必要なものを探したいのであれば、課題は「大量の情報から、条件に合うものを絞り込む」になるでしょう。他には、担当者ごとに操作できる範囲を変えたいのであれば「誰に、どこまで操作を許可するか」に、複数の拠点のデータを切り替えたいのであれば「いま見ている情報の範囲を理解しながら、別の範囲へ移動する」という課題になります。

こう考えると、決済、タスク管理、コミュニケーションなど、違う分野のプロダクトも参考になります。業務で扱うデータは違っても、ユーザーが操作するときに困ることには共通点があるからです。

機能ごとに、参考にするプロダクトを持っておく

僕の場合、参考を探し始めるときの候補は、次のようなものになります。

これらは、それぞれが唯一の正解という意味ではなく、考えるための入り口です。たとえば、「ユーザー招待」の場合、メールアドレスを入力する画面だけを見ても、十分ではありません。招待する側が、「相手に何を許可するのか」を理解できるか。招待した相手がまだ参加していないとき、その状態を確認できるか。招待を受けた側が「参加先を把握できるか」までを観察する必要があります。

「フィルター」の場合、条件を追加する操作に加えて、現在どのような条件がかかっているか、結果がゼロ件になったときにどう戻れるかも見たいところです。テーブルなら、一覧の見やすさだけでなく、行を選ぶ、詳細を開く、値を編集する、といった操作をどう整理しているかを見ます。

「この画面がカッコイイ」で止めずに、「この操作を、どう迷わず進められるようにしているのか」まで観察すると、参考の使い方が変わります。

参考にすべきは「見た目」より「判断の理由」

参考が見つかったら、次に考えるべきは「自分たちのユーザーや業務に合うかどうか」です。たとえば、毎日何時間も使う人と、月に一度しか使わない人では、必要な導線や案内が違います。操作に慣れた人なら、コンパクトなアイコンやショートカットが便利かもしれませんが、たまにしか使わない人には、操作の意味を伝えるテキストが必要でしょう。

また、同じ「削除」という操作でも「簡単に戻せる」データと「業務に大きな影響が出る」データでは、確認の仕方を変える必要があります。だから参考を見たら、以下のような問いを立てるようにしましょう。

「この設計は、どんなユーザーや利用状況を想定しているのか？」
「何をわかりやすくし、どの操作を効率化しているか？」
「自分たちの業務と比べて、前提条件のどこが違うか？」

画面を見るだけでは、設計者の本当の意図がわかりません。だからこそ、自分なりの仮説を立て、自社の課題に照らして確かめます。見た目を取り入れる場合も、「なぜ、この形が必要なのか」を説明できるところまで考えを深める必要があります。

できれば、自分で実際に動かしてみる

こうしたプロダクトは、可能であればいくつか契約して、実際に使ってみることをおすすめします。無料プランやトライアルが用意されていれば、触れられる範囲からでも大丈夫です。大切なのは、ログインして画面を眺めるだけで終わらせないことです。

たとえば「メンバーを招待して、共同作業を始める」「データを登録し、条件を絞って探す」といった、小さな目的を持って使ってみるのです。すると、画面の前後関係がわかってくるでしょう。何も登録していないとき、最初の操作をどう案内するのか。設定した内容をどこで確認できるのか。間違えたときに、どう修正できるのか。操作が完了した瞬間のわかりやすさや、少し迷ったときの感覚も、自分で触るからこそ気づくことができます。

「このUIはわかりやすい」と感じたなら、なぜ迷わなかったのかを考えましょう。逆に迷ったなら、何を期待して、どこで期待が外れたのかを振り返る。そうした観察こそが、自分の設計に使える知識になります。

触るのが難しければ、Mobbinも参考になる

業務向けのプロダクトには、利用開始までに問い合わせが必要だったり、実際のデータがないと操作を試しにくかったりするものもあります。その場合は、実在するアプリの画面や操作フローを集めたMobbinなどが参考になります。画面だけでなく、フローや動画を通じて操作の流れを確認できます。

複数のプロダクトを見比べ、「招待」「検索」「設定」などの共通するパターンを探すときにも役立ちます。そこで気になる設計を見つけ、触れるものは実際に試してみる。資料で広く探し、実機で理解を深めるという使い方がよいと思います。

参考を保存するときも、スクリーンショットだけでなく、「何の課題に使えそうか」「どこが良いと思ったか」のメモ書きなどと一緒に残しておくと、後から使いやすくなります。

参考を探す前に、課題を「一文」に言語化する

参考が見つからないときは、探し方ではなく「課題の捉え方」を見直してみてください。

たとえば、
「この業界の管理画面を探す」→「大量の情報を、複数の条件で絞り込みたい」
「競合のメンバー管理を見る」→「操作権限を理解したうえで、人を招待できるようにしたい」
etc.

このように課題を具体的に一文に（言語化）すると、解くべき本質が明確になり、見るべきプロダクトの選択肢が広がります。自社が属する業界に縛られず、別の分野から優れた解決策を見つけられるかもしれません。つまり、観察すべき操作対象も変わります。僕は、良い参考をたくさん知ることと同じくらい、目の前の業務との共通点を見つけることが大切だと思っています。

次にUIの参考を探すときは、まず「ユーザーは何をしたくて、どこで困っているのか」を書いてみる。その一文を持って、業界の外まで探しに行くようにしましょう。

プロフィール

文：村田俊英（Resilire）