UI施策の功罪
データサイエンスという言葉が流行る中、UI施策もデータドリブンで回す会社が増えてきました。しかし、それに比例して「UI改善施策を続けているのに成果が上がらない。それどころか利用者が減ってきてしまった。」といったお話も耳にするようになりました。UI施策をうまく回している会社とそうでない会社の何が違うのか、日常で使うUIに変更を加える場合利用者にどのような影響を与えるのか、データドリブンでUI改善を行う場合に潜む注意点やリスクをまとめました。
※ 本ノートは社内向けに作成したドキュメントをベースにしております。文中には指示語や断定的な表現が多く含まれますが、その点ご理解とご了承ください。以下の内容が少しでも皆様のお役に立てれば光栄です。
そのUI施策は必要？
本当にやってみないと結果が「わからない」施策なの？
はじめに、これはUI施策全てが無駄と言ってるわけではありません。
「ユーザーがサービスを利用する上で使いにくい点」が生まれた瞬間に直ちに修正は加えるべきです。そして、そのタイミングは、誤った設計に気付いたり、新しい要素や機能を追加しようとしたり、新しいデバイスが出たり、業界のトレンドが変化したり、流入してくるユーザーのリテラシーが変わる時です。その時が来たら必ず既存UI・デザインを見直し、「最適化」する必要があると言えるでしょう。
しかし、そういった理由もなく「ボタンを大きくしてみたら数字が上がるのでは？」のような思考で施策を回すと期待する効果は得られにくいでしょう。
仮にそれで数字が上がっても、その「施策の成果」だと証明することが非常に難しく、また、永続的に効果を発揮する安定的で再現性の高い施策にならない可能性があります。
定量的な証明が難しいケース
・ボタンを大きくする場合
どれだけ大きくするのか。1pxずつ無限に試すことは可能です。
しかし、どこまで大きくすればいいのか落とし所を数値のみで判断し最適解を導き出せるでしょうか。
・ボタンの配色を変える場合
どの色を使うのか。1色ずつ無限に試すことは可能です。
しかし、どの色が1番CVRが高いのか数値のみで証明できるでしょうか。
上記の2つのUI変更を仮説のない状態で行った場合、施策効果を定量的に証明することも、最適なUIとしてアウトプットすることも難しいように思えます。
また、その施策にどれくらいのリソースをかけるべきなのか、妥当性を証明することも難しいように思えます。
非効率なUI施策例
ここでは実際にあったUI施策の事例をもとに説明していきます。
A社では、自社で運用しているサービスのUI施策をデイリーで回しています。
毎日、この要素を1px上に持っていったらどうか。ボタンの色を変えてみたらどうか。施策数のみをKPIにUI施策を続けています。
しかし、これらの施策をしていてもしていなくても日々数値は変化します。
何も施策をしなかったとしても翌日の数字が前日と完全一致する事はレアケースです。
1pxタイトルの位置を下にずらしても前日との数値的対比は可能ですし、翌日それを戻しても同じように数値的対比ができます。数日続けば数値変化の平均を出す事も可能です。
つまり何でもいいのでUI変更をして「数値が変わった。」と報告することは容易なのです。
結果を出すためにとにかく何でもいいから施策を回さないといけない。
やることがなくなって暇だけど仕事してる感を出さないといけない。
質より量のデータドリブンで評価される現場において、非効率なUI改善を続けていくと、このようなオペレーションが蔓延する可能性が生まれるのです。
上記は極端な例ですが、ここまで悪意がなくても結果として同じような動き方や指示を出している場合もあります。
UI施策を恒常的に行う場合は、「思考することを停止した状態」で行うと大変危険なのです。そうならないように調整する人が必要になってくるでしょう。
擬似相関によるUI施策
擬似相関を説明するうえで有名なお話があります。
アイスクリームの売り上げが多い年ほど、溺死者が増える
一見関係ないような二つの事象に思えますが、この二つの事象は疑似相関している関係といえます。
実際にアイスクリームが売れるということは暑い日である可能性が高く、暑い日である可能性が高いという事は海やプールに行く人が増える可能性が高いという事になります。そして海やプールに行く人口が増えれば比例して溺死などの事故も増えるということになります。
直接的な因果は有りませんが、疑似的に相関しています。
しかし、この関係を「因果関係」として解釈してしまうと、溺死者を減らすために「アイスクリーム不買運動をする」ことに繋がりかねません。
このような「因果関係と相関関係の交錯」はUI施策においても多くみられるように感じます。
再現性の曖昧なUI施策
他社のサービスで「文字を赤にしたらCVRが上がった。」だから文字を赤にしたらCVRが上がるのではないか。
サービスの改善を検討されている方の中には、このような思考をされる方がいらっしゃいます。
上記アイスクリームの不買運動の例に似ています。
この施策は文字を変えた行為がCVRを上げたわけではありません。
文字を「赤という膨張色」を使用して強調した結果、その要素がユーザーにとって意味のある要素であり、それがユーザーの目に入りやすくなったからアクションが増えCVRが上がったのです。
つまり、赤をベースカラーにしているサイトの文字を同じように赤くしたら他の要素と同化してプライオリティが下がって見えてしまい、結果的に数値が下がる事も考えられます。
別の例を挙げます。
赤い色というのは「膨張色」と呼ばれ、色が広がって見えるので、強調のデザイン手法としては効果的と言えるでしょう。しかし、サイコロジー（心理学）の視点で考えると、黄色は警告色、赤は危険色となり、ネガティブな印象を与えてしまう色であるとも言えます。
実際に私が携わった改善事例の中でも、医療関係のサービスで「血」を連想させる赤いボタンを使うと数値が下がるというものがありました。
膨張色であることのメリットより、サイコロジーの与える印象の方がネガティブな結果を招いた事例です。
UI変更により数値が大きく変動する場合は、説明可能な因果関係が存在します。
無意識にユーザーを誘導してしまう「ボタン」などのカラーリングはとても重要な意味を持つので、この配色の変化がマイナスに働く事もあります。
このように、他のプロダクトやサービスの成功事例を「結果」のみにフォーカスして、そのまま別のUIやデザインに当てはめる事はサービスをミスリードしてしまう危険性があります。
効果の出るUI施策は限られてきますが、効果のないUI施策をやろうとしたら無限にやれてしまうので注意が必要になります。
UI施策の見えないリスク
明確な課題や仮説のない状況下でUI変更を行ってしまう背景のひとつに、UI改善がローリスク・ローコストで行える施策だと感じていらっしゃる方が多いように感じます。
確かに使いにくいUIはユーザーをミスリードしたり、機会損失を招く恐れがあります。
しかし一方で、既に問題なく使えるUIに対し、不用意に変更を加えようとすると目では見えにくいリスクに足元をすくわれることがあります。
私たちのデザインチームはそれを「ユーザーの信用残高の損失」と表現しています。
リスクなくPDCAを回しているつもりでも、背面化では「ユーザーの信用残高」を棄損している場合があります。
少し例を挙げてみますので、利用者の立場になって考えてみてください。
「やってみないと分からない」程度の理由でUIを変化していくとどうなるのか。
突然、日ごろ使っていた
・押戸が引き戸になっていたらどうでしょうか？
・エレベーターの登りと下りが変わっていたらどうでしょうか？
・信号の配色の意味が変わっていたらどうでしょうか？
・リモコンのボタンの配置が日替わりで変わっていくとどうでしょうか？
ちょっとしたUIの変更が、サービスを利用するユーザーの利便性を悪化させることは大いにあり得るのです。
そしてそれに「振り回された」と感じたユーザーはよほどの事がない限りはもう2度とそのプロダクトやサービスは使わないことでしょう。
目に見えるものだからこそ、また、ユーザーとサービスを繋ぐ接点になっているインターフェイスだからこそ、UIやデザインで変化する因果関係を正確に理解して、施策を最適化していかないといけません。
ユーザーの信用を失わないために
個人的にはUI改善を行う際は「ユーザー体験のどの部分をUIで解決したいのか」という目的と課題が明確化されている状態で行うべきだと考えています。
目的が明確になっていれば、「やってみないとわからないから」「他社でやってるから」という曖昧な理由での施策を減らせるかと思います。
効果のないUI施策の数を減らすことは、日々使ってくれてるユーザーの負担を減らすことに繋がります。
ユーザーの負担を減らすことはUX（顧客体験）の価値を高めてくれます。
UI施策を行う際は、「許容限界値（どこまでのテストなら許されるのかの限界値）」を設定してみることをお勧めします。
どこまでの変更ならユーザーを迷わせないのか、どこまでの改善ならユーザーに許容されるのかを定めて、その範囲で改善を行ってみてください。
あくまでもサービスを使っているのはユーザーの皆様です。
そして、多くのWEBサービスにおいてはお客様なはずです。お客様はテスターではありません。
お客様の貴重な時間や労力を使ってUIの実験をするのはなるべく避けましょう。どうしてもデータが欲しい場合は十分な検証ができるまで、社内で検証するか、テスト部分をアウトソーシングするなどの方法をまずは検討してみてください。
リリース前のサービスであれば、Betaなどを付けてデータ取得のためにUIの実験をしていることをきちんと伝えるのも良いかと思います。
UI施策の数値を追うがあまりサービスを利用してくださっている「ファン」の心を離さないように注意しましょう。
以上となります。
文頭にもございますが、本ノートは社内向けに作成したドキュメントをベースにしております。文中には指示語や断定的な表現が多く含まれますが、その点ご理解とご了承ください。本内容が少しでも皆様のお役に立てれば光栄です。