← エピソード一覧に戻る Episode 177 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 綺麗なUIなのに使われない理由
タカシ
皆さんこんにちは、タカシです。今日から新しく SaaS デザインのセクションに入ります。最初のテーマは情報設計。実は SaaS では、画面を綺麗に作ることより、顧客が迷わず仕事に入れる地図を作ることの方が、ずっと経営インパクトが大きいんです。
ミカ
ミカです。情報設計って、デザイナー向けの専門用語っぽく聞こえますけど、経営インパクトが大きいんですか。見た目が良いとか悪いとかより、もっと手前の『どこに何があるか』の設計が、そんなに事業へ効くんでしょうか。
タカシ
効きます。B2B SaaS は機能が増えるほど、使い方を覚えるコストも増えます。だから価値がないのではなく、価値にたどり着く前に迷って離脱する。情報設計は、その見えない離脱コストを減らすための設計なんですね。
ミカ
なるほど。料理で言えば、食材が悪いんじゃなくて、スーパーの棚配置が分かりにくくて買い物が終わらない、みたいな話ですね。SaaS でも、良い機能なのに辿り着けないと、それだけで使い勝手の評価が落ちそうです。
Chapter 2 原則 ― 情報設計は機能整理ではなく仕事の順番づけ
タカシ
Figma は情報設計を、ユーザー、文脈、コンテンツを理解し、コンテンツ階層と道案内を自然にする営みだと説明しています。SaaS に置き換えると、社内の機能一覧を並べるのではなく、顧客の仕事の流れに合わせて見せる順番を決めることです。
ミカ
同じプロダクトでも、営業が朝一で見たいものと、管理者が月初に見たいものは全然違いますもんね。機能は同じでも、誰が、いつ、何のために使うかで『自然な並び』は変わる。そこを丁寧に合わせるのが情報設計なんだ。
タカシ
その通りです。ここを外すと、会社の組織図そのままのメニューになりがちです。例えば『分析』『設定』『運用』と社内都合で分けると、利用者は今やりたい作業に辿り着けない。情報設計は、顧客の頭の中にある分類を先に理解する作業なんです。
ミカ
経営者の立場で考えると、ここを間違えるとサポート問い合わせも増えそうですし、オンボーディングも長くなりそうです。『使いこなせないから解約』って、実は機能不足じゃなく地図不足だった、みたいなこともありそうですね。
Chapter 3 具体例 ― Intercom と Atlassian が地図を描き直した理由
ミカ
ここは実例で見たいです。SaaS 企業って、実際に情報設計の見直しをどんな経営課題として扱っているんでしょう。できれば、単なるデザイン改善じゃなく、継続利用や複数製品展開に効いた具体例が知りたいです。
タカシ
まず Intercom です。彼らは機能追加を重ねた結果、ナビゲーションが『混乱の転換点』に達したと書いています。しかも、初期で混乱した顧客は価値を理解できず、長期的に成功しにくいとも言っています。かなり重い指摘ですよね。
ミカ
『分かりにくい』が、単なる不満じゃなくて、価値理解の失敗につながると。つまり情報設計の問題は、見た目の好みではなく、顧客の定着率の問題だということですね。これは普通に経営会議に上がるべき話に聞こえます。
タカシ
Intercom は利用データを見て Inbox が最も頻繁に使われる領域だと確認し、それをナビの最上段へ移しました。さらに、分かりにくいアイコンと不自然な並び順が混乱の主因だと特定して、『賢く見える』より『ひと目で分かる』を優先したんです。
ミカ
それ、すごく現実的ですね。新機能を作る前に、まず一番使う仕事に最短で行けるようにする。豪華な改善というより、毎日使う人の歩数を減らしている感じです。こういう積み重ねが経営数字にもかなり効きそうです。
タカシ
Atlassian も面白いです。2024 年に 6 製品へ新ナビゲーションを先行展開し、複数製品で同じ場所に同じ考え方を置く設計へ寄せました。予測可能性、一貫性、段階的開示を原則にして、製品をまたいでも学び直しを減らそうとしたわけです。
ミカ
買収や新製品が増える SaaS ほど、それは効きますね。同じ会社の製品なのに、毎回メニューの流儀が違うと、ユーザーは移動するたびに疲れる。情報設計って、単一画面の話じゃなくて、プロダクトポートフォリオの設計でもあるんですね。
Chapter 4 失敗パターン ― 斬新さが速さに勝つとは限らない
ミカ
逆に、情報設計の見直しで失敗しやすいのはどこですか。新しい UI にしたのに評判が悪い、という話もよくありますよね。良かれと思って変えたのに、なぜか現場の速度が落ちる。あれは実際、何が起きているんでしょう。
タカシ
典型例は四つです。第一に、組織図ベースでメニューを切ること。第二に、機能追加のたびに継ぎ足して整理しないこと。第三に、見た目の新しさを価値改善だと誤解すること。第四に、一斉変更して何が悪かったか学べないことです。
ミカ
三つ目、耳が痛いですね。『新しくてかっこいい』と『仕事が速い』は別なんだ。長時間使う SaaS だと、最初の驚きより、毎日の迷いの少なさの方が大事そうです。派手な模様替えが、現場では普通に裏目に出るわけだ。
タカシ
Figma の UI3 はその好例です。open beta 後に feature adoption や performance metrics を見ると、浮遊パネルが特にヘビーユーザーを遅くしていた。そこで固定かつ可変サイズのパネルへ戻しました。『大胆』より『仕事が速い』を選び直したんですね。
ミカ
しかも戻せるのが大事ですね。一度出したから守る、ではなく、遅くなるなら変える。情報設計って、完成品を当てる勝負じゃなくて、ユーザーの仕事速度を落としていないかを観測し続ける運営なんだと分かってきました。
Chapter 5 クロージング ― 経営者が明日から見るべき指標
タカシ
今日のポイントは三つです。情報設計は、機能の並べ替えではなく顧客の仕事の順番づけであること。初期の迷いは価値理解の失敗につながること。そして、良い情報設計は大胆さではなく、予測可能性と継続検証で作られるということです。
ミカ
明日から見るべきなのは、クリック率より『目的タスクに着くまで何秒迷うか』かもしれませんね。新規顧客が最初にどこで止まるか、既存顧客が一番よく行く場所はどこか、その二つを並べるだけでも、地図のズレが見えてきそうです。
タカシ
その通りです。SaaS を伸ばすとき、経営者は新機能の数を追いがちですが、本当に見るべきは、顧客が迷わず価値へ進めているかです。まずは主要役割ごとの上位五つの仕事を書き出し、今のメニューがその順番になっているか確認してみてください。
ミカ
今回は SaaS デザインの入口として、かなり本質的な話でした。次から画面を見るとき、『綺麗か』だけじゃなく『この地図で仕事が進むか』を考えたくなりますね。ではまた次回、続きを一緒に見ていきましょう。