UX for Business ―デジタル変革時代のビジネスデザイン手法

症状ではなく、原因に対処せよ

診断プロセスはまず、共通の原因を持つ可能性のある症状のか たまりを 探 すことから 始

まる。つまり、最初の症状を見つけた時点では、まだ問題解決に着手できない。他の症

状も引き続き探す必 要があるのだ。

現実のプロジェクトでは、最初の問題を見つけた時点で、その問題の原因を見に行く

のではなく、すぐに手を打ちたくなる誘惑にしばしば駆られる。場合によっては、その症状

を隠 すようなデ ザインをしたくなるかもしれ ない 。

たとえば、ブログの直帰率が高いことに気づいたとしよう。このとき、最初に表示され

るページに ボタンを 1 つだけ設置し、そこからデフォルトのページに遷移させるという方法を

取ることもできる。これは非常に簡単なので、サイト全体の直帰率は改善されるかもしれな

い。しかし、それで本当に何かが改善されたのだろうか？ 多くのユーザーは、次のペー

ジで離脱するだけだろう。つまり、本質的な原因を見つけるのではなく、単に症状を隠し

ただけなのだ。そうではなく、本当に改善すべきなのは最初のページの質そのものだ。

あるいは、直帰率が「高い」と感じた理由が、（検索エンジン経由のコンテンツ型サイト

のような）構造の異なるサイトと比較していたせいだったら、そもそもそれは問題ですらな

かった の か もしれ な い！

そして、目の前の症状を1つずつ解決しようとするうちに、プロダクトを複雑にしてしまう。

根本原因がそのまま残っている状態で、さまざまな症状を覆い隠すための要素が次々と追

加されていく。その結果、ユーザーは依然として迷子になったり、意図しない操作をしたり、

フラストレー ションを 感 じたりして い る の に 、 プ ロダクトだ け が ど ん ど ん 肥 大 化 して いくの