WIPへようこそ

まず最初に、私が普段思っていることを書きたいと思います。私は自分のキャリアを通じて、多数のデザイナーとプロダクトマネージャーと面接してきました。いつも候補者には、その人の担当プロジェクトのプロセスを説明してくださいとお願いします。それに対して、ほぼすべての人は、次の話のようなことを語ります。

まず、リサーチから始め、チームが(もちろん)付箋を使って盛大にブレインストーミングを行ってから、一連の手書きのスケッチを作り、そのすべての結果、立派で完璧なプロトタイプができあがり、これをテストして、世に送り出します。以上です。

始まりから完了まで満足のいく話です。

しかし、ここで問題があります。私がそのような話を信じることはほとんどありません。今日の製品がこのように明確で、リニアに、完璧な方法で構築されることはありません。現実はもっと乱雑です。ではなぜ、私たちは現実を直視しないのでしょうか。

長いこと、それこそがプロセスとされてきました。プロダクトデザインが物理的な製品を意味していた時代には、全員が慎重に構築されたリニアプロセスに従うことが非常に重要でした。世界がデジタル化するにつれて、デザイナーがデザインするスペースでの構築とバージョンアップが高速化しました。プロダクトチームは、あるデザインをユーザーに何年間も使い続けさせるのではなく、ものの数分で更新をデリバリーできます。今日、すべてのデジタル製品は未完成です。だからこそ、デザインの方法は変化しているのです。

デザイナーの仕事は終わったと感じることができません。終わらないからです。私たちが作っている間に、複数のコラボレーターがファイルを編集し、フィードバックを残して、デザインをアップデートします。デザイナーの多くはいつでもデリバリーできるため、新しいデザインが実際にいつ準備できるのかを知るのは困難です。これが、現代のプロダクトデザインと開発の混沌とした現実です。Figmaでは多くの時間を費やして、この現実を乗り切り、現実に合った構築方法を考えています。ここでは、私たちが見つけたコツと、新しい拡張・連携機能をいくつかご紹介します。

ファイルはもはやメールに添付してコラボレーターに送信する静的ドキュメントではありません。ブラウザーベースのツールにより、作業はURL経由で誰とでも、どこでも共有できるようになり、全員が同時に同じファイルを見て作業できます。

明らかになったことは、人はリアルタイムで成果物をアップデートできると、共有するのも早くなる

、ということです。ファイルのタイトルに「WIP」(作業進行中)という注釈を付けたことがある方なら、進行中のドラフトの威力をご存じでしょう。それはハードルを下げるサインで、閲覧する人はそれが文字通り進行中であることがわかります。作家が下書きを編集者に見せられるように、デザイナーはプロダクトマネージャーに初期の指示書を見せることができます。さあ、「進行中の作業」の世界へ飛び込みましょう。

終わりのない世界で前進する

つまり、フィードバックが早いほど、進捗が早くなるのです。いいことづくめですね。しかし、仕事がいつも変化していると、問題のステートメントが最終になる時、ソリューションが最終になる瞬間、さらには製品が最終になる時がなくなってしまいます。明確な段階のある固定されたプロセスの代わりに、すべてが流動的で自然発生的になります。

現在進行形のドキュメントへのオープンアクセスは、コラボレーターがいつでも出入りして、フィードバックを残せることを意味します。しかし、そうしたコメントは、作業するときに的外れになる可能性があります(それは避けられないでしょう)。昨日「承認した」と思ったものが、作業が進行中であるために完全に変わってしまうこともあります。最新情報を常に把握することが重要になります。それで、混乱を解消するために(そして外出先での応答を少し楽にするために)、新しい通知とモバイルコメントを導入しました。ワークフローを連携させるのはまだ難しく、そのため、Googleカレンダーのイベントにファイルを添付するFigma Chrome拡張機能やMicrosoft TeamsやZoomの直接コラボレーションできる機能などの新しい統合や拡張機能を試し続けています。

ただし、それでもファイルが最終的になる明確な瞬間はありません。それどころか、製品をデリバリーした後に「進行中の作業」ラベルを削除するのを忘れることもよくあります。強力ながらカオスな「作業進行中」の世界をナビゲートする新しい方法が必要です。では、実際にどのように仕事を進めるのでしょうか。

一定のペースでレビューするか、完璧な瞬間を待ってレビューするか

「常時WIP」な世界で最も大変なことに、いつフィードバックを求めるか、または関係者やリーダーシップに確認するかがはっきりしていないことがあります。私はFigmaで、いつ担当チームの作業をレビューするかを判断するようにしています。問題に関して足並みを揃えているとき、解決したとき、リリースの準備ができたとき、でしょうか。理想的には、作業が1つの段階から次の段階に進み、ちょうどよいタイミングで作業をレビューすることで、これは製品の方向について自信を強めるのにも役立ちます。

しかし、前述のとおり、進捗がそれほど直線的に進むことはめったにありません。アイデアを探ると、問題のスペースが変化する可能性がありますし、アップデートを続けているうちに、新しい方向を発見することもあります。プロダクトの他の部分が変化し続けて、新しい方向に進むこともあり、作業をいつ共有してレビューしてもらうのがよいのかを判断するのが難しくなります。時間が経つと、作業を共有していないことでハードルが上がり、心配も大きくなり、方向性の不一致につながる可能性もあります。

ここFigmaでは、定期的なデザイン批評会

がパーフェクトな解決策になっています。火曜日と木曜日、どのような状態や段階でも、仕事を持ち寄り、同僚や関係者にフィードバックを求めます。関係者がどのように感じているかについてのサインを毎週受け、必要に応じてアップデートと軌道修正ができるので、健全です。

これが未来のレビューだと思います。作業の状態に関係なく、一定のペースで作業をレビューするのは、決して訪れない完璧な瞬間を待つよりずっと効果的です。

フィードバックは内容も形式も大切

この運用モデルの難しい点には、特にコラボレーターまたは関係者として、フィードバックする方法を知るのが困難なことがあります。リアルタイムで作業が進んでいくのを目の当たりにするのは心が躍りますが、いつ変わるかわからないことを知っているので、どのような種類のフィードバックをどのような態度で伝えるかを判断するのは困難です。(編集者より: 今年のホリデーシーズンに、大切な人へ完璧なフィードバックを贈る方法で悩んでいるなら、Figmaのフィードバックギフトガイド

をチェックしてください。)

役に立つアイデアや方向付けが得られることを期待して、初期の作業をチームと共有することがあります。最初は、すばらしい反応が得られて良いのですが、少し経つと他の人も好奇心を示して、あまり価値のない意見を残して行くようになります。間もなく、見渡す限りコメントの山になります。さらにひどいと、誰か(特に役員クラス)がコンテクストを無視してファイルに入ってきて、フィードバックを残し、去っていくことがあります。このような状況は「swoop and poop」(突然やって来て、迷惑な攻撃をして去っていくこと)と呼ばれています。突然、対応しないといけないフィードバックがやってくるのです。そうなると大変です。

私は最近、フィードバックの範囲を決め、特定のレビューをハイレベルに保つプロのヒントを学びました。マーケティングチームは、ブログ投稿や長い形式のコンテンツを共有する必要があります。以前には、Google DocsやDropbox Paper経由で関係者にリンクを送信していましたが、コメントが大量にたまったり、変更を提案されたりしました。代替案として、チームは、FigJamでドラフトをスクリーンショットとして共有することを始めました。他の人たちは、付箋でフィードバックを残し、蛍光ペンを使って注釈を書き込み、さまざまな感情を表現できますが、そのどれも返信や解決を求めていません。このモデルでは、関係者が、チームの仕事を遅らせたり邪魔したりすることなく、意見を伝えられます。

この形式でのフィードバックは、Googleドキュメントでの山のようなコメントとは感じが違います。しかし、ここでは反対の問題が発生します。つまり、重要なフィードバックを拾い上げて、なくなったり無視されたりしないようにすることです。

これは、特にコメントがその場限りで、デザインがまだ進化中の場合に常に発生します。私はUber社にいたとき、運転者アプリに取り組んでいましたが、私のチームが、前もってユーザーの目的地を尋ねる「リクエスト」フローを開始するアイデアを思い付きました。かなり初期にこのアイデアを共有したところ、リサーチチームの誰かがインドチームからの重要なフィードバックにフラグ付けをしました。作業は進みましたが、コメントは忘れられなかったものの、誰もそれについてのアクションは取りませんでした。気付いたときには、製品はデリバリーされていて、このフィードバックに対応できていませんでした。リリースの数週間後、私たちはその問題を修正しなければなりませんでした。

重要なフィードバックが取り上げられ、優先されるようにするのは難しい場合もあります。数か月前、Coda社の共同創設者兼CEOであるShishir Mehrotra氏が主催する「リチュアル」(儀式)をテーマにしたディナーに出席しました。そこで私は、Hubspot社の共同創設者に「フラッシュタグ」の概念を紹介されました。これは、企業のリーダーがフィードバックの重要性を示す方法のひとつです。それは、どれほど気にかけているかを示すためにフィードバックの最後に付けるハッシュタグで、「対処すべき」度合いを示しています。

例:

• #fyiは、必ず対処すべき件ではないことを意味しています。
• #suggestionは、その件は確認したけれど守るエネルギーをかけるだけのものではないことを意味しています。どちらでも良い、ということです。
• #recommendationは、その件は対処すると良いものであることを意味します。「必ず対処すべき」を適用することも考えたが、そこまでではないということです。
• そして最後に、#pleaは、その件が絶対に対処されるべきであることを意味します。そのため、このフラッシュタグを見たら、優先的に対応するようにします。
  

スクリーンショットをFigJamに移植する場合でも、フラッシュタグを適用する場合でも、適切な態度でのフィードバックを促す多くのさまざまな方法があります。適切なタイミングでこれらのさまざまなフィードバックを活用して、作業に適切な影響を与える必要があります。

製品の完成度にこだわり過ぎない

最後に、WIPの世界でのデリバリーについて話したいと思います。レビューと同じく、デリバリーの準備ができたと確信できる完璧な瞬間はまずありません。作業は常に改善できるので、そうし続けたいという誘惑に駆られます。製品のデリバリー前にすべてのチェック項目をクリアできる完璧なリリースレビューというビジョンは存在しません。存在したとしたら、作業が遅くなり常時アップデートできるというメリットを台無しにすることになるでしょう。諦めが肝心です。デリバリーされる製品は、最後に見たとき、またはレビューしたときとは少し異なるものになることに慣れる必要があります。

そうです、これは、不完全なリリースを意味します。しかし、顧客はその1回だけで私たちの製品を判断しません。

何せ、リリース後でも製品を改善することはできるのです。私は、The Browser Companyのチームがその製品Arcを公開で構築するのを見るのが好きでした。デザイン部門責任者、Dustin Senos氏がフィードバックを求める動画を共有したとき、モック、プロトタイプ、また改善のための知見に満ちたアイデアを含む数百の返信を受けました。人々を作業に招待すると、気にかけ、本気になってくれます。そのため、結果もずっと良くなります。

どれほど多くのお客様が、製品が常に成長し、改善されていくのを見守りたいと思っているかには驚かされます。私はそれを、Uberのドライバーから見て取ることができました。少人数のドライバーに、ドライバーアプリのデザイン変更をサポートするように依頼したところ、多くの人が改善するための提案をテキストで送り続けてくれました。すべてのベータ版に参加を希望する人、ロードマップに影響を与えることを願って常に意見やフィードバックを寄せてくれる人、いろいろな意見をFigmaコミュニティでデザイナー達といっしょに見ています。ユーザーは製品が改善し続けることを望み、期待します。「なかなか良い」のままでは期待に応えていないのです。そこで、最後のヒントです。製品の完成度にこだわり過ぎないでください。改善への期待とチャンスは常にあるからです。

WIPへようこそ

これは、新しい仕事の方法です。このように仕事をすべきだという価値観やベストプラクティスのすべてに異を唱える考え方なので、カオスになるかもしれません。同時に、自由になることができ、真の創造プロセスに従っていると感じられます。

しかし、アップデートし続けるこの世界を愛しながら、少し心もとない、手に負えないという気持ちもあります。この新しいWIPの世界に対する自分自身の取り組み自体が、WIP（進行中の作業）です。Figmaコミュニティでこの考え方を公開し、アップデートしている理由でもあります。