デザインシステムは「作って終わり」ではない。Figmaの「Description」で脱・属人化を加速させる極意
こんにちは。現場でデザイナーとエンジニアの橋渡しをしながら、プロダクトの品質を磨き続けているエンジニアです。
UI/UXの世界でよく耳にする「デザインシステム」。でも、多くの現場ではこうなっていませんか？
「せっかく作ったコンポーネントなのに、エンジニアから『これ、どう動くのが正解？』とSlackで質問攻めに合う」「担当者が休むと仕様が誰もわからなくなる」。
これ、「ドキュメントがデザインと分離している」から起きる悲劇です。
今日は、Figmaの機能をハックして、「デザインを触れば仕様書もそこにある」という、究極のドキュメンテーション駆動デザイン（DDD）の第一歩を伝授します。これをマスターすれば、あなたのチームの生産性は劇的に向上します。
—
1. なぜ「外部ドキュメント」は崩壊するのか？
NotionやConfluenceに仕様書をまとめるのは素晴らしい習慣です。しかし、デザインが修正されるたびに、わざわざ別ツールを開いてドキュメントを更新するでしょうか？
答えは「No」です。結果として、デザインデータと仕様書の間には乖離が生まれ、開発者は「どちらが最新か？」という不毛な疑心暗鬼に陥ります。
解決策はシンプルです。「仕様をデザインデータの中に埋め込む」。
Figmaの「Component Description（コンポーネントの説明）」機能は、まさにこのために存在します。
—
2. 実践：Component Descriptionで「仕様のインライン化」
Figmaのコンポーネントを選択したとき、右サイドバーのプロパティパネル上部に「Description」という欄がありますよね。ここをただのメモ帳にしてはいけません。
推奨フォーマット：テンプレート化のルール
チームで共通のフォーマットを決めましょう。例えば、以下の項目をDescriptionにコピー＆ペーストする習慣をつけます。
💡 仕様概要
- 用途: (例: フォーム送信時のメインアクション)
- 状態: (例: デフォルト / ホバー / クリック / 無効)
- ガイドライン: [社内Wikiへのリンク]
🛠 エンジニア向けメモ
- Props: (例: `variant=”primary”`, `disabled={boolean}`)
- 挙動: (例: クリック時にローディング状態へ遷移する)
なぜこれが重要か？
エンジニアがFigmaの「Dev Mode」でコンポーネントをクリックした瞬間、この情報が目の前に現れるからです。わざわざドキュメントを探す時間はゼロになります。
—
3. HelloWorld的セットアップ：今日から始める「迷わない」環境作り
まずは、あなたのデザインシステムのベースとなる「Button」コンポーネントで試してみましょう。
手順1：Descriptionを記述する
1. Figmaでメインコンポーネントを選択します。
2. 右サイドバーの「Description」欄に、上記のテンプレートを貼り付けます。
3. 重要： リンク（URL）を貼り付けると、Dev Mode上でクリック可能なリンクとして機能します。
手順2：Docsリンクを追加（Doc Link）
Descriptionの下にある「Documentation Link」欄も活用しましょう。ここには、Storybookや該当コンポーネントの実装コードへのリンクを貼ります。
// コンポーネントの設定例
{
“name”: “PrimaryButton”,
“documentation”: “https://storybook.your-project.com/?path=/story/components-button–primary”,
“description”: “ユーザーのメインアクションを促すためのボタン。”
}
これで、エンジニアは「Figmaのデザインを確認」→「Dev Modeでコードと仕様を確認」→「リンクをクリックしてStorybookの実装コードへ飛ぶ」というシームレスなループを手に入れることができます。
—
4. チーム運用を成功させる3つの鉄則
この仕組みを定着させるために、以下のルールをチームに導入してください。
1. 「Descriptionがないものは公開しない」ルール
デザインシステムへのマージ条件として「説明文の記述」を必須にします。これが最大の品質管理です。
2. 「質問はSlackではなくFigmaのコメントで」ルール
仕様に関する質問は、必ず対象のコンポーネントにコメントを残させます。解決したらそのコメントを解決済みにし、そこから得られた知見をDescriptionに追記します。
3. 「更新」を評価する
「機能を作った人」だけでなく、「ドキュメントを最新に保った人」を賞賛する文化を作ってください。
—
最後に：デザインは「完成物」ではなく「コミュニケーションの装置」
ツールは使い手次第で、ただの描画ソフトにもなれば、チームを加速させる強力なエンジンにもなります。
「Component Description」を使いこなすことは、単なる入力作業ではありません。「次に触る人への思いやり」をコード化する行為です。
これを始めた瞬間、あなたのチームは「仕様確認のための会議」から解放され、より創造的なUI/UXの議論に時間を使えるようになります。
さあ、まずは一つのコンポーネントから、魂を込めたドキュメンテーションを始めてみてください。あなたの仕事が、もっと楽しく、もっと楽になるはずですよ。