フレームワーク活用ガイドひとことで言うと#
デザインデータを「投げて終わり」にせず、実装に必要な情報を構造化して渡すプロセス。ハンドオフの質が低いと、エンジニアが推測で実装して手戻りが発生する。逆にハンドオフが整っていれば、「デザイン通りに実装された」状態にスムーズに到達できる。
押さえておきたい用語#
- デザイントークン（Design Token）
- 色・フォント・余白などのデザイン値を変数名で管理する仕組み。
color-primaryのように名前で指定し、デザインとコードの共通言語になる。 - レッドライン（Redline）
- デザインファイル上に各要素のサイズ・余白・色を数値で注釈した仕様書。Figmaのインスペクト機能で代替可能。
- エッジケース
- テキストが極端に長い・データが0件・エラー発生など、通常とは異なる境界条件のこと。ハンドオフで最も抜け落ちやすい。
- デザインレビュー
- 実装完了後にデザイナーが実装結果をデザインファイルと照合して差異を確認するプロセス。
デザインハンドオフの全体像#
こんな悩みに効く#
- 実装されたUIがデザインと微妙に違う
- エンジニアから「ここのスペースは何px？」と毎回聞かれる
- デザインは完成しているのに、実装後の手戻りが多い
基本の使い方#
以下の情報をデザインファイルに漏れなく記載する。
- レイアウト: 各要素のサイズ、余白、位置関係
- カラー: 使用色のHEX/RGB値（変数名があればそれも）
- タイポグラフィ: フォント名、サイズ、ウェイト、行間
- 画像・アイコン: 書き出し形式、サイズ、解像度
- 状態: hover / active / disabled / error / loading の各デザイン
- レスポンシブ: ブレークポイントごとのレイアウト変化
「書いてなくても分かるだろう」は手戻りの温床。明示的に記載する。
静止画のデザインだけでは伝わらない動的な振る舞いを文書化する。
- アニメーションの種類とデュレーション
- 画面遷移のパターン（モーダル / プッシュ / フェード）
- テキストが長い場合の処理（省略 / 折り返し / スクロール）
- 空状態（データがないとき）のデザイン
- エラー状態の表示内容とタイミング
Figmaのプロトタイプ機能やLottieで動きを見せるのも効果的。
ファイルを渡すだけでなく、15〜30分のウォークスルーを行う。
- デザイナーが画面を共有しながら意図を説明する
- エンジニアがその場で疑問点を質問する
- 技術的な制約があれば代替案をその場で議論する
- 合意した内容をデザインファイルのコメントに記録する
コツ: 実装開始前に行うこと。実装中に「実はここ違います」は最大のコストになる。
実装が完了したら、デザイナーが実装結果を確認する。
- デザインファイルと実装画面を並べて比較
- 差異があれば優先度をつける（ブロッカー / Nice to have）
- 軽微な差異は次スプリントに回してもOK
レビューはリリース前に行う。リリース後に「ここ違う」となると修正コストが倍増する。
具体例#
ハンドオフドキュメントの構成:
1. 画面デザイン（Figma）:
- デスクトップ版（1280px）とモバイル版（375px）のデザイン
- 各要素にオートレイアウトとスタイルが設定済み
2. 注釈シート（全18項目）:
- 商品画像: スワイプで切り替え、ピンチでズーム対応
- 価格表示: 税込・税抜を切り替えるトグル
- 「カートに追加」ボタン: タップ→ローディング（200ms）→完了アニメーション
- 在庫切れ時: ボタンが「再入荷通知を受け取る」に変化
- レビューセクション: 初期表示3件、「もっと見る」で追加読み込み
3. ハンドオフミーティングの記録:
- エンジニアからの質問: 「商品説明が1000文字超えた場合は？」
- 合意: 300文字で「もっと読む」を表示、タップで全文展開
結果: 手戻り0件で実装完了（以前は平均5件の修正が発生していた）。実装期間も2週間から1.5週間に短縮。
状況: デザイナー1名とエンジニア3名のチーム。以前はハンドオフ後にSlackで平均25件/機能の質問が発生していた。
改善策:
- Figmaファイルにデザイントークン名を注釈（
spacing-md: 16px、color-text-secondary: #6B7280） - 全状態（通常・ホバー・エラー・ローディング・空）をFigmaのバリアント機能で定義
- エッジケース集を別ページに作成（データ0件、1000件超、ネットワークエラー等）
- 30分のウォークスルーを録画し、チーム全員がいつでも見返せるようにした
結果: 実装中の質問が25件→5件に減少。 エンジニアのコメント「デザインファイルを見るだけで実装できるようになった」。チーム全体の開発速度が1.4倍に向上。
状況: フィットネスアプリの「ワークアウト記録」機能。デザイナーがFigmaで15画面を作成し、ハンドオフ。
デザインレビューで発見した差異（全8件）:
- ブロッカー（2件）: ローディングアニメーションが未実装、エラー時のリトライボタンがない
- 重要（3件）: フォントウェイトがBoldではなくSemiBold、余白が8px→12pxにズレ、カラーが#333ではなく#3A3A3A
- Nice to have（3件）: 影の深さ、角丸の微差、アイコンサイズ
対応: ブロッカーは即修正。重要はリリース前に修正。Nice to haveは次スプリントへ。この仕分けにより、リリースを予定通り行いながら品質も確保できた。
やりがちな失敗パターン#
- 正常系だけ渡してエッジケースを省略する — エラー状態、空状態、テキストが極端に長い/短い場合のデザインがないと、エンジニアが独自判断で実装する。エッジケースこそ事前に定義する
- デザインツール上の値とCSSの値がズレる — Figmaの数値とCSS実装の値が一致しない場合がある。デザイントークンを使って共通言語化するのがベスト
- ハンドオフを一方通行にする — 「渡したから後はよろしく」は最悪のパターン。実装中の質問チャンネルを設け、デザインレビューまでをハンドオフのスコープとする
- ウォークスルーを省略する — 「Figmaを見ればわかるでしょ」という態度は手戻りの元。15分でも対面説明するだけで、実装精度が劇的に上がる
まとめ#
デザインハンドオフは「ファイルを渡す行為」ではなく「実装に必要な情報をすべて伝えるプロセス」。レイアウト・色・タイポグラフィの静的情報に加え、インタラクション・エッジケース・レスポンシブの動的情報を漏れなく記載する。ウォークスルーミーティングと実装後のデザインレビューをセットで行えば、手戻りを大幅に削減できる。