Figmaによるデザインデータ運用

（Figma Advent Calendar 2018の14日目記事です）

業務でFigmaを導入したので、その話をしたいと思います。
Figmaの導入を迷っている人や、その運用方法を検討している人のご参考になれば幸いです。

※ （2023年追記）このnoteは、2018年に書かれたものであり、Figmaの機能がまだまだ少なかった頃の情報です。正直言って「もはや役に立ちゃしない」情報なのですが、こんな時代もあったんだと参考になるかもしれないので、特に情報の更新もせずに残しておきます。
Figma使い始めの、「まずは基本機能の活用方法を知りたい」みたいな人に普通に有益かもしれません。

社内向け資料を適当にアレンジしつつnote記事化したんですが、かなりの長文（4000字くらい）になっちゃったんで、ダーっとスクロールしながら興味ありげなところだけ掻い摘んで読んでいただけたら幸いです。

【トピック】
・前提
・Figmaを選定した理由
・ポリシーは「なるべくシンプル・限界までゆるく」
・Figmaの活用範囲 - プロトタイピングとしては使わない
・オブジェクト名ルール
・コンポーネントはライブラリに置かない
・レスポンシブ対応
・コメント記述ルール
・多言語対応
・バージョン管理（ヒストリー機能の使用）
・Android版どうするか

まず、前提

いまの私の職場の、UIデザイン・実装まわりの状況は以下のような具合です。

- プロダクト（アプリ）は2つ。
- iOS、Android両対応。
- スマホ、タブレット両対応
- 言語は日/英/仏に対応
- 内部にデザイナーは１人（社歴数ヶ月）

「なにそれ地獄じゃん」と思った人、察し良いですね。みなまで言うな。

デザインデータが散在していて、アイコンやらロゴやら探すのに毎度苦労している状態です。Google Driveのフォルダやgithubに都度都度格納してきたので、とにかく見つけるのが大変。見つかってもそれが最新版なのかわからなかったり。

どこか一箇所に集約するにはどうすればいいか... と考えた結果、Figmaに集約できるデータはFigmaに集約し、集約できないデータはFigmaファイルを取っ掛かりにして探せるようにしよう、という結論に至りました。

Figmaを選定した理由

とにかくデータを集約したかったので、1つのプロジェクトに全て集約できて、ブランチとかを配慮する必要もなく、それでいて編集履歴を遡れるFigmaが最適と判断しました。

ポリシーは「なるべくシンプル・限界までゆるく」

内部のデザイナーリソースが決定的に足りていない状況なので、外部協力者にもFigmaファイルを編集してもらうことになります。
また、内部デザイナーが別タスク（Web制作とか）にアサインされて、一時的にUIデザインをエンジニアが行わざるを得ない、ということも起こりえます。

となると、Figma運用ルールはとにかくシンプルにして、編集者各々の癖なんかも許容できるような、「ゆるさ」を持たせなくてはいけません。

ルールをゆるくすると実装がカオスになりがちですが、ある程度のカオスっぷりは受け入れざるを得ないと考えています。
それより、「Figma慣れしてなくても使える」「デザイン知識なくてもさわれる」というあたりを重視していきます。

Figmaの活用範囲 - プロトタイピングとしては使わない

Figmaを使ってると、プロトタイピング機能を使ってUX検証とかしたくなります... が、私はFigmaの用途としてプロトタイプ検証を外しました。禁ずるわけではありませんが、プロトタイプ検証の手段の１つに過ぎないとしています。

UX検証は多くの場合、Figmaの機能だけでは対処しきれないです。例えば、ドラッグ＆ドロップによる並べ替え操作とか、カメラとの連動とか。
逆に、Figmaを使うまでもなくペーパープロトや、ホワイトボード上での図示で事足りることもあります。

どのようにプロトタイプ検証するかは都度考えるとし、Figmaのメイン用途は

- デザインスペック（画面仕様定義）
- 各種デザインデータ（翻訳文言とか）のポータル

の2点としています。

オブジェクト名ルール

なるべくルールをゆるくするつもりですが、オブジェクトおよびコンポーネントの分類と命名にはルールが必須です。ここだけは定めておかないと、デザインデータはカオスを超えて暗黒の領域へ堕ち入ります。そこに救いの手はありません。

というわけで、例によってAtomic Designの思想をベースに、BEMの考え方をいくらか混ぜたような感じで命名ルールを検討します。
概ね、以下のWebページ（これはsketch向けですが）にあるルールに倣うことにしました。
http://www.standardinc.jp/reflection/article/sketch-atomicdesign/

● オブジェクトは、element(lv1)、 control(lv2)、 area(lv3) の３階層に分類。

【図：各階層のオブジェクト例】

● オブジェクトは原則として「レベル/オブジェクトの種類/オブジェクトの意味」というフォーマットで命名する。
（例外あり：後述の「レベル０オブジェクト」と「標準UIコンポーネント」）
「オブジェクトの意味」については省略可。見た目を区切るためのボーダーなどは、”lv1/border”のように書いても問題ない。

【図：オブジェクト名前例】

● アイコン内のパスなど、lv1未満の階層のオブジェクトも存在する。
これらのオブジェクトまで名前をつけるとキリがないので、これらは命名不要。
便宜上、これらを「レベル０のオブジェクト」と呼ぶ。

【図：複数のレベル０オブジェクトで構成されたアイコンの例】

● 包含ルールは以下の通り。

- lv1のオブジェクトが包含できるのはレベル０のオブジェクトのみ。
- lv2のオブジェクトが包含できるのはlv1のオブジェクトのみ。
- lv3のオブジェクトはlv1, lv2, lv3いずれのオブジェクトでも包含できる。

【図：オブジェクトの包含関係。複数のlv3を一つのlv3にまとめたりもできる。】

● OS標準UIコンポーネントを使う箇所は、上記命名ルールに従わない。
ただし、オブジェクト名に「標準UI - 」という接頭辞を入れる。

【図：標準UIコンポーネント（ナビゲーションバー）】

コンポーネントはライブラリに置かない

Figmaにはコンポーネントをファイル横断で使い回せる便利な便利なライブラリ機能があります（※有料ライセンスのみ）が、これはあえて使用しません。

データの扱いを簡単にするために、作業効率は犠牲にしました。
また、デザイナーリソースの減少や一時的なデザインワークの凍結などにより、有料ライセンスを解約する可能性もあると見込んでいます。

そのような理由で、有料版の機能に依存するのは避けることとしました。
勿体ないけど。

レスポンシブ対応

デザインデータは、原則としてiPhone SEサイズで作成します。SEサイズで作れば他のスマホやタブレットでも収まるので。
ただ、SEサイズで組んだレイアウトがiPhone XSサイズやiPadサイズでどうなるのかが実装者にわかりづらい場合が多々あります。

レスポンシブ検証のために、「SEサイズでレイアウト組んだらそれを1つのコンポーネントにして、XSサイズとiPadサイズに拡げたインスタンスをFigmaファイル上に置いておく」とします。

【レスポンシブ対応手順】

1. SEサイズで画面を作成する。この際、Constraintを正しく設定する。

2. 作成した画面をコンポーネント化し、XSサイズ、iPadサイズのフレーム上にインスタンスを配置する。

3. 各フレームに配置したインスタンスをフレームサイズにフィットさせる。

SEサイズを作成する際にConstraintを正しく設定していれば、コンポーネントを拡大するだけでレスポンシブ検証が完了するはずです。
ただ、FigmaのConstraint機能は十分とは言えず、「タテヨコ比を保ちつつ横幅を画面にフィット」といった細かい（それでいてUI設計上は必須である）設定は出来ません。そういう場合は注釈を書くなど、補足が必要です。

コメント記述ルール

UIの修正・追加が発生した際には、簡単な説明コメントを記入します。
その際、詳細な説明の在り処を併記します。

【図：コメント】

対応完了したタスクについては、コメントをResolveします。

一時的なメモをキャンバス上（フレーム外）に置くことも可ですが、多用するとFigmaファイルが煩雑化してしまうので、不要になったメモは随時消して下さい。

【図：フレーム外に置いたメモ】

多言語対応

訳語は随時Figmaファイル上に反映して、見切れや不自然な改行など起きないかをチェックします。
翻訳文言データはGoogle Sheets等に取りまとめ、Figma上のコメントからリンクします。

バージョン管理（ヒストリー機能の使用）

デザイン修正タスクを1つ完了するごとに、ヒストリー保存（Command + Option + S）を行います。
その際、日付とタスクの概要を書きます。

【図：ヒストリー機能の使用】

Android版どうするか

この点は未検討です...。
現状では、「iOS用に作ったデザインデータをもとに、Androidエンジニアが良きに計らう」という運用になっています。

◼◼◼

長々と書きましたが、実はまだ運用始まったばかりで試行錯誤中です。
上記ルールに則りつつ、データの煩雑化とリファクタを繰り返しながらルールも修正してくことになると思われます。

お読みいただきありがとうございました！