チームで把握できる！Figmaデータの運用方法

デザイナーはもちろん、エンジニアの方やPdMの方もですが、デザインツールを使用していてこのような課題に直面したことがありませんか？

• 探しているデザインデータがどこにあるのかわからない
• 最新のデザインデータがどれなのかわからない
• 状態変化時のデザインを考慮できておらず、抜け漏れによる手戻りが発生する
• どうしてこのデザインに決まったのか、検討の流れや経緯がわからない

このような課題を解決するためにはどのようなデザインデータを作り、運用していくのが良いのでしょうか。
GoodpatchではFigmaをデザインツールとしてよく使用します。今回はあるクライアントとのプロジェクトにおいて検討したFigmaの運用方法の例をご紹介します。

課題：探しているデザインデータがどこにあるのかわからない

解決方法：FigmaのTeam, Project, Fileの構成を定義する

探しているデザインデータがどこにあるのかわからないという課題に対して、FigmaのTeam・Project・Fileの構成をしっかり決めることで、どこに何のデザインがあるのかが、デザイナーだけでなく、PdMやエンジニア含めたチーム全員が把握できるようになります。

今回、Figmaの運用方法を検討したプロジェクトではサービスが複数存在しており、それに合わせて全体構造を把握しやすく、管理しやすい形を目指して以下のような構成を取りました。

Teamについて

それぞれの構成について、まず、Teamはこの2つに分けました。

• Team：デザインデータのProjectが集まる場所
• Team：アーカイブのProjectが集まる場所

サービスの数が多く、サービスごとにアーカイブ内のProjectを分けたかったため、アーカイブをTeamとして切り分けています。

Projectについて

次に、デザインデータがあるTeam内のProjectの構成について以下のように分けました。

• Project：それぞれのサービスのデザインデータ
• Project：共通で使用するコンポーネントやスタイルキット

サービス独自のコンポーネントもあれば、サービス共通で使用するコンポーネントもあるためこのような構成にしました。

Fileについて

Project：それぞれのサービスのデザインデータ内のFileの構成は以下のように分けました。

• File：マスターファイル
• File：施策ファイル

リリース済みのデザインをマスターファイルに置き、新たに施策を検討する際には施策ファイルを新規作成することになり、リリースが行われていない施策検討中のデザインは施策ファイルに置かれることとなります。

Pageについて

File：マスターファイルの中には以下のPageを含めました。

• Page：デザインのマスターデータ
• Page：独自のコンポーネントやスタイルキット

このマスターファイルにはリリース済みのデザインを置きます。

File：施策ファイルの中には以下のPageを含めました。

• Page：実装用マスター
• Page：作業場

Page：作業場でデザインの検討が行われ、Page：実装用マスターにはリリース前の確定した実装用のデザインが置かれることになります。

課題：最新のデザインデータがどれなのかわからない・状態変化時のデザインを考慮できておらず、抜け漏れによる手戻りが発生する

解決方法：デザインのマスターデータの作成方法を定義する

マスターページには画面ごとにデフォルト状態+状態変化による画面変化のバリエーションをまとめました。

デフォルト状態は、UI StackにおけるIdeal State（理想形）としています。

UI Stackとはアメリカのデザイナー Scott Hurffさんが提唱した、「UIの考慮すべき5つの状態」という考え方です。
出典：How to fix a bad user interface

状態変化による画面変化のバリエーションはUI Stackにおける他の4つの状態のEmpty（空状態）, Error（エラー）, Partial（部分的状態）, Loading State（ロード中）にプラスして、仕様を説明するのに必要な（例えば画面を伸ばした時にどのような挙動になるのか、等）デザインを作成します。

また、仕様の話が出ましたが、Figmaにはデザインのみを置くようにし、細かい仕様はドキュメントツールでまとめました。
Figmaに記述すると、「誰がいつ更新したかわからない」「検索しづらい」「仕様部分をPdMやエンジニアが記述する場合、Figmaの使用方法がわからないので大変」といった不都合が生じやすいためです。

仕様書はこのような形式でFigmaデータ、全体の仕様、表示項目、状態変化時における画面変化のバリエーションを記載しました。

課題：最新のデザインデータがどれなのかわからない・どうしてこのデザインに決まったのか、検討の流れや経緯がわからない

解決方法：デザインを検討する際のデータの作成や運用方法を定義する

「解決方法：FigmaのTeam, Project, Fileの構成を定義する」で説明したように、デザインを検討するときはProject：それぞれのサービスのデザインデータ内に新しいファイルを作り、File：施策ファイルの中身はPage：作業場とPage：実装用マスターに分かれています。

Page：作業場は以下のように構成しました。

Page：作業場では、検討したデザインや仕様・デザインの意図、プロジェクトメンバーからのフィードバックや、何を議論したのかをメモしながら検討を進めます。

この様に検討を進めることにより、どのようなデザインパターンが検討され、そのパターンに対してどのような意見があり、どうしてこのデザインに決まったのか、という検討の流れがデザイナーだけでなくPdMやエンジニアの方がいつでも参照できるようになります。

別ツールでデザインに関する議事録を残しておくことも重要ですが、Figmaに記載があると、すぐにどのデザインの話をしていて、いつ検討があったのかということがわかりやすくなります。

また、この際に左から右に検討を進めることで、最新のデザインがどこにあるのかひとめでわかるようになります。

⚠️ 検討時の注意点
検討の際、コンポーネントをそのまま繋いでおくと検討の履歴が正しく残りません。コンポーネント接続を切ること（Enter→Option + Command + “B”でDetach instance）をおすすめします。

課題：最新のデザインデータがどれなのかわからない

解決方法：更新ルールを定義する

今回はサービスのマスターデザインがFigmaにある前提で、小規模改善を行う際の更新ルールを紹介します。

(1)施策ファイルを新たに作成し、マスターデザインを複製

File：施策ファイルを作成します。その後File：マスターファイルからPage：作業場に、施策に関連するマスターのデザインを複製します。

(2)Page：作業場内で検討したデザインパターンを残しつつデザインを検討

「解決方法：デザインを検討する際のデータの作成や運用方法を定義する」で説明したデータの形で、Page：作業場内でデザイン検討の履歴を残しながらデザインを検討します。

(3)デザインが確定次第、Page：実装用マスターに移動させ、状態変化における画面変化のバリエーションを作成・仕様書を記載

デザイン確定後、File：施策ファイルにおけるPage：実装用マスターにて、デフォルト状態の必要な端末のデザインと状態変化における画面変化のバリエーションを作成します。

この際、PdMまたはデザイナーが仕様をドキュメントツールに記載します。

(4)リリースされ次第File：マスターファイルにデザインとコンポーネントをマージ

リリースされ次第、File：施策ファイルはFile：マスターファイルにデザインとコンポーネントをマージします。リリースされ次第、という時期をしっかり定義しておくことでどれが最新のデータなのかがわかりやすくなります。

(5)Team：アーカイブにFile：施策ファイルを移動

そしてTeam：アーカイブ内の該当ProjectにFile：施策ファイルをリリース日を追記した上で移動させます。リリース日を追記することで、どの様な時系列で施策が行われたのかがわかりやすくなり、前の施策のデザイン検討の履歴を参照しやすくなります。

⚠️ 検討時の注意点
この際もコンポーネントをそのまま繋いでおくと検討の履歴が正しく残りません。コンポーネント接続を切ること（Enter→Option + Command + “B”でDetach instance）をおすすめします。

まとめ

このようなFigmaの運用方法をプロジェクトで提案しました。結果、「抜け漏れがないかを事前に把握できるのでよかった」「エンジニアに渡しやすいデザインファイルになった」などといった嬉しいお言葉をいただきました。

今回紹介したのは一例であり、組織の規模や体制、サービスの性質によって適切な運用方法は異なります。運用しながら会社に合わせて再構築し、どのような運用方法が適切なのか？デザイナーだけでなく、PdMやエンジニアと一緒に模索しアップデートを重ねることが最も大事なことなのではないでしょうか。

この記事はGoodpatch Design Advent Calendar 2022 7日目でした！