SEOコンサルタントやデータアナリスト自身による、UX デザイナー視点での UI 改善

JADE のデザイナー masay です。

早いもので JADE へ参画し半年が経過しました。その間あんなことやこんなことがありましたが、本日は、主に SEO コンサルタントやデータアナリストが、Google Analytics や Looker studio で作成したレポートなどの定量データをもとに問題発見や仮説立案をしたあと、SEO コンサルタントやデータアナリスト自身でページの UI やサイトでの体験改善施策をどうやって見出していくか を、デザイナー視点でお話したいと思います。どうぞ宜しくお願い致します。

定量 × 定性は最強

SEO コンサルタントやデータアナリストが定量データに向き合い観測された違和感や異常は、問題提起や明らかな課題として仮説立案されると思います。

上司やチーム、クライアントの要求は… 現状を把握する為の問題一覧でしょうか、 それとも既に定義されている問題の裏付けと課題化でしょうか、 はたまた、まるっと問題発見から解決策の提案までを求められている状態でしょうか。 出てくるのであれば、事業・サービスの戦略や方向性のような大きな粒度のアウトプットも求めている、ということもあるかもしれません。

ところで、数値で可視化される Web サイト上の行動データは、すべて実際に存在している人間によるクリックやスクロールなどの行動結果で構築されています。 オンラインか店舗に足を運んでかわかりませんが日々の就労により得られた賃金で購入したスマートフォン端末の、ホームスクリーンに追加されているブラウザのアイコンから、帰宅途中の電車の手すりに捕まりながら不自由な右手の親指のみで、週末に家族と企画しているイベント内容を充実させるべく、イベントに関連しそうなキーワードを検索エンジンで代わる代わる検索をしている… かもしれない人々の行動結果です。

Google Analytics などの定量データに向き合っていると、個々の人々の行動を意識できなくなってしまうことがあります。ところが実際には個々の意識を持ったユーザーがいるわけで、先に記載したような問題提起や施策の仮説立案は、その定性的な個々の人々の視点で向き合うことで、アウトプットの信憑性や納得感を高めることができ、また新たな発見も得られると思っています。

誰でもできる UX Designer 視点のユーザビリティテスト

定量データから導き出された違和感や異常は、定性的にユーザビリティテストやヒューリスティック調査、ユーザー行動可視化ツールの閲覧、場合によってはアンケートやご意見内容との照合によりその信憑性を高められます。

あくまでも仮想のものですが、例をあげます。

とある大型施設予約サービスの Google Analytics データから、全セッションのうち「利用用途ページ」の閲覧を含むセッションは予約率が高いことがわかり、利用用途ページを見ていないユーザーに対しても見てもらうことで予約率の向上に寄与できるのではという仮説が立てられました。

GA のデータからこの仮説が導き出せたことは大きな成果です。これをしかるべき担当者へ共有をすることで改善を前に進めることももちろん可能です。 ですがもしここで、定性的な視点から裏付ける期間的猶予があるならば、実際の個々の人々の視点で向き合うことで仮説の信憑性を高めると共に、具体的に Web サイト上で何をすれば良いかまで見出すことができます。言い方を変えると、仮説は立てられたが具体ページに対してどうしたらよいかわからない場合であっても、それを見出せる可能性が高いです。

定性的な裏付けは、かけるコストに応じてその信憑性は比例します。 SEO コンサルタントやデータアナリスト自身で定性的な裏付けを行う際に適しているものの一つにユーザビリティテストが挙げられますが、そのコストと信憑性をいくつかのケースとして挙げだしてみます。

	信頼性	コスト	内容
1	高	高	専門のインタビュアーないし UX Researcher が、専門の施設で行うサンプル数（テスト実施数）が 10 を超え、撮影動画、対話テキスト、テスト結果と仮説を含むレポートを含むもの
2	中〜高	低〜中	専門のモデレータないし UX Researcher もしくはユーザビリティテストの閲覧・実施経験がある人（モデレータ）が、社内外から被験者を選定し社内外の会議室等で行うもの
3	中〜高	低	社内で案件担当者が社内メンバーに対して行うもの

手法が体系化された、よくユーザビリティテストと呼ばれているものは 1 ないし 2 を指し、主に UX Researcher と呼ばれる専門家が実施します。 これからやり方含めお伝えするのは 3 ですが、ユーザビリティテストを得意としている方、起業経験があったりコンサルタント企業や大規模企業にお勤めの、テストレポートに見慣れている方々からは、それはユーザビリティテストではないと一蹴されてしまう可能性があります。が、3 を私は UX Designer 視点のユーザビリティテストと呼んでおり、これはいくつかの前提が伴っていれば誰もが実施でき、またその結果は第三者からみても納得可能なもの だと捉えています。1、2 は期間・金銭いずれのコストも低くなく、とはいえ短期でより信頼性の高いアウトプットを求めている前述の一蹴してしまいそうになる人々にとっても、よくよく考えてみれば実は求めているのは 3 だったという事も多いです。

ペルソナを取り巻く難しい状況

さて 3 ですが、これは SEO コンサルタントやデータアナリスト自身が、社内のメンバーに対し、Web サイトを操作してもらうモデレートをするものです。

ユーザビリティテストのやりかた自体はインターネット上に多く存在していますので、そちらを参考にしていただいても良いですが、3 をするにあたって絶対になくてはならないのは、その Web サイトが掲げているユーザー像 です。

ユーザー像はどんな形をとっていてもかまいませんが、第三者がそれによって明確にその人物像を想像でき、更にユーザーになりきることができるものであるのが望ましいです。

企業やサービスによっては、明確にペルソナとして定義している場合があります。既にある場合は、モデレータはそれを元に社内で被験者を探しだすことができます。その際、私生活から完全にペルソナと一致する人を探す必要は全くありませんが、ペルソナとあきらかに乖離がある人は避けなければなりません。例えば妊婦の方向けのコミュニティサイトのペルソナはほぼ間違いなく女性になると思いますが、その被験者に男性をアサインするのは無理があります。

企業やサービスで、ペルソナが定義されていない場合は話は少し難易度があがることがあります。今お話している明確なユーザー像を元にした Web サービスのプロダクト改善は、明確な売上や数値上の目標と相反すると捉えられていることが多く、使い勝手を良くするのはいいんだけど KPI は売上だから悪いけど実施の優先度は下げざるを得ないから… というようやりとりは多くの場所で起きています（これが一概にそうではない理由は可愛いイラストと共に後述します）。 更に、ペルソナやユーザビリティテスト、カスタマージャーニーマップを作ったことはあるが、その本質や活用方法がわからなかったばかりに、ペルソナ等にネガティブなイメージを持っている、作成してはいるがほぼ向き合っていない、というような場合も難航することが多いです。

ペルソナのような明確な顧客像が定義されていない場合の進め方はいくつか存在します。

	ペルソナ	ペルソナの共有	テスト内容の共有	施策の共有
a	作る	する	する	する
b	作る	しないが場合によってする	しないが場合によってする	する
c	作らない	-	-	する

c は是非避けてください。そして a か b に至る為に、是非ユーザビリティテストを実施してもらいたいと思います。 b は弱気に見えますが、場合によっては重要なのは結果でもあり、初回のアウトプットではペルソナとユーザビリティテストの内容には触れず、「Google Analytics の調査データからの仮説立案を元にいくつかの施策を考案したので共有します」と、見い出した施策をまず伝え、もしプロセスに興味を持たれた場合にはじめてそのプロセスを伝えるものです。施策の信憑性が問われてしまった場合は開示します。その結果納得してもらえることもそうでないこともあると思います。

ユーザビリティテストを実施するとどうしてもそのプロセスを共有したくなりますが、前述の通り施策を提示する前に手段に対して議論が起きてしまうと本末転倒です。もちろん、関係性によっては事前にそのプロセスを開示し、場合によって一緒にペルソナを構築していけるならそれがベストです。

ペルソナを作ってみる

a、 b のペルソナを作る場合ですが、ペルソナはある人物を形作る要素の集合体で、重要なのはユーザビリティテストの被験者がそれをもとにそのペルソナになりきれるものかどうか です。ペルソナに対しての被験者からの質問等も発生し得ますのでモデレータの手腕もある程度問われます。c を実施するには以下のような属性があれば十分だと思いますが、なりきれるかどうかの視点で要素は自由に差し引きが可能です。

• å¹´é½¢ / 性別 / 学歴、教育レベル / 職業 / 家族構成 / 所得
• 仮の写真、名前（時代に即した名前を付けるとより良いが、被験者の年齢が近ければ省く）
• よく利用するソーシャル or ニュースチャネル
• よく利用するデバイス
  
  
• 上の４つの項目をテキスト化したバイオグラフィー
• サービスや Web サイトに関連する、ユーザーが置かれているペインポイント含む現状
• ペインポイントや現状に対しての要求及びゴール

これらの情報は、Google Analytics などのデータに日々向き合っていたり、サービスにある程度の期間触れ続けているとある程度見えてくるものでもあります。ここで顧客像が皆目検討がつかないという場合はある意味マズイ状況なのはお伝えするまでもありませんので、自信を持って作成して下さい。もし企業・サービスが実施しているアンケートやご意見などの情報があれば、それらに目を通すことでより精度の高いものが構築できます。クライアントへ質問をしてみても良いと思います。ペルソナは複数あっても差し支えませんが、基本的には最も多いであるペルソナに対してテストをし、優先度の高いペルソナが複数存在する場合は人数分テストは実施します。

UX Designer 視点のユーザビリティテストをやってみる

ユーザビリティテストのプロセスはいくつかの点に注意さえすれば複雑なものではありません。 テストは以下の様な流れで実施します。

	すること
1	冒頭で「テスト中、頭で考えていることを是非口に出して下さい」と伝える
2	被験者自身をテストするものでもなく、どう回答しても評価や関係性に何ら影響は与えないことを伝える
3	ペルソナをインプットしてもらったあと、いきなり対象のページを触ってもらわずに、あなたならまず何をしますかと伝えて、自由に行動してもらう
4	相手が黙ってしまったら「今何か考えてますか」と適宜示唆する
5	相手がペルソナではなく素の人格になってしまっていたら適宜示唆する
6	しばらく自由に行動してもらったあとで、調査したいページに訪問しなかったら、一旦中断して、規程の検索ワードで検索した際に調査対象ページに訪問したつもりで引き続き操作してもらう
7	ここを押してください、等の誘導は可能な限りしない

ユーザビリティテストを実施すると、様々なことが見えてくると思います。思いもよらない検索ワードが出てきた、ファーストビューで直帰した、考えもしなかった情報の要望が出てきた、明らかに間違った操作が観測できた、など。

「個人的な意見なんですけど」と被験者が発声することもよくあります。この場合は、一旦素の人格の意見を言ってもらい、その後速やかに暗示をかけて（？）ペルソナに戻ってもらって下さい。これらは、モデレータも被験者自身もサービスに対する洞察が深まるもので、それはそれで価値あるものです。

利便性向上は CV に直結… する

被験者が不満に感じる瞬間はとても重要です。ユーザビリティテストは、モデレータと被験者以外にもうひとりメモ役の方がいるととても良いのですが、ユーザーが不満に感じた瞬間は、残念な絵文字（😩）と共に何が残念だったかを記載しておいて下さい。 ブランド・商品・サービス名の名指し訪問以外では、検索エンジン経由で複数のサイトを行き来するようにユーザーは行動します。そのような状況下では、これは私の経験上、テストページ訪問中に３度不満に感じる瞬間が訪れると大多数のユーザーは離脱して検索エンジンに戻り、他のサービスを探します。これは単体の不満としては問題視しにくいが積み重なってはじめて可視化する問題で、「利便性向上にはつながるが売上貢献しない」施策として却下されるが、実はそれが売上向上に直結する施策だったという最たる例です。弊社で提唱している検索体験モデル QCLS の Surf 部分の最適化にもつながります。

一連の体験で感じたストラグルの積み重ねによって離脱するユーザーと、問題に単体で向きあってしまった場合の乖離

そして、本来の意図は定量データに向き合うことで見いだされた仮説の定性的な裏付けですので、もし事前にあげだしていた仮説に関係する問題が発見されなかった場合は、具体的にその箇所に関して掘り下げをしてみても良いと思います。先の例で言えば「今施設の使用用途欄があったと思いますが、使用用途欄は目に入りましたか」「どう思いましたか？」のように被験者の自然な操作を阻害しない形で掘り下げられると、ユーザーを誘導することにならずベストです。

ユーザビリティテストを実施し、自身の目でユーザーの行動を見ると、問題は火を見るより明らかになってきます。CV 向上のために導線を太くないし新設すべきだがどこに何をすれば良いかわからないというケースであっても、どのタイミングで何が欲しいというユーザーの行動がわかっていればどこに何があれば効果的かが強く想像でき、UI 改善の提案としては FigJam や miro、Google Slide などを用いて既存キャプチャにヒゲをはやして何をすべきか記載するだけで十分なものができあがります。… 即開発できるレベルの UI 化まで求められる場合、しかるべき精度の UI でレビューしたいという場合は是非最寄りの UI Designer に相談してください。

テストは３人程度に対して実施してみてください。今となってはかなり以前の投稿になってはしまいましたがニールセンのユーザビリティテストの実施回数に関する投稿によれば 5 人を超えるテストでは新たな発見は見い出しにくいとされており、モデレータ自身が得る洞察と、我々に与えられている期間を考慮すると 3 人で十分です。何より、ユーザビリティテストはその必要とされる集中力の為に、多くのテスト実施は他の業務へ影響を与えかねません。

担当者の行動と施策、それぞれの優先度

さて、見いだされた施策群には優先度をつけることで、実行までの判断をし易くできます。

まず、テストで観測されたもののうち、ユーザーの明らかな誤解による操作ミスの修正は最優先で修正をすべきです。なぜなら、それらの製作者側も含め誰も望んでいない行動は Google Analytics などのデータに影響を与え、検証や仮説立案をそれらを考慮して行うことは不毛で検証結果の信憑性も疑わしくなってしまうと考えられるからです。もちろんこれは釈迦に説法でして、SEO コンサルタントやデータアナリストの方々はそういった明らかな問題発見も含めて調査検証を行っていますから、その繰り返しで問題を発見解決し、更に改善を仮説立てているとも思います。 考え方を変えてみると、ページの UI や構成がユーザーの誤解を生み誤操作を引き起こしてしてしまうような明らかな問題があるうちは、Google Analytics などのデータからは問題発見はできるかもしれないがデータからの仮説立案は非常に難しい可能性があるとも捉えられます。

先にお伝えしたように、専門家ではなくても UX Designer 視点のユーザビリティテストによって Web サイト上の問題を発見し解決策を見い出せるであろうことがわかりました。ですので、定量データに向き合った際に明らかな異常を感じたり明らかな問題が発見された場合は、踏み込んだ調査の前に一度ユーザビリティテストを行ってみると良いかもしれません。また、社内のデザイナーがいらっしゃれば、ユーザビリティーヒューリスティック調査等を実施してもらうことでも多くの問題が発見できると思います。

同じことを書きますが、ユーザビリティテストやヒューリスティック調査でも見いだされるわかりにくさや使い勝手の問題は、単体では CV 貢献しないと優先度が落ち、調査本来の価値が埋もれてしまうことが多いです。ですが先述した通りユーザーが感じる不満は積み重なって売上を阻害する大きな要因になり得ますので、是非それらの調査を活用していただけたらと思います。

効果×コストのマトリクス（左）と、アイゼンハワーマトリクス（右）

施策の優先度は、改善効果と費用２軸のマトリックスと、アイゼンハワーマトリックスの２つにプロットすることで優先度が付けやすくなります。 優先度付けで特に難しいケースとして、緊急の問題は発見したが解決には大きなコスト、特に開発に大きなコストがかかるようなケースがよくあります。それらの施策はアイゼンハワーマトリクスの左上にプロットされることになるはずですが、重要な問題だがすぐにはできないと早合点せずに、まずどんな手段を使っても良いので低コストで最低限問題を解決できる手段はないかを検討し、中長期的な根治は別軸検討するのが望ましいです。

最後に

かなり長くなってしまいましたが、ここまでお読みいただきありがとうございました。

体系化された手法なども用いて色々と記載しましたが、特に重要なのは、分業・専業化された昨今の体制下でプロダクトに向き合うことは、体制上どうしても個人の主観で見てしまいがちで、いずれの手法もユーザーの視点 = 利用者視点に立つ為に用いているという点です。 デザイナーがよく言うユーザー視点は、言葉だけ見ると「それくらいみんな持ってる」と捉えがちですが、本当の利用者視点はなかなか持てないことが多く、それを意識的に持ちましょうというのがユーザー視点でもあり UX Design の大前提です。 文中ではユーザビリティテストは実施する前提ですが、ユーザビリティテストは実施できなくても、「私は王女オリゲルド」と自身がペルソナになりきった上で Web サイトに触れるだけでも新たな洞察が得られると思います。

そしてこれは Designer である私自身にとっても言えることで、日々研鑽を深めるばかりです。

では。