この記事の内容
あやね
FigmaのデザインをHTMLに移すには、まず「スタイルを参照して実装する」のか、「コード生成ツールで実装のたたき台を作る」のかを決めます。CSSスニペットをコピーしても、ページ全体のHTMLやフォームの送信処理ができるわけではありません。
この記事では、Pixsoでデザインを開発者へ引き継ぐ方法と、Anima・Builder.io・pxCodeでコードを生成する方法を分けて説明します。チームで画面を調整してから開発に渡す場合は、PixsoのUIデザインツールでFigmaファイルを読み込み、寸法やスタイル、画面の状態を共有できます。
1. Pixsoでデザインとスタイルを開発へ渡す
PixsoでFigmaファイルを読み込む方法は、チームでデザインを確認し、実装に必要な情報を渡すために使います。この手順は、完成したHTMLプロジェクトの書き出し手順ではありません。
Pixsoで確認する情報
Pixsoはブラウザで画面を作成・共有できるデザインツールで、Figmaファイルのインポートにも対応しています。読み込み後は、元のファイルと見比べながらフォント、画像、コンポーネントの状態を確認し、実装に必要な画面を整理します。
引き継ぎは、次の順で進めると取り違えを防げます。
1. 元ファイルと利用権限を確認する。編集・書き出しが許可されたFigmaファイルを用意し、Pixsoのワークスペースを開きます。
2. Figmaファイルをインポートする。インポート機能からファイルを読み込み、元の画面と比較します。文字の折り返しや画像の欠落など、表示の差はこの段階で調整します。
3. 対象の要素を選び、開発向けの情報を確認する。ハンドオフ用の表示で寸法、余白、色などを確認し、どの画面・状態を実装するのかを開発者とそろえます。
4. CSSはスタイルの参考として使う。確認・コピーしたCSSスニペットを既存のコンポーネントやスタイル設計に合わせて取り込みます。見出し、リンク、ボタンなどのHTML要素、キーボード操作、データ取得や保存は別に実装します。
2. コードを生成する三つの選択肢
生成コードから実装を始めたい場合は、出力形式に加え、既存のコンポーネントや開発環境に合わせて直せるかを比べます。まず小さな画面やカードを一つ試すと、全画面を変換する前に修正量を把握できます。
1. Anima
AnimaのFigma連携では、FigmaのデザインからHTML/CSSやReactなどのコードを生成できます。静的なHTMLが必要なのか、アプリのコンポーネントとして組み込みたいのかを先に決めてから出力を選びます。
- Figma用Animaプラグインなど、Animaが案内する連携方法で対象のデザインを取り込みます。
- 必要な出力形式を選び、プレビューでレイアウト、画像、文字の折り返しを確認します。
- コードを開発環境へ移し、既存のスタイルや部品に合わせます。見た目だけでなく、リンク先、フォームのラベル、操作後の状態まで実装します。
上の画像はプラグインを使う流れの参考です。図中の古いボタン名を探すよりも、取り込み・プレビュー・コード出力の各段階で、何を確認するかを押さえておきましょう。
2. Builder.io
Builder.ioのFigma取り込みは、デザインをBuilder側へ渡してコード化する流れです。既存サイトをFigmaへ取り込む「HTML to Figma」は逆方向の機能であり、それを選ぶだけでFigmaからHTMLを出力できるわけではありません。
- Figmaで対象のフレームを選び、Builderのプラグインを開きます。
- Smart Exportなどのエクスポート機能でデザインをBuilder側へ渡します。
- プロジェクトのフレームワークやコードの書き方に合わせて出力を調整し、コードを取り込みます。既存の部品を使う場合は、同じ役割の部品を重複して作っていないか確認します。
3. pxCode
pxCodeは、Figmaのデザインを取り込み、レイアウトを調整してHTMLやReact、Vueなどのコードを出力するツールです。特に、画面幅が変わったときの要素の並び方を、出力前に確認する用途があります。
- pxCodeが案内するFigma連携で、対象のデザインを取り込みます。
- ページ内の要素のまとまりを確認し、横並び・縦並びや余白を調整します。
- 広い画面と狭い画面で、文字の折り返し、画像の大きさ、表示順を確認します。
- 必要な形式でコードを出力し、実際の開発環境で表示と操作を確認します。
3. 料金カードを例に、HTMLで何を確認するか
たとえば、プラン名、月額料金、機能一覧、「このプランを選ぶ」ボタンを持つ料金カードを移すとします。元のデザインどおりに一度表示できても、料金の更新や長い文言、決済画面への移動まで正しく動くとは限りません。
| 対象 | デザインで渡す内容 | 実装後に確認すること |
|---|---|---|
| 料金と支払周期 | 金額、通貨、月払い・年払いの区別 | 表示と選択した契約条件が一致し、金額変更時も単位が欠けない |
| 機能一覧 | 短い文言と長い文言の例 | 文字が増えても途中で隠れず、隣のカードと重ならない |
| 選択ボタン | 選択後の遷移先と渡すプラン | 適切なリンクまたはボタンとして操作でき、選んだプランが次の画面に引き継がれる |
| 読み込み・失敗時 | 料金を取得できないときの表示と再試行 | 古い料金のまま契約を進めず、利用者に次の行動を示す |
| 狭い画面 | カードの並び順と比較に必要な情報 | 見た目の順序だけでなく、キーボードや読み上げ時の順序にも意味が通る |
最初は一つのカードを、通常幅・狭い幅・長い文言の三つで試します。その後、キーボードで選択できるか、フォーカスが見えるか、画像に適切な代替テキストがあるかを確認します。契約情報の保存や決済処理は、生成された見た目とは別に開発・検証が必要です。
デザイナーと開発者は、生成コードをそのまま採用する範囲と、既存のコンポーネントで置き換える範囲を決めておきます。余白を一か所直すために多数のページを編集する状態なら、部品とスタイルの共通化を先に見直したほうが、その後の変更を扱いやすくなります。
4. 見た目の変換と、使えるページの実装をつなぐ
スタイルを正確に伝えるならデザインの共有とCSSの参照、実装のたたき台が必要ならコード生成ツールというように、目的から方法を選びましょう。いずれの場合も、通常時だけでなく、長い文字や狭い画面、読み込み失敗時まで対象に含めます。
HTMLに移した後の修正のしやすさは、見た目の再現度と同じくらい重要です。料金カードのような小さな単位で確かめてから、残りの画面へ進めると、チームに合う方法を判断できます。
