火曜日の朝8時、開発者から連絡が入ります。彼らはモーダルのコーディングに4時間も費やした挙句、それが承認済みのバージョンではなく、「Exploration_v3_temp」という名前の作業用ページから作られたものだと気づいたのです。
このような悲劇は、ハンドオフを単なる「立ち退き通告」のように扱うことで起こります。デザインをまとめ、フェンスの向こうに投げ捨て、あとはエンジニアリングチームが何とかしてくれるだろうと期待する。Northwind Studioでは、整理されていないFigmaファイルは、いつか回収されるのを待っている「負債の書類」にすぎないことを早い段階で学びました。もし開発者があなたのリンクを開くのを嫌がっているなら、ファイルの作り方と渡し方を見直す時期です。
ハンドオフは「丸投げ」ではなく「対話」である
デザインを壁の向こうに投げ捨てて自分の仕事は終わりだと考えるのは、レイアウトの崩れや不満の残るメールのやり取りを生む原因になります。優れたハンドオフは、スプリントの最後に行われる1回限りのミーティングで完結するものではありません。デザインとエンジニアリングが初日から共通の言語を構築していくことで実現します。
私たちはプロジェクトを開始する際、高精度のモックアップを作成する前の段階から開発者をファイルに招待します。ワイヤーフレームを見てもらい、レイアウトのロジックに疑問を投げかけてもらったり、技術的なハードルになりそうな部分を早期に指摘してもらったりするためです。この継続的なパートナーシップにより、正式にファイルをハンドオフする頃には、開発者はアプリケーションがどのように動作すべきかをすでに理解しています。トリッキーなインタラクションについても事前に意見を交わしているため、どこに真実のソース（Source of Truth）があるのかを正確に把握できているのです。
人間の目で見てわかるようにFigmaファイルを構造化する
開発者がFigmaファイルを開いたとき、5秒以内にすべての画面のステータスを理解できるべきです。どのフレームが実装可能で、どれが作りかけのブレインストーミングなのかを開発者に推測させているようでは、システムとして破綻しています。
私たちは、Figmaのサイドバーを明確で予測可能なページ構造で整理しています。絵文字を視覚的な道標として使い、進行中の作業と承認済みの仕様を明確に区別しています。
以下は、私たちが一般的なプロジェクトファイルを構造化する際の現実的な例です。
--- 🟢 READY FOR DEV ---💻 Desktop - Dashboard📱 Mobile - Dashboard--- 🟡 IN PROGRESS ---🧪 Layout Explorations🎨 Brand Assets & Moodboards--- 🔴 ARCHIVE ---📦 Old Iterations
「Ready for Dev」ページ内では、ユーザーフローに沿って、フレームを左から右、上から下へと整理します。また、Figmaのセクションツールを使用して関連する画面をグループ化し、セクション全体に「開発準備完了（Ready for development）」のステータスバッジを付与します。このシンプルな視覚的合図により、開発者はこれらのデザインが確定しており、実装を進めても安全であることを一目で理解できます。
芸術家ではなく、開発者のようにコンポーネントを命名する
Figmaファイル内のレイヤー名が「Group 412」や「Rectangle 12」、「Button-New-Final-v2」のようになっているなら、開発者に不要な翻訳作業を強いていることになります。デザインコンポーネントは、実際のコードベースの構造を反映している必要があります。
見た目に基づいて要素に名前を付けるのではなく、その要素が何をし、どこに存在するかに基づいて命名しましょう。モダンなフロントエンドフレームワークと整合性の取れた、スラッシュ区切りの体系的な命名規則を使用します。
たとえば、ボタンのバリアントに Red-Button-Large と命名するのではなく、以下のような構造化された命名システムを使用します。
Button / Primary / Danger / Large
構造化された命名とFigmaのコンポーネントプロパティを使用することで、エンジニアリングチームと同じ言語で話すことができます。開発者がコンポーネントをインスペクトした際、ReactやVueのpropsに直接マッピングされるプロパティが表示されます。これにより推測作業がなくなり、デザインファイルと実際のアプリケーションの両方でUIの一貫性が保たれます。
ピクセルパーフェクトにこだわりすぎない境界線を知る
静的なデザインは幻想です。ウェブページはポスターではありません。ユーザーのビューポート、ブラウザの設定、フォントの好みに応じて、伸縮し、縮小し、再フローします。静的な1440pxのフレーム上で個々のピクセル値を微調整することに何時間も費やすのは、実際の環境では崩れてしまうディテールに時間を浪費しているのと同じです。
静的なフレームのピクセル調整に執着するのではなく、システムのルールを定義することに集中しましょう。
- すべてにオートレイアウト（Auto Layout）を使用する: ボタンやカードを手動でボックスを描いて作成するのはやめましょう。Figmaのオートレイアウトを使用して、パディング、ギャップの間隔、配置を定義します。ボタンのラベルが「送信」から「アカウントを作成」に変更された場合、ボタンは自動的に伸縮するべきです。
- 制約（Constraints）とリサイズルールを定義する: 画面サイズが変更されたときに要素がどのように動作すべきかを開発者に示します。カードはコンテナいっぱいに広がるべきか、それとも固定幅を維持すべきかなどを明確にします。
- エッジケースをドキュメント化する: テキストブロックのコピーが想定より3行長くなった場合、何が起こるでしょうか？三点リーダー（...）で省略するのか、それとも下のコンテンツを押し下げるのか。デザイナーは理想的な状態だけでなく、システムの挙動をデザインする必要があります。
デザイントークンで共通言語を話す
デザインとエンジニアリングの間で最も頻繁に発生する摩擦の原因は、曖昧な値の使用です。ある画面で #F3F4F6 の背景を使い、別の画面で #F9FAFB を使っている理由が、単にデザイナーがカラーピッカーツールを使ったからというだけである場合、コードベースはすぐに肥大化し、一貫性を失います。
デザイントークンは、生のカラーコード、フォントサイズ、ピクセル値を名前付きの変数に置き換えることで、この問題を解決します。開発者にリンクの色として #3B82F6 を使うよう指示する代わりに、color-brand-primary というトークンを使用するように伝えます。
私たちのデザインシステムには、開発に対応したトークンがファイルに直接組み込まれており、Figma内の変数がコードベースのCSS変数に直接マッピングされるようになっています。このアプローチにより、ブランドのプライマリカラーを更新する必要が生じた場合でも、1つの中心的なトークンファイルを変更するだけで済みます。手動でコードを更新することなく、デザインライブラリと実際のサイトの両方に変更が反映されます。
明確な境界線とフィードバックループを確立する
完璧なファイル構造と堅牢なトークンシステムがあっても、実装フェーズでは必ず質問が生じます。コードベースに混乱を招くことなく、フィードバックや開発後期の変更に対応するための明確なプロセスが必要です。
私たちは、デザインが「Ready for Dev」セクションに移動した後は、厳格な「フリーズ」ルールを適用しています。開発中にクライアントから変更要求があった場合、開発中の仕様フレームを直接編集することはしません。代わりに、フレームを「In Progress」セクションに複製し、調整を行い、まず開発者と変更内容を確認します。承認されたらフレームを入れ替え、バージョンログやシンプルなFigmaのコメントで変更内容を記録します。
Figmaの「開発モード（Dev Mode）」を使用することも、開発者がレイヤーを誤って移動したりフォントの太さを変えたりすることなく、レイアウトの確認、距離の測定、CSSコードのコピーを行うのに役立ちます。これらの境界線を尊重することで、開発者の集中力を守り、最終製品が承認されたデザイン通りに仕上がるようになります。
優れたデザインシステムは、プレゼンテーションでの見た目の美しさだけでなく、いかにうまく構築されているかによって定義されると私たちは信じています。チームのデザイン運用を効率化し、エンジニアリングチームが喜んで使える一貫したビジュアルシステムを構築したいとお考えであれば、私たちがその仕組み、トークン、ワークフローのセットアップをお手伝いします。
よくある質問
すべての画面サイズをデザインせずに、レスポンシブデザインの仕様を伝えるにはどうすればよいですか？
すべてのビューポートをデザインする必要はありません。代わりに、最小と最大のブレイクポイントをデザインし、Figmaのオートレイアウトを使用して要素がどのように伸縮するかを示し、中間サイズの画面での折り返し動作をドキュメント化します。
Figmaでデザインを「開発準備完了」として示す最善の方法は何ですか？
Figmaファイル内に専用の「Ready for Dev」セクションまたはページを作成し、承認されたフレームにFigmaの組み込みステータスバッジを付与します。アクティブなドラフトや検討中のデザインが含まれるページから開発者に実装を進めさせてはいけません。
ハンドオフプロセスを改善するために、デザイナーはコードを学ぶべきですか？
デザイナーがプロダクションコードを書く必要はありませんが、ブラウザがどのように動作するかを理解しておく必要があります。CSSのボックスモデル、Flexbox、Gridの基本を知っておくことで、技術的に実現可能で実装しやすいレイアウトをデザインできるようになります。
マイクロインタラクションやアニメーションを開発者に伝えるにはどうすればよいですか？
Figmaのプロトタイプを使用して流れを示し、それを補足するドキュメントやシンプルな画面録画を用意します。具体的なイージングカーブ、遅延、トリガー状態を記録しておくことで、開発者がアニメーションの数値を推測する必要をなくします。