デザインは見た目の問題ではない: 遷移のコストでプロダクトを設計する思考法

tttt

Hatched by tttt

Apr 14, 2026

1 min read

84%

0

フック: もしデザインの価値を距離で測れたら、何が変わるか

あなたのチームが「見た目をよくして」ほしいと頼んだとき、デザイナーはため息をつくかもしれない。なぜなら良いデザインは単なる装飾ではなく、ユーザーが何を求めているかを理解し、彼らをある状態から別の状態へ導くことだからだ。ここで投げかけたい問いは単純だが重い: その「導く」行為を、地図上の移動と同じように測り、最適化できたらどうなるだろうか。

本稿はその直感から出発する。プロダクト上のあらゆるユーザー行動は状態と遷移のネットワークとして表現できる。そして各遷移にはコストがあり、目的によってそのコストは変わる。デザイナーとプロダクトマネージャーがこの視点を共有すると、見た目の議論は行動の最短化と価値の最大化へと変わる。以下でその理由と実務への落とし込みを示す。


セットアップ: デザインは個人作業かつシステム思考か

プロダクトマネージャーは時に個人の貢献者としてデザイン的な作業に深く関わる。ワイヤーを引き、ユーザーフローを想像し、小さな実験を設計する場面は多い。だが同時に、デザインはチームの才能と手法を動員してソリューションを実現する活動でもある。ここに張り付く緊張がある: 一方で細部へ手を入れる必要があり、他方で広い視点で「どの遷移を優先するか」を決めねばならない。

この緊張を解く鍵は設計作業を「遷移とコスト」の言葉で再定義することだ。ユーザーがボタンを押す、フォームを送信する、別ページに遷移する、これらはすべて状態の遷移であり、遷移には好ましさや負担といったコストが伴う。たとえばある遷移は時間的コストが低いが認知負荷が大きい。別の遷移は逆だ。何を最小化したいかによって「最短ルート」は変わる。

この視点は次の二つを同時に可能にする: 1) デザイナーの仕事を見た目の調整からユーザー価値の定量的改善へと移行すること。2) プロダクトマネージャーが個人貢献者としても、チームのリソースの最適配分者としても振る舞えること。


探索: 遷移のコストでプロダクトを読む方法

ここからは具体的な読解法を導入する。いくつかの抽象化を経て、デザイン上の決断を計量化し、比較可能にするフレームワークを示す。

1 観点を状態と遷移に切り替える

プロダクトを「画面」や「ページ」だけで語るのをやめて、ユーザーの状態を定義する。状態とはユーザーのコンテクストや目的のことだ。例: 初めて来訪した見込み客、カートに商品を入れたが支払いに移っていないユーザー、課金済みだが新機能を試していないユーザー。

各インタラクションは状態間の遷移だ。オンボーディングのチュートリアルが終わることは「未習得状態」から「基礎習得状態」への遷移だし、A/Bテストで生まれる差分は同じ遷移における複数の経路の比較だ。

2 遷移にコストを割り当てる

次に遷移ごとにコストを設定する。ここが本稿の核心だ。コストは一つの尺度に統一する必要はない。目的に応じて次のようなコストを使い分けるのが重要だ:

  • 時間コスト: 操作にかかる時間や待ち時間
  • 認知コスト: ユーザーが考えなければならない量や不確実性
  • 感情コスト: ストレスや不快感、信頼の低下
  • 経済コスト: 企業側およびユーザー側の金銭的負担
  • 失敗コスト: ドロップオフや離脱による機会損失

大事なのはコストの選び方は目的に依存するという点だ。配送を最速化したいなら時間を最小化する。コンバージョン率を高めたいなら認知と失敗コストを重視する。コストは混ぜ合わせた重み付けでもよい。

3 最短経路の再定義

従来の「最短ルート」は距離やクリック数の最小化で語られがちだが、目的に合わせて正しく定義し直す必要がある。検索体験で「最短」は時間であり、学習の場面では認知負荷の軽さが「最短」になる。コードのように明確なオブジェクティブを定めると、デザイン上のトレードオフが明確になる。

4 モデルを使って仮説検証を設計する

遷移とコストを定義すれば、A/Bテストや小規模な実験で直接測れるメトリクスを設計できる。例えば認知コストをプロキシするために、最初のクリックまでの時間やヘルプページへの遷移率を用いる。失敗コストは離脱率やエラー率で代用する。

こうしてデザインの決定は「美的な妥当性」ではなく「どの遷移のコストを下げるか」という目標に変わる。デザイナーは見た目の調整だけをする職人ではなく、ユーザーの状態と遷移を示す地図の作家になる。


合成: フレームワークと実務への落とし込み

ここまでの考えを実行に移すための手順を示す。プロダクトチームが日常的に使える簡明なプロセスだ。

トランジションコストマップを作る 5ステップ

  1. 状態の列挙: ユーザーの代表的な状態を3 から 7つにまとめる。過剰に細分化しないことが鍵だ。例: 新規訪問者、有料トライアル中、支払い未完了、有料会員。

  2. 遷移の洗い出し: 各状態間にユーザーが移る経路を書き出す。可能な限り実際のユーザー行動に基づいて優先度を付ける。

  3. コスト基準の決定: ビジネス目標に沿って、どのコストを重視するかを決める。複数選ぶ場合は重みを付ける。例: 認知コスト 0.5、時間コスト 0.3、失敗コスト 0.2。

  4. 推定値の割当て: 定量データがあれば数値で埋める。無ければユーザーテストや現場の直感でレンジを埋める。重要なのは相対比較可能であることだ。

  5. 最短経路の発見と実験設計: どの遷移のコスト削減が最もインパクトが大きいかを見つけ、仮説と実験を設計する。

具体例1: オンボーディングの再設計

問題: 新規ユーザーが初回使用で離脱する。

状態: 初回訪問者 -> アカウント作成 -> 機能理解 -> 初回成功体験

コストの重み付け: 認知 0.6、時間 0.3、感情 0.1

発見: 現状はアカウント作成のフォームが長く、認知コストと時間コストが高い。最短経路はアカウント作成を簡素化し、初回成功体験へのショートカットを作ること。実験: ソーシャルログインを追加し、初回チュートリアルを分割して一つ目の小さな成功をすぐ提供する。評価軸: 初回成功率、7日後継続率。

具体例2: 決済フローの最適化

問題: カートから支払い完了までの落ちが高い。

状態: 商品閲覧 -> カート投入 -> 支払い情報入力 -> 支払い完了

コストの重み付け: 失敗コスト 0.5、感情コスト 0.3、時間 0.2

発見: 支払い入力のエラー表示が不親切で、感情コストと失敗コストが高い。対策としてエラーの即時検出、入力補助、安心感を与える文言を追加する。実験: バリデーションの端末側での即時化とサポートチャットの表示。評価軸: 支払い完了率、カスタマーサポート接続率。


実務で起こる二つの抵抗とその解き方

この考え方を導入しようとすると、二つの典型的な抵抗が出てくる。

抵抗一: デザイナーは数字で芸術を測られるのを嫌がる。

対処: 測れることは美を損なうものではない。むしろデザインは説得力を持つための手段だと位置付ければよい。数値はどのデザインがユーザーの負担を下げたかを示す証拠になる。美しさは残るが、その優先順位がユーザー価値に結び付く。

抵抗二: PMは細部に踏み込みすぎて設計者の領分を侵すという恐れを持つ。

対処: 遷移とコストの地図は共同物であり、PMは仮説のフレームを提供する役割を持つ。細部の実装やビジュアルはデザイナーに委ねるが、なぜその遷移を最小化すべきかという問いを共に検証する。


Key Takeaways

  1. ユーザー体験を「状態と遷移」で捉えよう。画面ではなくユーザーのコンテクストを軸にすることが重要。

  2. 遷移ごとにコストを設定し、目的に応じて重み付けして最短経路を定義し直そう。時間、認知、感情、失敗の各コストを検討すること。

  3. トランジションコストマップを作り、仮説に基づく実験で証拠を集めよう。感覚で決めないことが効率化の近道になる。

  4. デザインは見た目の問題ではなく、ユーザーをある状態から別の状態へ移すための地図作成だと再定義しよう。これによりチームの議論は直感から因果へと移る。

  5. 小さな勝利にフォーカスせよ。大きなリファクタリングを待つより、遷移コストが高い箇所を一つずつ下げる方が短期的に効果が出る。


結論: デザインの再文明化、そしてプロダクトの倫理

デザインを見た目の問題と切り捨てるのは簡単だが、それはユーザーとの約束を軽んじることになる。遷移のコストを意識する思考は、単に効率的なプロダクトを作る方法論ではない。ユーザーに対してどのような負担を強いるかを明示する倫理的な枠組みでもある。

最後に残したい考えはこれだ: どんなデザインも最終的にはユーザーをある場所から別の場所へ連れて行く。重要なのは、我々がその移動を意図的に設計し、どのコストを払わせるかを選ぶことだ。見た目をよくするかどうかの議論は消えて、代わりに「どの遷移のコストを誰に、どれだけ負わせるか」という深い問いが残る。

その問いに正直になることが、良いデザインと良いプロダクトマネジメントの出発点である。

Sources

← Back to Library

Hatch New Ideas with Glasp AI 🐣

Glasp AI allows you to hatch new ideas based on your curated content. Let's curate and create with Glasp AI :)

Start Hatching 🐣