Figmaのガイドラインを作りました

デザイナーとしての仕事とはちょっと違いますが、1人目のデザイナーとして2人目以降のデザイナーの為に、Figmaの運用ルールを考え、ガイドラインを作りました。

なぜガイドラインを作ったのか

1人デザイナーとしてやってきたので、Figmaも自分自身のルールで運用していました。

しかしいずれ2人目のデザイナーが入るので、自分だけ分かるルールでFigmaを運用し続けていくことは、不可能でした。

その為、今後Figmaを決まったルールで運用していく為に、ガイドラインを作ることとしました。

課題を整理する

2人目のデザイナーの為だけだと、現在直面している課題を解決する事にはならないので、まず現状Figmaのガイドラインがない事によって、発生している課題を洗い出しました。

作るガイドラインは、この課題を解決する事を軸として考え、設計していきました。

直面している課題
・デザイナーとエンジニアで見ているデザインデータが違い、誤ったデザインがプロダクトに反映されてしまう事があった
・最新のデザインデータが、どこにあるかわからない事が多々あった

ガイドラインを作成する目的
・今後新しいデザイナーが入ってきても、正しいルールでサービスを運用・保守し続ける
・デザイナーとエンジニアでデザインデータの認識を合わせて、サービスを正しく更新し続ける
・デザインデータを適切に管理し続ける

Figmaのディレクトリ構造と運用ルールを可視化する

ガイドラインはデザイナー以外も使うので、まずFigmaのディレクトリ構造をスプレッドシートで可視化しました。

ファイルがどのような状態か、プロジェクトに名前をつけて管理する事にしました。状態は以下の3つとしました。

作業用
・作業中のFigmaファイルを入れる
管理用
・最新の画面デザインを全て入れる
リリース済み
・リリースが終わったFigmaファイルを入れる

Figmaのファイル名、Page、Frameの命名規則を決める

Figmaのファイルの命名規則とPage、Frameの命名規則を決めました。

社内はJIRAを使っていますので、ファイル番号はJIRAの番号としました。

Pageに、今のデザインステータスの名前をつける事にしました。デザインステータスは、以下の3つに分けました。

デザイン中
・デザインを作成中の場合
レビュー中
・デザインが終わり意思決定者にレビューをお願いしている場合
実装中
・レビューが終わりエンジニアが実装中の場合

Frameには画面がどのようなデザインかわかる為に、大項目・中項目・状態の3つに分けて管理する事にしました。

名前を決める為に、なんのページがあるのか洗い出しをしました。

ワークフローを可視化する

実際の運用ルールに則り、ワークフローを可視化しました。

変更点を視覚化できるものやUIフローを作る

デザインデータの変更点や、UIフローを視覚化する為のものを作成しました。

一部freecracyさんのデザインスペックを使い、自分達が使うだろうものだけ残しました。

バージョン管理は使わない

ガイドラインを作るにあたり、バージョン管理は使わない事としました。理由としては、

・スピーディーにリアルタイムで更新が出来るFigmaの場合、都度バージョン管理をすると生産性が落ちると思った為
・Figmaのバージョン管理はbranchを切れないので、そもそもバージョン管理としては向いていない
・editorしか使えないので、ほとんどデザイナー専用の機能となってしまっている
・運用ルールでは過去データは残しておく事ができるので、バージョン管理を使わなくても過去データが見れる
・デザインデータ自体がバージョン管理に向いていない
・そもそも使うケースが少なかった

となっております。

最後に

Figmaはスピーディーな開発と、誰でもデザインが見れるので透明性が上がるのが、一番良いところだと思っています。

その為、Figmaのスピード感を生かす為に敢えてバージョン管理を行わず、最低限の命名規則だけ行いました。

ガイドラインは実際に運用してみないと成果が分からない為、今後は実際に運用してみて、より自社に合った形に整えていきたいと思っています。

ポートフォリオサイトにも公開していますので、よかったら見てください！