akier’s note

Product Management, Design, Software

ユーザーを愚かに見せるな(About Face)

www.amazon.co.jp

Kyashというアプリを使っていたらこのようなエラーが出てきた。

f:id:iwata1990:20200808231057p:plain:h400
Kyashのエラー画面

これは典型的なダメUIだと感じる。About Faceを参照しながら、なぜこういうUIを作ってしまうのか、どうするべきなのかを論じる。

このUIの何がユーザーを(というか私を)苛立たせるのか

私は一応もともとソフトウェアエンジニアとして働いていたので、こういうUIを作ってしまう気持ちは痛いほど分かる。

チャージできませんでした。
Kyashにご登録のカード会社へお問い合わせください。

適切なエラーメッセージとしてまず必要なことである、何が起きたのかというファクトを正しく明示せよという原則に則って「チャージできませんでした」と簡潔な文が最初に来ている。確かにnginxのアクセスログで「8月8日の23時頃にエラーアクセスがありました」とか書かれていてもデバッグができない。

そして次のメッセージ、「Kyashにご登録のカード会社へお問い合わせください。」。これはおそらく実装的にはクレカ会社とのAPI連携で、クレカ会社側が何かエラーを返してきたということなのだろう。つまりKyash側は少なくとも仕様どおりの動きをしている。であればまず疑うべきはクレカ会社側の問題なのだから、そっちを調べろという指示である。まっことごもっともなメッセージである。

しかしこのメッセージはユーザーをバカにしているようにしか(少なくとも私には)見えない。インプリメンテーションが露出しており、メンタルモデルに全く則していないからであろう。平たくいえば、この画面を見る時のユーザーのことを全く何も考えていないのだ。「お前のクレカ設定が間違ってるんだから何とかしてこい。うちは知ったこっちゃない」と言わんばかりに見える(被害妄想?)。

ユーザーのゴールは何か

こういう時は慌ててメッセージの文言を変えるのではなく、ユーザーのゴールを考え直すところから始めることがAbout Face的にも推奨される。慌ててパッチワークをしてもろくなことにはならない。

このエラーメッセージは、私が土曜の夜中に知り合いへ送金しようとした時に発生した。
この時のユーザーのゴールとはなんだろうか。

About Faceではゴールとタスクは全く別物であって、世にはびこるユーザーインターフェイスはタスク指向でしかないものが多すぎると言っている。例えばKyashにおけるタスクとはこんな具合だ。

  • 現金と同等の汎用性を持ったポイントを任意の相手に渡す
  • 対面せずにオンラインで渡す
  • 24時間好きな時に渡す

一方、(少なくとも私にとっての)Kyashのゴールはこんな具合だ。

  • 送金を忘れないように、思い立ったその場ですぐに実行できる
  • 銀行口座は印鑑証明とかの写真を撮るとかコピーを郵送するとか馬鹿げた行為なしで送金できる
  • アプリを勧めずとも周囲の人が既に使ってくれている

手段がタスクであって、目的がゴールであるといったところか。どんなアプリであってもゴール指向でないデザインがされていれば、いずれは使われなくなっていくと本書は断言している。

この場合のゴールとは何か

とはいえ問題はクレカ会社側のAPIがいつもと違う動きをしていることだ。Kyash側としては(バグ改修などを除けば)手出しができない状況なのだろう。

しかし私からすれば、明日は日曜だしそもそも窓口も分からないしどうせ聞いたところでたらい回しにされて「Kyashとかいうアプリがダメなんですよ」とカード会社のヘルプデスクから冷たくあしらわれる言われる未来すら想定される。全くやる気がでない。しかしこの支払を忘れて相手から信用を失うのが怖すぎる。

つまり私の今のゴールはこうなる。

  1. 相手を待たせたくない。送金を忘れたり、送金が遅れることで「こいつだらしないな」と思われたくない
  2. なんとか電話せずに自分で解決したい(ヘルプデスクに電話する体験はたいてい最悪)
  3. 会社が休みの間になんとか解決したい。平日になると忙しくて忘れるのが怖い

ここまでゴールの解像度が上がると、少しはマシな打ち手が見えてくる。

1を解決しにいく場合、Kyashアプリ側が相手方へ「クレジットカード会社側のトラブルで送金が遅れてしまっているようです。◯◯さんと我々は最善を尽くしてこのトラブルを解決しようとしています。」とでもメッセージを送ってくれる機能を実装することが考えられる。要は「こいつだらしないな」と思われなければよいのだ。

2, 3を解決しにいく場合は、こうしたトラブル時のよくある解決手法のうち、クレカ会社へ電話せずにできそうなことが書かれたFAQページへのリンクでも貼れば良い。別に100%解決を保証しなくても良いので、可能性があれば教えて欲しい。(e.g 一旦他社のクレカを紐付ける)

どれも2週間もあればリリースできるような機能である。技術的にはできないはずがない。

なぜこうなってしまうのか。どうすれば避けられるのか

おそらくこのUIを考えたのはエンジニアだろう。もしかしたらディレクターやPdMが「もうちょっとユーザーフレンドリーにできないの?」とか聞いたかもしれないが、エンジニアが「いやクレカ会社側のトラブルなんだから知りませんよ」と冷たくあしらったのかもしれない。なんにせよこれはインプリメンテーションモデルに則ったメッセージだ。事実として、インプリメンテーション的には、このエラーは100%クレカ会社側のAPIの責任である(とKyashエンジニアは思っている)。
つまりインプリメンテーションに最も近いエンジニアがこのUIを考えたと考えるのが自然だろう。特にこうしたエラーの理解は多少技術がわからないと判断が難しいところがある。技術が分からないPdMやディレクターがメッセージ内容を丸投げするとこうなるのだ。

PdMとしてできることは、以下ではないだろうか。

  • 技術を理解し、顧客のメンタルモデルを理解した上で、すべてのUIを自分で設計する
  • 上記ができない、どうしてもエンジニアへ任せるしかない場合は
    • この画面を見た時のユーザーのゴールを定義し、エンジニアにそれを伝達する
    • ユーザーのゴールさえ特定されていればそこに最適化してくれる優秀なエンジニアを予め採用しておく

なんにせよ、このUIを作り出した責任はPdM又はディレクターにある。PdMやディレクターは設計者でもありつつ、こうしたバッドUIを防ぐ優れたQAでもいなければならない。大変つらい仕事だ。だがやりがいはある。。。。。と思う。

私自身も、気をつけねばらならない。

で、結局どうやって解決したの?

よく見たらSMSでクレカ会社から新着メッセージが届いており、開いたところどうも不正利用防止システムが働いたようだった。この利用は私本人ですよ的なボタンを押したらすぐに解決。「よくあるケース」的な感じでKyashアプリ内にこれが出ていたらどんなにNPSが上がったことだろうか。。。。残念である。