カテゴリー
Design Develop

Figmaのメインコンポーネント移動

FigmaでB2B系など画面数が多いサービスをデザインするときに汎用パーツをコンポーネントにして一元管理することでデザイン・仕様変更などの対応コストを抑える構成にするが、その際にFigmaのライブラリ機能を使ってメインコンポーネントと画面デザインを別Figmaで運用することも多い。(MUIなどのデザインシステムのコンポーネントFigmaを利用する場合も同様)

ただ画面デザイン工程でメインコンポーネントに必要な要素が網羅されていることは少なく、往々にしてコンポーネントの作成+追加が必要になる。

その際に、画面デザインFigmaで作成したコンポーネントを、メインコンポーネント管理のFigmaに移動させる場合があるのだけど、この方法がちょとわかりづらく、失敗するとメインコンポーネントに紐づかない迷子インスタンスが発生して実装時に混乱が生じるので、メインコンポーネントの移動方法をメモしておく。

Figmaの構成は「ライブラリ管理」と「デザイン作業」の2つ。

「デザイン作業Figma」で作成したコンポーネントのメインコンポーネントを「ライブラリ管理Figma」に移動させていきます。

まず「デザイン作業Figma」はライブラリのインスタンスを参照利用しているだけで、メインコンポーネントを持っていない状態。

しかし作業中に「デザインFigma内」でコンポーネント(Comp-B)の作成が発生。このメインコンポーネントを「ライブラリ管理Figma」に移動させる。

移動の手順は大きく分けて以下の4ステップ。

  1. 移動の準備
  2. 移動の実行
  3. 移動の反映
  4. 移動の確認

ということで、以下メインコンポーネントの移動手順の詳細。

1)移動の準備

移動させるコンポーネント(Comp-B)のコンテクストメニューからMain Component / Publish selected componentsを選択してPublish。

⚠️Publish処理完了までのタイムラグについて

成功通知がToast表示されるまで待機が必要。時々完了までの時間がかかる場合があり、完了前に次の作業をするとややこしい状態になることがある。

2)移動の実行

移動させるコンポーネント(Comp-B)を「デザイン作業Figma」からカットして「ライブラリ管理Figma」にペースト。

ペーストすると画面右下にライブラリアップデートの通知Toastが表示されるのでPublishをクリック。

⚠️間違えてDismissした場合

左パネルのライブラリアイコンからPublishしても大丈夫。不安な場合は両方のFigmaでUndoして移動前の状態に戻しても一応大丈夫。

Publishパネルが開くのでPublishを実行。完了通知Toastがでるまで待機。

3)移動の反映

続いて「デザイン作業Figma」にマスターコンポーネントの移動を反映させる。

「デザイン作業Figma」のLibraryアイコンからライブラリ管理パネルを開くと、移動したコンポーネントが表示されているのでUpdateを実行。

⚠️インスタンスパネルからのアップデートについて

「デザイン作業Figma」の移動コンポーネントのインスタンスを選択した右パネルのアップデートアイコンからもアップデートが可能。ただし、選択インスタンスだけのアップデートになるので注意(プレビューなどで一部インスタンスにだけ変更を反映したい場合に利用する感じ)

4)移動の確認

確認方法はいくつかあるが、念の為全部やっておいたほうが安全。この確認でRestoreが提示される場合は3)移動の反映を忘れている可能性が高い。

4a)メインコンポーネントの参照

「デザイン作業Figma」上のインスタンスからGo to main componet (Ctrl+Alt+Shift+K) を実行して「ライブラリ管理Figma」が表示されればOK。

4b)ライブラリの確認

「デザイン作業Figma」「ライブラリ管理Figma」両方のライブラリをライブラリパネルで確認。

以上でメインコンポーネントの移動は完了。

🐙余談

1つのライブラリで複数プロダクトを複数チームがデザインしているようなデザインシステム運用の話になるのだけど、マスターライブラリへの格上げ承認を誰が管轄するのか?というワークフロー的な課題を強く感じる場面が多い。

理想はマスターライブラリ運用チームが監査+承認する形だろうけど、そこまでリソースが確保されているケースはなかなか無い気がする。

しかしマスター運用をきちんとしないと、プロダクトごとに独自デザインルールが発生することになり、デザインシステムの価値が無くなるリスクがある(当然コード管理も含めて)。

一方であまりにストリクトな管理にしてしまうと開発スピードの低下や、ユーザービリティ最適化の弊害となるリスクもあるため、堅牢性と柔軟性のバランスを持った組織構成とワークフローの検討がかなり重要になるが、そのへんうまく運用できているケースがどれくらいあるのか興味がある。

Googleでもプロダクトごとに統一されていないケースが多いし、Attlasianみたいにデザインシステムあるけどサービスとして使いやすいのか?という疑問を感じるケースも多々ある😅

現状のデザインシステムではレイアウトや複合要素に対する定義はまだ不十分な点があるように感じる。レイアウトレベルのコンポーネント化などができようになるとデザインシステム管轄範囲の定義などスムーズになりそうな気がするけれど、その方法はまだ見当ついてない・・・(現状FigmaではInstance Swapで対応する形が主流だけど、かなり面倒だし実装時の見通しが悪い)

デザインシステムの運用で興味深い記事を見つけたので後で読む

属人化させないデザインルール管理。ログラスの「AI駆動のデザインシステム運用フロー」について|Cocoda

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です