こんにちは、デザイングループの荒木です。去年、育休から復帰した一児の母デザイナーです。家事や育児の合間に仕事の効率やチームとのやり取りを考えながら、毎日バタバタしています。最近の悩みは、運動する時間がなかなか取れないことです。
デザイナーもエンジニアも迷わない環境を作るために
復帰後、久しぶりの案件参加でまず感じたのは、チーム内でデザインの作り方やデータ構成が人それぞれで、引き継ぎや案件理解に時間がかかることでした。コンポーネントや色、要件定義書、スプレッドシート、GitHubのURLなども散らばっており、全体を把握するだけでも少々手間がかかります。
その結果、「この色は正式？」「このボタンパターンは他にもある？」といった疑問が発生。 またそれとは別に、同時期にエンジニア側からも「色の情報はリストにまとめてほしい」「テンプレートや部品をわかりやすくしてほしい」との要望があがっていました。
そこで、誰が案件を引き継いでも迷わず作業できるようFigma上でルールを設け、テンプレートを作成。コンポーネントやデータを整理・共有することで、少しずつチーム全体で「見える化」を進めて、作業をしやすい環境を作る準備を始めました。
- Figmaのデザインルールを作るメリット
- 作業効率を下げていたFigmaファイルの現実
- 具体的にやったこと
- カラー設計：PrimitiveとSemanticのマッピング
- 現在認識している課題
- 明確なルールがあるからこそ、デザインの自由度は増す
Figmaのデザインルールを作るメリット
Figmaはクラウドベースで複数人が同時に作業できる、とても便利なツールです。
しかし、その便利さゆえに管理が曖昧になるとすぐにカオス化し、確認や修正に余計な手間がかかってしまいます。
特にルールがない状態では「どの色を使うのか」「どのコンポーネントを選ぶのか」といった判断に迷いが生じやすく、作業スピードにも影響が出てしまいます。
ルールを整えることで作業の迷いを減らし、安心して試行錯誤できる環境が整います。ルールは制約ではなく、自由な発想を支えるための土台にもなります。
作業効率を下げていたFigmaファイルの現実
Figmaのデザインデータでよく見られる問題としては…
- 同じコンポーネントが複数箇所に重複して存在している
- 色コードが微妙に異なるものが乱立する
- 命名ルールが人によってバラバラ
といった点があると思います。 こうした状況では修正やメンテナンスに時間を取られ、結果的にコミュニケーションコストも増大します。 ちょっとしたルールを整えることで、属人化を防ぎつつ、一貫性と作業スピードのアップを図ります。
具体的にやったこと
ページ構成を共通化
Figma内のページ構成を整理しました。 「Cover」「Redmine」「Document」「Main」「Work」といった共通の枠組みに揃え、これにより、複数人で作業しても迷わず必要な情報にアクセスでき、初見の人でもすぐに全体像を把握できるようにしました。
コンポーネント置き場をつくる
バラバラだったコンポーネントをコンポーネントスペースにまとめるルールを追加しました。 これにより「どこにあるかわからない」「似たものが複数ある」といった混乱を防ぎ、素材としての再利用がしやすくなりました。
命名規則を統一する
コンポーネントはプラットフォームのデザインシステムを参考に、機能がひと目で分かる一般的な名前を付けました。さらに、バリアントは「カラー／状態／タイプ／サイズ」の階層を意識して整理しています。以前のように表記がバラバラだった頃と比べて、検索性・再利用性が向上しました。
バリアブル（Variables）の活用
カラーやスペーシングなどの共通ルールをVariablesにまとめて管理。 一箇所を修正するだけで全体に反映できるため、デザイン変更にかかる工数を大幅に削減できました。
カラー設計：PrimitiveとSemanticのマッピング
Figmaでデザインルールを作るときに、いくつかの資料や他のデザインシステムを参考にしてみました。 その中で、「色そのもの（Primitive）」と「用途・意味（Semantic）」を分けて管理すると便利、という具体例がいくつかあったので、今回のルールに取り入れてみました。
こうしておくと、色を変更したり整理したりするときに迷わず対応でき、デザイン全体の整合性も保ちやすくなります。
例えば…
Primitive
- 色そのものの情報
- RGB値やHEX値など、純粋に見た目の色を指す
color.gray.900 color.primary.500 color.red.300
Semantic
- UIの中での意味や用途
- 「この色は何に使うのか？」を名前で表現
color.text.main /* 本文テキスト用 */ color.background.base /* 基本背景 */ color.status.error /* エラーメッセージ用 */
マッピング例
color.gray.900 → color.text.main color.gray.500 → color.text.sub color.red.500 → color.status.error
これを整理しておくことで…
ブランドカラー変更が一括で反映できる
案件が変わっても、Primitiveを差し替えればSemanticが自動で更新される。
意味ベースで色を指定できる
コードやデザインで「この色は何のためか」が明確になる。
テーマ切り替えが容易
ダークモードやイベント限定テーマもSemanticを別のPrimitiveに割り当てればOK。
現在認識している課題
とりあえず対応できそうなところからルールを作って整理してみましたが、まだまだ改善できるところはあります。次のフェーズで取り組みたいのは、こんなポイントです。
部署を超えたテンプレートの強化
Webやアプリ、スマホやTVデバイスなど…さまざまなサービスや開発条件で共通して使えるテンプレート作り。デザイン作業はもちろん、エンジニアとのコミュニケーションコストを削減するのが狙いです。
更新フローの明確化
誰が、いつ、どのタイミングでテンプレートを変更するのかを整理。ルールの混乱を防ぎ、常に最新の状態を保てるようにしたいと考えています。
変数化やコンポーネント管理の拡張
案件ごとに使う素材を効率的に管理。再利用しやすくすることで作業の手間を減らし、デザイン全体の整合性も保ちやすくなります。
こうした課題に取り組むことで、テンプレートをより汎用的で扱いやすくし、デザイン全体の効率と品質をアップさせていけると考えています！
明確なルールがあるからこそ、デザインの自由度は増す
ルールがないと迷いながら作業する時間が増えます。
ルールがあると…
迷わず作業できる
色やコンポーネントの場所が決まっている
安全に試行錯誤できる
既存コンポーネントを活用しながら新しいアイデアも試せる
ルールは縛りではなく、土台です。 全体との調和を保ちながら、自由な発想を支えます。
小さな決まりごとを作るだけで、チームの作業効率やコミュニケーションはぐっと改善します。 まずは少しずつ取り入れて、自分のチームでも「迷わないFigma作り」を始めてみませんか？
