汚いFigmaデータの悩み
命名・構成
プロジェクト名
日本語と英語が混在していたり、命名規則がないと検索できない。また、新しく命名する時に困って、結局いいかげんに命名され、状況は悪化するばかり。
ファイル名
プロジェクト名と同様。作成する頻度が多いので、より困る。また、どの単位でファイルを分けるべきか悩む。組織体制が縦割りになっていれば迷わないが、横断的に影響するプロジェクトの場合迷う。
ファイルのサムネイルをデザインする – Figma Learn - ヘルプセンター
ライブラリ名
「デザインシステム」「スタイルガイド」「コンポーネントライブラリ」の語彙について、チーム内で共通認識がないと混乱する。合意形成をするとともに、ドキュメント化した方が良さそう。
ページ名・構成
ワイヤーフレームとスタイリングを同じファイルに作成する時、同じページに置くべきか、別ページに置くべきか悩む。
事業部（=普段開発しない人）に合意形成をする時、ワイヤーフレームを理解しておらず「こんなにグレーにするのか」と文句を言われることがある。そういう場合は、スタイリングとワイヤーを並べておかないと合意形成できないことがある。
しかし、1ページのデータ量が増えると見にくくなる。そして、ページの読み込みが遅くなる。
A案とB案を作る時も、並べるべきか別ページにすべきか、担当者や状況によって変わる。こうして、ページ構成が統一できなくなる。
フレーム名・レイヤー名
その場で使うだけなら適当で済むが、同じ要素を繰り返し使う場合には不都合が多い。マルチ編集もできなくなるし、無駄なフレームがあると階層が分かりづらくなる。
ライブラリとファイルの構成
例えば、Webを基準にデザインシステムを作った後に、アプリのスタイルを定義する際、アプリでは再現できないスタイルが多く、publish（公開）されたシステムをそのまま取り込んでしまうと、作業する際にノイズが多くなってしまう。
本来であれば、デザインシステムの配下にWeb・アプリなど個別のデバイス・OS用のスタイルガイドを作成するべきだったが、すでに運用されているので変更は難しい。
コンポーネント名・階層
「/」で区切ることで階層化できるが、この階層が乱れているとかなり作業効率が落ちる。
近年では各社、ページによって階層化する例がよく見られるが、エンジニアなどデザイナー以外に共有する際に探しにくくなるので、index（どのページに何が書いてあるのかの目次）を作った方が良さそう。
バリアントのプロパティ・値
昔は英語版しかなかったが、UIが日本語になったことで「default」→「デフォルト」のように値が変わってしまい、そこから日本語で命名する人と、過去データに則り英語で命名する人に分かれてしまった。
バリアントの作成と使用 – Figma Learn - ヘルプセンター
ローカルスタイル名
影響範囲は比較的小さいものの、思ったよりプロジェクトの影響範囲が拡大した際に、適当に命名していると混乱を招く。
また、デザインシステムとするファイルのローカルスタイルは、そのままpublish（公開）されるため、命名が間違っていると検索不可能になる。
variables（変数）の活用
variables（変数）の活用例
アクセシビリティの改善など、今後配色が変更される可能性がある場合、色をそのまま定義してしまうと、後日直すのが大変になる。そこで、変数を使ってデザイントークンを定義することで、後の作業が楽になる。
また、アプリのSF Proとヒラギノのサイズが微妙に違う問題があるが、具体の数値を入力して管理するのは大変な作業になる。それを変数で管理する手もある。（例：ヒラギノの18.2ptを「17pt」と命名しておくとか。）
変数の作成と管理 – Figma Learn - ヘルプセンター（フォントをヒラギノ←→SF Proに変えた時に、自動で調整してくれたりするのか？調査中）
（あるか分からないが）例えば、今後SF Proの日本語が出た場合、現在ヒラギノでデザインしている部分を、一気に置き換えることもできたりする。
変数とスタイルの違い – Figma Learn - ヘルプセンター
variables（変数）の理解
近年リリースされた機能なので、理解していないデザイナーもいる。この場合、よく分からず接続を解除してしまったりするかもしれない。そうすると後々困るので、認識を確認しながら共有しないといけない。
「なんでこのバージョンがないの？」
「ブールを使ってます」
「ブールって何？」
変数、コレクション、モードの概要 – Figma Learn - ヘルプセンター
説明欄を綺麗に書くのも手段の一つになりそう。
参考記事：デザインシステムの構築 – Figma Learn - ヘルプセンター
Figmaデータが汚いと発生する問題
開発速度の低下
他のデザイナーが理解するのに時間がかかる。
レビューが遅れる。
流用して使用する際に遅くなる。
理解できても非効率なデータの作り方だと作業速度が遅くなる。
エンジニアが混乱し、実装速度が遅くなる。
実装物の確認の際にFigmaが見づらい。
精神状態・意識の問題
他のデザイナーに頼むと開発スピードが落ちる状態だと、仕事が頼みづらく、属人化してしまう。
チーム内にフラストレーションが溜まる。
最低限の開発に時間と労力を取られ、「より良くしよう」という意識が働かなくなる。
汚くなる原因
Figmaデータ作成とデザインは別の作業
デザイン作業は、Figmaデータを作ることがメインではない。その画面の内容を考えてデザインすること。そこで、デザインデータをきれいにする工程を別途用意しないと、整っていないまま次の工程に進んでしまう。
データを整える時間がない
必要性はわかっていても、プロジェクト進行や組織の状態によって、時間がないことがある。職人気質なデザイナーに囲まれていると、「当たり前に出来ているべきこと」については「別途時間を取るなんて許さん」となってしまうこともあるかもしれない。
必要な精度は状況による
レイヤー・フレームやコンポーネントの命名について、全部を完璧に作り込むべきかは状況による。エンジニアの体制や受託・内製か、プロジェクトの進行段階によっても変わる。そのFigmaを見る相手に、どこまで作り込むべきかヒアリングしなければならないが、エンジニアとデザイナーが直接会話しにくい状況だと、どこかで齟齬が起こる。完璧に作り込む時間を掛ければ解決するが、その時間分施策の進行が遅れる。
OS・実装について理解していない
AppleやGoogleが出しているFigmaを流用して、アプリのデザインを作成した際に、「この仕様を実装するには、無駄に工数がかかる。」と指摘されたことがある。OSの仕様に準拠したからと言って、それが既存の実装状態と違えば意味がない。
解決タスク
コンポーネントの浄化
命名やレイヤー構造など、コンポーネントを綺麗にするだけで、大分マシになる。現行のコンポーネントを直すと既存のデータが崩れるおそれがあるので、チームで連携して影響を確認しながら見直す必要がある。
スタイルガイドを綺麗に作る
サービス全体のデザインシステムが汚い状態でも、個別のアプリのスタイルガイドなど、下位概念のシステムを作る際に浄化（濾過とでも言うべきか）できる部分もある。
工数の確保・投資価値があるのでは？
業務効率がどんどん悪くなるよりは、なるべく早くコンポーネントの改善をすべき。エンジニアからの要望を集め、工数を確保しに行った方が良い。データが汚くて残業するくらいなら、コンポーネントの整理で残業した方が、トータルの時間で元が取れる。
また、デザイナーのスキルアップとしてもプラスになる。