003：UXでもUIでも何でもいいからUをプロセスに取り込む

先日のエントリ（002：制作物に対する客観性（追記有り））について、タイトルに「追記有り」とあることからもわかる通り、致命的な欠落があったため少し加筆してある。その加筆内容とは、端的に言うと「ユーザー目線が不在のままデザイナーとクライアント（意思決定者）と綱引きしてたって何の意味もない」という話であり、これについては猛省が必要だと感じている。

とはいえデザイナーやクライアントが「いやユーザーはこう思うはず」だとか言い合っていても仕方ない。実際にエンドユーザーに触ってみてもらってフィードバックを求めていくのが最もユーザー目線の実現に近いのでは無いかとは思う（と言いつつも、他方でテストユーザーが「正解」を持っているわけでもないだろう。こういったフィードバック型の「カイゼン」では問題解決は行えるだろうが、そもそもの問題設定でミスる可能性は往々にしてあるのだが、そういった懸念については今回は保留しておこう）。

ということで、ユーザーテスト以外で、サービス開発のプロセスにユーザーを取り込む方法を探してみたのだが、UXのKPIを初期段階で設定するというやり方を発見した（UXのKPIを設定しよう！~ ユーザー体験の定量化ってなぜ必要？ ~）。UXKPIとズラッとかくとギョーカイ人しかわからない感じになるが、要は「サービスの中でユーザーが最低限体験して欲しいところを予め決めておいてその達成率を見ていきましょう」という話かと思われる（上記エントリ内では〈「これさえ見ておけば良質なユーザー体験が提供できている」という指標 〉と述べられている。ではそのUX-KPIとは具体的にはどういったものが挙げられるだろうか。下記は上記エントリ内で挙げられている例である。

「週3回以上タスクをシェアしたユーザーの割合/月」（タスクシェアアプリのケース）
「購入した上で、15日に1回以上ログインし続けているユーザーの割合」（アパレル系ECアプリのケース）

とはいえ、UX-KPIを導入しただけでは以下のような課題は残るだろう。

• そのUX-KPIはどれぐらいあれば適正なのか？
• そもそもそのUX-KPIの達成がそのまま良いユーザー体験を意味するのか？
• UX-KPIが目標値に届かない場合の原因の特定はいかにして行われるのか？
• そもそもファンダメンタルな価値をそのサービスが提供できているか否かについてはUX-KPIの達成度では判別できないのではないか？

おそらくは、UX-KPIの他にも複数の指標を組み合わせることで、ユーザーの価値にどれほど寄与できているかどうかを事後的に計測するしかないのだろう。つまりはリリースしてみてUX-KPIを取ってきて原因の仮設を立てて解決策を打ちリリースしてみてUX-KPIをやって…を繰り返すしかないというわけである。そうなると、そもそもUX-KPIのとりようがないメジャーリリース前に「いやUXとしては…」とか言っていても仕方がない、ということになろう。

そうであれば、いわゆるスモールスタートで始めて、アーリーバード達からUX-KPIを採集していく、という形が一般的になるだろう。ここで難しいのは、アーリーバード達はUXに対する感度が高く、かつインフルエンサーであることが多い一方で、スモールスタートではサービスの「粗」を取り切れていないことが多い、という点だろう。つまり、スタート直後のファーストインプレッションとしての粗がインフルエンスされてしまう。それを考慮に入れると、やはり数度にわたってクローズドローンチを行い、テストユーザーからのUX-KPIを見て最低限の「粗」を取ってからメジャーリリース、という方法が最も適当だと言えようか。

こうなると、もはやデザイナーがどうこうとかいう話じゃなくなってくるかもしれない。こうなってくると、マネジメント層に対してうまく伝えるしかなくなるのだが、それに至って思い出したのは、先ほどアマゾンで見ていた〈Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES) 〉という本のユーザーレビュー中の以下の一文である。

この本では，リーン・スタートアップを知っているデザイナーなどを想定して，どのように実践できるかなどが書かれている。

ただ，方法論などはある程度決定権がなければ，実践できず，メンバーが読んでも上司を説得できなければ無意味となる。

そういう意味でこの本が必要であったり有効な人はかなり限られる。僕が読んでも意味ないと思った。

先日のエントリでも少し言及した記憶があるかもしれないが、結局のところあらゆる平社員デザイナーはこれに限る…という話でまたも締めてしまった。