イリヤ・ビルマンが自身のブログで、ユーザーの動きを不必要に遅くしてしまうインターフェースについて、2本の記事にわたって論じている。

「クリックさせてほしい（Let me click）」と題された1本目で、ビルマンはユーザーを近道ではなく、わざわざ遠回りなクリックへと追いやる箇所をいくつか紹介している。

Aegeaのコメント設定には、「send by email」チェックボックスと、それに紐づいたメールアドレス入力欄がある。チェックが外れていれば、欄を埋める意味はない。このアドレスは他に何にも使われないからだ。逆に、アドレスが空欄のままチェックが入っていれば、システムは送り先を知らないので何も送れない。要するに、これらのコントロールは相互に関連している。

論理的に考えれば、チェックが外れている間は入力欄自体を無効化してしまえばいい。どうせ入力しても意味がないのだから。だが、それは苛立たしい。先にアドレスを入力してからチェックを入れたい場合はどうなるのか。アドレスが入力されているときにチェックを外せなくするのは、さらにたちが悪い。外したいのだ――クリックさせてほしい！

続編では、ビルマンはポッドキャストアプリOvercastの具体例を取り上げている。その開発者は厄介なシステム上の課題に直面していた。

どのポッドキャストでも、端末にダウンロードしておくエピソード数を設定できる。たとえば上限を3つに設定し、そのポッドキャストをあまり聴かなくなったとしよう。すると次の3つのエピソードがダウンロードされ、その後はダウンロードが止まる――無駄に容量を使っても仕方ないからだ。[…]

[しかし、]すでに3つダウンロードされている状態で、ユーザーが手動でもう1つのエピソードのダウンロードを求めたらどうなるか。整理のために、すぐに削除してしまうわけにはいかない。[…]

最終的に、マルコの妻ティフがある解決策を提案する。ユーザーがそれ以上エピソードをダウンロードできないようにしてしまえばいい、そしておおむね「エピソードの上限は3つに設定されていますが、これは4つ目になるので拒否されました」というメッセージを表示すればいい、と。

マルコはその解決策を気に入った。私は気に入らなかった。確かにそれはマルコの問題は解決するが、ユーザーの問題は解決しない。

私はOvercastのブロックを実際に見たわけではないが、2本の記事にわたるビルマンのどの例にも納得させられた。身体が覚えた操作は、求めるものを求める。誰にも止められない。

私からも2つ付け加えたいことがある。

1.

ビルマンはこれを「クリックさせてほしい」と提示しているが、私からは以前役に立った、別の／補足的な2つの原則を提示したい。

• 好きな順番でやらせてほしい。Google Homeアプリの例を見てほしい。温度と保持時間を変更できるのだが、先に時間を変更してから温度を変更すると、苛立たしいことに時間がリセットされてしまう。どの順番でもよさそうに見えるインターフェースなのに、特定の順番を強制してくるのだ。

• いまの操作が最も大きな勢いを持っている。ユーザーはその場にいて、能動的にあれこれタップし、なんとか物事を片付けたいと思っている。もしOvercastが本当に「エピソードの上限は3つです」というメッセージを出すのだとしたら、ユーザーに設定画面への行き方を思い出させ、変更させることになる。勢いは失われる。過去の自分の決定は、いまの自分の決定ほど重要であるべきではない。

2.

ビルマンが挙げた例のすべてに同意するが、物事はもっと奇妙になりうる。ときに、クリックさせたり、好きな順番で操作させたりすることが、かえってインターフェースを理解しづらくする場合もある。

Figmaでは、各テキストボックスのサイズを、完全に自動（幅も高さも自動――短いラベルに使われる）、幅のみ固定（高さは自動――テキストの段落に使われる）、あるいは幅も高さも手動（グラフィック要素に使われる）に設定できる。

幅や高さが自動になっているテキストボックスでは、それらの値を入力するフィールドがグレーアウトして変更できないこともわかるだろう。それらを変更するには、まず特定のモードに切り替える必要があり、そうすることで該当するフィールドが有効になる。これはかなりややこしい領域で、それらの関係性を理解しやすくするためのものだが、実質的にFigmaがときにクリックを許さず、特定の順番での操作を強制することを意味している。

だが、これはあくまでそれらのフィールドでの話だ――キャンバス上のオブジェクトはいつでもつかんでリサイズでき、その場合はドラッグの勢いを尊重して自動的に手動モードに切り替わる。

ここでの一貫性のなさは意図的なものだ。これらが正しい選択だと言いたいわけではなく、システムをすでに理解しているのに簡単にクリックできないことに不満を覚えるユーザーからの声も確かに聞いている（残念ながら、現代のGUIにおいて無効化されたフィールドを「突破する」ための良いアフォーダンスを私は知らない。モリーガードのようなものだ）。私が主に伝えたかったのは、こうしたことは難しいということ、そして「クリックさせてほしい」と「クリックできないことがシステムの理解に役立つ場合もある」のバランスを取るのは至難の業だということだ。

10年ほど前の、ニューヨーク・フィルハーモニックのコンサート最前列で誰かの電話が鳴ったという話をよく思い出す。演奏は実際に中断し、指揮者も観客も憤慨した。恥じ入った持ち主が後に語った言い訳はこうだった。「電話はサイレントにしたのですが、アラームも設定していたのです」

これが実際にあったことだと仮定しよう（人々の証言によれば、鳴ったのはマリンバの着信音で、アラームの標準音ではない――とはいえ人々の記憶は往々にして曖昧だ）。これは「クリックさせてほしい」の絶好の例だと私は思う。特定の時刻にアラームを設定することもできるし、その後に電話をサイレントにすることもできる。逆の順番でも同じだ。あなたは電話に矛盾する2つの指示を与えたことになり、電話のロジックはどちらの場合でもアラームを優先すると決めているのだ。

ここで簡単なインターフェースの解決策は思いつかない。ここでは順番が関係ないのが正しいように感じられる。サイレントモードは通話にも影響するのだから、アラームがオンのときにサイレントモードへの切り替えを禁じるのは考えにくい。プロセスのどの時点で効果的なUIの警告を出すかも、私には想像がつかない。（ちなみに、昔のiPhoneはトップバーに小さなアラームアイコンを表示して、さりげなく知らせてくれていた。）

サイレントモードとアラームは、ビルマンの言うように相互に関連している――しかし、そのつながりをユーザーに説明するのは結局のところ厄介なのだ。