Figmaオープンベータリリースの解剖学
市場投入は、リリースで終わりではありません。製品の作り方や仕事の進め方について深く掘り下げる「解剖学」シリーズ、今回はFigmaの開発モードにメスを入れ、リリース後の重要な2週間を詳しく探ります。
Figmaオープンベータリリースの解剖学 を共有
Laura Edelbacherによるイラスト
実際、リリース日は製品寿命の最初の日です。製品を市場に投入した今、ユーザーの反応や、目標に向かって順調に進んでいるかどうか、すぐに修正が必要なことは何かを確認する時です。リリース後の2週間は、プロダクトマネージャー、デザイナー、データサイエンティスト、マーケターなど、全員が招待されたユーザーリサーチパーティーと言えるでしょう。
検体Aの開発モードを見てみましょう。これはFigmaで開発者専用に構築された、最初のワークスペースです。今年のConfig期間中にリリースされた開発モードは、開発者にとってより良いデザインツールとは何か?という疑問に対する当社の答えです。デザインファイルのブラウザインスペクターのように、開発者は、Figmaのキャンバスをホバーしたりクリックしたりすることで、寸法、仕様、アセット、その他の情報を収集することができます。オープンベータは、すべてのFigmaユーザーが2023年末まで無料で利用できるもので、当社は、これが私たちのコミュニティに役立っているかどうか、また、どのように改善することができるかについて、重要なインサイトを得ることができます。当社がどのようにリリースの準備をし、最初の2週間でバグやリクエスト、フィードバックをどう処理したかをご覧ください。
オペレーションを支える頭脳
料理人が多すぎるとスープが台無しになる、という諺がありますが、手術の執刀者が足りなければ解剖に失敗します(これは医学的には真実ではありません。比喩であることをご了承ください)。開発モードを市場に送り出した人たちが、コミュニティからのフィードバックの収集、分析、対応に追われていました。私たちは皆、どうすれば製品をもっと良くすることができるか知りたかったからです。
どのように物事を分担していたかというと、製品チームは特定の機能の使用状況の追跡を担当し、マーケティングチームは一般の人達の反応を測定し、サポートチームはバグや改善に集中しました。とはいえ、全員が常にコミュニケーションをとっていて、重要なツイートを見逃したり、頻発する問題について知らされなかったりすることはありませんでした。当社のプロダクトマネージャーであるAvantika Gomesは、あらゆる情報源から引き出した情報の分析と統合を行い、アクションアイテムの優先順位をつけ、次のステップを調整し、発散しました。
重要なデータ: 何を解析したのか
クローズドベータの最後の数週間は、開発者やデザイナー達と、そのワークフローや問題点について話すことに多くの時間を費やしました。そこで学んだことは、開発モードの中核となる仕組みの発散を行ったり、ユーザーのコラボレーションを反映するために機能を微調整したり、当初考えていなかったニーズを満たすために新機能を追加したりするのに役立ちました。言い換えれば、正しい道を歩んでいると同時に、学ぶべきことがまだたくさんあることを私たちは知っていたのです。
用語説明
ノーススターメトリックとは、成功の重要な尺度であり、目標や期待に応えるための最も強力な指標です。
開発モードを使用している開発者ロールの週間アクティブユーザー(WAU)の割合というノーススターメトリックに基づいて調整することに加え、私たちのオーディエンスに届いているかどうか、彼らがワークスペースについてどう考えているか、何を修正する必要があるか(の統計情報)を知りたかったのです。フィードバックが殺到することはわかっていたので、重要な統計情報を固定し、誰が何をモニタリングしているのかをチーム全員が把握できるようにしました。
プロのヒント
結果が出始める前にベンチマークとなる指標を設定しておくと役立ちます。そうしないと、数字の良し悪しに翻弄されることになります。当社の調査担当者も、主要な指標を示したダッシュボードを事前に作成し、リリース前後の変化を簡単に比較できるようにしていました。
- 機能の採用: インスペクトパネル、変更内容比較、関連リンク、その他の機能をチェックし、どれだけの人が使っているか、どれが最も注目されているかを確認しました。
- リーチと反応: 雰囲気チェックの力を過小評価してはいけません。ソーシャルメディアへの投稿の印象、メールの開封率、製品内のメッセージの印象が、当社が開発者層にうまくリーチできているかどうかを教えてくれる一方で、ソーシャルセンチメントやConfig中の利用者層の生の反応は、どの機能がユーザーの気分を盛り上げているかを教えてくれました。
- 修正と改善: 何がユーザーを悩ませているのかを理解するために、ヘルプセンターの記事画面、製品内のフィードバックボタンからの投稿を確認しました。そしてサポートチケットについては、後ほど詳しく説明します。
問題の核心
私たちが欲しかったのはフィードバックであり、実際得られたのもフィードバックでした。リリース後最初の24時間に、フィードバックフォーム、サポートフォーラム、ソーシャルメディア、営業活動での会話、その他のチャネルから、コミュニティからの2,000を超える回答を得たのです。
フィードバックチャネルのトリアージ
情報の流れを整理することを目的とし、耳に入るものをすべて聞くために別々のSlackチャネルを3つ設定しました。製品内のフィードバックボタンは、トリアージプロセス全体を通して唯一の真実の情報源であるAsanaのフォームにリンクされていて、すべての投稿がタスクとして自動的に記録され、専用のSlackチャネル#dev-mode-feedback-streamにプッシュ通知で送られました。(他の場所で収集したフィードバックを基に、手動によるチケット作成も行いました。)こうして初日には1,500件以上のメッセージが寄せられたのです!
もうひとつのSlackチャネル#dev-mode-internal-feedbackでは、Figmaの従業員がデザインの矛盾点、多くの場合、初心者が見過ごしがちな点について意見を述べることができました。また、#dev-mode-external-feedbackでは、サポート、営業、その他、顧客と接するあらゆる人からの意見を集めました。また、TwitterやLinkedInには、Figmaの大規模なコミュニティがあり、何がうまくいっていて、何がうまくいっていないのかをすぐに教えてくれます。注目すべきフィードバックを皆がSlackで共有し、誰もが見られるようにしたのです。
行動への飛躍
バグレポートをより詳しくする必要がある場合、エンジニアたちはユーザーに直接メールを送り、フォローアップを行いました。また、チームはユーザーに連絡し、一時的な回避策を提案したり、ヘルプセンターの担当者を紹介したりもしました。これまでに83人の顧客とチャットし、現在のその数は増え続けています。
プロのヒント
フィードバックへのお礼や、ヘルプが行われていることの確認など、チームが簡単にユーザーに返信したり、フォローアップしたりできるように、いくつかの返信テンプレートをドキュメントに置いておくのは良いアイデアです。左の例は、開発モードでのコメントへのアクセスについてよくある質問に対応したものです。
お世話になっております。
ご連絡ありがとうございます。開発モードをご利用いただき、また、開発モードのコメントへのアクセスに関するご意見をいただき、感謝申し上げます。
開発モードでコメントにアクセスすることは可能です。コメントをオンに切り替えるには、左上のスピーチアイコンをクリックするか、またはキーボードのショートカットの「C」を押していただくと、コメントモードに入ります。詳しくはこちらからヘルプセンターをご覧ください。
何らかの理由でショートカットキーが機能しない場合はお知らせください。動画またはスクリーンショットがあれば大変助かります。
これまでのご協力とフィードバックに心より感謝します。このベータ版のリリースにあたり、開発モードの使用体験をより良いものにするために、私共ではコミュニティの皆さまからのご意見をお待ちしています。必ずしもすべてのフィードバックを直ちに反映することはできませんが、成長を続けることをお約束するとともに、今後もご意見をお寄せいただけますようお願いいたします。
よろしくお願いいたします。
Molly
用語
バーンダウンチャートやリストは、プロジェクトの成果物が段階的かつ頻繁に発生するアジャイルプロジェクトマネジメントから発生したもので、いつまでに何を終わらせなければならないかを追うのに役立ちます。
開発モードをデリバリーすることで、デザイナーのワークフローを壊してしまうのではないかと心配していました(実際に、そうなりました)。それに関連するpingはいずれも、最初の数日間に繰り広げた応急処置のバーンダウンリストとなりました。たとえばファイルインポートとエクスポートの問題、ログインのトラブル、利用規約の受け入れの問題などです。最初の1週間で、200件を超えるフィードバックを解決したのですが、我ながら悪くない数字だと思います。
情報の消化
プロのヒント
フィードバックを俯瞰するには、Asanaのウィジェットを使ってタスクをFigJamファイルに取り込み、テーマごとに整理します。
優先度の高いバグをつぶしながら、データの並べ替えと、短期的なロードマップの改善を始めました。チケットの取り込みは、映画『ワイルド・スピード11』の筋書きになりそうなほどでしたが、次のように対処しました。問題がAsanaに入ってくると、PM、リサーチ、デザイン、エンジニアリングの各チームがタグを付けて分類しました。最終的には、読み込みに時間がかかり、多くのセクションをスクロールする手間もかかるため、フィードバックをまとめるのが難しくなりました。そこで、FigJamに移行し、Asanaのウィジェットからチケットを取り込み、さまざまなセクションに整理したのです。これにより、人々が最も気にかけていること、優先すべきことがよくわかるようになりました。
結局、これも手作業になりすぎたため、データをGoogle Sheetにエクスポートするようになりました。これにより、複数のチケットを一度に表示したり、1つのチケットに複数のタグを追加したり、任意のタグの下にいくつのチケットがネストされているかを数えたりすることができました。物事を視覚的に考える私たちとしては、FigJamにとどまることができるように、ワークロードを自動化する方法を考えています。
処方箋
ロードマップの策定
開発モードに関するインサイトは、下半期に向けた製品ロードマップの計画に役立っています。ユーザーが好むものと好まないものがよくわかるようになったため、製品面での次のステップを描くのがとても簡単になりました。マーケティングチームがユーザー理解におけるギャップを特定できるため、教育的な記事やライブストリームでの対応も引き続き可能です。
振り返り
プロのヒント
スプリントの後はみんな疲れていますから、振り返りはポジティブな雰囲気で始めます。私たちはFigmateの皆さんに、「一緒に仕事をしてとても良かったスタッフ」と「うまくいったこと」を教えてほしいと頼みました。「どんな問題に直面したか」を掘り下げるよりもそちらが先でした。
リリースの記憶がまだ新しいうちに、プロジェクトを振り返る会を2回開催しました。1つはマーケティングチームの戦術に焦点を当てたもの、もう1つはマーケティング、製品、デザイン、エンジニアリングにまたがる部門横断的な仕事の進め方についてでした。これらを2回に分けて話し合うことで、ワークフローがどのように交差しているかを全体で見る前に、コアチームのプロセスを分子レベルで理解することができました。
結果の共有
チームとリーダーシップに最新情報を提供するために、10を超えるチームからのレポートが必要でした。各チームはさまざまなツールを使用していたため、ご想像のとおり、FigJamファイル内にダッシュボードと指標をまとめました。全体的な概要ができあがった一方で、1つのチャネルをさらに詳しく調べたい場合には、個々のチームのファイルにリンクすることができるようになりました。
リリースから約1ヶ月が経過した今、私たちは緊急手術から、定期的な製品の修正と成長のための健康的な治療計画の策定へと移行しました。Slackでは、ユーザーフィードバックの要約を毎週投稿し、機能の改善と修正についてまとめ、隔週で測定値の共有を行っています。
最近リリースされた他の機能と同様、開発モードはWIP (制作途中)です。インターフェースの改善では前進を遂げましたが、オープンベータのゴールはできる限り多くのフィードバックを得ることです。それを念頭に置き、私たちは皆様の声をお待ちしています。
皆さまからのご意見をお待ちしています。Figmaのリサーチパネルへの参加(と期間中のお小遣い稼ぎ)をご希望の方は、今後のリサーチのご案内をお送りしますので、このアンケートにご協力ください。