第33章

リデザインでは救われない

リデザインは、たいてい正しい答えではない

リデザインの提案は、こんなふうに聞こえる。プロダクトが雑然としてきた。操作の流れは継ぎはぎだ。コードベースは悪夢のようだ。きちんとリデザインすれば、一気に整理できる。新しく始めて、最初から正しい構造にすればいい。決断力があるように聞こえる。十分ひどい状態になったとき、真剣なデザイナーが下す判断のように聞こえる。私は、この提案を何度も聞いてきた。

ほとんどの場合、それは正しい判断ではない。それでも手を伸ばす理由は、プロダクトの状態より、自分自身の心理に深く関わっている。

プロダクトは、どうして雑然とするのか

チームが雑然とさせようとしたから、プロダクトが雑然とするのではない。誰も、わかりにくい購入手続きや、見つけるまで4回タップしなければならない設定画面を、最初から計画しない。少しずつ積み重なる。関係者に頼まれて、ボタンが増える。例外的なケースを見せる必要があって、モーダルが現れる。想定していなかった画面に、新機能が置かれる。そして誰かが、全体が古くさく見えると言い、白紙からの出直しを夢見始める。

一つひとつの判断は小さかった。そのときは、それぞれもっともに思えた。そして、その小さな判断が積み重なって何になっているかを、一歩引いて問う人はいなかった。

C. Northcote Parkinson は1958年、こういう状況を説明した。チームはボタンのラベルを2時間議論するのに、そのボタンが載る構造は誰も問わない。小さなことは、目に入りやすく、意見も言いやすいから議論される。大きなことは、誰も一人では全体を頭に収められないので、背景で膨らんでいく。

これがUX負債だ。指をさして示せる、一つの派手な失敗ではない。千もの小さな近道が積み上げた代償だ。Nielsen Norman Group は、プロダクトチームに共通するこのパターンを説明している。対処を先延ばしにするほど、難しくなり、費用も増える。ほとんどのチームは知っている。それでも、請求額が小さいままであることを期待する。

やり直すほうが、簡単に感じる

混乱がある程度まで進むと、デザイナーは脱出を考え始める。提案は自然にできあがる。問題は絡まりすぎて、一つずつでは直せない。本格的なリデザインなら、今度こそ正しくつくれる。古い仕組みにとどまるのは、穴をさらに深く掘るだけだ。その提案から抜け落ちているのが、計画錯誤だ。

Daniel KahnemanとAmos Tversky が1979年に指摘し、Buehler, Griffin,とRoss が1994年に確認した。人は、過去のプロジェクトが予定を超えたと知っていても、これから自分が取り組むプロジェクトにかかる時間を、一貫して短く見積もる。計画段階のリデザインがすっきり見えるのは、まだ何一つ現実にぶつかっていないからだ。

今のプロダクトは現実にある。現実の制約があり、すでに把握した特殊なケースがある。代わりのものは、構想のなかにしかない。この比較は、決して公平ではない。

自分たちがつくったものを過大評価する問題もある。Ralph KatzとThomas Allen は、技術者のチームを対象にした研究で、これを記録した。集団は、内部で開発した解決策を、外部の代替案より優れていると評価した。実際に優れていたからではない。リデザインの話は、よくここから始まる。

既存の仕組みをつくったのは、前のチームだ。心のどこかに、自分ならこんなつくり方はしなかった、という感覚がある。その考えがどれほど魅力的か、私も知っている。

Diggは、人々が知っていたものを壊した

2010年、Diggはバージョン4を公開した。会社は苦戦し、成長は横ばいで、チームには解決すべき本当の構造上の問題があった。答えは全面的な刷新だと判断した。新機能、新しいインターフェース、出版社などとの新しい提携を、同時に世に出した。

Diggのユーザーは、何年もかけて使う習慣をつくっていた。何がどこにあるかを知り、仕組みを覚えていた。バージョン4は、それをすべて置き換えた。ユーザーが投稿したリンクより、出版社などのコンテンツを優先するインターフェースになり、覚えていたナビゲーションは移動した。基本機能さえ安定しないほどのバグも抱えたまま公開された。

ユーザーは、改善するかどうか待ってはくれなかった。去った。

公開翌月のアクセスは26％減った。多くのユーザーがRedditへ移り、そのまま戻らなかった。Diggは2012年、50万ドルで売却された。最盛期の評価額は2億ドルだった。

Diggの誰も、プロダクトを壊したかったわけではない。直そうとしていた。だが、すべてを一度に、一回の一般公開で直そうとした。ユーザーがすでに信頼していたものに戻す手段もなかった。間違いは、その意図ではない。リデザインの規模だった。

まず、実際の問題を五つ挙げる

つくり直しの話が勢いづく前に、やっておく価値のあることが一つある。リデザインで解決するつもりの、具体的な問題を五つ書く。漠然とした不満ではない。はっきり名前をつけられる問題だ。「購入手続きの確認段階で、38％のユーザーが離脱する」は、その一つになる。「古くさく感じる」は、ならない。裏づけのある問題を五つ挙げ、それらに共通する深い原因があり、つくり直さずには解決できないと示せるなら、議論する価値がある。五つまで挙げられないなら、おそらくリデザインの問題ではない。あるのは、いら立ち、引き継いだ混乱、あるいは、壊れている以上に見た目が気に入らない仕組みだ。

別の方法は、会議で発表しても、あまりわくわくしない。リストの最悪の問題を選ぶ。直す。改善したかを測る。次を選ぶ。時間がかかり、いつも足りない気がして、関係者向けの見栄えのよいスライドにもならない。だが、リデザインは、ほぼいつも、会議で「この程度で済む」としていた規模を超える。

リデザインしたくなること自体は、非合理的ではない。2年間、仕組みが複雑になる一方なら、本気で直したいという気持ちは間違っていない。破綻するのは、まっさらな出発点があるという前提だ。今のプロダクトを複雑にした制約の多くは、やり直しても、そこに残っている。

関係者は、同じものを求める。特殊なケースも残る。日程も、また縮む。

最初からやり直しても、難しい部分は消えない。たいてい、同じ難しさに最初からもう一度向き合うことになるだけだ。