← エピソード一覧に戻る Episode 178 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 迷子になるUIはなぜ売上を削るのか
タカシ
今日は SaaS デザインの中でも、かなり経営に効くテーマ、ナビゲーション設計です。見た目の話に見えて、実は定着率やサポート負荷、さらにはアップセルまで左右する、かなり重い論点なんですよね。地味ですが、事業の速度を決める土台です。
ミカ
ナビゲーションって、要するにメニューの置き方ですよね。でもそれが売上に響くって、ちょっと大げさにも聞こえます。ボタンの位置や並び順で、そこまで経営インパクトが変わるものなんですか？ 正直まだ半信半疑です。
タカシ
かなり違います。B2B SaaS は毎日同じ画面を使うので、一回の小さな迷いが月に何十回も積み上がる。すると活用率が落ち、問い合わせが増え、最終的には『この製品、なんだか重いね』という評価になるんです。
ミカ
なるほど。たしかに一回のイライラは小さくても、毎日だと効きますね。今日は、どう置けば迷わないのかを、SaaS 企業の実例つきで見ていきたいです。現場で使える基準まで、できればかなり具体的に知りたいです。
Chapter 2 原則 ― 共通行動と業務導線を分けて考える
タカシ
まず原則です。良いナビゲーションは、全部を見せることではありません。利用者が『今やりたい仕事』にたどり着くまでの予測可能性をつくることです。検索、作成、通知、設定のような共通行動は、どこでも同じ場所にあるべきなんですね。
ミカ
共通行動って、どの画面でも使う動きのことですね。逆に、案件を見るとか請求を確認するとか、仕事固有の移動は別の考え方にしたほうがいい、と。全部を同じレイヤーで並べないのが大事なんですね。かなり整理の仕方が変わりそうです。
タカシ
その通りです。ここを混ぜると、製品が育つほど導線が濁ります。特に SaaS は複数役割が同じ製品を使うので、全員に全部見せるより、骨格は共通、頻出業務は役割や文脈に合わせて最短化する、という考え方が効きます。
ミカ
メニューを増やして安心するんじゃなくて、迷わせないルールを固定するわけですね。なんというか、整理整頓より交通整理に近い感じがします。道が多いことより、迷わない標識のほうが大事なんだなと、かなり腑に落ちます。
Chapter 3 具体例 ― Intercom、Atlassian、Slack、Notion はどう直したか
タカシ
Intercom は象徴的です。機能追加を重ねた結果、ナビゲーションが『混乱の転換点』に達したと認めました。ただ、全部作り直すのではなく、顧客調査で原因を二つに絞った。アイコンが分かりにくいことと、並び順が直感に反していたことです。
ミカ
問題を広げすぎなかったんですね。『UI が悪い』みたいな雑な話じゃなくて、どこが迷いを生むのかを特定した、と。経営でも同じですが、論点を絞れないと直しようがない。で、実際には具体的に何を変えたんですか？
タカシ
利用データを見ると Inbox が最頻利用領域だったので、最上段に移しました。しかも Inbox を Outbound の上に置いて、『in が out より先』という自然な順序へ戻した。派手ではないですが、毎日使う導線ではこういう修正が効くんです。
ミカ
小さい変更なのに、すごく本質的ですね。頻度の高い仕事を一番近くに置く。経営者からすると、開発工数のわりに効果が大きそうですし、サポート問い合わせの減り方もかなり早そうだなと思います。再現性も高そうです。
タカシ
Atlassian はさらに大規模でした。検索と作成はトップバー、製品内移動はサイドバーに分け、16人の調査、160人の試験導入、100社の早期公開、30人の開発者検証を重ねています。変更を一発勝負にしなかったのが重要です。
ミカ
かなり慎重ですね。しかも製品横断の話だから、失敗すると全部に響く。結果はどうだったんでしょう。みんな元に戻したがったりしませんでしたか？ こういう変更って、どうしても反発が強そうですし、社内も緊張しそうです。
タカシ
2025年時点で、250組織、3万人超が新ナビゲーションを使い、旧UIへ戻したのは2.7%でした。大規模変更としてはかなり低い数字です。段階公開と学習支援を入れると、変更嫌悪だけで判断しなくて済む好例ですね。
ミカ
『反対が多いからやめる』じゃなくて、誰がどこで詰まったのかを見るのが大事なんですね。感情の大きさだけで判断すると、改善の芽まで潰しそうですし、本当に困っている層も見えなくなりそうで、かなり危ないです。
タカシ
Slack も面白いです。大企業ユーザーは検索や⌘Kをブラウザみたいに使うと分かり、履歴と検索を上部に整理しました。一方で、サイドバー下に置いた compose ボタンは新規ユーザーにほぼ無視され、上に動かすと理解された。よく使う導線は、賢さより発見しやすさです。
ミカ
下のほうに置くと目立ちそうなのに、見つからないんですね。人って意外と、アプリの『こうあるはず』で探してる。ナビゲーションは発明大会じゃない、という感じがします。期待を裏切りすぎると、便利でも届かないんですね。
タカシ
Notion も同じで、数百人から数千人規模では一つのサイドバーに全部門を積むと破綻します。そこでチーム単位の空間を作り、必要なものだけ参加・非表示できるようにした。権限管理とナビゲーション整理を一体で考えたわけです。
Chapter 4 失敗パターン ― 斬新さと一斉変更が招くコスト
ミカ
ここまで聞くと、失敗もだいぶ見えてきますね。私が経営者なら、つい『全部入りのメニューにしておけば安心では』って考えそうですけど、それが危ないんでしょうか。見せないと不親切だと思ってしまいそうで、やりがちです。
タカシ
危ないです。典型例は四つあります。組織図そのままのメニューにすること、検索と作成を奥へ隠すこと、初心者と熟練者を同じ前提で扱うこと、そして大きな変更を一斉公開して反応だけ見ること。この四つで、だいたい迷子が量産されます。
ミカ
一斉公開は怖いですね。反発の声が大きいと、どこが悪いのかより『全部ダメだった』に見えてしまいそうです。管理者だけ先に試すとか、Sandbox で見せる意味がよく分かります。切り分けないと判断を誤りますね。
タカシ
そうです。変更嫌悪と本質的な欠陥は分けて見ないといけない。経営者はクリック率だけでなく、初回価値到達時間、主要タスク完了率、問い合わせ件数を見て、『導線が事業を速くしたか』で判断するべきなんです。そこが本丸です。
Chapter 5 クロージング ― 明日からの見直しポイント
ミカ
今日はかなり見方が変わりました。ナビゲーションって UI の飾りじゃなくて、顧客が価値に着くまでの交通網なんですね。混む道を放置すると、みんな静かに離れていく、と。派手さより流れの良さを見るべきなんだと腹落ちしました。
タカシ
まさにそこです。まずは主要ペルソナごとに、毎日三回以上やる操作を書き出してください。その操作に二クリック以内で届くか、検索と作成が全画面で同じ場所にあるかを確認する。これだけでも改善の糸口が見えます。
ミカ
皆さんの SaaS でも、『便利な機能があるのに辿り着けない』が起きていないか、ぜひ見直してみてください。次回も、SaaS デザインを経営目線で一緒にほどいていきましょう。今日の話が導線見直しのきっかけになればうれしいです。