1. ホーム
  2. Alertbox

UXの活動を報告するのはやめ、ビジネス成果を報告しよう

UXチームは経営陣に、活動内容やUX指標ではなく、ビジネス成果を報告すべきである。それは、収益やコスト、リスク、スピード、リテンションへの影響を示し、必要なリソースを確保するためである。

UXチームが予算協議で不利になる理由が、その業務に価値がないから、ということはほとんどない。原因はその業務の報告のやり方にある。ユーザビリティテストから得たデータやユーザーの発言は根拠のある妥当なものである。しかし、そのデータや発言は調査が企業の業績にどう影響するのかを経営幹部に説明するものではない。同じ企業内で2種類の言語が使われているのである。UXチームは適切なほうの言語を使うようにする必要がある。

この問題は、企業が自らの投資の成果を測って評価する厳格な測定文化を構築するにつれて、より深刻になっている。自分たちの業務をビジネス成果に結びつけられないUXチームは、個々の予算協議で不利になるだけでなく、コストセンターに分類され、それに応じてリソースを削減される。

UXチームをコストセンターに見せてしまう2つの間違い

コストセンターとは、目に見えるリターンを生み出さないのにお金がかかる部門のことである。リソースの確保に苦労しているチームが繰り返しやってしまう報告のパターンは次の2つである。

間違い1：影響ではなく、実施した作業を報告する

「今四半期には24件のユーザーインタビューを実施し、3件のユーザビリティ調査を行いました。」

この報告は、経営陣にチームが何を行ったのかは伝えるが、その結果、何が変わったかについての情報は何も伝えていない。実施した作業についてのみ報告すると、成果がなかったように見える。その結果、経営陣には、リソースを費やしているのに、それに見合う成果として示せるものが何もないように見えてしまう。

間違い2：ビジネス指標ではなくUX指標を報告する

「SUSの平均スコアが62から74に向上しました。」

これは、経営陣が追跡していない（そして、おそらく理解もしていない）指標が改善したことの説明である。CFO（最高財務責任者）は、SUSスコアが何を意味するのか、あるいは74という数値が良いのかどうかを判断する基準を持ち合わせていないし、オペレーション部門の責任者も、タスク完了率を自らが責任を負う四半期目標と結びつけることはできない。こうした指標は調査報告書に記載するものであって、予算協議で持ち出すようなものではない。

マッキンゼーの調査によると、デザインチームのアウトプットを客観的に評価できる企業は半数にも満たない。UXチームがビジネスで用いられる言語で報告できなければ、経営陣は直感に頼るか、そうした報告ができる他のチームを頼ることになるということだ。

経営陣は投資を実際にどのように評価しているのか

UXの影響をビジネスの言語に結びつけるには、経営陣が投資を評価するときに用いる5つの問いを理解するとよい。

1.   収益に影響を与えるか

質の低いUXは、収益を押し下げることがある。決済フローやユーザー登録ファネル、機能利用時における摩擦は、ユーザーの離脱を引き起こすことがあり、UXデザインに関する決定がその直接的な原因といえる。UXの改善を収益と結びつけるのが難しいことは多々あるが、変更の対象範囲を明確にして追跡することで、収益とのつながりをたどれるようになる。

2.   コストを削減できるか

サポートへの問い合わせには、その1件ごとにコストが発生する。インタフェースがわかりにくかったり、エラー表示がわかりにくかったり、オンボーディングに問題があったりすると、ユーザーは助けを求めて電話やメールをしてくるが、UXでその根本的な原因を解決できれば、オペレーションチームが「失敗需要」と呼ぶもの、つまりプロダクトがユーザーの期待に応えられなかったがために発生する問い合わせを減らすことができる。特定のフローについてデザイン変更前後の問い合わせ件数を比較したデータは、リソースに関する協議でUXチームが提示できる最も説得力のある根拠の1つである。

また、手戻りも、UX業務によって大幅に削減可能なコストといえる。デザイン中に見つかった問題はFigmaのようなツール上で修正できるが、問題が発見されないまま開発プロセスの後工程に進めば進むほど、その修正にかかるコストは高くなる。

3.   リスクを軽減できるか

取り逃がした取引、誤ったフォームの送信、誤解される指示といったデザインに起因するエラーは、のちのち法務やサポート、コンプライアンス、財務面でリスクを生じさせる可能性がある。リリース前にこうした故障モードを明らかにする調査は、リスクを軽減する。実ユーザーによるテストを一度も行わなかったプロダクトが引き起こすコンプライアンス違反や製品リコール、公になった重大なトラブルによって生じるコストに比べれば、ユーザビリティ調査のコストは微々たるものだ。

4.   市場投入までの期間を短縮できるか

ユーザビリティ問題は、デザイン中に見つかればすぐに修正することができる。一方、問題が開発後に見つかると、エンジニアリングの時間やQAサイクル、場合によっては全面的なデザイン変更が必要になり、その結果、リリース日が後ろ倒しになり、スプリントの開発余力が消費される。特定のプロジェクトで、UXが早い段階から関与したことによって、緊急パッチやデザイン変更など、リリース後の修正が減ったということを示せれば、UXはプロダクトの市場投入を遅らせるのではなく、早めるのだということを証明できる。

間違ったものを作ることには、機会費用というリスクもある。チームが間違った解決策に時間を費やしている間に、競合他社は正しい解決策を開発し、優位に立つかもしれない。

5.   リテンションや満足度を向上させるか

プロダクトがユーザーの期待どおりに機能しない場合、あるいは、価値を生み出す機能が探しにくいと、ユーザーはそのプロダクトの利用をやめてしまう。しかし、UXによってオンボーディングが改善され、ユーザーがより早く最初の成果を得られるようになったり、それまでは見逃されていた有用な機能に気づけるようになったりすると、ユーザーがそのプロダクトを利用しつづける可能性が高まる。

リテンションを測定するには、ある週に利用を開始したユーザーのうち、7日後または30日後にもまだアクティブであるユーザーの割合を追跡し、オンボーディングの変更前と後でユーザー群を比較する。ロイヤルティと満足度については、CSATやNPSのような一般的な指標を追跡すればよい。

UX指標を経営陣が重視することに結びつける

両者の違いは、つまるところ、一連の過程のどこを測定しているかにある。

上流の指標は、デザインがどの程度うまく機能したかを示す。例としては、タスク成功率、エラー率、SUSスコアなどである。

下流の指標は、その結果、ビジネスにどのような変化が生じたかを表す。例としては、サポートへの問い合わせ件数、コンバージョン率、離脱などである。

下流の指標は、そのUX業務にどのような価値があったかを伝えてくれる。すでに収集している指標を捨てる必要はないが、それらの指標と経営陣が追跡している指標との間に橋をしっかりとかける必要がある。以下の表は、一般的な上流の指標と、それに最も直接的に結びつくビジネス上の優先事項との対応を示し、指標ごとにその説明方法を提案したものである。

指標ビジネス上の優先事項説明のやり方
タスク成功率収益ユーザーがタスクを完了できないとサポートへの問い合わせが発生する。決済やユーザー登録における摩擦は収益を押し下げる。
エラー率コスト削減デザインに起因するエラーは、返金、再処理のコスト、コンプライアンス上のリスクを生じさせる。
SUSスコアリスク軽減間違ったものを作ることや体験に起因するエラーは、財務上のリスクや機会費用を生じさせる。
リリース後の修正市場投入までの期間短縮UXチームが早い段階から関与すれば、手戻りの回数や緊急パッチの数が減る。
初回利用完了リテンションオンボーディングを完了しないユーザーは早い段階で離脱する。
CSAT満足度満足度は、契約更新や利用拡大を予測する。

必要なデータは、すでに企業内に存在している。財務やプロダクトアナリティクス、カスタマーサポート、マーケティングの各部門と連携して、彼らが何を追跡しているのかを把握し、デザインを変更したフローの変更前後のデータにアクセスできるようにしよう。変化の方向だけを示すデータでも、「ナビゲーション変更後の四半期には、［機能］に関する問い合わせが30％減少した」のように、誇張せず事実を伝えるものであれば説得力がある。

実務上の注意点として、UXからビジネスの言語への翻訳が可能なのは、下流のデータにアクセスできる場合に限られる。現在、チームがプロダクトアナリティクスやカスタマーサポート、財務レポートから得られるデータにアクセスできていないなら、まずそこについて話し合う必要がある。

目的は、UXがもたらす成果を誇張することではない。チームが行うUX業務と、企業が追跡する数値との間にすでにあるつながりを明らかにすることである。

結論

企業は、いまやあらゆる部門で測定文化の構築を進めている。UXは、常に、ビジネス上の重要な指標よりも上流に位置してきた。つまり、ユーザーがそのデザインを使って重要なタスクを実行するのに苦労すると、サポートチケットが発生し、コンバージョンの機会が失われ、場合によっては顧客を失うことになる。UXチームは常に重要な数値に影響を与えてきたのだ。今こそ、その貢献を自分たちの実績として示すべきときである。

記事で述べられている意見・見解は執筆者等のものであり、株式会社イードの公式な立場・方針を示すものではありません。

キーワード