ただの進行管理の人で終わりたくない! ディレクターのためのUXデザインノウハウ

author.jpg

こんにちは。ゲーム第一本部・モバイルディレクターの@hiro93n(向かって右)です。今回はNode.jsの日本ユーザグループ代表とのツーショットでお送りしております。

UXデザイン、と書いていますが、グラフィックデザインのことは一切話していませんので予想と反してしまった方はごめんなさい。どちらかと言うとサービスデザインの話です。

私自身は半年くらい前までは横断組織(SWAT)でUX系デザイナーっぽく体系化をやりつつ現在はとある新規サービスのディレクター兼プランナーをメインに担当しています。

具体的には簡易ターゲット設定した上でリーンダイアグラムを書き、サービスとして何を一番推していくのか?を決め、プロデューサーと目線合わせをした上で優先順位に応じて情報設計をしていくことが多いです。

というわけで、今回はUXデザイナー寄りなディレクターの動き方についてお話をしたいと思います。

結果以上にユーザシナリオを評価しよう

チームで置いたユーザ像が実情と離れていると、サービス設計からUIから色んなところがイマイチとなり、サービスの進む方向性も狂ってしまいます。

ユーザ像が自分たちに都合のいい人になっていないか、というのもありつつ自分たちのサービスを最初に楽しんでくれる人のマジョリティなのか、極端な一部なのかも見極める必要があります。

image1.png

ユーザ像、ペルソナを理屈だけで突き詰めはじめるとキリがなかったりするので実際の開発時には、ユーザテスト等で少しずつ補正することをしていきますがそこでやることは正解を掴むと言うより、仮説の確度を上げることです。

ユーザシナリオとその検証

何はなくともやっておくとサービス設計しやすいのは、ペルソナを暫定で立てて、ユーザシナリオを立てておくことだと思っています。

image2.png

個人の、点としてのペルソナだけだと、そのペルソナが関わる周囲の人との接点や時間の流れを考えることがやりにくく、結果その人自体の性格や趣味ばかりに気が取られがちになり暫定で組めばいいのに時間をかけすぎる、結局使いにくいものが生まれてしまいます。

実際に立ててみたシナリオについて、最近はリーンダイアグラムを加えて妥当性の判断をしています。

リーンダイアグラムについてはリーンUX界隈で深く語られているので詳細は省きますが視点としては

・そのサービスがカバーするニーズを魅力的に見える人って、今使っているサービスの資産を捨ててまで欲しい「不自由」や「不満」ってあるの?

・日頃どんなところを探しているの?検索ワードは何なの?

・刺さると思っている要素を最小限に押さえたとき(MVP)、何が実現できてたらいいの?

あたりを妥当性のチェックとして押さえています。

小難しく書きましたが、刺さっているのか刺さってないのかをどこまで確かめるか、確かめた上で何かできることがあるのか、というモノを押さえればいいのです。

絶対の正解シナリオは立てられなくとも、それ本当に成立するの?それ何か意味あるの?と言う部分は冷静に振り返れますし、あったら嬉しいけどなくても困んないな、という機能開発からもある程度は抜け出しやすくなるツールだと思います。

その時に必要なのは、シナリオと因果の関係です。

因果とシナリオ

風が吹けば桶屋が儲かる、と言いますが、物事の多くには因果があります。

原因と結果は必ずしも隣同士ではなくいくつかの段階を挟んでいることが多いと思います。

image3.png

Aに対する施策を打ってEのみを見た時に結果が出なかったとしてその施策の効果は本当にゼロなのかと言うと、実はCやDあたりまでは効いていたのだ、という場合があります。

シナリオを立てるのはA〜Eまでの流れを設計することと同義でUXを定量分析するというのは、施策がCまでなのかDまでなのか、それともまだ見ぬFに効いてしまったのかを数字で判断するという行為です。

例えば、UIを変えたけど売上が上がりません、というのはEだけを見ていると言う話でそもそもEまでの道はつながっていたのか(何となく上がるんじゃない?ではないよね)も含めて振り返らないと、せっかく施策を打ったのに次の打ち手に繋がる積み上げもないよね、という悲劇が起こります。

Dまで来ていたら、立てたユーザ像はあながち間違っていないのでしょうしAで終わっていたらそもそも見誤っている。

施策を評価する場合

・元々立てているユーザ像やシナリオは合っていたのか

・課題の設定は合っていたのか

・打ち手として勝ち筋のあるものだったのか

の3点から見てあげることで、次の打ち手についてもまたゼロからにならず積み上げがある状態で打てるようになるので、結果的にみんな幸せになれそうです。

思った通りに使われた?それとも意外に使われた?

食器乾燥機なのに実際は模型乾燥機として売れている、なんて話がありますがせっかくユーザシナリオも立てたのなら、思った通りに使われたら良いですよね。

使われたか使われてないかから更にさかのぼって、思い通りだったのかどうかまで検証するのはUI含めたタッチポイントであれば特に、ディレクターの役目のひとつだと思います。

広告の効果測定で使う表現に置き換えると、このように表せます。

使った:CTR

想い通りに使った:CVR

使いやすさ改善のために新規動線を作ったとして、アクセス解析を見るとどうやら使われているらしいのだけど、それは思った通りの人に使われているのかどうか。

先の因果の話で言うと、A~Eの経由で使っているのか、それとも全然予想外のところで使っているのか。

曜日ダンジョンで必要スキルが異なるから、その日ゲームにはじめて来た人は編成をするだろう、という仮説があるとします。

編成ボタンをファーストビューからアクセスしやすい位置に置いたとして、押される回数が増えました。その場合あり得る可能性としては

・予想通り、曜日ダンジョン都合で編成ボタンを押している

→編成後、曜日ダンジョンに行っている?曜日ダンジョンに行きやすくなっている?

・頻繁に仲間が手に入るから編成ボタンを押している

→直前のページはガチャなど、仲間の増やせるページに鳴っている?

・仲間のパラメータが見にくいから、レベルが上がるたびに編成ボタンを押している

→ステータスボタンの使われ方とかどうなっている?

など、結果から導けるものは複数あるので、前後の関係性を見る。CVRで評価することで確実性が増します。

施策の結果は想い通りだったのか、ユーザ層はどうか、と言う部分を定量的なデータで持てると次の施策をどう打つべきかをより確度高くリードできるディレクターになれると思います。

分析するのはプロのアナリストに任せたらいいじゃん、でいいのかな?

組織としての分析チームやアナリストがいる、という場合もあると思います。

その場合、専門家がいるならディレクターは分析しなくてもよいかも…しれません。ただし、この辺は優先順位と得意不得意の話で、分析すること自体も分けられるはずなのです。

分析自体はログの設計で半分以上終わっている、などと言われます。

ユーザの行動を設計しコンバージョンを最適化するノウハウはディレクターが持っていることが
多いと思われますし、そうであれば何をどのタイミングで知りたいのかについては
アナリストに任せるのではなく、ディレクターが推進して決めていくほうが良いかもしれません。

分析する、というのは最終的にログの分析スクリプトを書けるかどうかではなく何を知りたくて、その結果から何を導けるかが大事なポイントです。それなら、ユーザシナリオを設計した人が一番分かっているはず(分かっていないとおかしい)です。

更に言えば、知りたい時に即自分で手を動かしてデータを手に入れられるとアナリストがイベントでのゲームバランスの分析などで忙しい中でもイベントUI設計の振り返りの材料を集めたり、イベント途中のUI改善が行えたりとより攻め型のディレクターの動きを取ることができます。

もちろん、余裕があるようであればアナリストに分析レビューしてもらえると自分の分析スキルも上がってなおよしです。

これだけ押さえて!GoogleAnalyticsの基本設定

ユーザシナリオの立て方や分析の必要性は分かった。で、何が必要なの?とうことで今回はGoogleAnalytics経由の設定についてざっとご紹介します。

これだけ設定しておけば、一通りの施策評価ができるはずです。(ちなみに、GoogleAnalyticsはアプリにも対応しています)

最初の最初は、フィルタしよう

GoogleAnaytics。実は一定以上のユニークURLをotherでまとめてしまう仕様になっています。

モバゲー自体、何の設定もせずにいると全体のURLの第2位(45%前後)がotherとなります。すなわち、半分以上のURLが結局訳分からないモノ扱いされてしまうということです。

ソーシャルゲームでは、ユーザid別のパラメータや経路別パラメータなど、同じURLに見えても複数のパラメータを持っていることが多々あります。そのため、すぐにユニークURL不足に陥ってしまうのです。

特にid別に経路見なくてもいいよ、と言う場合は、id経由のものをまるっとまとめられます。

そのために必要なのがフィルタ機能です。フィルタの設定には下記の手順が必要です。

1)アナリティクス設定からフィルタを選ぶ

image4.png

2)フィルタの編集でカスタムフィルタを選び、下記の設定を行う。

*リクエストURIの部分は正規表現でパラメータを捕獲しています。

^(.*?)([?&]from[^&]*)(.*)
image5.png

フィルタが反映されるのは、プレミアムなら4時間以内、フリーなら48時間程度かかりますがかんたんに確認したい場合は、リアルタイム>コンテンツなどでアクセスを評価してみると正しくフィルタリングされているかが分かりますので、ぜひ使ってみてください。

・・・と言われても、いきなりフィルタなんかかけて何か起こったら恐いと思います。

そこで使えるのが、プロファイルです。

GoogleAnayticsにはプロファイルと言う概念があり、ひとつのサイト(プロパティ)に対し複数のプロファイルを紐付けられます。

そしてこのプロファイルに対しフィルタをかけられるのです。

これにより、パラメータがついているものもついていないものも同じアクセスに含められ結果、ユニークURL数を減らせます。

仮に、今農園ゲームを運営しているとします。

その場合のプロファイルの分け方としては

・何もしないそのままのもの

・ユーザid別には見ないもの(ユーザidをフィルタ)

・ガレージ・ショップなどに含まれる、野菜のid別には見ないもの(野菜idをフィルタ)

・テスト用プロファイル(ここで試してから他に設定を反映させる)

などがあります。”何もしないそのままのもの”だけを残しておけば、あとは用途に合わせてプロファイルを設定するのが良いと思います。

点のイベントと線のナビゲーションサマリー

メニューを押された、2つ出しているバナーの上側が押された、などの行動を把握できるのがイベント機能です。

イベント機能には下記の2種類があり、必要に応じて使い分けが必要です。

_trackEvent:メニューの開閉等、ゴールとなるものに利用。全体のPVに含まれない

_trackPageview:経路となるものに利用。全体のPVに含まれる

具体的な設定はDeNA Creator blog(http://creator.dena.jp/archives/31165214.html)を参照頂ければと思いますが、ゴールなのか経路なのかが大事なポイントです。

経路を知りたいと言うのは、例えば新しくメニューUIを導入した時に、メニューを開いたあとにどのページに行ったのかを知りたい、というシーンです。

一方ゴールを知りたい、というのは、例えば新たにSNSシェアボタンを設置してそのボタンは果たして使われたのかどうか、というシーンです。

では、その遷移はどうやって把握すれば良いでしょうか。

そのために使える機能が、ナビゲーションサマリーです。

image6.png

ナビゲーションサマリーを使うと、前後のページ遷移について把握できます。

image7.png

更にさかのぼる、あるいは深掘る場合には、ページ名をクリックして行く必要があります。

予めページのグループ化を行っておくと、ショップページ全体からマイページに来て、そのあとミッションページに進んでいる、というようなフローもざっと確認できます。

※ショップのタブ毎にURLが異なるような場合は個別にURLが出てしまうため、それをまとめておく

イベントフローを使っても似たようなことができますが、条件を区切って細かく見る場合はこちらの方がおすすめです。

なお、チュートリアルのように複数段階の動きを見たい場合は新たに目標を設定&目標到達プロセスを利用することをお勧めしますが、今回はまず、ナビゲーションサマリーまで覚えて帰って頂ければと思います。

UXデザイナー型ディレクター、という立ち位置

よくよく見ると、施策を打って数字を見て、というところで結構普通のWebディレクターの立ち振る舞いと近いかもしれません。

ただ、UXデザインのノウハウでプロダクトを良くする所に深く突っ込む、と言う点でいわゆる制作ディレクターより、事業主体のディレクターに踏み出している点は異なります。

UIやアセット周りのことから一歩踏み出して、ユーザシナリオや効果分析ができるようになるとチームで進める施策の善し悪しであったり、事業の方向性の検討まで職域が広がるので新たな立ち位置で活躍できると思います。

ブラウザでもアプリでも、ユーザにどう喜んでもらおうかと思う部分は同じです。

私たちもDelight and Impact the Worldを実現できるよう追求していきますので、皆様からも是非知見をお寄せ頂けると幸いです!

 

今回はちょっと引いた目線でお話ししましたが、近日中に当社ゲーム開発現場のど真ん中でUXやUI設計を担当するメンバーが実践的な記事を書く予定ですので、ぜひともお楽しみに。

これからも一緒に面白いプロダクトを作っていきましょう。