第28章

選択肢が増えるとユーザーは離れる

機能を増やすほど、使いにくくなる理由

ユーザーに多くを与えて、プロダクトを悪くしてしまった。それが、機能の落とし穴だ。

選択肢が多いほど価値が高く見えるので、チームは機能を足し続ける。ところが開いてみると、ユーザーは選び、見渡し、比べ、自分の判断を疑いながら進まなければならない。時間を節約するはずのプロダクトなのに。

人は、複雑さを買いすぎる

Debora Viana Thompson, Rebecca Hamilton,とRoland Rust は2005年、このパターンを「機能の多さによる疲れ」と名づけた。買う前には、追加機能があるほど高機能に見える。買ったあとには、同じ機能が、選び分けたり、使いこなしたりしなければならないものに変わる。

Barry Schwartz は、別の角度から同じ問題を掘り下げた。選択肢が増えると、満足よりも、後悔や選ぶことの回避が増えることが多い。William Hick は、それよりずっと前に、もっと単純な形で負担を測っていた。選択肢が多いほど、判断は遅くなる。

ここでの問題は、手間全般ではない。経路、機能、設定、操作が多すぎて、選ぶこと自体が負担になる瞬間だ。

その負担は、二度現れる。最初は購入時だ。機能のそろった製品のほうが、多くの場合に対応できそうなので、安心に見える。次は使用時。同じ豊富さが、メニューの重さ、設定の重さ、迷いに変わる。比較で勝つのに役立ったものが、使い始めたあとの実作業を遅くすることがある。

足したものの大半は、使われない

2019年、Pendo は615のソフトウェア製品を調べ、機能の80％が、ほとんど使われないか、まったく使われていないと報告した。この数字が重要なのは、使われない機能も、コードのなかに静かに眠っているだけではないからだ。メニュー、設定、初期案内、ナビゲーション、比較ページに現れる。

その一つひとつが、ユーザーが目を通してやり過ごすか、判断しなければならないものになる。ここでチームは自分たちをごまかす。主な作業ができるなら、使われない機能があっても害はないと思う。害はある。ユーザーに、必要な情報と雑音を選り分けるよう、要求し続けるからだ。一つだけ設定を変えに来た人が、15個の選択肢を突きつけられる。そんな設定画面を、私は見てきた。

追加機能は、誰かが使う前から、プロダクトの印象も変える。混み合ったツールバーは、使うのに手間がかかると伝える。ぎっしり詰まった設定画面は、信頼する前に、仕組みを理解しなければならないと伝える。操作項目の半分を無視していても、ユーザーはその雑然とした状態を通して、プロダクトを理解しなければならない。

Jiraは、判断だらけのプロダクトになった

Jira は、バグ管理ツールとして始まった。そして大きくなった。カスタムフィールド。権限の階層。課題の種類。自動化ルール。増えるワークフローの状態。増えるモジュール。増えるプラグイン。規模が大きくなると、多くのチームは、使い方がわかる状態を保つだけでも、管理者を必要とするようになる。

DegreedでJiraに切り替えたときのことを、今でも覚えている。こたえたのは、一つの悪い機能ではなかった。積み重なりだった。ナビゲーション、選択肢、操作、設定。どこも選ぶことだらけ。やりに来たことを始める前から、重く感じた。私もチームも、できるだけ使うのを避けるようになった。

複雑さは、いつも悪いわけではない。問題は、主な仕事がすでにはっきりしているのに、判断を次々にユーザーへ渡し続けることだ。Linear は、逆の方向に進むことで、魅力の一部を築いた。独自に決めることを減らし、既定値を増やし、尋ねることを減らした。

Jiraがよい例なのは、苦痛の理由が、単に手間がかかることではないからだ。決めに来たわけでもないことを、何度も決めさせられることにある。

だからといって、あらゆる専門家向けツールを、一般消費者向けの意味でシンプルにすべきだという話ではない。高度な機能が本当に必要なプロダクトもある。問題は、単純なことを一つ済ませて帰りたい人も含め、全員に最初から専門家向けの選択肢を渡すところから始まる。

この区別は重要だ。問題は、高度な機能そのものではない。それを出すのが早すぎることだ。ユーザーの成長に合わせて道具も広がるなら、追加機能は、それを理解できる文脈が整ったときに届く。初日に判断の分岐を丸ごと浴びせるなら、まだ必要のない力のために、ユーザーに代償を払わせている。

だから、ここでは既定値がとても重要になる。よい既定値があれば、簡単な判断はプロダクトが代わりに済ませられる。悪い既定値は、負担を丸ごとユーザーに戻し、それを柔軟性と呼ぶ。

判断の数を数える

選択肢を点検しよう。画面が実際に求める判断を数える。ナビゲーション項目、補助的な操作、フィルター、タブ、モード、入れ子の設定、設定できるがめったに変える必要のないもの。そして、それぞれが、大半のユーザーにとって、大半の場面で、主な作業の役に立つかを問う。

役に立たないなら、取り除く。上級ユーザーに本当に必要だから取り除けないなら、実際に必要になるまで、主な操作の経路から外しておく。

段階的開示が役立つのは、こういうときだ。迷わず使える既定値を一つ。最初の選択肢は少なくする。細かな操作は、ユーザーが求めたときや、使いこなせるようになったときに渡す。プロダクトの水準を下げるのではない。複雑さを後ろに移すのだ。最初から全員に浴びせる代わりに、本当の必要性と結びついたときに出す。

こうしてつくられたプロダクトは、使えばすぐに違いを感じる。主な経路は、すんなり進める。高度な経路は、待っていてくれる。たいてい、それが正しい順番だ。最初に求めることは少なくする。ユーザーに関心を持つ理由ができてから、もっと求める。

選択肢を一つ足すたびに、ユーザーが速度を落とし、ためらい、やめてしまう瞬間も一つ増える。