読者です 読者をやめる 読者になる 読者になる

web「サービス」のマーケティングドリブン開発。多数決で決めよう。

ようするに「その数学が戦略を決める」で紹介されていた手法を取り入れようという話。
あるWebサービスを開発するとき、「この機能のUIはどうやって実装しようか」と悩むことがあるだろう。サービスの造り手はユーザじゃないから、どんなUIが便利なのか、自信をもって決められるわけがない。できるのは、整合性を保証するぐらいだ。
そんなとき、いくつかの選択肢を全て実装してみて、ユーザに使ってもらってconversion率を比較すればいいじゃないか、ということ。
そのための造りこみは、設計の段階はもちろん、開発環境や開発ツールにも及ぶだろう。そういう開発パターンというものを共有できれば、オープンソースのサービス全体のクオリティは飛躍的に上がるんじゃないだろうか?

  1. 本番サービスのほかに、テスト用のサイトを用意する。ユーザごとに別モノに見えるのが良いかもしれないし、ほとんど同じで、調整したい部分だけ異なるほうが良いのかもしれない(実はここんところが難しいのだろう)
    1. UIを変更したら、最初はなれるまで時間がかかる、その後でデータを取らないと、変更前との比較は難しい。(このラグの設定も難しいのだろう。それだからこそ、リアルタイムでどう変化するかを最初からデータで把握していないと、調整すらままならない)
  2. あるユースケースのgoalをとりだして、それを実現するpath(passでもいいけど:-)をpluggableにできるように設計する
    1. goalというのはassertionの集積として記述する(要するにsub-goalだ)、というのがすぐ思い浮かぶけれど、どうすべきかはやってみないとわからないな。
  3. 実験用サイトでは、毎回ランダムにpathを設定するのではなく、1人のユーザには統一したUIを提供できるように設計する
    1. 逆に、あるユーザのUIの履歴をすべてとっておいて、回帰テストに利用することも大事だろう。
  4. 目標goalごとにどのパスを通ったか、どのパスがgoalにたどり着く率が高かったかを評価できるように、ログ解析ツールを設計する(google analyticsのconversion率ってそういうものかな?)
    1. もちろんgoalにたどり着かなかった原因としてはプログラムのlogicのbug(不整合)もあるだろうけれど、ユーザが途中で止める、迷うというのも立派なbugとして扱っていいと思う
    2. できるならば、goalに到達するまでの時間が短いほうがいいし、単位時間あたりのgoalの達成数が多いほうがいい

とまぁ、ちょっと思いつきをリストにしただけでも個人で再発明するのは無駄すぎる。だからこそ、こういうツールが広まったら、楽しくサイトをいじれるんじゃないだろうか。その結果、カスタマイズが容易で、居心地のいいサービスがひとつでも増えるとしたら、やりがいのある仕事だよなぁ>自分

inspired by

その数学が戦略を決める

その数学が戦略を決める

僕がTDDをやめた理由 - カタチづくり