ワークフローラボ: Figma Makeを使ってデザインを直接デプロイする

Workflow Labへようこそ。ここではFigma製品とツールを活用したワークフローのサンプルを紹介します。

従来の方法では、「些細な点に気づいた」という段階から「リリース済み」までのプロセスは、チケットを経由して行われます。デザイナーがそれを書き上げ、それをバックログに記録しますが、エンジニアリングチームがすでに引き受けたその他の項目の中に埋もれてしまいます。些細ではあるものの高度な技術を要する修正の場合、このキューでその前向きな行動が消え失せてしまうのです。そのような細かい作業は優先順位をつけにくく、重要度が高すぎるため放置することもできないため、いつまでも未解決のまま残っています。

さらに、もう1つ失われるものがあります。デザイナーが書かれた説明をハンドオフすると、そのニュアンスが失われます。「行間をもう少し狭くして」や「スクリーンリーダーの読み上げが間違っている」といった指摘は、スクリーンショットのやり取りや説明の繰り返しにつながり、エンジニアは、本来ならデザイナーが直接下すはずであった決定事項を「通訳」する役割を強いられることになります。しかし、このワークフローに取り組むための別の方法があるとしたらどうでしょうか?

問題

例として、「未来予測博物館(MOSF)」を取り上げます。これは、文化が未来をどのように想像するかを探求する架空の博物館です。Webサイトの完全なアーキテクチャの再構築に伴い、現在はアクセシビリティにおける改善に取り組んでいるところです。さまざまな優先事項が競合している中で、このプロジェクトにリソースを割くことは大きな課題です。デザイナーはアクセシビリティのギャップに対処したいと考えていますが、エンジニアは同様に重要な再構築に専念する必要があります。双方の目標を達成するために、PMは異なるパスを提案します。エンジニアには負荷の高い作業を任せ、デザイナーは Figma Makeを活用し、本番環境のコーディングによって負荷の低いクラフトレベルの変更をエンドツーエンドで行います。この最後の20％こそが、技術的には機能するWebサイトと、真にアクセス可能なWebサイトを分ける決定的な要素であるため、チームはこの戦略について合意しました。このパスでは、チケットを発行することなく、デザイナーがこのスクリプトを裏返し、キャンバス上の作業からレビューを経て、プルリクエストのマージへと進めていきます。

キャンバス上でフィードバックを収集する

デザイナーは、何か手を加える前に、現在のユーザー体験を徹底的に検証したいと考えています。そこで、Figma Designのエージェントを使って、Webサイトに初めての訪れた人の中で旅行を計画している人、リピーターメンバー、スクリーンリーダーで操作する人など、合成ペルソナのセットを生成し、それぞれにサイト内で操作をしてもらい、フィードバックを収集しています。

寄せられるフィードバックは具体的で、そのほとんどが些細なものです。たとえば、展示会ページのラベルが曖昧で混乱を招きやすい、コールトゥアクションが見つけにくい、日付ピッカーを一目で把握しにくい、コレクションが結果を返さない時に画面が空白になり、処理が行き詰まるなどがあります。これらはいずれも大きな変更ではありませんが、こうした細かな修正が積み重なることで、Webサイトの使いやすさが向上します。

デザイナーがフィードバックに対処し、その設計変更をチームに持ち帰り、全員で再検討します。デザイナー、エンジニア、PMが各項目を確認します。訪問ページでの表示をより明確にし、コールトゥアクションを目立たせ、日付ピッカーを使いやすくします。この変更によって、「どのような方法でWebサイトを利用しても、誰もが簡単にサイトをナビゲートし、楽しむことができる」という共通の目標を達成できるとチームの意見が一致しました。

コードを使って直接作業を行い、バックログを省略する

合意が得られた変更は些細なものであり、その内容は十分に理解されているため、チケットを書いて待機する代わりに、デザイナーはエンジニアにコードベースへのアクセス権をリクエストします。これは、書き換えを引き継ぐためではなく、これらの具体的な修正を直接行うためです。

エンジニアによってアクセスが許可されたら、デザイナーはプロジェクトのGitHubリポジトリをMakeに接続します。現在Figma内でライブになっている本番環境のコードベースで、デザイナーは現在のサイトから新しいブランチを作成し、リストの最も簡単な修正「展覧会ページの日付ピッカー」から開始します。これはFigmaエージェントのペルソナが解析しづらいと感じたものです。

この静的モックでは、変更に5分かかります。しかし、コードに照らし合わせて作業を進めると、Makeによってキャンバスではわからないものが明らかになります。日付ピッカーは1回限りのものではありません。日付ピッカーは共通のコンポーネントであり、イベントカレンダーやメンバーシップのサインアップフロー内でも同じピッカーが使用されています。1つの些細な修正だと思われたものが、同時に3か所で行う必要がある変更であることがわかりました。

チケットベースのワークフローでは展示会ページの日付ピッカーだけが修正され、イベントカレンダーとメンバーシップフローが古いバージョンのまま残されます。そして、誰もそれに気づかないまま放置される可能性があります。デザイナーがコーディングに関わるようになったことで、共有依存関係がより明確になり、適切な場所で一度修正を行えば済むようになりました。

この修正が完了したら、デザイナーはリストの残りの項目(ラベルを明確にする、目コールトゥアクションを目立たせる、空の状態を分かりやすい表示に改善する)を順に処理していきます。個々の項目は些細なものですが、すべてを修正することで、単に機能するだけのサイトが、細部まで配慮されたサイトへと生まれ変わります。これらの項目は、通常はバックログに放置されたままになっている最後の20％なのです。

チーム全員でレビューする

変更が完了すると、デザイナーは作業をチームに送り、最終レビューを依頼します。ここからアクセシビリティの目標が具体的になります。目に見える修正は完了しました。また、チームは、それぞれの支援技術がどのように動作すべきかについて、その機能が実装されている場所に注釈を付けました。注釈には、共有される日付ピッカーが読み上げるaria-labelによって、単に読みやすいだけではなく、声に出して読みやすくする、スクリーンリーダーラベルを画面上の内容に合致させる、フォーカス順によって、アクションをスキップせずにコールトゥアクションに到達できるようにする、空の状態にスクリーンリーダーが読み上げることができるメッセージを表示する(検索結果なしという無言の回答を避ける)が含まれます。

PMはアクセシビリティの目標に向かって作業が進んでいることを確認し、エンジニアはコーディングで扱う内容についての意見を述べ、デザイナーは最終的な調整を進めます。

PRをプッシュする

最後のアノテーションが処理されると、デザイナーはMakeから直接プルリクエストをコードベースにプッシュします。エンジニアはコードを確認し(この時点で、更新されたデザインの意図、チームのコメント、アクセシビリティに関するアノテーションがすべて同じ変更に添付されている)、承認し、ブランチをマージします。バックログに四半期にわたって放置されていたはずの修正が、わずか1日でリリースされました。

この作業方法によって、わずかな変更で長期的な成果をもたらすことができます。チケットは、クローズされると消失し、そこに存在していた意思決定も失われます。変更をマージすることで、コメント、アクセシビリティに関するアノテーション、日付ピッカーを共有可能にした理由などをすべて保持することができます。たとえば、誰かが6か月後に日付ピッカーを再確認したとき、その時点に至るまでの経緯が、チームの共有履歴にそのまま残されています。

本番環境までのプロセス: 従来とは異なるハンドオフ形式

従来の引き継ぎモデルでは、デザイナーとエンジニアはアセンブリライン上の2つのステーションとして扱われていました。このモデルは、規模が大きく、明確に定義された機能には適しています。しかし、より洗練された仕上げやアクセシビリティの向上、および製品体験全体を形作る磨き上げには、デザイナーが直接コーディングできる別のハンドオフ形式が必要になります。

この作業方法では、デザイナーにエンジニアになるように求めたり、エンジニアにデザイナーになるように求めたりすることはありません。この方法によって、双方で最も重要な決断を下せるようになりました。エンジニアはアーキテクチャの刷新に専念し、デザイナーは最初から最後まで細部の仕上げを担当し、PMはプロジェクト全体を目標に向かって着実に進め続けました。ブランチによって、チーム全員の貢献(目に見えるデザイン、書面によるフィードバック、スクリーンリーダーが読み上げるラベル)が、キャンバスからプルリクエストのマージへと引き継ぎされました。

このワークフローでは、最後の20%が省略されることはありませんでした。すべてリリースされました。

Makeプロジェクトを直接GitHubにプッシュする方法について詳しくは、 ヘルプセンターをご覧いただくか、最新のConfig講演のコードによるデザインとFigma Designエージェントの操作を視聴してください。