【Figma公式推奨】使い方ではなく、運用方法マニュアル2024年版
2024年リリースのMulti-Editに対応しました。
Figmaconfig2023にリリースされたVariables,Developer mode,NestedComponentに対応しました。
Figmaconfig2022で発表されたComponent PropertyとAutoLayoutについても追記しました。
世の中のFigmaの日本語ドキュメントがショートカットや基本機能の解説に終始していることで、毎回チームに運用マニュアルをインストール必要が出てきて辛いのでこちらにオープンドキュメントとしてまとめておきます。
コピペしてアップデートしてもらって大丈夫です。各社のNotionページにPullしてあげてください。
あくまで現状のFigmaの仕様の前提で個人的な運用最適解としての見解です、こういったたたき台があることで議論が活発になると嬉しいなという気持ちです。💕気に入ってくれた方はフォローお願いします！
https://twitter.com/rikikamano
①Team,Project,File,Pageの使い分け方
前提としてそもそも会社やチームの規模感によって違いことはいうまでもありません。
その上で、基本的な最善手は
Team
ProductA(iOS),ProductA(Android),ProductB(iOS),DesignToken,Other
Project
Wip,UnderReview,Shipped,DesignSystem
File
FeatureA,FeatureB,EnchanceA,Master
Page
Main,Dev,ResearchTeamsを分ける一番大きな理由はデザインシステムが使い分けられることです。トークンとして出し分けることが想定される場合はProductやOS単位でTeamを分割するほうが余計な混乱を避けることができるでしょう。
もちろんTeamに関しては、そこまで課金してませんということもあると思うのでそういった場合は下記のような粒度でも問題はないと思います。大事なことはPageやFrameを最小単位で運用することです。
Project
ProductA(iOS),ProductA(Android),ProductA(iOSのShipped),ProductA(AndroidのShipped),DesignSystem,Other
File
FeatureA,FeatureB,EnchanceA,Master
Page
Main,Dev,ResearchProjectは基本的にFileをシンプルにするための一覧性の高いワークフローとしてみるのが一番です。チームが小さいうちは課金額などの都合でProjectを,Salesなどの他チームとの区切りにしてしまったり、ProductAの中でProjectをiOSとAndroidなどと分けてしまうと、デザインのステータスが結局FileのPageに寄ってしまい、視認性が悪くなったり単純に読み込みが重くなってしまいます。
最後にFileやPageは前述の通り、デザインのステータスの中でも最小限の単位、作業中や完成、リサーチ中などのステータスで収めるべきです。たまに見るFileを登録画面のように分けて、どんどんMainにマージしていくという手法は、登録画面のようなページの概念が認識ズレ起きやすかったり、一つのページで複数変更が走ると辛いので、1PRに対して1Fileが安全策だと思います。Masterが全画面で見れないものめんどくさいですしね。Fileの中で過程を残しておく必要がある場合は右に行くほど最新、パターンだしは下に展開などルールを決めておくと良さそうです。
細かいですがPCとSP作る必要がある場合も、実装者が同じであればPageを分ける必要性はあまり感じません。更に細かいですがデザインシステムが細かくアプデ走るときはFile肥大化するとコンポーネントのUpdateめんどくさいので細かくする恩恵を受けられます。
これらはFigma公式でも推奨されている使い方と利用シーンです。
https://www.figma.com/best-practices/team-file-organization/teams/
②ファイル名の付け方
Figmaの検索アルゴリズムの微妙さは、中の人がよくわかっています。Figmaのデザイナーが推奨する、タグ名をひたすらつけてなにかのワードで引っかるようにするが現状最適解です。
もちろんIssueのチケット名と一致させるなどは大前提ですね。
③テンプレートファイルの使い方
これは上記で推奨したPageの構成やファイル名の命名規則を設定しておいてテンプレートファイルとして置くのがシンプルで良いと思います。
④GroupとFrame、Sectionの使い分け方、名前の付け方
結論から言うとFrameは子要素の整理の基準となる枠です。FrameにすることでConstraintやAutoLayoutを使うことができます。なのでFrameを作成する時にデバイスごとのサイズを選択できるわけですね。
※またFrameはそれ自体にStorokeなどのプロパティを持つことができます
Groupは単純にScaleのConstraintしかかからないので、2段の文字組みやコンポーネントのAtomより小さい単位に使うべきだと思います。
そして最後のSectionはFrameからレイアウト機能や他のプロパティをもたせることができない単純な整理用の機能です。
命名は基本的にコンポーネントと同じですが、初期は画面単位でついていればGroup0000、Frame0000で十分です。
⑤コンポーネント名の付け方
このへんも僕の考えた最強の命名規則が大量に存在していますが、基本は公式に忠実に
- 命名は実装のクラス名に寄せる
- 基本単数形
- アッパーキャメルケース
- 種別を / ではなくできる限りVariantとPropertyで定義
- Variantは色とサイズに限定して、それ以外はPropertyでBoolenやTextタイプを使って定義
- ただ初学者は最初はComponent / Size / Typeくらいが妥当
- AutolayoutでComponentを整理するとFrameの入れ子が複雑になるので避ける単体で利用されることのないコンポーネントは、
_Calendar-dayRowとして、同時に使われる親と子のコンポーネントの結合がわかるようにしています。
あとコンポーネントの階層を深くすると検索性が悪くなるのでState系の分岐はVariantを使ったり、コンポーネント数が増えてくるとButtonの下の要素はすべてVariantにしたりいてコンパクトに運用しています。
それでも一番上の階層から下階層のインスタンススワップがめんどくさいという場合は上の階層から下階層を操作しやすくするようNestedComponentを活用しましょう。
システムに関する運用の詳細はこちらにまとまってます
⑤サムネイルの作り方
サムネイルは最低限でいいと思います。テンプレートがFigmaCommunityにあるのでそのあたりを参考にしてみるでよいかなと。
ステータスの表記や、デバイスのタグとかはProjectやTeamの分類で自明なことなので過度にコストをかけないほうが良いと感じます。
⑥コメントの使い方
a.コメントで確認が必要なものは相手にメンションを向ける
通知はデフォルトだとメールで来ているはずですが、Slackなどで受け取りたい場合は2通りの方法があります
SlackにFigmaアプリをインストールしてDMで受け取る
指定のチャンネルにFigmaアプリを招待する
ただ、連携するファイルを設定する必要があるのでめんどくさい。ファイルの追加とかはProject単位で設定できる
細かいですが、確認者はスタンプではなくメンションを向けて答えてあげましょう🔥
b.疑問点が解決したコメントはResolveして認識があったことを確認しましょう
ファイル単位でステータスを実装に進める場合はResolvedされてないものがないか確認しましょう、あれこれどうなってったけを起こさないように。
c.1つのスレッドの中に違うイシューを混ぜない
これはSlack等々でもリテラシーとして問われる話かもしれませんが、さかのぼって背景などを知りたい時にノイズになるので1スレッド1イシューで済むようにこまめにReslovedしましょう。
d.コメント内はデザインに関するイシューに限定するように努力する
仕様や実装に関する話をしてしまうと、これなんでこうなったんだっけとなった時にFigmaのコメントなのかSlackなのかコンフルなのかJiraなのかワケわからなくなって辛くなるので、要注意。
理想はやりとりは中心となるドキュメントツールが有ると良いと思います、Single Source of Truthな仕様書的な。
e.コメントの指摘箇所は正確に、可能なら範囲を指定する
たまに起きるんですがコメントの指摘が、指定の画面からだいぶずれていることがあります。改善パターンを出すたびにコメントの位置を変えたり、コメントの範囲指定をしっかりおこないましょう。
⑦プラグインの使い方
プラグインはチームに共有されることはないので、自分の検索の邪魔にならない程度に使っていないものをアンインストールすると良いと思います。
逆に他の人がどんなプラグインで楽をしているのか？が見えづらいのでそのあたりはMTGやペアデザ等で共有してみると気づきがありそうです😏
⑧デザインの配置の仕方
これはあまり議論にあがることはありませんが、作った画面のパターンや遷移をいい感じに見せるメソッドは1つです。
同階層の遷移は縦に階層の下がる遷移は横に、パターンも横に展開する
理由は単純に作業するPCのディスプレイが横長で、増え続けるパターンを一覧で見やすいからです。
ついでに階層構造なんかも横縦いい感じに配置してあげると、ユーザーストーリーが視覚化されていい感じです。
⑨Branchの使い方
バージョン管理を擬似的なファイルのコピーで行うブランチは基本的にDiffが分かりづらいというのもあり、多用するシーンは少ないです。
ただ今推奨している利用方法だと1施策に複数人が改善案を出すパターンなどはかなり複雑になるので、ブランチを使ってみると良いと思います。
MasterみたいなものをPageにおいた時にアマチュアのデザイナーからそれをブロックする機能が現状無いのでそういったシーンには適していると思います。
⑩通知関連
Figmaは民主化したとはいえメール通知などでは多職種の方に気づいて貰えない可能性が高いです。
Slackと連携して通知を受け取りやすくしてもらったり、チャンネルに流すようにしましょう。
⑪その他
デザイン的な細かい仕様をふせんコンポーネントとするやり方が通例として存在するようですが、個人的には仕様書にすべてまとめておくほうが背景やイシュー、なぜそうなったのかを一貫して理解できるのでそちらをおすすめしています。
そういったドキュメントはDevmodeのFrameと各種ツールを連携する機能をつかって紐づけて置きましょう。
仕様書やいろんなドキュメントをいい感じにNotionで運用する方法はこちら
人それぞれな使い方は型を学んでから
はじめに知っておけばこういった運用で躓くことはないはずですがFigmaのBestPracticeのドキュメントは全部英文なので意外に浸透していない気がします。
昨今デザインリファクタという言葉も聞くようになりましたが、そういったタイミングで運用自体のフローも見直されるとみんなハッピーになれるはずです。
何かご意見、ご質問あらば下記からお願いします😆
いつもありがとうございます、面白い話するのでお茶でもしましょう。