ユーザーエクスペリエンスチームのための実験
A/B テスト、つまり実験を行っているか気になりますか?
はい、私たちはアプリで実験を行っています! ほとんどの実験は Growth チームが SaaS プロダクトで実施し、その大半は登録、トライアル、購入フローに対して行われます。私たちはまた、ステージグループと協力して、機能の可視性、使いやすさ、学習しやすさを高める実験も行っています。これらの実験は、最終的には収益に結びつく KPI の改善を目指しています。たとえば、プロダクトとのエンゲージメントを高めること、顧客が機能を使用したりアカウントをアップグレードしたりする速度を高めること、ネームスペースで使用されるステージ数を増やすことなどです。
実験とは?
実験は、特定の目標に対するデジタルプロダクトの改善を検証・測定する方法です。基本的に、プロダクトで何かを変更すればユーザーが反応し、私たちが影響を与えたいメトリクスがそれによって変化するというアイデアを持っています。実験は、ユーザー数が多く、良いベースラインプロダクトがある場合にうまく機能します（実験が良いアイデアではないのはいつ? セクションを参照）。
GitLab で使う用語
実験と UX について話すときの語彙は少し異なるため、いくつか重要な用語と GitLab での使い方を以下に示します。
- 実験 (Experiment): 通常、A/B または多変量テストを指します。
- 仮説 (Hypothesis): 通常、実験の結果として何が変わると考えるかについての一文の声明です。例: 「サインアップフォームのミドルネームフィールドは妨げになっていると考えています。これを検証するため、サインアップフォームからミドルネームフィールドを削除し、サインアップ率の増加を観察することで測定します。この実験は、サインアップが 20% 以上増加したら成功と呼びます。」
- バリアント/コントロール (Variant/Control): コントロールは「現在の」ユーザーエクスペリエンスです。バリアントは「提案されたデザイン」です。
- 成功メトリクス (Success metric): 実験のスコープ内で、ユーザーが望ましいアクションを取った瞬間を示します。たとえば、UI に追加された新しいボタンを含むバリアントを目にしたすべてのユーザーのうち、そのボタンをクリックしたのが何人か、などです。
- アダプション (Adoption): これは、ユーザー（またはアカウント）が私たちのプロダクトと関係を確立する方法に関するものです。コンバージョンを超えた、習慣がどのように形成されるかに関するものです。たとえば、誰かがマージリクエストを 1 つマージしただけでは、その機能を採用したことにはなりません。しかし、ユーザーがマージリクエストを作成し、レビューするチームメンバーを追加するようになると、プロダクトを使い続ける可能性が高くなるかもしれません。その知見が私たちのアダプションメトリクスに反映されます。
- エクスパンション (Expansion): これはアカウントがどのように成長するかに関するものです。アクティベーションの後にあります。ユーザーがアクティベートされたとみなされたら、より多くの機能を使ったり、より高い tier にレベルアップしたり、サブスクリプションにユーザーを追加したりする可能性を最も高めるものは何でしょうか?
- リテンション (Retention): 一定期間内にどれだけのユーザー（またはアカウント）がアクティブでいるかを指します。たとえば、Day 0 に 100 個の新しいネームスペースが作成された場合、1 か月後、3 か月後、6 か月後にどれだけがまだアクティブでしょうか?
- AHA モーメント (AHA Moment): プロダクト内で、ユーザーが理解する瞬間（または複数の瞬間）です! プロダクトの価値と、それが自分にどう役立つかをまさに理解する瞬間です。GitLab における AHA モーメントの例は、パイプラインが初めて成功したときでしょう。
- 統計的有意性 (Statistical significance): 統計学の授業を思い出すかもしれませんが、これは結果にどれだけ自信があるかを示す方法です。実験が成功して有意性に達したと言う場合、私たちが行った変更によって実験が成功したのであって、他の理由ではないと自信を持っているという意味です。実験が有意性に達しなかったと言う場合、おそらく測定された影響が非常に小さかったか、影響がまったくなかったか、実験グループに十分なユーザーがいなかったということです。
- 有意性に達するまでの時間 (Time to significance): 結果に有意性/信頼性を持たせるのにかかる時間です。これは、コントロールとバリアントを目にするユーザー数の関数です。これは数日から数週間に及ぶ可能性があります。実験対象のエリアがどれだけのトラフィックを得るかによって異なります。
Growth セクションには、コンバージョン、アクティベーション、エクスパンション、アダプションに関連するグループがあります。これらのグループが取り組んでいることは、上記の定義に関連しますが、まったく同じではありません。
実験はいつ・なぜ使うべきか?
プロダクトの変更の影響を定量化する必要がある場合（例: クリック率、コンバージョン率、その他のメトリクス）、またはソリューションを検証する必要がある場合に、実験を使用してください。
実験が良いアイデアではないのはいつ?
プロダクトに変更を加えてそのままロールアウトする方が望ましい状況がいくつかあります。次のような場合です:
- 変更が正しいもので大きなユーザビリティの改善になると非常に自信がある場合。すべてのユーザーがすぐに改善の恩恵を受けられるようにするためにこれを行います。これらの変更は小さくても大きくてもかまいません。アイコンのみのボタンにラベルを追加することから、数ページに及ぶフローの修正まで、さまざまです。
- 「大きな賭け（big bet）」の場合。これは、サインアップフローの再設計など、全体的なベストプラクティスに沿った大きな変更で、データに基づき、ユーザーテストやその他の UX リサーチ手法など、他の形態のソリューション検証を実施した場合です。
- 当たり前に思えるかもしれませんが、バグの修正方法を決めるために実験を使うことはしません。
- 有意性に達するまでに長時間かかり、収益への影響が不確実/低い、かつ/またはユーザーへの影響が非常に高い/確実な場合。この場合、変更を実施するか、実験を却下できます。Growth グループは、実験の優先順位付けに ICE フレームワーク を使用しています。
- ベースライン体験が貧弱で、ヒューリスティックスコアリング で B- 以下の場合。この場合、実験に進む前にまず体験の初期改善を要求します。
実験のためにどうデザインするか?
Growth でのプロダクトデザインプロセスの多くは引き続き馴染みがありますが、いくつかの違いがあります。理解し従うべき考慮事項と概念もあります。
- 実験の場合、ユーザーストーリーや JTBD ではなく、実験の記述（write-up）（リンクを追加）から作業します。ただし、私たちが実験している機能の JTBD には引き続き精通している必要があります。
- デザインを始める前に、よく書かれた実験を常に用意したいです。最低限必要なのは、仮説、ビジネス問題、サポートデータがあるか、期待される結果は何かです。始めるのに役立つよう、Experiment Idea Issue テンプレート を使ってください。
- ノーススターメトリクスとユーザーエクスペリエンスのビジョンの組み合わせが、すべてではないにしてもほとんどの実験を駆動するものであるべきです。そこに到達するには、デザイナーはプロダクトマネージャーと協力して UX 戦略を確立する必要があります。そのような UX 戦略の例は こちら と こちら で確認できます。
実験はユーザーリサーチに取って代わるか?
いいえ、取って代わりません。これは、実験は 何 が起こっているかを教えてくれるのに対し、ユーザーリサーチは なぜ 何かが起こっているかを教えてくれるためです。私たちは Growth で問題検証とソリューション検証の両方のリサーチを行っています。たとえば、次のようなことを問うかもしれません:
- 問題検証では、ユーザーがトライアル中に何を学ぼうとしているかを理解したいかもしれません。この種のリサーチからの洞察は、UX 改善と実験のアイデアの両方に反映できます。
- ソリューション検証では、大きな賭けに対してユーザビリティスタディを実行するかもしれません。また、四半期ごとに主要なフローでユーザビリティスタディを実行し、リリースした実験について定性的なフィードバックを得ています。
- 場合によっては実験が決定的でなかったり、期待と一致せず驚かされたりすることがあります。これが起こると、「なぜ」を見つけるためにユーザーリサーチを行います。
良い実験は良い仮説から始まる
- 良い仮説とは、真偽を簡単に検証できる声明です。
- 仮説声明を書くためのテンプレート: 私たちは テストする変更を挿入 が 望ましい結果を挿入 につながると信じています。 メトリクスのターゲット変化を挿入 を見たときに、これが真であるとわかります。
- 良い仮説声明の例: プロジェクト作成ページに SAST スキャンを有効にするチェックボックスを追加することで、Secure ステージのユーザーアダプションが高まると信じています。Secure のアダプションが 5% 増加するのを見たときに、これが真であるとわかります。
- 仮説は重要なことを検証します。ユーザーが気にせず、会社が気にしないなら、検証する価値のあるものではありません。
- 仮説は 1 つのことを検証するべきです。「X と Y が真であると考える」や「X が X と Y につながると考える」のようなことは避けてください。
- 実験が複数のメトリクスに影響を与えると予想する場合は、実験の記述（write-up）で事前にすべてをリストアップしてください。 最初のメトリクスに加えて trailing メトリクスにも影響を与えたい場合は、実験の記述（write-up）でそれを非常に明確にしてください。
- データを収集した後、良い仮説を書いていれば、それを結論として再述できるはずです。例:
- 仮説: ページにコアラの画像を追加するとクリックが 10% 増加すると考える。
- 結論: ページにコアラの画像を追加した結果、97% の有意性でクリックが 12.4% 増加した。
正しいメトリクスを選ぶ
TBD
注意すべきこと
実験はプロダクトを改善する素晴らしい方法です。ただし、考慮事項が多いため、目標と制約をよく考えてそれが正しいアプローチか確認してください。
- 実験を開始すると、単に変更を導入する場合に比べて遅延が生じる可能性があります。これらの遅延は、実験を開始するための追加のエンジニアリング作業、統計的有意性に達するまでの時間の延長、Growth 外のチームでの実験経験の不足などによって生じる可能性があります。
- まだ実験を行ったことがないチームの場合、Growth にガイダンスを求めてください。プロダクトデザイナー に連絡することが最初のステップです。プロダクトデザイナーが直接助けてくれるか、データ分析、実験開始の技術的課題、結果の誤解の回避、実験が一度に多くのことをテストしすぎないようにする支援ができる人につないでくれます。
- 実験についてある程度の経験があるチームの場合でも、Growth に確認し、現在進行中の競合する実験がないかチェックしてください。
- 実験したいエリアがどれだけのトラフィックを得るかを考慮してください。低いですか? 実験を完全に避けてください。中程度ですか? 統計的に有意な結果に達するまで時間がかかる可能性があることを認識してください。
リソース
実験のアイデアはありますか?
Growth のプロダクトデザイナー の 1 人に連絡するか、専用のテンプレート で Issue を開いてください。
bfd74782)