Illustrator iPad 版のベータプログラムの成功を支えた10のレッスン | アドビUX道場 #UXDojo
アドビでは、ベータテストのベストプラクティスを確立するために、何年にもわたり試行錯誤を繰り返してきました。この記事ではIllustrator iPad 版のベータプログラムを成功に導いた10個の主要テーマを紹介します。
Illustrator iPad 版が公開された日のことです。それはあっという間に日米のアプリストアで一位を獲得し、4.6スターの評価をユーザーから得て、いくつもの辛口メディアには好意的なレビューが掲載されました。
この日の成功は偶然ではなく、計画的に準備された結果です。効果的なベータプログラムのお陰で、製品チームはデザインと実装を成功裏に進めることができました。おそらくもっとも重要だったのは、Illustrator の将来のエコシステムをつくり上げるという作業に、ベータプログラムを通じてユーザー自身が関与し、実際に巻き込まれていると感じていたことです。あるベータ参加者は次のように語っています。
「これまで数多くのベータプログラムに参加してきましたが、このコミュニティに参加できて本当によかったです！Illustrator iPad 版を直感的なものにしようと限界まで追求するのは実に楽しい体験でした。このベータに関わったすべての人に感謝の意を表します」
ベータプログラムは、開発中の製品やサービスについてのフィードバックを集め、公開前に改善することが目的です。ひとつ以上の主要なワークフローを最初から最後まで遂行するのに十分な機能が実装されたら開始して、ターゲットユーザーのリアルな体験を理解する手掛かりを集めます。
この数年間、アドビはベータテストのベストプラクティスを確立しようと試行錯誤を重ねてきました。この記事では、Illustrator iPad 版のベータプログラムを成功させるべく使われた10個の主要なテーマを取り上げて、それぞれの詳細とベータテストへの組み込み方を紹介します。
Illustrator iPad 版のベータプログラムのメンバーであるDaveが共有した彼のデザインプロセス。
効果的なベータのための10のステップ
1. 目的を設定する
これは当たり前のように聞こえるでしょうが、チームとして、ベータプログラムの目的に合意することは不可欠です。合意された目的は、より細かな判断をするときの明確な判断基準にもなります。たとえば、誰をプログラムに招待するべきかとか、どんな種類のオンラインイベントを開催すべきかといった判断です。
設定した一番の目的がマーケティングとエンゲージメントだった場合は、デザインや製品戦略を洗練させるためのフィードバックを集めることがより困難になるでしょう。たとえば、マーケティング優先のベータプログラムには、ソーシャルメディアのインフルエンサーが多く参加するかもしれません。彼らがフォロワーに製品を宣伝してくれることを期待するためです。その場合、製品チームとベータ参加者の関係は、参加者を喜ばせる方向に向かいがちです。対応可能なフィードバックを集めるために困難な課題解決のテストをぶつけて、参加者にネガティブな印象を持たれることは躊躇するかもしれません。
また、参加者の関心を買おうとして製品の優れた点を強調することに注力すると、率直で偏りのないフィードバックを得る障害になります。ベータ参加者の声は、アプリが公開されたときのリアルなユーザーの反応とは異なるものになるでしょう。
もしユーザー体験を洗練させるための対応可能なフィードバックを集めることがベータプログラムの目的の場合は、この記事に書かれていることが役に立つでしょう。有効な製品へのフィードバックを収集すれば、チーム全体にメリットがあります。デザイナーであればアプリのUXに関する有益な情報を得られます。エンジニアはバグを見つけてコードの品質を向上させられます。マーケティングは活発なコミュニティを成長させる機会を持てます。製品マネージャーは開発する機能やロードマップをユーザーのニーズに沿うよう調整できます。
Illustrator iPad版のベータプログラムのメンバーであるEdinah Cheweが共有した彼女のデザインプロセス。
2. コミュニティを立ち上げる
ユーザーは自分の声が届いていると感じていたいものです。コミュニティの一人ひとりからの問題報告や質問やリクエストが、製品チーム内のさまざまな役割を持つメンバーに確実に届くようにしましょう。どんなトピックにも、その分野の専門家からの回答があることは重要です。参加者が質問やフィードバックへの真摯な反応を得られなくなれば、彼らはコミュニケーションすること自体を止めてしまうでしょう。イースターエッグのようなちょっとしたギフトを用意したり、魅力のあるデザインチャレンジを開催したり、参加者の役に立つワークショップを開催することで、積極的な参加を促すのは有効です。
チーム体制の観点からは、チームの各部門の代表がユーザーからの質問に答えたり、フィードバックをフォローする責任を持つよう調整するべきです。そうすれば製品チームのだれか一人だけがコミュニティに対する責任を負わなくてすみますし、チーム全体が持つコミュニティを活性化する能力を十分に活用できるでしょう。
コミュニティのプラットフォームを決める際は、ユーザーの日常に存在するコミュニケーションプラットフォームを選ぶようにしましょう。ユーザーが普段は使用していない環境で、継続的なやり取りや、頻繁な参加を期待するのは無理があります。私たちは Slack を選択しました。調査したところ私たちのユーザーの多くが日々のクライアントやチームとの協業に Slack を使用していたためです。実際、Slack の採用は成功でした。
付け加えると、どのプラットフォームを選択するにせよ、そのプラットフォームはユーザーのセキュリティとプライバシーを十分に保護していると、製品チームとして自信を持てるものであるべきです。
また、異なるタイプのユーザーをベータプログラムに招待するときは、コミュニティを分けることも重要です。タイプごとにコミュニティを分ければ発見したことの背景を判断するのが容易になりますし、ベータ参加者側の体験もより良いものになります。
私たちはこのことを失敗から学びました。あるベータの時に、プロのデザイナーと学生を招待したことがあります。そしてすぐ、学生たちがプロに対して及び腰になったことに気が付きました。学生たちは蚊帳の外にいるかのように感じていました。ですから、たとえば Slack を使用するなら同一のワークスペースを2つ用意する必要があるわけです。単にチャネルを分けるだけでは不十分です。
Behanceに掲載されたベータプログラム参加者の作品
3. ユーザーを中心に行動する
理想的なのは、製品チーム内のすべての部門の代表が参加したグループをつくり、そのグループがベータ参加者とのコミュニケーションを担うことです。グループのメンバーは、ユーザーと会話する前にちゃんと準備をしておきましょう。ユーザーと直接会話する際のベストプラクティスはいくつか存在しますが、ここでは一つ紹介します。ユーザーにはモデレーターを喜ばせようとする傾向があります。そのバイアスを低減し、参加者が自分の意見を述べる余裕を持てるような環境を提供するにはどのようにすればよいのでしょうか。
まず、参加者が多少の困難に直面すること自体は問題ではありません。それは、何を修正すべきかという洞察をチームに与えてくれる機会です。同様に、回答を提供しないのもOKです。その代わり、「なぜ？」を確認することが必要です。たとえば、「XXができる機能が欲しい」とあるユーザーが言ったときに、「それは予定にありません」と返答するのではなく、「なぜその機能が欲しいのか？」「その機能を使って何をしたいのか？」「その機能を製品のどこでどのように使いたいのか？」を聞いてみましょう。その会話の方がずっと具体的な洞察を与えてくれます。デザインチームはどこから着手すればよいのか判断する手がかりを得られ、製品マネージャーはどのワークフローにどの機能が必要であるかをより明確に把握できます。場合によっては、他の機能がユーザーの問題を解決している様子を目にすることさえあるかもしれません。
エディンバラからベータプログラムに参加したMonika JurczykがIllustrator iPad版で作成したイラストレーション。
4. 参加者を注意深く選別する
ベータプログラムを開始する際に必ず発生する大きな問題があります。誰をベータに招待すればよいのでしょうか？ここで重要なのは、参加して欲しい人の基準を明確に定義することです。参加者の声が製品の将来を形づくることになるのですから、参加者は想定しているユーザーの特性を反映する存在であるべきです。選別の基準となる項目には、職業、使用するツール、ワークフロー、ニーズ、達成したい目的などが含まれるでしょう。定義したすべての基準を尋ねる選別用の質問表を作成し、回答が基準を満たすユーザーだけを招待します。
選別のために行う調査は、製品開発に役立つデータ収集の機会にもなります。最も優先するべきはベータプログラムに参加するユーザーの選別だとしても、同時に他の目的に利用することは可能です。たとえば、製品への興味を調査すれば、どの母集団がもっとも製品（の機能）が公開されたときに関心を持つ可能性があるかを推測する手掛かりになります。また、ユーザー情報は、後にユーザーがフィードバックを提供した時の背景の確認にも利用できます。使用するデバイス、同様の製品の経験、他のテクノロジーの利用といった情報は、彼らのフィードバックを解釈する際に役立ちます。
ベータ参加者に接するときは、公平さと相手に対する配慮を忘れてはなりません。私たちは多様性のある社会に生きています。製品のユーザーも同様のはずです。さまざまな背景、身体的あるいは精神的な能力を持つ人々のための場所を確実に用意しましょう。多様な視点を集めれば、さまざまなユーザーが直面する課題をより良く理解でき、公開前の問題解決に役立ちます。この件に関するより詳しいヒントは、Adobe Design Inclusive Workshop や Adobe Design inclusive resources をご覧ください。さまざまな能力を持つユーザーを招待しコミュニティを維持するためのベストプラクティスについては、私たちのチームが近い将来ガイドを提供する予定です。
Illustrator iPad版のベータプログラムに参加したSophia Yeshiの作品。Illustrator iPad版を使って制作された
5. フィードバックを厳密に追跡する
すべてのフィードバックを追跡し選別する努力を怠れば、どれほど有用なフィードバックも失われてしまうでしょう。そこで私たちのチームは、Reacji Channeler という Slack プラグインを使用することにしました。このプラグインは事前定義されている絵文字を使い、個々のメッセージへのタグ付け、ソート、チャネルへの送信などを可能にします。これを利用して、テントウムシの絵文字付きメッセージはバグ情報としてエンジニアリングチームに、クリップボードの絵文字付きメッセージはユーザビリティ関連のフィードバックとしてデザインチームに送るというフローを実現しました。少ない労力でフィードバックを正しい場所に送れる仕組みの実現によって、製品チーム全体をフィードバックへの対応に巻き込むことができました。製品チームは新しい製品開発で忙しいことを忘れてはなりません。時間をかけてメッセージの内容をすべて確認するよう要求するのは現実的ではありません。
私たちは Instabug も使用しました。Instabug はアプリ内で動作するサービスで、バグやログやクラッシュ情報を手軽に開発チームと共有できる手段をユーザーに提供します。また、ユーザーは改善要望レポートを直接送信することもできます。通常 Instabug のフィードバックはエンジニアリングチームに送られましたが、ユーザビリティや機能に関する要求は分析のためにリサーチチームに送られました。
6. フィードバックの実用的な分析
Reacji Channelerで振り分けられたフィードバックは、データベースに保存しました（私たちは Airtable を使用しました）。データベース化された入力の整理と分析は、リサーチャーの担当ですが、チーム全体が詳細を参照できるように、誰もがデータベースにアクセス可能な状態にしました。
Airtable のフィードバックを分析したリサーチャーは、発見した内容をチーム内の各部門に共有する役割も担います。これは、チームとしてのフィードバックへの対応を可能にします。私たちは、毎週行われていた全体会議の一部としてフィードバックセッションを行い、いくつかの重要な洞察、たとえば複数名から寄せられた機能リクエストや、繰り返し投稿されるユーザービリティの問題を共有しました。
共有された発見は、それぞれ実行可能な対応策と組み合わせてタスク化します。内容によっては、責任を明確にするために対応策を Jira に入力しました。
7. 一連の作業を国際化する
インクルーシブの観点からは、製品ユーザーとなる可能性を持つすべての人々への配慮が必要です。すなわち、ベータプログラムは世界的に行われるべきです。国際化とは単純に言語を翻訳することではありません。私たちの同僚の Wilson Chan と Mika Nakamura が指摘しているように、国際的なリサーチとは、言語だけに留まらず、文化的な色やシンボル、美的感覚、デバイスの使い方、人との関り方、技術標準、オフィスでの働き方、ものを購入する習慣、学習スタイル、さらには法律まで対象を広げる必要があります。この記事で紹介しているすべてのベストプラクティスは、複数の国々（言語、文化）で実施されるべきものです。
日本からベータプログラムに参加した Shunsuke Satake が Illustrator iPad 版を使って制作した作品
8. 住民を見つける
ベータを立ち上げるには「そこ」に常駐してくれる人々が必要です。成功するベータには、各部門（デザイン、開発、リサーチ、製品マネジメント、コミュニティマネジメントなど）から専属の人員が任命されているものです。また、私たちの経験では、誰か専任の人がいるとき、ベータの運営がもっともうまくいきました。そうです、ベータへの関与はフルタイムの仕事になり得るのです。
さらに、UXリサーチャーを最初から最後まで巻き込むことを強く推奨します。リサーチャーが日々の運用に関わることは無いとしても、フィードバックの質を向上させる手段を考えてくれるでしょう。UXリサーチャーは、ユーザーとのセッションを開いたり、オンラインで調査したり、データ分析も得意です。ベータ参加者は製品のファンであることが多いものですが、偏った意見を分析の際に把握できるのもUXリサーチャーです。
9. 継続的に評価する
ユーザー調査の強力なツールのひとつである縦断的研究は、アプリケーションを使ったワークフロー全体の変化を長期にわたり追いかけるのに適した調査手法です。たとえば、一か月間のユーザー体験の変化をより良く理解したいときに利用できます。
私たちの場合は、まず事前に30分間の民俗学的なインタビューを個々の参加者と行いました。そして毎週、主要なワークフローを必須のタスクとして参加者に実施してもらい、問題のありそうな領域を特定しました。参加者は、毎週末、決められたフォーマットでフィードバックを記入して提出するよう義務付けられていました。調査を終えるときは、個々の参加者と30分間の振り返りとフィードバックのインタビューを実施しました。プロセス全体を通じて、参加者にはモデレーターと直接連絡できる手段を提供し、何か気になる点、バグ、課題、質問が見つかったらいつでも連絡するよう奨励しました。繰り返しになりますが、調査の中に、さまざまな能力の人や異なる文化を持つ国の視点を含めることは重要です。
縦断的研究の結果は、ユーザーの成功に役立つものと邪魔するものを明るみに出します。また、時間の経過による習熟度の向上を測定する方法としても有効です。たとえば、私たちが注目していた指標のひとつは、ユーザーのタスク遂行能力の向上です。習熟度の向上と共に、指示されたタスクを完了するための時間は短くなるはずです。基本的に、望ましい結果は下の図のようになるでしょう。
Damon Nelsonによるグラフィック
10. ベンチマークテストを行う
ベンチマークテストを行うと、ユーザーの製品に対する認識の変化を測定するための指標を得られます。特に、新しいバージョンを提供した時、基礎的な指標を取得して、修正されたバグ、パフォーマンス改善、新機能の追加などに伴う影響を調べるのにはベンチマークが適しています。得られた指標を見れば、製品開発を進める上で、製品の成功やユーザー満足度向上のために対応すべきかもしれない課題（メンタルモデルの不一致、意味が明瞭でないコピー、最初に使用する際の体験の質の低さなど）を見つけられます。また、リサーチャーにとっては、ユーザー体験をよりよく知るための情報を得る機会です。私たちは、アプリ内に調査用の機能を組み込んで、ベータ版を大きく更新するごと利用しました。
測定する指標には、ベータの進行に伴う遷移を把握しておきたいものを選択します。いくつか例を挙げるなら、使いやすさ、パフォーマンス、満足度などは代表的な指標です。特にベータ参加者に関して言えば、製品を実際に使用する意図は重要な指標です。すなわち、もし明日製品が公開されたら、彼らがそれを実際に使用するかを確認するのです。
選択肢はリッカート尺度を使って尋ねます。それと、定量的な質問を定性的な質問と組み合わせて、リッカート尺度の質問をした後に、その答えの理由を聞くことをおすすめします。数字だけがすべてのストーリーを語るわけではありません。
複数のベータ参加者のデザインプロセスを示している動画。
おわりに
ベータプログラムを実施するには、時間とリソースの投資が必要です。それでも、誤ってデザインされたアプリを公開した後に改良することに比べれば、ずっと少ないコストになるでしょう。Illustrator iPad 版の開発チームは、ベータプログラムの期間を通じて集められた豊富な情報のおかげで、開発中に重大な方針変更を決断し、製品の成熟度を推定し、マーケティング資料を洗練させ、最終的にユーザーの期待に応える製品の公開にたどり着くことができました。
この記事はHow to Design a Successful User-Centered Beta for Your Product（著者:Laura Herman & Rebecca Gordon）の抄訳です