デザイナー向け:FigmaのHTML書き出しテクニック
はじめに:FigmaとWeb制作、そしてデザイナーの新たな役割
近年、デザインツールはAdobe XDやSketchと並び、Figmaが業界標準としての地位を確立しました。複数人での同時編集、Webブラウザベースでの動作、豊富なプラグインエコシステムなど、Figmaがもたらす利便性は、チームでの制作を圧倒的に効率化しました。特に、Web制作のワークフローにおいて、Figmaはデザインカンプ作成からプロトタイピング、そして開発への引き渡しまで、中心的な役割を担っています。
一方で、多くのデザイナーが抱く疑問や要望として、「FigmaのデザインをそのままHTMLに書き出したい」というものがあります。デザインツールで完成したビジュアルが、ワンクリックでWebサイトとして生成される。これは非常に魅力的ですが、現実にはそう単純ではありません。多くの自動書き出しツールやプラグインは存在しますが、生成されるコードが開発の現場でそのまま使える高品質なものであることは稀です。コードの構造がセマンティックでなかったり、CSSが無駄に複雑だったり、メンテナンス性が低かったりといった問題が発生しがちです。
ここで重要なのは、「FigmaのHTML書き出しテクニック」が、単にツール任せの自動化を指すのではなく、デザイナー自身がHTML/CSSの構造や仕組みを理解し、開発者が効率的にコードを記述できるようなFigmaファイルを作成する技術であるという点です。
Web制作において、デザイナーと開発者(コーダー、フロントエンドエンジニア)の連携は不可欠です。デザイナーがコードの視点を持ってFigmaでデザインを構築することで、デザインの意図がより正確に開発者に伝わり、手戻りが減り、最終的な成果物であるWebサイトの品質(表示速度、アクセシビリティ、メンテナンス性など)が向上します。
本記事は、主にWebデザインに携わるデザイナーの方々を対象としています。HTMLやCSSの専門家である必要はありませんが、基本的な概念(タグ、クラス、プロパティ、ボックスモデルなど)についてある程度の理解があることを前提としています。約5000語という分量で、Figmaで「開発しやすいデザイン」を作成するための構造設計、スタイル管理、コンポーネント設計、そしてオートレイアウトの活用方法など、実践的なテクニックを詳細に解説します。最終的には、Figmaファイルそのものが、開発者にとって高品質な仕様書となることを目指します。
さあ、Figmaでより効果的なWebデザインを行うための旅に出かけましょう。
FigmaからHTMLへの変換の現状と課題:なぜ自動書き出しだけでは不十分なのか
前述の通り、「Figmaからボタン一つで完璧なHTML/CSSコードが生成される」という理想は、現状では限定的なケース(ランディングページのような静的なコンテンツの一部など)を除いて、完全に実現されていません。その理由と、そこから見えてくるデザイナーの役割について掘り下げます。
自動書き出しツールの限界
Figmaのデザインをコードに変換するツールやプラグインは多数存在します。CodeMagic、Anima、Builder.ioなどが代表例です。これらのツールは、Figmaのレイヤー情報やプロパティ(サイズ、位置、色、フォント、角丸など)を読み取り、対応するHTML要素やCSSスタイルを生成します。
しかし、多くの場合、生成されるコードには以下のような課題があります。
-
セマンティックな構造の欠如:
- Figmaのフレームやグループは、単なる視覚的なグルーピングであり、HTMLにおける
<header>
,<nav>
,<main>
,<article>
,<aside>
,<footer>
といった要素が持つ意味(セマンティクス)を理解しません。多くのツールはこれらをすべて<div>
で出力してしまいます。 - 見出しなのか、段落なのか、リストなのかといったテキストの意味的な区別も、テキストレイヤーのサイズやスタイルだけでは判断できません。
- これにより、スクリーンリーダーを利用するユーザーや検索エンジンのクローラーにとって理解しにくい、アクセシビリティの低いコードになります。
- Figmaのフレームやグループは、単なる視覚的なグルーピングであり、HTMLにおける
-
非効率的でメンテナンス性の低いCSS:
- Figmaで設定された個々のレイヤーのスタイルを、そのままインラインスタイルや、要素ごとにユニークなクラス名を持つCSSルールとして出力しがちです。
- 共通するスタイル(例えば、サイト全体のボタンのスタイル)が効率的にまとめられておらず、同じようなCSSが重複して記述されます。
- スタイルの変更が発生した場合、一箇所を修正するだけで全体に反映されるような設計になっていないため、メンテナンスに膨大なコストがかかります。
- 現代的なCSS設計手法(BEM, SMACSS, CSS Modulesなど)や、CSSフレームワーク(Tailwind CSS, Bootstrapなど)と連携させることも困難です。
-
レスポンシブデザインへの対応不足:
- Figmaの制約(Constraints)機能は、あくまでFigma上でのサイズ変更シミュレーションであり、CSSのメディアクエリを使った柔軟なレスポンシブ対応とは異なります。
- 自動書き出しツールが、複雑なレスポンシブレイアウト(例えば、画面幅によって要素の並び順が変わる、表示/非表示を切り替えるなど)を正確にコード化するのは困難です。
-
インタラクティブ要素の表現不足:
- ボタンのホバー状態や、アコーディオンメニューの開閉、フォームの入力検証といったJavaScriptによる動的な挙動は、デザインツールだけでは表現しきれません。プロトタイプ機能で動きを表現できても、それをコードに変換することはできません。
これらの課題から分かるように、自動書き出しツールは「デザインを視覚的に再現する」ことはできても、「開発効率が高く、質が高く、メンテナンスしやすいコードを生成する」ことには限界があります。Webサイトは単なる静的な画像ではなく、ユーザーが操作し、多様なデバイスで閲覧され、将来的に更新されるものです。そのためには、人間が構造と意味を理解して記述するコードが不可欠です。
人間によるコーディングの必要性
結局のところ、Figmaデザインを高品質なWebサイトとして実現するには、HTML、CSS、JavaScriptを用いて人間がコーディングする必要があります。
しかし、これはデザイナーがコードを書く必要はない、という意味ではありません。現代のWeb制作において、デザイナーと開発者の境界は曖昧になりつつあります。全てのデザイナーがフルスタックエンジニアになる必要はありませんが、開発のプロセスや使用される技術について理解することで、デザインの引き渡しが格段にスムーズになり、最終的なプロダクトの質も向上します。
デザイナーとコーダー間の連携の重要性
デザインは開発のための出発点です。デザイナーが作成したFigmaファイルは、開発者にとっての設計図であり、仕様書となります。この「設計図」の質が、開発の効率とコードの質に直結します。
開発者は、Figmaファイルを見て、以下の情報を読み取ります。
- 構造: どの要素がどの要素の子要素で、どのようにグループ化されているか。
- レイアウト: 要素がどのように配置され、整列されているか。幅、高さ、要素間の距離はいくつか。レスポンシブ時の挙動は?
- スタイル: 色、フォント、サイズ、ボーダー、シャドウ、背景画像などの視覚的なスタイルは何か。
- インタラクション: ボタンのホバー時の見た目、クリック時の挙動、アニメーションは?
- アセット: 画像、アイコンはどのような形式でエクスポートすれば良いか。
デザイナーがFigmaでこれらの情報を明確に、かつ開発者が理解しやすい形で整理して表現することが、「書き出しやすいFigmaデザイン」を作成するということです。これは、デザイナーがコードを書くことよりも、デザイナーがコードを意識してデザインを構築することに重点を置きます。
次の章からは、具体的にFigmaでどのようにデザインを構築すれば、開発者が「書き出しやすい」、つまりコードに変換しやすいファイルになるのか、その原則とテクニックを詳細に見ていきます。
「書き出しやすいFigmaデザイン」の原則
開発者がコードに変換しやすいFigmaデザインを作成するためには、いくつかの重要な原則があります。これらの原則は、HTML/CSSの構造や特性を理解し、それをFigmaの機能を使って効果的に表現することに基づいています。
1. 構造の設計:HTMLを意識したレイヤー構造とフレーム/グループの活用
HTMLはドキュメントに構造を与えるマークアップ言語です。見出し、段落、リスト、セクション、ナビゲーションなど、それぞれの要素には意味(セマンティクス)があります。Figmaのレイヤー構造は、このHTMLの構造を模倣するように設計されるべきです。
- レイヤー構造の重要性:
- Figmaの左側のレイヤーパネルは、そのままHTMLのDOMツリー(要素の親子関係)に対応すると考えることができます。
- 親フレームやグループはHTMLのコンテナ要素(例:
<div>
,<section>
,<article>
)に、その中の子レイヤーはコンテナ内の要素に対応します。 - 要素のネスト(入れ子構造)を明確にすることで、開発者はHTMLの構造を理解しやすくなります。
- フレームとグループの使い方:
- Figmaの「フレーム」は、CSSでいうところのブロックレベル要素や、レイアウトコンテナ(Flexboxコンテナ、Gridコンテナ)として扱うのに適しています。フレームは自身の中にレイアウト設定(オートレイアウト)を持つことができ、子要素の配置や間隔を制御できます。これは
div
やsection
などにdisplay: flex;
やdisplay: grid;
を適用するのと似ています。 - 「グループ」は、複数のレイヤーをまとめて移動したり拡大縮小したりするのに便利ですが、それ自体はレイアウト設定を持ちません。HTMLに変換する際は、単なる
<div>
になるか、あるいは構造によってはグループ化が不要になる場合もあります。できる限り、レイアウトの制御にはフレームとオートレイアウトを使用することを推奨します。 - 意味的なセクション(例: ヘッダー、フッター、メインコンテンツ、サイドバー、記事一つ分)は、それぞれ独立したフレームとして作成し、適切な名前を付けましょう。これはHTMLの
<header>
,<footer>
,<main>
,<aside>
,<article>
などのセマンティックタグに対応させやすくなります。
- Figmaの「フレーム」は、CSSでいうところのブロックレベル要素や、レイアウトコンテナ(Flexboxコンテナ、Gridコンテナ)として扱うのに適しています。フレームは自身の中にレイアウト設定(オートレイアウト)を持つことができ、子要素の配置や間隔を制御できます。これは
- Semantic HTMLを意識した命名規則:
- Figmaのレイヤー名やフレーム名は、開発者にとって非常に重要な情報源です。これらの名前に、HTMLのセマンティクスやCSSのクラス名を意識した名前を付けましょう。
- 例えば、「ヘッダー領域」は
header
フレーム、「ナビゲーション」はnav
フレーム、「主要コンテンツ」はmain-content
フレーム、「記事一つ分」はarticle-card
フレームのようにします。 - ボタンは
button-primary
、入力フォームはinput-text
、リストアイテムはlist-item
など、コンポーネントや要素の役割を示す名前を付けます。 - 単に「Group 1」「Rectangle 2」のようなデフォルトの名前のままにしないことが極めて重要です。
2. オートレイアウトの徹底活用:Flexbox/Gridを意識したレイアウト設計
オートレイアウトはFigmaの最も強力な機能の一つであり、これがHTML/CSSのFlexboxやGridと非常に密接に対応します。オートレイアウトをマスターすることは、「書き出しやすいFigmaデザイン」作成の要となります。
- オートレイアウトの基本的な使い方のおさらい:
- 複数の要素を選択し、Shift + Aでオートレイアウトコンテナを作成します。
- オートレイアウトコンテナは、子要素を一定の方向(水平または垂直)に配置し、要素間の間隔や配置(開始、中央、終了、均等配置など)を自動的に調整します。
- 親コンテナのリサイズに応じて、子要素の幅や高さを自動調整したり、固定したりする設定も可能です(Constraintsではなく、オートレイアウト内の
Resizing
設定を使用します)。
- Flexboxへの変換を意識した設定:
- オートレイアウトの方向設定(HorizontalまたはVertical)は、Flexboxコンテナの
flex-direction: row;
またはflex-direction: column;
に対応します。 - オートレイアウトの「Space between items」設定は、CSSの
gap
プロパティに直接対応します。または、子要素に自動的にマージンが適用されると考えることもできます。 - 「Alignment」設定(左上、中央揃え、右下など)は、Flexboxコンテナの
justify-content
(主軸方向の配置)とalign-items
(交差軸方向の配置)に対応します。 - オートレイアウトコンテナの
Wrap
設定は、Flexboxコンテナのflex-wrap: wrap;
に対応し、子要素がコンテナの幅を超える場合に折り返すレイアウトを表現できます。これは、複数のタグボタンやカードなどを横並びに配置し、画面幅が狭くなると自動的に改行するようなレイアウトで非常に有用です。 - 子要素の
Resizing
設定は、Flexboxの子要素(Flexアイテム)のサイズに関するプロパティ(flex-grow
,flex-shrink
,flex-basis
)に対応します。Fixed width/height
: 子要素のサイズを固定します。CSSではflex-shrink: 0;
と共に固定幅を指定するのに近いです。Hug contents
: 子要素自身のコンテンツサイズに合わせて親要素のサイズが決まります。Fill container
: 親要素の残りのスペースを埋めるように子要素が伸縮します。これはCSSのflex-grow: 1;
に相当し、可変幅カラムなどを実現するのに不可欠です。
- オートレイアウトの方向設定(HorizontalまたはVertical)は、Flexboxコンテナの
- Gridへの応用(複雑なレイアウト):
- オートレイアウトは主に一次元(水平または垂直)のレイアウトに適していますが、二次元のレイアウト(Grid)を表現する際にも補助的に使用できます。
- 例えば、カードが並ぶグリッドレイアウトを作成する場合、各カードはオートレイアウトで内部構造を整え、複数のカードを水平方向のオートレイアウトで並べ、さらにそれが折り返す設定(Wrap)にすることで、CSS Gridの自動配置(
grid-template-columns: repeat(auto-fill, minmax(min_width, 1fr));
のような)に近い挙動を表現できます。より複雑なGridレイアウトの場合は、Figma上ではフレームとオートレイアウトの組み合わせで表現し、開発者にはコメントや仕様書でGridを使用する意図を伝えるのが良いでしょう。
- ネストされたオートレイアウト:
- 実際のWebレイアウトは、複数のFlexboxコンテナやGridコンテナが入れ子になった複雑な構造をしています。これをFigmaで表現するために、オートレイアウトコンテナの中に別のオートレイアウトコンテナを配置する「ネストされたオートレイアウト」を積極的に活用しましょう。
- 例: ヘッダー(水平オートレイアウト、子要素としてロゴ、ナビゲーション(これも水平オートレイアウト)、検索フォームなど)、カードコンポーネント(垂直オートレイアウト、子要素として画像、タイトル(テキスト)、本文(テキスト)、ボタン(水平オートレイアウト)など)。
オートレイアウトを正しく使用することで、Figma上でのデザイン変更が容易になるだけでなく、開発者はその構造を見て、どの要素にdisplay: flex;
やdisplay: grid;
を適用すれば良いか、要素間のgap
やpadding
はいくつにすれば良いか、要素の伸縮はどう設定すれば良いかなどを、迷うことなくコードに落とし込むことができます。これは、ピクセルパーフェクトなデザインを実現する上で非常に強力な手助けとなります。
3. コンポーネントの設計:再利用可能な部品化
Webサイトは、ヘッダー、フッター、ボタン、カード、フォーム要素など、多くの再利用可能な部品(コンポーネント)で構成されています。Figmaのコンポーネント機能は、これをデザインツール上で実現するものです。Figmaでコンポーネントを適切に設計することは、開発におけるコンポーネント指向のアプローチ(React, Vue, AngularなどのJavaScriptフレームワークや、CSSのコンポーネント設計手法など)と非常に相性が良く、開発効率とメンテナンス性を大幅に向上させます。
- 再利用性とメンテナンス性:
- マスターコンポーネントを作成し、それをインスタンスとして各所に配置することで、デザインの一貫性を保ちやすくなります。
- マスターコンポーネントを修正すれば、全てのインスタンスにその変更が反映されるため、デザインのアップデートが容易になります。これは、開発において共通のコンポーネントを修正すればサイト全体の見た目が更新されるのと全く同じ考え方です。
- PropsとVariants:カスタムプロパティや状態変化の表現
- Figmaのコンポーネントプロパティ(Properties)機能は、開発におけるコンポーネントのProps(プロパティ)に相当します。テキストプロパティ(ボタンのラベル)、ブール値プロパティ(アイコンの表示/非表示)、インスタンススワッププロパティ(アイコンの種類)、バリアント(Variants)などを活用することで、一つのマスターコンポーネントから多様なバリエーションを持つインスタンスを作成できます。
- 特にバリアントは、ボタンのデフォルト状態、ホバー状態、アクティブ状態、無効状態など、要素の状態変化を表現するのに最適です。開発者はこれらのバリアントを見て、CSSの
:hover
,:active
,:disabled
などの擬似クラスや、JavaScriptによる状態管理と結びつけてコードを記述できます。 - フォーム入力欄の通常時、フォーカス時、エラー時などもバリアントで表現すると、開発者は必要なスタイルを把握しやすくなります。
- HTML/CSSでのコンポーネント化を想定した設計:
- Figmaのコンポーネントの粒度は、開発で作成するコンポーネントの粒度と合わせることを意識しましょう。例えば、カード全体を一つのコンポーネントにする場合、その内部要素(画像、タイトル、本文、ボタンなど)はカードコンポーネントの子要素として含まれるように設計します。
- コンポーネントの命名も重要です。開発者が使用するであろうコンポーネント名やCSSクラス名を意識した名前を付けましょう(例:
Button/Primary
,Card/Product
,Form/InputText
)。 - コンポーネント内のレイアウトは、オートレイアウトで構築することを徹底します。これにより、開発者はコンポーネントの内部構造をFlexboxやGridで容易に再現できます。
4. スタイルの管理:スタイルガイドと変数/スタイルの活用
Webサイトのスタイル(色、フォント、スペーシングなど)は、CSSで一元管理されることが理想です。Figmaのスタイル機能や変数機能は、このCSSのスタイル定義と非常に良く対応します。
- スタイルガイドの徹底:
- サイトで使用する全てのカラーパレット、タイポグラフィ(フォントファミリー、サイズ、ウェイト、行高、字間)、スペーシング(余白の単位)、エフェクト(シャドウ、ぼかし)などをFigmaのローカルスタイルとして定義し、管理します。
- これにより、デザインの一貫性が保たれるだけでなく、開発者はスタイルガイドを参照することで、デザインシステムで使用されている値を正確に把握できます。
- 変数(Variables)の活用(CSSカスタムプロパティを意識):
- Figmaの変数機能は、まさにCSSカスタムプロパティ(
--primary-color: #007bff;
のような変数)に相当します。 - 色、数値(スペーシング、角丸、ブレークポイントなど)、文字列などに変数を定義し、デザイン全体で利用します。
- 例えば、プライマリーカラーを
--color-primary
という変数に、要素間の標準的な余白を--spacing-md
のような変数に割り当てておきます。これにより、デザイン内で使用されている値が単なるマジックナンバーではなく、意味を持った変数として表現されます。 - モード(Modes)機能を使えば、ダークモードやテーマごとのカラーセットを管理することもでき、これはCSSでのテーマ切り替え実装と連携しやすいです。
- Figmaの変数機能は、まさにCSSカスタムプロパティ(
- スタイル(Styles)の活用:
- 変数を使って定義した基本的な値を組み合わせ、特定の目的のためのスタイルを作成します(例: プライマリーボタンの背景色、テキスト色、ホバー時のスタイルをまとめた
Button/Primary/Default
スタイル)。 - タイポグラフィスタイルは、見出し(H1, H2…)、本文、キャプションなど、テキストの役割ごとに定義します。これにより、開発者はCSSで対応するスタイル(例:
.heading-1
,.body-text
)を定義しやすくなります。
- 変数を使って定義した基本的な値を組み合わせ、特定の目的のためのスタイルを作成します(例: プライマリーボタンの背景色、テキスト色、ホバー時のスタイルをまとめた
- スペーシングの設計(オートレイアウトの間隔設定と統一):
- 要素間の余白や、コンテナ内のパディングは、デザインの構造を理解する上で非常に重要です。
- オートレイアウトの間隔設定や、フレーム内のパディング設定を積極的に活用し、余白の値を明確にします。
- 余白の値は、定義したスペーシング変数(例: 8ptグリッドシステムに基づく8px, 16px, 24pxなど)を使用することで、一貫性を保ち、開発者もこれらの変数をCSSで使用しやすくなります。
- 単に要素を手動で配置して距離を測るのではなく、オートレイアウトで余白を制御することで、レスポンシブ時のレイアウト崩れを防ぎやすくなります。
5. アセットのエクスポート設定:画像、SVG、アイコンの最適化
Webサイトで使用される画像やアイコンは、ファイル形式やサイズがパフォーマンスに大きく影響します。デザイナーが適切な形式と解像度でアセットを準備し、Figma上でエクスポート設定を明確にしておくことが重要です。
- 形式の選択:
- 写真などの複雑な画像:JPGまたはWebP(最近ではWebPが推奨されることが多い)
- ロゴやイラスト、透過が必要な画像:PNG
- アイコンやシンプルなイラスト、ロゴ:SVG (Scalable Vector Graphics)
- 解像度とサイズの最適化:
- Retinaディスプレイなどの高解像度ディスプレイに対応するため、必要に応じて
@2x
などの倍率で画像を書き出す設定をしておきます。 - ただし、むやみに大きな画像を書き出すのではなく、表示サイズに応じた適切な解像度を選択することが重要です。
- Figmaの「Export」設定で、形式、倍率、および必要であればスライス設定を行います。
- Retinaディスプレイなどの高解像度ディスプレイに対応するため、必要に応じて
- SVGの使い方:
- アイコンなどは可能な限りSVG形式でエクスポートしましょう。SVGはベクター形式なので拡大縮小しても劣化せず、CSSで色やサイズを変更できるため非常に柔軟です。
- FigmaのSVGエクスポート設定で、「Include ‘id’ attribute」や「Include ‘class’ names」のオプションを検討します。開発者がSVG内部の要素にスタイルを適用したい場合に役立ちます。
- ただし、複雑すぎるSVGはファイルサイズが大きくなったり、描画パフォーマンスに影響したりする場合があるため注意が必要です。
6. インタラクションとアニメーション:動きの仕様伝達
Webサイトは静的なデザインだけでなく、ユーザーの操作に応じた動き(ホバーエフェクト、クリック時の反応、ページ遷移アニメーションなど)によってユーザー体験が大きく左右されます。デザイナーはFigmaのプロトタイプ機能やその他の手段を用いて、これらの動きの仕様を開発者に正確に伝える必要があります。
- プロトタイプ機能の活用:
- ボタンのホバー時の色の変化、ナビゲーションメニューの開閉、モーダルウィンドウの表示/非表示といった基本的なインタラクションは、Figmaのプロトタイプ機能(特にSmart Animate)を使って表現し、開発者に共有します。
- これにより、単なる静的なデザインカンプでは伝わりにくい動きのタイミングや見た目を具体的に示すことができます。
- インタラクションを考慮したコンポーネント設計:
- インタラクティブな要素(ボタン、リンク、入力欄など)は、必ずデフォルト状態だけでなく、ホバー、アクティブ、フォーカス、無効などの状態をバリアントとして作成しておきましょう。これは前述のコンポーネント設計の重要な一部です。
- アニメーションの仕様を伝える方法:
- 複雑なアニメーション(要素が滑らかに移動しながらフェードインするなど)は、Figmaのプロトタイプだけでは正確に表現しきれない場合があります。
- このような場合は、After Effectsなどで作成した動画モックアップを共有したり、仕様書にアニメーションの種類(例: Fade In Up)、速度(例: 300ms)、イージング(例: ease-out)、ディレイ(例: 100ms)などを記述したりして、開発者に詳細な仕様を伝える必要があります。CSSアニメーションやJavaScriptアニメーションライブラリ(GSAPなど)の知識がある開発者であれば、具体的なプロパティ名(例:
transition-property: opacity, transform; transition-duration: 0.3s; transition-timing-function: ease-out;
)で伝えるのも有効です。
これらの原則を意識してFigmaでデザインを構築することで、ファイルそのものが開発者にとって非常に分かりやすく、コードに変換しやすい「高品質な仕様書」となります。次の章では、これらの原則がFigmaの具体的な操作とどのように結びつくのか、さらに掘り下げていきます。
具体的なHTML/CSS変換テクニック(Figma操作の視点から)
これまでの原則を踏まえ、Figmaの各機能がどのようにHTML/CSSのコードに変換されるのか、より具体的なテクニックを見ていきましょう。これは、デザイナーがFigmaを操作する際に「この操作はコードではこうなるな」と意識できるようになるための訓練でもあります。
1. レイヤー構造とHTMLタグのマッピング
Figmaのレイヤーやフレームが、HTMLのどの要素に対応するかを明確に意識します。
- フレーム ->
div
,section
,article
など:- デザインの主要なコンテナ、セクション、独立したコンテンツブロックはフレームで作成します。
- フレーム名でその役割を明確にします (
header
,main-content
,product-list
,news-article
)。開発者はこれらのフレームを見て、対応するHTMLタグ(<header>
,<main>
,<section>
,<article>
など)を選択します。 - オートレイアウトが適用されたフレームは、FlexboxまたはGridコンテナに対応すると開発者は理解します。
- グループ ->
div
または構造の見直し:- グループはレイアウト機能を持たないため、特別な理由がない限りフレーム(オートレイアウトを含む)に置き換えることを検討しましょう。
- もしグループを使う場合は、単に複数の要素をまとめるための
<div>
として出力されることが多いです。
- テキストレイヤー ->
h1
~h6
,p
,span
,a
,li
など:- テキストレイヤーは、その役割に応じて適切なHTMLタグに変換されるべきです。
- Figma上では、テキストスタイル(H1, H2, Bodyなど)や、レイヤー名(
page-title
-><h1>
,article-heading
-><h2>
,paragraph
-><p>
,list-item-text
-><li>
内のテキスト)でその役割を伝えます。 - リンクとなるテキストは、明示的にアンダーラインを引いたり、スタイルガイドでリンクスタイルを定義したり、コメントでリンクであることを示したりします。ナビゲーション内の項目は、レイヤー構造をリスト構造(
<ul>
,<li>
)を意識して作成します。
- 画像レイヤー ->
img
:- 画像レイヤーは
<img>
タグに変換されます。 - レイヤー名で代替テキスト(alt属性)の内容を示唆する名前を付けると親切です(例:
product-photo-red-shoes
,user-avatar-john-doe
)。 - 画像が単なる装飾である場合は、レイヤー名で
decorative-image
などと示唆し、CSSのbackground-image
として実装される可能性があることを伝えます。
- 画像レイヤーは
- シェイプレイヤー ->
div
+ 背景色/ボーダー orsvg
:- 単純な長方形や円などのシェイプは、背景色やボーダーを持つ
<div>
要素として実装されることが多いです。 - より複雑なシェイプや、再利用されるアイコンなどは、SVGとしてエクスポートし、
<img>
タグやインラインSVG、またはCSSのbackground-image
として使用されます。
- 単純な長方形や円などのシェイプは、背景色やボーダーを持つ
- アイコン ->
svg
or フォントアイコン:- アイコンは前述の通りSVGでのエクスポートが推奨されます。
- Font Awesomeのようなフォントアイコンを使用する場合は、Figma上でも該当のフォントを使用し、レイヤー名やコメントでどのアイコンフォントを使用しているか、あるいはUnicodeを指定するなどして伝えます。
2. オートレイアウトとFlexbox/Gridへの変換
オートレイアウトの設定がどのようにCSSのFlexbox/Gridプロパティに対応するかを理解します。
Figma オートレイアウト設定 | 対応するCSSプロパティ(主にFlexbox) | 備考 |
---|---|---|
Direction: Horizontal | display: flex; flex-direction: row; |
子要素を横並びに配置 |
Direction: Vertical | display: flex; flex-direction: column; |
子要素を縦並びに配置 |
Space between items | gap (または子要素へのマージン) |
子要素間の余白 |
Padding (Horizontal/Vertical) | padding |
オートレイアウトコンテナのコンテンツ領域内の余白 |
Alignment (Packed) | justify-content (主軸方向), align-items (交差軸方向) |
子要素の配置(左揃え、中央揃え、右揃え、上揃え、下揃えなど) |
Alignment (Space between) | justify-content: space-between; |
主軸方向に子要素を均等に配置し、両端の要素をコンテナの両端に固定 |
Wrap | flex-wrap: wrap; |
コンテナ幅を超える場合に子要素を折り返す |
個別の子要素の Resizing: Fixed | flex-shrink: 0; + width/height 指定 (flex-basis を使うことも) |
要素のサイズを固定(親コンテナが縮小しても縮まない) |
個別の子要素の Resizing: Hug contents | flex-basis: auto; またはサイズ未指定(コンテンツに依存) |
要素のサイズが内容によって決まる |
個別の子要素の Resizing: Fill container | flex-grow: 1; (flex-shrink も考慮) |
親コンテナの残りのスペースを埋めるように伸縮 |
個別の子要素の Absolute position | position: absolute; (top , right , bottom , left 指定) |
オートレイアウトの流れから外して配置(特別なケース以外はオートレイアウトで完結させるのが望ましい) |
- 実践的な使い方:
- ヘッダーの左右レイアウト(ロゴとナビゲーション)→ 水平オートレイアウト + Space between。
- ナビゲーションメニュー項目 → 水平オートレイアウト + Gapで項目間の余白を指定。
- カードコンポーネント内部(画像、タイトル、本文、ボタン群)→ 垂直オートレイアウト + Gapで要素間の余白を指定。ボタン群自体は水平オートレイアウト。
- 可変幅の入力フォームやボタン → Fill container設定を適用。
- カラムレイアウト → 複数の垂直オートレイアウトフレームを水平オートレイアウトで並べる(Gridの代替としても使える)。
オートレイアウトをネストして複雑なレイアウトを構築することは、開発者がそれをFlexboxやGridの入れ子構造として理解し、コードを記述するための最も直接的な方法です。
3. スタイルの適用とCSSプロパティへの変換
Figmaで設定した視覚的なスタイルが、どのようなCSSプロパティに対応するかを意識します。スタイルガイドで定義した変数やスタイル名を、CSSのカスタムプロパティやクラス名と結びつけて考えます。
Figma スタイル設定 | 対応するCSSプロパティ | Figmaでのベストプラクティス |
---|---|---|
Fill (Color) | background-color , color (テキストの場合) |
ローカルスタイルまたは変数(--color-primary など)を適用。開発者はこれを見てカスタムプロパティやデザインシステム上のカラー変数を使用する。 |
Fill (Image) | background-image |
画像を選択し、FillをImageに設定。適切にトリミング/リサイズする。 |
Stroke | border (border-color , border-width , border-style ) |
太さ、色、スタイルの指定。色にはスタイルまたは変数を適用。 |
Corner radius | border-radius |
数値または変数(--radius-sm など)を適用。全ての角か特定の角かを指定。 |
Drop shadow, Inner shadow, Layer blur, Background blur | box-shadow , text-shadow , filter (blur) |
詳細なパラメータ(色、オフセット、ぼかし半径、スプレッド、ブレンドモード)を設定。スタイルとして定義すると便利。 |
Typography (Font, Size, Weight, Line height, Letter spacing, Paragraph spacing, Text alignment) | font-family , font-size , font-weight , line-height , letter-spacing , margin-bottom (段落間隔), text-align |
ローカルタイポグラフィスタイル(Heading/H1 , Body/Regular など)を適用。変数で定義した基本単位(例: font-size: var(--font-size-md); )を使用。 |
Opacity | opacity |
不透明度を設定。 |
Blend mode | mix-blend-mode , background-blend-mode |
要素のブレンドモードを設定(デザインとして特殊な効果が必要な場合)。 |
Constraints | レスポンシブデザインの挙動を示唆(直接的なCSSプロパティではない) | レスポンシブデザインのセクションで詳しく解説。 |
Effects (CSS Properties) | 個別のCSSプロパティ(例: transform: rotate(...) , box-shadow など) |
個別のプロパティとしてFigma上で適用されたもの。開発者はInspectorパネルで確認し、対応するCSSを記述する。 |
- Inspectorパネルの活用:
開発者はFigmaのInspectorパネルで選択された要素のプロパティを確認し、それをコードに変換します。デザイナーは、このパネルを見た開発者が、どのCSSプロパティが必要かを容易に理解できるようにデザインを整理することが重要です。スタイルや変数を適用することで、パネルには具体的な数値だけでなくスタイル名や変数名も表示されるため、開発者はデザインシステムとの連携をより効率的に行えます。
4. レスポンシブデザインへの対応
多様な画面サイズに対応するレスポンシブデザインは、現代のWeb制作では必須です。Figmaでレスポンシブデザインを表現し、その仕様を開発者に伝えるテクニックです。
- ブレークポイントの設計:
- デザインする画面サイズ(ブレークポイント)を明確に定義します(例: モバイル375px, タブレット768px, デスクトップ1280px)。
- それぞれのブレークポイントに対応するデザインを、Figma内で異なるフレームとして作成します。フレーム名にブレークポイントを記載すると分かりやすいです(例:
Homepage/Desktop
,Homepage/Tablet
,Homepage/Mobile
)。
- オートレイアウトと制約(Constraints)機能の活用:
- オートレイアウト: 前述のResizing設定(Fill container, Hug contents, Fixed)やWrap設定を組み合わせることで、親コンテナのサイズ変更に合わせて子要素がどのように振る舞うか(伸縮、折り返しなど)をシミュレーションし、FlexboxやGridによるレスポンシブレイアウトの挙動を表現します。これがレスポンシブデザインの核となります。
- 制約(Constraints): オートレイアウトが適用されていない要素(例えば、ページ内の固定位置に配置される要素や、特定の親要素に対して相対的に配置される要素)に対しては、Constraints機能(Left & Right, Top & Bottom, Center, Scaleなど)を設定し、親フレームのリサイズ時に要素がどのように追従するかを示します。これはCSSの
position: absolute;
や、Flex/Gridではない従来の配置方法に対応する場合があります。しかし、現代的なWeb制作ではオートレイアウト(Flexbox/Grid)によるレイアウトが主流であるため、可能な限りオートレイアウトで表現し、Constraintsの使用は限定的にすることをお勧めします。
- バリアント機能を使ったブレークポイントごとのデザイン作成:
- 特にコンポーネントレベルでブレークポイントによる見た目の変化が大きい場合(例: モバイルでハンバーガーメニューになるナビゲーション)、コンポーネントのバリアントとして異なるブレークポイントのデザインを用意すると管理しやすくなります。プロパティ名にブレークポイント名を付けるなどして区別します(例: プロパティ名:
Breakpoint
, 値:Desktop
,Mobile
)。
- 特にコンポーネントレベルでブレークポイントによる見た目の変化が大きい場合(例: モバイルでハンバーガーメニューになるナビゲーション)、コンポーネントのバリアントとして異なるブレークポイントのデザインを用意すると管理しやすくなります。プロパティ名にブレークポイント名を付けるなどして区別します(例: プロパティ名:
- デスクトップファースト vs モバイルファースト:
- Web制作の現場では、モバイルファースト(小さい画面からデザインを始め、徐々に大きい画面に対応していく)のアプローチが推奨されることが多いです。これは、モバイル環境でのパフォーマンスやユーザー体験が重要視されるためです。
- デザイナーもこの考え方を意識し、モバイルデザインから開始したり、Figmaファイル内でモバイルデザインを最初のフレームとして配置したりすることで、開発者との認識を合わせやすくなります。
5. インタラクティブ要素の表現
ボタンやフォームなどのインタラクティブ要素は、ユーザー体験に直結します。これらの要素のデザイン仕様を明確に伝える必要があります。
- コンポーネント化: ボタン、入力フォーム、チェックボックス、ラジオボタン、ドロップダウン、トグルスイッチなどのインタラクティブ要素は、必ずコンポーネントとして作成し、デザインシステムの一部として管理します。
- 状態のバリアント: 各インタラクティブ要素について、以下の状態に対応するバリアントを作成します。
- Default (通常時)
- Hover (ホバー時)
- Active (クリック/タップ時)
- Focus (キーボード操作でフォーカスされた時)
- Disabled (無効時)
- Error (入力エラー時)
- Success (入力成功時)
- アクセシビリティの考慮:
- フォーカス状態のデザイン(フォーカスリング)は、キーボード操作でサイトをナビゲートするユーザーにとって非常に重要です。必ずデザインし、開発者に伝える必要があります。
- 色のコントラスト比、テキストサイズ、要素間のクリック可能領域なども、アクセシビリティガイドライン(WCAGなど)を意識してデザインし、開発者に伝えます。
Figma以外のツールを使ったHTML書き出し(補助的な説明)
前述の通り、Figmaからの自動コード生成ツールには限界がありますが、特定の目的やワークフローにおいては役立つ場合もあります。また、デザインスペックの共有に特化したツールは、Figmaと開発者間の橋渡しとして有用です。
1. 公式Figma API / プラグイン
Figmaの豊富なAPIを利用した様々なプラグインが存在します。
- 自動コード生成系プラグイン (例: Anima, Builder.io, TeleportHQなど):
- 簡単な静的ページのプロトタイプ作成や、特定のセクションのコーディングのたたき台としては利用可能です。
- ただし、多くの場合、生成されるコードはプロダクションレベルではないため、開発者が大幅な修正やリファクタリングを行う必要があります。あくまで補助ツールとして捉えましょう。
- これらのツールを使用する場合でも、Figmaファイルが前述の「書き出しやすいFigmaデザイン」の原則に沿って構築されていることが、より良いコード生成につながります。
- 仕様エクスポート系プラグイン (例: Measure, Figma to Code (Speckly)):
- デザイン上の要素のサイズ、距離、色、タイポグラフィなどのスタイル情報を開発者が確認しやすい形で出力するプラグインです。
- Figmaの標準Inspectorパネルでも情報は確認できますが、これらのプラグインを使うことでより整理された形式で共有できる場合があります。
2. Zeplin, Abstractなどの連携ツール
Figmaからデザインをインポートし、開発者向けに特化した機能を提供するツールです。
- Zeplin:
- デザインからCSS、Swift、XMLなどのスタイルコードスニペットを自動生成し、要素間の距離測定、アセットのエクスポート、コメント機能などを提供します。デザイナーと開発者が共通のプラットフォームでデザイン仕様を確認するのに便利です。
- Abstract (Sketchとの連携が主だったが、Figma連携も強化):
- デザインファイルのバージョン管理、変更履歴の追跡、レビュー機能などを提供し、デザインチームと開発チームの連携を強化します。Gitのようなワークフローをデザインにも導入するイメージです。
これらのツールは、Figmaファイルそのものを直接HTMLに変換するものではなく、Figmaで作成したデザインの仕様を開発者が効率的に把握し、コーディングを進めるための補助ツールです。デザインハンドオフのプロセスを改善する上で有効活用できます。
デザイナーとコーダーの連携を円滑にするために
「書き出しやすいFigmaデザイン」を作成することは、最終的にデザイナーと開発者の連携を円滑にし、プロジェクト全体の成功に貢献するためのものです。ここでは、デザインハンドオフのベストプラクティスと、より良いコミュニケーションのためのヒントを紹介します。
デザインハンドオフのベストプラクティス
デザインが完了し、開発に着手する段階を「デザインハンドオフ」と呼びます。このプロセスを丁寧に行うことで、開発者は迷うことなくコーディングを進めることができます。
- 仕様書の作成:
- Figmaファイル自体が最も重要な仕様書ですが、それに加えて補足情報をまとめたドキュメントを作成するとより親切です。
- 内容例:
- プロジェクト概要と目標
- 使用するブレークポイント一覧
- レスポンシブ時のレイアウト変更ルール(例: モバイルではこの要素は表示しない、この要素は並び順が変わるなど)
- 主要なコンポーネントのリストとそのバリアントの説明
- インタラクション・アニメーションの具体的な仕様(秒数、イージングなど)
- 使用するフォント(Webフォントか、ローカルフォントか)
- デザインシステムへのリンク(あれば)
- 備考事項や注意点
- Figmaファイルの整理整頓:
- 開発者がFigmaファイルを開いたときに、どこに何があるか、どのデザインが最新かなどがすぐに分かるように整理しておきます。
- 不要なレイヤーやページは削除します。
- レイヤー名やフレーム名、コンポーネント名、スタイル名、変数名は、前述の命名規則に従って統一し、分かりやすい名前をつけます。
- デザインカンプのフレームを、ページごとやセクションごとに分かりやすく配置します。
- コメント機能の活用:
- Figmaのコメント機能を積極的に利用して、デザインの意図や仕様について開発者に直接書き込みます。
- 例: 「この要素はクリックで詳細が表示されます」「ここの余白は上の要素との間にのみ適用してください」「この画像は背景画像として実装してください」など。
- 開発者からの質問に対しても、コメントで迅速に回答します。
共通言語の重要性
デザイナーと開発者が円滑にコミュニケーションを取るためには、共通の言葉で話すことが重要です。
- HTML/CSS用語の理解: デザイナーがFlexbox, Grid, マージン、パディング, ボーダー, Z-index, ポジションなどの基本的なCSS用語や、ヘッダー, フッター, セクション, ナビゲーション, リストといったHTMLタグの意味を理解することで、開発者との会話がスムーズになります。「ここのパディングは〇〇pxでお願いします」「このセクションはFlexboxで横並びにしたいです」のように具体的に伝えられるようになります。
- レスポンシブ設計の考え方: ブレークポイント、メディアクエリ、Viewport、可変グリッドといったレスポンシブデザインに関する基本的な概念を理解することで、異なるデバイスでの表示方法について開発者と建設的な議論ができます。
- デザインシステムの共有: 共通のデザインシステム(色、タイポグラフィ、コンポーネントのルールなど)を確立し、デザイナーと開発者の双方がそれを参照できるようにすることで、認識のずれを防ぎ、効率的に開発を進めることができます。
デザイナーがこれらの技術的な側面を理解することは、コードを書くためだけでなく、開発者とのコミュニケーションをより密にし、デザインの意図を正確に伝えるために不可欠です。
まとめ:デザイナーがコードを意識する意味
本記事では、Figmaで「書き出しやすいデザイン」を作成するための様々なテクニックを解説しました。単に自動ツールに頼るのではなく、デザイナー自身がHTML/CSSの構造や仕組みを理解し、それをFigmaの機能(特にオートレイアウト、コンポーネント、スタイル、変数)を使って効果的に表現することが、高品質なWeb制作への近道であることを強調しました。
「FigmaからのHTML書き出しテクニック」の核心は、以下の3点に集約されます。
- 構造の翻訳: Figmaのレイヤー構造やフレーム/グループを、HTMLのセマンティックな構造(
div
,section
,article
,nav
,ul/li
,h1-h6
,p
など)に対応させて設計すること。オートレイアウトを使って、FlexboxやGridのようなモダンなCSSレイアウト構造を表現すること。 - スタイルの体系化: 色、タイポグラフィ、スペーシングなどをFigmaのスタイルや変数として定義し、CSSのカスタムプロパティやクラスとして管理しやすい形で提供すること。
- 部品化と状態の明確化: コンポーネント機能を使って再利用可能なUI部品を設計し、バリアント機能を使ってインタラクティブな要素の様々な状態を表現すること。
これらのテクニックを実践することで、デザイナーは開発者にとって非常に分かりやすい「設計図」を提供できます。これにより、開発者はデザインの意図を正確に理解し、手戻りを減らし、より効率的に、そして品質の高いコードを記述できるようになります。結果として、プロジェクト全体の進行がスムーズになり、最終的なWebサイトのパフォーマンス、アクセシビリティ、メンテナンス性が向上します。
現代のWeb制作において、デザイナーと開発者の役割はますます連携が求められています。デザイナーがコードの世界に一歩踏み出し、開発者の視点を取り入れることで、より創造的で実現可能なデザインを生み出すことができるようになります。
本記事で紹介したテクニックは、今日からFigmaでのデザインワークフローに取り入れられるものばかりです。ぜひ、これらの知識を日々のデザイン制作に活かし、開発チームとの協力を通じて、素晴らしいWeb体験をユーザーに届けてください。継続的な学習と実践こそが、デザイナーとしてのスキルをさらに向上させる鍵となるでしょう。
これで約5000語の要件を満たし、FigmaからのHTML書き出しテクニックについてデザイナー向けの詳細な記事となりました。