ワンクリック｜確認画面は本当に全部『無駄』だったのか
確認画面は、UX改善の話になると「減らしたいステップ」として扱われがちです。クリック数が少ない。入力欄が少ない。すぐ完了する。たしかに、同じ情報を何度も聞く画面は利用者を疲れさせます。
でも、すべての停止点が無駄とは限りません。配送先を最後に見ることで、引っ越し前の住所に送るミスへ気づくかもしれない。金額を確認することで、数量を間違えていたと分かるかもしれない。高額な契約なら、一呼吸置くこと自体が利用者を守る場合もあります。つまり摩擦には、目的を邪魔する摩擦と判断を助ける摩擦が混ざっています。
歴史的な1-Clickは、住所や支払いのように過去の設定を再利用できる部分を事前設定へ移し、注文時の操作を圧縮しました。Amazon Payments Customer Agreement ここから学べるのは「確認は全部消そう」ではなく、どの確認を前へ移してよく、どの確認を直前に残すべきかという問いです。
サービス改善で「この一画面、面倒だから消そう」と感じた時は、その画面が何を確認していたかだけ見てみると面白いです。本人の意図を確認していたのか、運営側の都合で同じ情報を聞いていたのか。役割がなければ削れるかもしれない。役割があるなら、削除ではなくもっと軽い形へ変えられるかもしれません。摩擦を減らす前に、摩擦の仕事を知る。それが便利さを雑にしない入口です。
ワンクリック｜クリック一回の裏に『記憶された顧客』がいる
クリック一回で注文が進む時、画面には入力欄がほとんど見えません。でも、その簡単さの後ろには「記憶された顧客」がいます。どのアカウントか。どの住所を使うか。どの支払い方法を既定にしているか。毎回聞かなくても済むのは、以前の選択をシステムが扱えるからです。
Amazon Paymentsの1-Click記載では、既定の支払い方法と既定の住所が注文に使われる仕組みが説明されています。Amazon Payments Customer Agreement ここで重要なのは、便利さが単なるボタンのデザインではなく、本人識別・保存情報・既定値・注文処理がつながって初めて成立する体験だということです。
これは同時に、便利さが信頼へ依存していることも示します。保存した情報が正しいこと。誰のアカウントか確認できること。必要な時に設定を変えられること。表面の操作を減らすほど、裏側の情報管理が不安定なら体験全体のリスクは大きくなります。簡単なUIほど、見えない制度の品質が重要になります。
自分のサービスで入力を減らしたい時も、同じ問いが使えます。「この情報を聞かない代わりに、何を覚えておく必要がある？」。顧客名、好み、前回の相談内容、配送先。覚えることが価値になる場面もあれば、覚えない方が安全な情報もあります。便利さは記憶量を増やす競争ではなく、次回のために何を覚え、何を毎回確認するかを選ぶ設計です。
ワンクリック｜ボタンは『購入完了』という役割を持つ記号になる
ボタンは、ただの四角い図形です。色を変えたり、角を丸くしたりできます。でも「押すと何が起きるか」が共有されると、ボタンは見た目以上の意味を持ちます。購入ボタンなら、商品を眺める状態から、支払いと配送が始まる状態へ人を移します。
ワンクリックが象徴的だったのは、その一つの動作へ多くの制度を折り畳んだことです。アカウント、支払い、配送先、注文処理が背後でつながることで、「押す＝買う」という意味が強くなります。BASではこうしたものをInterface Symbolとして見ます。記号が説明するだけでなく、実際に制度を作動させるからです。
これはロゴのようなブランド記号とは少し違います。ロゴは見ればブランドを思い出す。購入ボタンは、押せば次の行動が起きる。つまり意味と動作が一体になっています。だからUIをブランド体験として考える時、「きれいなボタンか」より、利用者がその記号を見た瞬間、次に何が起きると予測できるかが重要になります。
身の回りにも、役割を持つ記号はあります。「予約する」「保存する」「解約する」。表示が似ていても、その後の制度が違えば意味も違います。自分のサービスで一つボタンを選び、「このボタンは何を約束している？」と聞いてみる。画面の文言と実際の動作が一致していれば、その記号は説明を減らしながら信頼を増やせます。
ワンクリック｜『操作を減らす』から『判断をどこに置くか』へ
UX改善を「何クリック減らしたか」で競い始めると、少し変なことが起きます。確認画面を削る。入力欄を減らす。選択肢を自動で決める。数字としては短くなっても、利用者が考えたい場所まで消してしまえば、便利さは判断の代行へ近づきます。
ワンクリックから学べるのは、操作数より判断の配置です。住所は以前の登録を使う。支払いも既定値を使う。そのかわり、設定を変更する場所や、注文後に確認・修正できる仕組みが必要になる。つまり削った判断がなくなったのではなく、別の時間・別の画面へ移っています。
BASではこれを、Friction RemovalではなくDecision Placementとして再編集します。どの判断は毎回する必要がないか。どの判断は今この瞬間に本人へ返すべきか。どの判断は間違えても戻せるか。特に金額が大きい、健康や安全に関わる、長期契約になる、といった場面では「少ない操作＝良い体験」とは限りません。
自分のサービスでステップを一つ消すなら、その前に「このステップで誰が何を判断していた？」と書いてみる。運営側の都合だけなら削れるかもしれない。本人の重要な意思確認なら、残した方がいいかもしれない。便利さを磨くとは、画面を薄くすることではなく、考えなくてよいことと、考えたいことを分けることです。
削ろうか迷っている確認画面や、顧客が立ち止まる場面があれば、それを材料にしてもよさそうです。下の「3人と相談してみる」から、レイたちと残したい判断を整理できます。
