デザインデータのマスター管理をやめたワケ

ビズリーチ事業部でデザインチームのリーダーを担当しています長尾です。

みなさんはプロダクトのデザインデータをどのように管理していますか。
今回は私たちのチームで、デザインデータのマスター管理をやめて、Figmaのファイル構成と開発フローを変えた話を紹介します。

この記事は、2022年4月に登壇した ViViViTさま主催のオンラインイベント「デザナレ」の内容をまとめたものになります。

マスター管理をやめて、工数を削減

私たちはマスター管理をやめたことで、少人数で開発の最新情報を常に同期できている状態を作ることができ、デザインの作業工数やエンジニアとのコミュニケーションにかかる時間を削減できました。

デザインを後で見返すときに困らないか懸念もありましたが、デザイナーは常に実装されている最新のデザインを把握していますし、エンジニアも実装するデザインデータしか必要なく、データの場所を常に把握できています。そのため、マスターデータがなくても不都合は起こりませんでした。

それでは次のセクションから、開発チームの体制、チームの課題、Figmaのファイル構成やワークフローのBefore / Afterなど、その中身をくわしく紹介します。

開発は、少人数のスクラム体制

私が担当している「Executive Search Support」は、主にヘッドハンター様が、ビズリーチに登録している会員様にスカウトを送るプロダクトです。

このプロダクトは、多くのヘッドハンター様に利用していただいていますが、開発はデザイナー2名を含めた、全12名のスモールチームで開発しています。

スクラム開発を導入していて、スプリントは2週間単位。プロダクトオーナーや、プロダクトマネージャー、エンジニア、QAのメンバーと密に連携できる体制です。

私たちのチームの特徴は開発チーム全員で施策を課題から検討していること。そのため、デザイン段階でもFigmaファイルを全員で触りながら議論を進めます。もちろんデザイナーもヒアリングや定量分析から参加して、課題設定からリリース後の振り返りまで、一気通貫で携わっています。

課題は、認識を揃えるためのコミュニケーションコスト

この体制で起きていた課題は、デザイナーとエンジニア間でFigmaのデザインデータに関する認識を揃えるためのコミュニケーションコストがかかっていたことでした。

課題の背景にあったのは、Figmaのファイル構成とリリースまでのワークフローです。

変更前のFigmaファイル構成

プロダクトに関わるすべてのデザインデータを、1つのファイルで管理していました。

ファイルは「作業用ページ」「Masterページ」「Componentページ」の3種類のページで構成されています。

作業用ページは、デザイナーの作業スペースで、チームで仕様を決めるときの議論やデザインレビューもこのページで行います。

Componentページは、プロダクトで利用するすべてのコンポーネントを管理するページです。Atomic Designの概念で言うと、Atoms単位からOrganisms単位でコンポーネント化したデータを格納しています。

今回管理をやめたMasterページは、プロダクトのすべての画面を管理しており、画面遷移やステータスによる画面の違いを網羅しています。ページ数は21にのぼり、各ページには平均約30のアートボードで管理していました。

変更前のワークフロー

次に「リリースまでのワークフローと、各ページをどのように使っていたか」を説明します。

このワークフローの課題は、リリースまでに2回、エンジニアにFigmaの最新ファイルを共有して合意形成する必要があることでした。

作業用ページでデザインFIXまでを行う
デザイン作成から、仕様決定、デザインレビュー、デザインFIXまでを行います。仕様を決める前には、エンジニアやプロダクトオーナーらに、対象となるアートボードのURLを共有していました。

Masterページにデータを反映して、実装してもらう
FIXしたデザインをMasterページに反映し、実装用データとしてエンジニアにURLを共有、エンジニアによって本番環境へ実装・リリースされます。

Componentページの編集
新しいコンポーネントや既存コンポーネントの編集が必要になった場合は、Componentページに反映して、常に最新の状態を保ちます。

Masterページへのデータ反映がボトルネックに

このワークフローでボトルネックになっていたのが、Masterページへの反映作業でした。

チームのデザイナーは私を含む2名で、それぞれ2〜4件の施策を担当しています。そのため、デザインFIXまでの作業を優先して、Masterページに反映する時間を作れず後回しになりがちでした。

Masterページは、画面遷移やステータスごとの画面パターンを全て網羅しており、1つの画面がMasterページに複数あります。1つデザインを変えると、膨大な量のアートボードから変更すべき画面を探して、全ての画面を変更する作業に時間がかかっていました。

Masterページに最新の状態が反映されていないと、エンジニアも必要なアートボードがどこにあるかわからず、結局膨大な量のアートボードから探さなくてはなりません。

そのため、たびたびエンジニアからは「最新のデザインはどこにあるのか」「FIXしたデザインデータとMasterページのデータが違う」などの声が上がり、混乱させてしまっていました。

こうした情報とデータ共有のすれ違いが積み重なり、Figmaに関する認識を揃えるためのコミュニケーション工数がかかっていたのです。

マスター管理をやめて、ファイル構成とワークフローを変更する

このような経緯でデザインデータのマスター管理をやめることにしました。

具体的には、Masterページにデザインデータを反映する工程をなくし、施策単位でFigmaのページを作成するようにしたので、ファイル構成とリリースまでのワークフローを紹介します。

変更後のファイル構成

これまでは1つのファイルにすべてのデザインデータを格納していましたが、施策用と、コンポーネント管理用の2つのファイルに分けました。

施策用ファイルには、施策ごとにページを作っています。
1つのページで施策に関わる課題設定やワイヤーフレーム作成、スタイルの調整、実装用の仕様メモなど、リリースまでに必要なすべての情報を管理して、そのページだけで完結できるようにしています。

施策ごとにページを作りファイル内にページが増えて、後で見返しにくくならないよう、3ヶ月ごとに新しい施策用ファイルを作る運用にしています。

施策ページは、目的に合わせてざっくりエリアを分けています。左側はFIXしたデザインを置くエリア、右側は作業用エリアです。

あえて作業用エリアを作っているのは、意思決定などの議論の場で手戻りを減らすためです。

チーム全員で仕様を決めるときに、デザインを検討した思考の変遷や作業プロセスを誰でも見れるようにしておくと、なぜそのアウトプットになったか説明しやすく、スムーズに合意形成できます。

変更後のワークフロー

デザインデータをMasterページに反映する作業がなくなり、施策用ページをそのまま実装データとしてエンジニアに渡せるようになりました。

以前は、エンジニアにデザイン作成から実装までに2回データを渡していましたが、Figmaのデータ共有が1回で済んでいます。

マスター管理をやめた結果

デザインデータのマスター管理をやめて、デザインの作業工数やエンジニアとのコミュニケーションにかかる時間を削減できました。

1スプリントで、約1〜1.5時間の削減になりました。時間の削減で、実装・リリースまでの時間が短くなり、結果的にユーザーへの価値提供のスピードも上がっています。

ワークフロー上は1つの作業がなくなっただけですが、反映する画面の量や細かい余白調整に時間がかかっており、常にMasterを更新し続けるタスクやプレッシャーがなくなって、グロース施策に集中できるようになったのもよかったです。

エンジニアとのFigmaファイルのやりとりも、共有するアートボードのURLを一元管理できるようになりました。全員が同じデータを見れることで、認識を合わせるコミュニケーションが減って、本当に必要な議論に時間を使えるようになりました。

当日いただいた質問への回答

イベント当日は皆様から多数質問をいただきましたので、一部の質問への回答を紹介します。

Q：
同じように施策単位でFigmaのページを分けています。同じ画面を並行して更新するときに、差分の管理が複雑になってしまっています。この場合、どのように解決しているかなどあれば教えていただきたいです。

A：
そのような場面に遭遇したことがないですが、両方のページに反映せず、Figma上にメモや付箋で「〇〇は反映できていないです」などのメモを添えて対応すると思います。

Q：
エンジニアや企画などが既存デザインを見るときは、各施策のファイルを見にいくのでしょうか。それとも、既存デザインは別にファイルを設けているのでしょうか。

A：
Figmaファイル内にあるそれぞれの施策ページを見てもらっています。
施策ごとにAsanaのタスクを立てて、施策ページのFigma URLや仕様、受け入れ条件などを全てまとめる運用にしています。ですので、いつ誰でもAsanaから施策に関わる既存デザインや、作業中のデザインを見られます。

Q：
新しいメンバーが入った時に、認識のずれは起こらないのでしょうか。

A：
基本的には実装したサービスを正としているので、新メンバーの方には実際の画面を見てもらって認識を揃えています。 

またComponentページに、テンプレート単位でガイドを用意しているので、今のところ大きく認識がずれることは起きていません。

おわりに

デザインのマスター管理をやめるにあたり、Figmaのファイル構成やリリースまでのワークフローをどのように変えたか。工数が減った結果とともに紹介させていただきました。

メンバーの人数や、ステークホルダーとの関わり方など、開発の環境などが違えばそれぞれに最適なワークフローがあると思いますし、私が所属するチームも変化がおこれば、それに適応する必要があると考えています。

今回、他社の方々のプレゼンを聞いて強く感じたのは、Figmaはあくまでも1つのツールでしかないことです。プロダクト開発に携わるメンバーとして何より優先すべきなのは、いかに早くユーザーに価値あるサービスを届けるかです。あわせて、デザイナーとしてはスピードだけでなく、品質を守ることも重要です。

これからも業務を行いながら、ワークフローの課題を探し、最適化を行っていきたいと思います。

ViViViTでアーカイブ動画を公開しています

登壇のアーカイブ動画を公開中です。興味を持たれた方は、ぜひ下記リンクからご覧ください。

「デザナレ」アーカイブ動画
※動画を見るには、ViViViTにログインする必要があります。