【Figma】複数人でも管理・作業しやすいデザインルールを考える
自己紹介＆執筆背景
こんにちは、坂元 亜希織（さかもと あきお）です。
web系の専門学校卒業後、不動産Techで5年半webデザイナーとして務めた後、2020年に株式会社Sun AsteriskにUI/UXデザイナーとして中途入社しました。
Sun*に入社してから、複数人でデザイン作業をする機会が増えました！
仲間と一緒に作り上げていく楽しさを感じつつも、忙しくなるにつれ段々と統率が取れなくなって、デザインに一貫性がなくなったり、デザインファイルが汚くなったり…。
管理上の困ったことにも悩まされる日々です。
今回は「Figmaで、複数人でも管理・作業しやすいデザインルールを作る」をテーマに、とあるプロジェクトで私が体験してきた失敗と、それに対する施策をSun* Advent Calendar 2022 17日目の記事としてまとめます。
失敗①どこになんのページがあるかわからない
プロジェクト開始から2年超…Figmaファイル上には200くらいの画面が無秩序に配置されるカオス状態になっていました。
▼こうなった経緯
Figmaの便利機能である「Prototype」。画面同士を線でつなぐことで画面遷移を表現し、プレビューで実際に近い画面の操作感を再現できます。
プロジェクト開始当時、Prototypeの恩恵を最大限受けるために1つのページに全ての画面デザインを集約する形でデザインを作成していました。（ファイル上のページ間をまたいでPrototypeをつなぐことはできないため）
しかし、新機能実装のたびに必要な画面デザインが増えていきます。
画面の配置ルールも決めていなかったため画面上には夥しい数の画面が無秩序にひしめくことになるのですが、複数人で作業していると当然どこになにがあるかわからなくなり…。
2年も経てば1ページ管理の恩恵よりも弊害のほうが大きくなってしまいました。
▼解決した方法
サイドバーナビゲーションの構成に沿ってページを分けた
ページの中での画面配置ルールを策定した
1.サイドバーナビゲーションの構成に沿ってページを分けた
デザイン作業が落ち着いた隙を見計らって、サイドバーナビゲーションの構成に合わせたページ構成で画面を分けることにしました。（すごい時間かかった）
ある程度の規模が見込めるプロジェクトであれば、最初からページを分けて管理されることをおすすめしたいです。
ページをまたぐような遷移に関しては、遷移先FrameのURLをテキストリンクにしてメモを残しておく形で運用しました。
クリックするとFigma内で該当のFrameへ遷移できます。ブラウザで動作するFigmaだからこそできる技ですね。
2.ページの中での画面配置ルールを策定した
▼策定したルールは以下です。
列方向に画面の遷移を、行方向に画面のバリエーションやパターンを配置する
複数のフローがある場合は起点となる画面の列は空け、改行してフローを配置する
ページ遷移を実線で描くことで、画面遷移を把握しやすくする
ページ遷移を実線で描くことに関しては、以下の理由からこのような対応となりましたが、状況によってPrototypeを使ってもよいと思います。
クライアントもFigmaを見るため、操作に慣れない人でも遷移をわかるようにしたい
条件による分岐まで設定できない
今のところ条件による分岐が多いようであればこの方法が一番わかりやすいかな？と思います。
画面上に簡単にフローチャートや画面遷移図を引くプラグイン「Autoflow」を使うと作業がかなり楽になります。
これでだいぶ迷子になる原因を潰せましたし、
画面遷移を意識しながら修正作業が行えるため、影響範囲の認識漏れも防げそうです。
失敗②同じ役割の画面が複数ある場合に、デザイン修正が漏れる
例えば
ダッシュボードから遷移する受注入力画面では全ての項目を入力可能
顧客情報から遷移する受注入力画面では顧客情報を記入済みのdisabledにする
など、遷移元によって若干デザインが変わるケースってありますよね？
こういった場合、今までは先に作った受注入力画面を複製してdisabledパターンのデザインを作成していたのですが、修正が発生した際にこの複製されたdisabledパターンの修正が漏れるということが結構起こっていました。
▼解決した方法
1.修正元をなるべく一箇所に集約した
ダッシュボードから遷移する受注入力画面をComponent「default」とし、となりに顧客情報をdisabledにしたデザインをVarient「disabled」として登録します。
そして、顧客情報のフロー上にはVarientの複製を配置します。
デザイン修正が発生した際、「default」の隣に「disabled」があるので修正を忘れることはありませんし、複製側にも自動で修正が反映されることになるので複製が何個あろうとも修正は一度で済みます。
失敗③作り手によりデザインの差異が生じる
これはまだ解決できていない課題です。今後どう解決していくかをまとめています
▼目立った課題は3つです
コンポーネントを使いまわせず、デザインに一貫性がなくなる
細部の余白ルールまで設定できていない
文言の表記揺れが多発する
▼今後行いたい解決方法
Atomic Designでのコンポーネント整理
Atomic Designを応用した余白ルールの整理
表記のルールを厳密に定める
1.Atomic Designでのコンポーネント整理
Atomic Designとは、アメリカのWebデザイナーのBrad Frost氏によって考案・提唱された考え方です。
UI の構成要素を5段階に分けて考えるという点が最大の特長です。
Atomic Designの定義に照らし合わせると、当該プロジェクトでのComponent定義はせいぜいLv.1 原子〜Lv.2 分子 程度の最低限のものでした。
個々が使いやすいように大きなパーツをComponent化することはありましたが、それを全体で共有し、一箇所で管理するということをしていなかったのです。
今後はある程度まとまった単位でもComponentを定義していくことで、デザインに一体感を持たせ、開発コストも削減していければな〜と思っています。
コンポーネント化するかしないかの判断基準がないとうまく運用できなさそうなので、以下のようなルールを設けるとよさそうです。
2つ以上のバリエーションが出来る（できそうな）場合
2回以上の利用機会がある/ありそうな場合
追加定義を行った場合、定例やプロトタイプツールのコメント機能でお知らせする
2.Atomic Designを応用した余白ルールの整理
ヘッダーとコンテンツの間など、ページレイアウトに関する余白ルールは定めていましたが、細かいデザインにまでルールを適用するのが難しく、「8の倍数で余白設定してね」くらいであとはデザイナー個人の裁量に任せていました。
大半は問題なくデザインできるのですが、辻褄が合わない場面も多々増えてきます。
そこで、余白ルールにもAtomic Designの5段階のレベルをうまく活用するのを検討しています
例えば
隣接するComponentがLv.1同士なら8pxの余白を設ける
隣接するComponentにLv.2が含まれるなら16pxの余白を設ける
…
といった形で、ある程度のまとまりごとに余白感を定義できそう…じゃないですか？
各Componentが持っているpaddingによっては余白が空きすぎて見えたりしてしまうので、全てのケースでこのルールが適応できるわけではないのですが、ある程度の指針にはなるかな？と思っています。
また、Componentとして定義していないデザインでも、個人の中にある程度余白の基準がインプットされるので、全員が近い感覚でデザインすることが可能になりそうです。
割と実験的な方法な気がしますが、今後チャレンジしていきたいです。
3.表記のルールを厳密に設定する
これはもう表記揺れを見つけて潰していく作業になりますが、表記揺れの傾向なんかは今までの経験でなんとなく分かっていたので、プロジェクト開始時点で定義できていればよかったな〜と後悔しています。
▼よくある失敗
似た意味を持つ単語の表記揺れ（作成 / 追加 / 登録 など）
アクションボタンのラベルの表記揺れ（編集する / 編集 など）
おくりがなの表記ゆれ（取り消し / 取消し / 取消 など）
Figmaでは文言の一括置換も可能です。
左サイドバーの検索枠から表記揺れの文言を検索→右のアイコンから「Replace」選択で簡単に該当箇所の洗い出しと置換ができます。
まとめ
理想は、”10人いれば10人が同じ判断で同じデザインができること”です。
完璧は無理でも、少しでも近づけたらデザイナーも開発もハッピー！
私の失敗を、少しでもデザインルール策定に役立てていただけると幸いです。
Sun* Advent Calendar 2022はまだ続きます！
明日18日はKohei Takahashiさんの「WindowsでPodmanの環境を用意してみる ～Docker Desktopの影を求めて～」です。お楽しみに！