はじめに
背景
- 前提条件
はじめに感じた迷い
3ファイルになったお約束
画面からではなく、Atomsから作る？
- もっと頑張ってほしいところ
- そこはかとないロックインの不安
まとめ
クレジット消費量の余談

はじめに

Figma Make でUI探索を行い、Figma Designに戻して俯瞰と総覧性を確認する、という流れで仮説検証を進めることが増えました。ある程度の操作イメージは掴めるものの、もっと実際の体験に近い動きを見せたい。ならば探索の次のステップとして、Figma Makeを「実装に近いモックアップ」として扱うといいのではないかと試行錯誤をしてみました。

この記事では、Figma Makeを試す最中に整理した考え方と運用ルール、その過程で気づいた点をまとめています。結論、思っていたより「実装寄りの世界」に足を踏み入れることになりました。

背景

いま私は法人企業向け採用支援システムdodaCONNECTのUI/UXデザイナーとして、その中でも0->1で新しい機能・サービスを追加していく案件に携わっています。企画とデザイナーで仮説検証前のモックアップを叩いてる段階ですが、今回は情報量が多く細やかな操作品質の高さを追求しようとしています。（Googleアナリティクスの簡易版をイメージいただけると良いかもしれません）

そうなってくると、どうしても実際の操作に近いモックアップでテストしたい⋯⋯Figma Makeなら精度高くいけるんか？ということで、試してみることにしました。

前提条件

Figma Design側に一定Fixされた画面が2画面ある
Reactベースのデザインシステムは持っていない
Figma Designにまとめられたガイドライン、デザイントークン（variables）とUIライブラリは揃ってる

まずはその2画面のモックを、Figma Make × Figma Design だけで作れるか！？というチャレンジです。

はじめに感じた迷い

Figma Make を触り始めた段階で、まず「どこから手をつければいいのか」が把握できませんでした。チャットで聞いても「さあコンポーネントを作りましょう」とコードを書かせようとしてきます。 UIライブラリファイルを読み込んではいるものの、Guideline.mdは当然空っぽ。

どの品質を基準に作るべきか
何を守れば一貫性が保たれるのか
既存ライブラリをどこまで信用してよいのか

そこで、まずは Figma Makeの思想を理解し、それに合わせた「お約束」を定義してから実装に進む形をとることにしました。

3ファイルになったお約束

結果として、以下の3つを順番に整備しました。

Project Philosophy & Mindset（思想と前提）
DesignPrinciples.md（判断基準）
Guidelines.md（具体的なルール）

Project Philosophy & Mindset.md （思想と前提）

これは「Figma社はFigma Makeで何をさせたいの？デザイナーはどう自身を変革するといい？」から始まったFigma Makeと私の壁打ちの結果、おおよそAIと私はどのように振る舞えばいいのかを認識合わせし、なんとなくまとめたものです。

 **協業ルールの合意と「庭師（Gardener）」の哲学**:
    - **役割定義**: AIは単なるコーダーではなく、コードベースという「庭」を管理する「庭師（Gardener）」であると定義。
    - **3つの行動指針**:
        1.  **土壌を守る（System）**: `globals.css`（デザインシステム）という土壌を汚さず、栄養（トークン）を正しく行き渡らせる。
        2.  **剪定する（Refactor）**: ハードコードされた値や重複（雑草）を刈り取り、セマンティックなコードを保つ。
        3.  **育てる（Grow）**: コンポーネントを、土壌（トークン）から自然に生えてきた植物のように構築する（無理なオーバーライドをしない）。

庭師（Gardener）は、ブライアン・イーノの以下の言葉に基づきます。（解説ブログたくさんあるので割愛します）

My topic is the shift from 'architect' to 'gardener', where 'architect' stands for 'someone who carries a full picture of the work before it is made', to 'gardener' standing for 'someone who plants seeds and waits to see exactly what will come up'." — Brian Eno | Composers as Gardeners

ほかには以下のようなことも言ってました。

 Stop thinking of yourself as an architect, and start thinking of yourself as a gardener.
AIとの協業: AIにコードを書かせる際、最も不足するのがこの「異常系・準正常系」の指示です。デザイナーがここを緻密に定義（デザイン）できれば、エンジニアにとって神のような存在になれます。

だいぶFigma Makeに都合の良いエンジニアマインドなスコープではありますが、君がそういうならそうしようと、今回は受け入れます。

正直、それはそうだけどちょっとどうかな？っていう内容ではあります。これはGemini3.0が起こしたハルシネーションか、そもそもFigmaがデザイナーをそう捉えてるのか、できれば精緻に捉えて評価したいですが今回はFigma Make自体の検証でもあるので「そういうもの」としました。

DesignPrinciples.md（判断基準）

これは一般的なデザインシステムで定義されているデザイン原則と同じものです。

私の案件でも同様にデザイン原則が定義されているので、それをMarkdown形式に変換しお約束としました。「ちょうどよくシンプル、信頼できる存在、身近な存在、快適さとプラスアルファ」そのようなことがまとめられています。

Guidelines.md（具体的なルール）

こちらも一般的なコーディングガイドラインの範囲のものです。

コード生成は、階層構造（Primitives→Tokens→Components→Screens）にしましょう
既存コンポーネント・セマンティックトークンを必ず使いましょう
やっていいこと10個、やってはいけないこと10個

など、厳密なガイドラインの形をしています。

画面からではなく、Atomsから作る？

※ ここでいうAtomsはAtomic Design文脈のAtomsです。

実際に作り始めると、Figma Makeでは画面単位ではなく、まずコンポーネントから組み立てる必要があることに気づきます。

Figma MakeはReactベースです。実装側では一般的に、UI を小さなコンポーネントに分解し、それらを組み合わせて最終的なページを構築していく作り方をします。デザイナーはFigma Design で画面を起点に考えて行きますが、それはまったく逆の、フロントエンド実装時と同じアプローチです（たぶん）

その違和感についてもFigma Makeはこう説明します。

> 「コンポーネントから組み立てて、状態（State）で表示を切り替える」という考え方が、React的にもガイドライン的にも正解です。
>  従来の考え方: `index.html`, `about.html` ... とページを作る（画面遷移）。
>  今回の正解:
> まず `Card`, `Button`, `Header` などの部品を作る。 次に `MainLayout` を作る。
> 中身のコンテンツエリアを、ユーザー操作（State）によって出し分ける（例：タブ切り替え、モーダル表示、ステップフォームの進行）。

具体的な進め方の流れは以下です。