Figma を使ったデザインデータ運用・管理の一例

こんにちは、UIデザイナーの水澤です。

弊社 Gaji-Labo は受託開発会社であり、お客さまの事業・サービスを成長させるためのサポートを行っています。UIデザイン事業においては Figma を用いてデザインを作成するため、データの運用・管理は日常的な業務です。

今回は、Figma を使ってどのようにデザインデータを運用・管理しているかの一例をご紹介します。

案件内容や状況に応じてより良い形に変えていきたいと思っているので、あくまで一例として参考程度に読んでいただけたらと思います。

デザインデータの作業環境

Figma でデザインデータを作成する前に、まずはどちらの Figma 環境下で作業を行うか決める必要があります。基本的にはお客さまから弊社メンバーをご招待いただき、お客さまの Figma 環境下で進めていく方法が後々の作業負担もなくスムーズです。

Figma のアクセスレベルは上図の通りになっており、主に最高レベルは Team を指します。もし外部のメンバーを招待する場合、Team または Project、File のいずれかのレベルで招待可能です。

もしお客さま側でデザインシステムを所有している場合、デザインシステムに含まれた UIコンポーネントをライブラリとして他の File でも活用できます。ライブラリの共有範囲は同じ Team 内に限られるため、開発要件としてその UIコンポーネントを利用する方針であれば、ライブラリを活用するためにもご招待いただく方法が良いと思います。

デザインデータの管理・運用方法

デザインの検討フェーズで重要なことのひとつが、どのような過程・議論で UI を決めていったかという記録だと思います。これは終盤に差し掛かるにつれて重要性が出てきます。

プロジェクトの進め方として定例会議を行うことが多いため、そのときの議論を議事録として残すことはもちろんですが、実際には Figma のデザインデータを見ながら会話をするため、直接そのデータにコメントを残すこともあります。Figma のコメント機能はどの部分の議論をしているのか明確にしやすく便利です。但し、コメント数が増えてくると時系列を追って参照しにくいところがあります。

デザインデータの履歴については History機能がよく挙げられますが、閲覧に時間が掛かることもあり自分はあまり活用していません。

上記の悩みを解決する方法として、定例会議ごとに Page を分ける方法を実践してみています。こうすることで、Page ごとにデザインデータとコメントを参照できるため、時系列で振り返りやすくなります。

留意点1: 過去データのコンポーネントは Detach が必要

Page で区切った場合もデザインデータのコンポーネントは当然紐づいたままなので、親コンポーネントを更新すると履歴として扱いたいデザインデータにも影響が出てしまいます。履歴として扱いたいものは Detach する必要がありますが、その作業に手間が掛かってしまうことが難点です。

留意点2: File のメモリ容量が圧迫されやすい

Page ごとにデザインデータを複製する運用のため、Page が増えるごとにデータ容量が倍増することになります。

Figma は File のメモリ容量が圧迫されるとアラートが表示されるようになりました。この数値が 60% の段階ではまだ余力はありますが、100% になるとファイルがロックされて閲覧できなくなってしまうため、そうなる前に別の File を作成して最新データを移動しましょう。

100% に達していなくても、History機能などの重い処理をしたときにエラーが起こることがあったので、60% のアラートが出た時点で対策をした方が望ましいです。

終わりに

デザインシステムを所有している場合はご招待いただく形を推奨しましたが、弊社の Figma 環境下で作った後に納品する形も可能です。お客さまの状況に応じて、お互いにより良い形を相談しながら決めていけたらと思います。何らかのご事情や Figma に関してご不明点などがある場合も、お気軽にご相談ください。