データがわかるデザイナーになる
アーロン・ギトリン Aaron Gitlin
グーグルのインタラクションデザイナー
今回は、「データがわかるデザイナー」になるためには何が必要かというテーマについて、グーグルのインタラクション・デザイナーのアーロン・ギトリン氏によるMediumの記事をご紹介いたします。
Becoming a data-aware designer
How to integrate data thinking and A/B testing methodologies into your design process
ペーパーレス・ポストで、私はリサーチと実験によるサイトの改善を専門とするチームと一緒に働く機会があり、その過程で、私は定量的分析、特にA/Bテストの言語とプロセスに精通するようになりました。その知識により、サービスを測定可能な形で改善することに関心を持つ組織と仕事をする際に必要な能力が、大幅に向上しました。デザイナーの皆さんが、どのようにしてデータと実験をプロセスに組み込むことができるか、その参考になればと、私の最近の経験を書いてみました。
・・・
多くのデザイナーがそうであるように、これまでの私の主な情報収集方法は、ヒューリスティック分析や競合分析、インタビュー、ユーザビリティテストなどの定性的なものでした。ペーパーレス・ポストのチームのおかげで、そのレパートリーが増え、デザインプロセスの重要な部分として、データをより流暢に使えるようになりました。また、ロシェル・キング、エリザベス・チャーチル、ケイトリン・タンが執筆した『Designing with Data』という本が、このテーマの実践と用語の基礎を与えてくれました。この記事でも、この本の内容を参考にしています。
私は最初は、データ部門やマーケティング部門が説明するプロセスに懐疑的でした。比較的小さな微調整のために延々とA/Bテストを繰り返すことは、ユーザーの体験を向上させるためには、最も退屈で効果のない方法のように思えました。キングらのおかげで、私はようやく、データドリブンデザインに対する懸念を理解して、明確に表現できるようになり、それをデータインフォームドデザインやデータアウェアデザインと対比させることができました。
データドリブン（データ駆動）とは、一本の細い経路に集中し、その途中で純粋な最適化と効率化に注力することです。例えば、パフォーマンスの向上や青の色調のテストなどがこれに該当します。
データインフォムド（データに精通している）であるということは、必ずしも一本の細い経路ではなく、経験や本能など、定量的なデータ以外のインプットに基づいて作業を行うことを意味します。異なる体験のA/Bテストや、構造化されたユーザビリティテストがこのカテゴリーに入るかもしれません。
データアウェア（データがわかる）であるということは、データ収集の範囲の広さや限界を理解し、問題ごとにどの方法が最適かを判断することです。データアウェアなチームは、ステークホルダー・ワークショップ、一連のユーザーインタビュー、A/Bテストの統計的に有意な結果に基づいて意思決定を行うことに、同じ価値を見出すかもしれません。
では、なぜこのようなことが重要なのでしょうか？
多くの企業がデータドリブンであることをアピールしていますが、たいていのデザイナーは、直感、コラボレーション、そして定性的なリサーチ手法を重視しています。それでは、私たちはどこに当てはまるのでしょうか？
私はやはり、デザイナーの最大の強みは、直感と、理論から実践に移す意欲だと考えています。データは、問題が何であるか、どうすれば解決できるかを教えてくれるわけではありませんが、その一方で、データは、問題を明らかにし、その情報を提供し、解決策の効果を評価するのに役立ちます。デザイナーはこの追加の情報を使って、より多くの角度から問題を評価し、その結果をもとに、問題解決のための直感を研ぎ澄ますことができるのです。
私が特に気に入ったのは、『Designing with Data』に掲載されているこの言葉です。データの価値と、人の直感と意思決定との統合の重要性を説いています。
私たちが発見したことの一つは、測定項目の数を増やしたり、測定の精度を高めたりしても、実際には確実性につながらないことが多いということです。これがあれよりも優れている、というような明確な結果にはなりません。ただ、実際にはもっと多くのものが関係しているという、より深い複雑性が見えてきます。そうなると、本当にバランスが必要になります。私たちはまだ直感を持っていなければなりません。何が重要で、何が重要でないかを判断しなければならないのです。
ジョン・ワイリー（グーグルのイマーシブ・デザイン・ディレクター）
上の３つの円の図に話を戻しますが、私はデザイナーはデータアウェアな問題解決のアプローチを守ることが重要だと考えます。データインフォームドなチームの一員として生産性を高めることができれば、デザイナーは組織の中で尊敬されるビジネスパートナーになることができます。私たちは完全にデータドリブンである必要はないかもしれませんが、さまざまなデータ収集方法を流暢に話せたら、誰もが話を聞いて答えられるようなコミュニケーションができます。
キングらは、データアウェアな考え方で実験を行うためのフレームワークを紹介していて、私もそれを自分の仕事を整理するのに役立てています。ここでいうデータとは、質的・量的を問わず、あらゆる情報を意味することを忘れないでください。真に客観的であるべきなのは、あくまでも結果なのです。
1 - 目標
目標を設定することは、この記事の範囲外ではありますが、超具体的である必要はありません。例えば、私のチームの目標の一つは、新しい大きな機能群に頼らずに収益を上げることでした。大まかですが、それでも実際の測定基準と明確なビジネス価値を持つ目標です。もちろん、このような目標は、倫理観と誠実なデザインの実践という基準で調整する必要がありますが、それについてはまた別の機会にお話ししたいと思います。
2 - 問題／機会の領域
目標を達成するために、努力できる領域はたくさんあるでしょう。しかし、どこかから始めなければなりません。選択肢を絞るためには、どのような情報が必要でしょうか。ユーザーがファネルのどこでドロップアウトするかに関するデータはありますか？ 「パワーユーザー」がサイトをどう使っているかはわかりますか？ タグ付けされたカスタマーサポートチケットは？ アンケート調査は？ ユーザーリサーチは？
理想的なのは、これらすべてを組み合わせたものですが、まだ他にも、HBRのような伝統的な情報源から、もっとデザインの専門家を対象としたIDEOのワークショップのアウトラインや、今では一般的になったグーグル・デザインスプリント・ツールキットのアクティビティのようなものまで、注力すべき分野を見つけるためのリソースは無数にあります。
ペーパーレス・ポストで、私のチームは、価格設定がお客様のチェックアウトの妨げになっていることを示す定性的な情報（カスタマーサポートチケット、逸話的ストーリー、個人的な直感）と、定量的な情報（大量のアンケート、コンバージョンのドロップオフポイント）の両方を入手しました。そこで私たちは、会社の収益を増加させることを目標にして、価格設定メカニズムでのユーザーエクスペリエンスの向上について、問題／機会の領域を定義しました。
3 -仮説
解決すべき問題について大まかな合意が得られたら、今度は検証可能な解決策、つまり「仮説」を立てることになります。
データアウェアの考え方を持つ上で、最も根本的で難しいことの一つは、優れた仮説を立てることです。私たちは「このインタラクションはより良いユーザー体験になるだろう」とか「このレイアウトでユーザーはより自信を持てるようになるだろう」とは言えません。これらは良い仮説ではありません。評価されるべき明確な指標がなく、測定可能な結果への明確な道筋がありません。仮説には、以下の項目を明確に記載する必要があります。
評価の対象となるユーザーセグメント【ユーザーグループ】
私たちが起こしている変化【変化】
どのような結果になると考えているか【効果】
なぜそのような結果になると考えるのか【根拠】
そして最後に、私たちが観察することを期待している測定可能な結果 【測定】
キングらは、以下のようなフォーマットを提案しています。
【ユーザーグループ】にとって、もし【変化】があれば、【根拠】なので【効果】があり、それは【測定】に影響する。
For [user group(s)], if [change] then [effect] because [rationale], which will impact [measure].
しかし、どんなに優れた仮説であっても、単独で作るべきではありません。
それは、以下のことを考慮に入れた、より大きな戦略の一部でなければなりません。
失敗した場合に何を学び、それをどのように将来の思考に適用するか
成功した場合に何を学び、それが次のステップにどう影響するか
このテストにどれだけの労力をかける価値があるか
最後のポイントは、重要かつ複雑なものです。私たちが解決しようとしている問題はどれくらい大きいのでしょうか。考えられる限りの最高のチェックアウト体験でしょうか？ 今あるものよりもをより良くしたものでしょうか？ この二つのアプローチの意味合いを理解することが重要です。
例えば、私のチームは、インフラの複雑さから、短期的には価格モデルを根本的に変えることはできないと分かっていました。基本的には、既存のシステムを変更して改善することを考えており、システムそのものを変えることは考えていませんでした。下の図は、この二つの選択肢の違いを視覚的に表したものです。
既存のシステムの改善を試みることは、ローカルマキシマムに対してデザインすることである
より良いシステムを求めることは、グローバルマキシマムに対してデザインすることである
ローカルマキシマムばかりを追求しないように気をつけることはもちろんですが、何よりも大切なのは、自分たちが今どこにいて、何に時間を使うのが最善かを、チームが認識することです。
仮説の選び方
では、どのような情報をもとに仮説を選べばよいのでしょうか。私の経験では、最高のアイデアは複数の情報源から得られるものです。例えば、マーケティング調査であったり、社内ワークショップであったり、大量のアンケート、カスタマーサポートへの要望、過去のA/Bテストの結果、あるいはこれらすべてかもしれません。キングらは、これを「データの三角測量」と呼んでいます。それは、新しい仮説やアプローチを形成するために、異なる情報源を構造的に利用することです。
私は、シンプソンズの食物連鎖のピラミッドを思い出さずにはいられません。シンプルに、真ん中の人を「アイデア」に、動物の王国を「さまざまなデータポイント」に置き換えるだけです。
4 -実験
実験、あるいはテストは、アイデアを検証するだけでなく、将来のデザイン決定のための情報を得る機会でもあります。時には、情報を得ることだけがテストの目的だと判断することもあるでしょう。このような探索的テストは、必ずしもすべてのユーザーに提供することを目的としているわけではなく、特定のタイプの行動について、より多くの知見を得ることを目的としています。評価的テストは、特定のソリューションを検証するためのもので、一つのバージョンを全てのユーザーに展開することを目的としています。
いずれにしても、以下のような実験を行うことが重要です。
可能な限り変数をコントロールし、バリエーションの違いを明確にします。バリエーションが曖昧だと、結果も曖昧になってしまいます。
選択肢が仮説を明確に表している。これは言うは易し行うは難しですが、良いアイデアであっても実行が不十分だと、悪いアイデアと同じような結果になる可能性があることを覚えておいてください。ユーザビリティテストにおいて内的妥当性と外的妥当性を押さえることががこの問題の解決に役立ちます。
組織の要求を犠牲にしない。これは組織によって意味が異なるかもしれませんが、多くの場合、ブランド・インテグリティとアクセシビリティを含みます。
テストは意味があり、倫理的である。巨大な「こちらをクリック」ボタンをテストすることは、おそらく意味がありません。隠れた追加料金のテストは倫理的ではありません。
統計学のベストプラクティスの基本的な概要については『Designing with Data』を読むことをお勧めしますが、他にも素晴らしいリソースがたくさんあります。「スタックオーバーフロー」のABテストプロセスに関するこの記事も、一般的なまとめとして参考になりますし、「アナリティクス・ツールキット」の統計的有意性に関する詳細なレビューを読めば、さらに深く掘り下げることができます。世の中の多くの情報はかなり技術的ですが、たとえ数学に疎いデザイナーでも、統計的有意性の要件が高くなるほど結果の潜在的な妥当性は高まるが、より厳密な収集が必要になるということを理解すべきです。結果をより確かなものにするためには、より多くのインタラクションを長期間にわたって記録しなければならないでしょう。
もちろん、結果に確信を持ちたいのは当然ですし、そうでなければ意味がありません。しかし、製品を有意義に改善するために十分な速さで進まなければ、私たちは何のために仕事をしているのでしょうか。チームや組織が協力して、テストにどれだけのリスクと厳密さを持たせるかを理解することが大切です。自分たちのベースラインが何であるかを把握することは、それぞれのチームにかかっています。
こちらの記事では、サンプルサイズの計算例を紹介しています。また、下のスクリーンショットは、自分でサンプルサイズを決めたり、勝敗シナリオを実験したりするのに役立つオンラインツールです。
ペーパーレス・ポストでは、まずp値を0.05としました。これは、偽陽性の可能性は5%だけだと考えたからです。この基準値をもとに、統計的に有意な結果を得るために、どれだけのユーザーインタラクションを記録する必要があるかを計算できました。必要な数を得るために2～4週間以上のテストが必要だと思われる場合は、より早く結果が得られるような仮説を再検討することになるでしょう。
いくつかの例
ここでは、私たちがペーパーレス・ポストで、どのように計画し、テストを行い、結果を分析したかについて、いくつかの例を紹介します。ここまでを振り返ると、私たちはすでに以下のことを確認しました。
目標：既存の機能を利用してサイトの収益を上げる
問題／機会の領域：価格モデルと、それをお客様にどのようにうまく伝えるか
これが次のステップにつながります...
仮説を立てる
コインとは、ペーパーレス・ポストが使用する仮想通貨です。例えば、招待状の料金は1枚につき1コインなので、25枚の招待状を受け取った場合、25コインを支払います。そして、お客様には20／40／80／150コインといったコインパッケージを買っていただいて、たくさん購入するほど価値が上がる仕組みになっています。これはわかりにくいですよね。
何人かのチームメイトと私は、自分たちで何度か調査をした後、チーム全体でミーティングを行い、結果を集めて照合しました。膨大な数のアイデアが出ましたが、その中でいくつか可能性を強く感じたものがありました。
価格帯の数を減らす
コインを購入するためのより多くの選択肢を提供する
「コイン」の概念を実際のドルに置き換える
コインの仕組みをファネルの早い段階で説明する
ここでは、ローカルマキシマム（現在のシステムの改善）を追求しているのであって、グローバルマキシマム（より良いシステムの発見）を追求しているわけではないことを忘れないでください。そのため、上記の選択肢のいくつかは除外されてしまいましたが、それでも十分なアイデアがありました。そこで考えたのが、上記2つ目の「コインを購入するための選択肢を増やす」というアイデアです。そこで、次のような仮説を立てました。
送信するつもりのユーザーは、一度に多くのコインを購入することに価値を感じ、より大きなコインパッケージを購入する。その結果、平均注文額が増加し、コンバージョンはほとんど変化せず、全体的な収益が増加することになる。
そして、その結果は以下のようになりました。
左はコントロール、右がテストバリエーション。一部の色やフォントを変更することは、技術的には実験に交絡変数を導入することになるが、リスクは低いと判断した。
結果
そして結果はどうだったでしょう。予想された結果（テストグループの平均注文額が高くなる）が得られたという意味で、このテストは「勝ち」でした。統計的には有意であったものの、相対的な増加は劇的なものではありませんでした。少数の人々がより高価なパッケージを選択しただけでした。しかし驚くべきことに、このステップから最終的な購入に至るまでのコンバージョンは、はるかに高い割合で増加しました。これは何を意味するのでしょうか。私たちは、ユーザーに選択肢を提示することで、情報を提供すると同時に、最適な価格で購入できることを確信させることができたのだと解釈しています。これは、2日ほどでコーディングして実施したテストから得られた、有意義な情報と結果です。
このテストは、私たちが探索的な考え方でシンプルな実験を行い、定量的な分析で予想される結果と予想外の結果の両方を検証し、さらに定性的な分析でその結果を解釈した、とてもいい事例です。それはまた、「勝ち」や「負け」だけではない実験の価値を示しています。今回の実験の後に考えたフォローアップテストの候補は以下の通りです。
パッケージ間の価値の増加を改善する
特定のパッケージをプロモートまたはデフォルトに設定する
コインを購入すると何が得られるかをより直接的に説明する
テスト戦略
このチームで働く前、A/Bテストの経験が少なかったと述べましたが、ペーパーレス・ポストで厳密なテスト分析やデータ収集に不慣れだったのは、私だけではありませんでした。外から見ると、私たちのチームで、一見関係のない小さなテストがいくつも行われているように見える人もいました。本番稼動したものもあれば、しなかったものもあります。私たちのチームは進歩していると信じていましたが、他の人たちは、ユーザーエクスペリエンスの向上ではなく、ビジョンの欠如と統計に対する過度に独断的なアプローチとして見ていました。
先ほど、最良の仮説は、成功と失敗を繰り返し、その過程で学んだことを記録していく戦略に基づいていると述べました。しかし、社内である程度同意していても、それを他の人と共有する正式な方法がないことに気づきました。スプレッドシートや統計的な分析では、私たちの戦略をより多くの人に効果的に伝えることはできませんでした。
その戦略を伝えるために、私とPMは最終的にこの図を描いて、組織全体を味方につけることができました。
左側のラベルは大まかなテーマであり、最初の列のカードは問題／機会の領域を表しています。それ以外のカードは、その領域内での仮説を表しています。各分野のアイデアは最終的に重なり合い、図の右側に表示されています。それぞれのテストでは次のテストにつながる情報やアイデアを探っているので、詳細は意図的に二段階ほどにしています。右側の最後のカードは、私たちが最善のアプローチだと信じていた先入観を表していますが、そこに一気に飛びつくのではなく、少しずつ学びながら調整していきました。
図のように２つに枝分かれするアプローチをとったのは、製品の価値をアピールしながら、システムの仕組みをより明確に伝えたかったからです。私たちは、美しくデザインされた製品には価値があると信じていますし、お客様にも同じように感じていただきたいと思っています。それを実現したのが、カードの詳細ビュー（多くのEコマース企業では、PDPまたは商品詳細ページと呼ばれることが多い）です。
ビッグアイデア
では、そこでの大きなコンセプトとは何でしょうか。図の中の枝はどこで結合するのでしょうか。
チーム、そして組織として、私たちは、アドオンの表示、可能なカスタマイズ、価格の公開は、すべてお客様にとって価値があると考えました。しかし、三つ以上のコンセプトを一つの大きなプロジェクトに投入するのではなく、それらを分割してテストすることにしました。そうすれば、何が機能し、何が機能しないかを実際に学ぶことができて、私たちの組織とお客様にとって、実際に機能するソリューションを提供することができます。
一つの小さなアイデア
既存のビューは、アイテムのサムネイルリストで構成されていましたが、お客様に興味を持っていただいて、パッケージの中のすべてのデザイン要素の価値を見せるには、もっと良い方法があるかもしれないと考えました。私たちは次のような仮説を立てました。
この新しいビューでカードを選択したユーザーは、パッケージ全体の素晴らしさを実感して、より多くのアドオンを購入するだろう。その結果、平均注文金額が増えて、コンバージョンはほとんど変わらずに、全体的な収益の増加につながるだろう。
そして、私たちが導き出したのがこれです。
平均注文金額は、目を見張るほどではないものの（相対的には数ポイント）、仮説通りに上昇しました。ただし、最初のテストと同様に、コンバージョンが大幅に増加しました。この新しいビューを見たユーザーが、カスタマイズのフローに入り、チェックアウトにまで至る確率が大幅に上がりました。私たちはとりえず、お客様が何にお金を払うかを決定する他の要因があったとしても、フルパッケージを提示することは、製品を検討してもらうための優れたフックになると結論づけました。
メンバー全員が合意したこの大きな夢のデザインは、当初の構想通りには実現しませんでしたが、そこから生まれた数多くのアイデアが実現しました。それがプレゼンスライドやドキュメントの中に使われ、存在感を示すだけで、チームは自分たちのビジョンと統計の両方に自信を持って前進することができました。
要約すると
すべてのプロジェクトとチームは、自分たちに合った方法で仕事を進めることになりますが、誰にとっても役立つと思われるいくつかのステップがあります。
データの三角測量を使って、適切な問題／機会の領域を見つけ、仮説を絞り込む。
測定・検証可能な優れた仮説を書いて、文書化する。
広く伝えることができるテスト戦略を持つ。いくつかのレイヤーに分かれている必要がありますが、多すぎてはいけませんし、定期的に更新される必要があります。
ビッグアイデアと、チームのアイデアのいくつかを表現するビッグデザインを持つ。ポイントは、手分けしてそのデザインを作るのではなく、テスト戦略に視覚的な対比要素を持たせることで、仲間やリーダーとのコミュニケーションに役立てることです。また、デザインするという行為自体が、アイデアを生み出すのに役立つこともよくあります。
少なくとも最初は小さなテストをする。ビッグアイデアはたいてい多くの仮説を含むので、それをテストすると分かりにくい結果になる可能性があります。小さく、より焦点を絞った実験を行うことで、自分のアイデアに対する情報と自信を得ることができ、それがチームの勢いと賛同を得て、より大きなテストを行うことにつながるのです。
・・・
では、どうするか？
経験にもよりますが、多くのデザイナーは、データ分析のために数学的な知識をそこまで深掘りする必要はないでしょう。しかし、今回説明したコンセプトとフレームワークを基本的に理解することで、間違いなく、すべてのデザイナーはその恩恵を受けることになります。そうすることで、直感を研ぎ澄まし、お客様とお客様にサービスを提供しようとしている組織に真に役立つ仕事をすることができるのです。また、現代の組織的リーダーシップの言語を話し、真剣に受け止められるような方法でコミュニケーションをとることができるようになります。
私は、このプロセスに参加できたこと、そしてPMやデータサイエンティスト、数学専攻のデザインインターンが、統計学の考え方を理解する手助けをしてくれたことに感謝しています。今後は、さらに知識を高め、そのことについても書いていけたらと思っています。
本を読んで、質問をお寄せください。また、上記の情報で改善点などあれば、ぜひお知らせください。
この記事は、2018年9月に公開されました。英文はMediumで閲覧できます。
●Becoming a data-aware designer
https://uxdesign.cc/becoming-a-data-aware-designer-1d7614ebc3ed
DMNでは、他にも様々なブログを「DMN Insight Blog」にて配信しております。最新の記事をご覧になられたい方は、ぜひご登録をお願いいたします！
➡️「DMN Insight Blog」メールマガジン登録
◆ DMN事務局 （株）ｍｃｔ
〒150-0001 東京都渋谷区神宮前2-4-11 Daiwa神宮前ビル1F-2F
TEL 070-1470-7231 （お電話受付時間 9:00〜17:30）
e-mail: info@ddmn.jp
DMN Website ddmn.jp