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

はじめに

こんにちは。株式会社gazでUIデザイナーをしている@tosiiuです。

弊社ではスタートアップで発生する様々なデザインニーズに対して柔軟にデザインリソースを提供する「beaverin」という事業を運営しています。

この記事では、私がbeaverin事業でデザイン支援を行っている営業職向け資料作成Saas「SmartSlide」で現在運用しているデザインフローを紹介します。

課題

以前のSmartSlideではFigmaでマスターデータを管理し、それを中心にデザインを行っていました。その運用を続ける中で以下のような課題が発生していました。

Figma上のマスターデータと実装の同期が負担に

以前のSmartSlideではUIに対する変更が加わる経路として以下の3つがありました。

1. 通常のデザイン変更
デザイナーが主導する通常のデザイン変更です。Figmaを用いて以下のようにデザインの変更を決定していました。

【大きな変更の場合】
1. Figma上のマスターをもとに、作業用ページにてデザイン
2. レビュー＆修正
3. デザインFIX後、当該デザインをマスターへ反映
4. 実装

【小さな変更の場合】
1. 該当するマスターのフレームを作業中ステータスへ変更し、作業
2. レビュー＆修正
3. デザインFIX後、作業中ステータスを解除
4. 実装

2. Figmaを通さないデザイン変更
全てのUIに対する変更の意思決定が必ずしもFigmaを通して行われるとは限らず、Slackやミーティングで決定するUIの変更もありました。
例えば、細かな文言変更や、実装工数の観点から仕様を少し変更する際など、実装者とメンバーの間でUIの共通認識が取れているケースではわざわざFigmaにデザインを起こしていませんでした。

3. 実装者によるデザインの調整
当時はデザインデータをあくまで理想形と捉え、厳密に従わず、とにかく早く実装できる形に実装者の裁量で変更する方針をとっていました。ユーザーにプロダクトをとにかく早く届け、検証を重ねる必要があるスタートアップとしては初期のフェーズだったためです。

Figmaでマスター管理を行うため、これらの3つの経路によって変更されたUIを全て遡及的にマスターへ反映する必要がありました。
この反映コストは大きい上に、ユーザーに価値を届けることに直接寄与しないため、通常のデザインタスク（新規機能開発や既存機能の改善等）が優先されていました。

その結果、マスターデータと実装に乖離が生まれ、次のような問題が発生し始めていました。

・実際のUIにもとづいた検討がなされづらい
・マスターデータが最新であるか分からず、どこを見て仕様の確認や実装すべきか分からない
・実装者が「デザインデータに含まれる古い仕様」と「実際に実装されている仕様」を脳内で突き合わせ取捨選択をしながら実装する必要がある

プロトタイプの難易度が高く、メンテンスが難しい

当時はFigmaのマスターデータ上でプロトタイプの設定も行っていました。

Figmaのプロトタイプ機能には状態の概念や条件分岐の概念が無く、一定以上のプロトタイプ表現には「プロトタイプのためのフレーム」が必要になるケースが多いです。
しかし、保守性の観点からマスターデータは出来るだけ設計図としてのコンパクトさを保っていたいと考えていたため、プロトタイプ表現に制約が生じてしまうことがありました。

また、マスターデザイン上でプロトタイプを設計するとアプリケーションの全体の遷移をサポートすることになり、プロトタイプの規模としてはとても大きくなります。
Figmaのプロトタイプ機能は、基本的に目視で手動で一つ一つ設定・確認していくため、大きなプロトタイプでは抜け漏れが発生しやすくなっていました。

今どうやっているか

実装＝マスターデザイン

実装されているUI＝マスターデザインと定義し、Figma上のデザインデータは実装や共通認識のために使い捨てるものとみなしています。Figma上でのマスター管理は行っておらず、特段事情がない限り実装されたUIからの差分としてデザインを検討しています。

具体的には、現状実装されているUIのスクリーンショットをベースにデザインを行っています。（新しいビューを用意する場合等にはゼロからFigmaでデザインすることもあります。）
プラグインなどを利用してFigmaのオブジェクトとしてCode to Designな感じで取り込むのが理想ではありますが、Figmaへ読み込んだ後にレイアウトの崩れを修正する必要があるものが多く、この方法に落ち着いています（いい方法があったら教えて下さい）。

マスターへの反映作業が無くなったことによる大幅な工数削減はもちろんですが、現状のUIに基づいた、より有効なデザインが出来るようになったと感じています。
作業スコープ外の部分でのレビュアー・実装者との認識齟齬も大幅に減りチームとしてのストレスやミスがが軽減されました。

JiraチケットごとにFigmaを切り分ける

デザインファイルを目的に合わせた使い捨てとするため、Jiraとの対応関係を明確にしています。

Figma上での作業エリアを完全にJiraチケットごとに切り分けています。無料プランで運用していることもあり、ページやファイルでの切り分けではなく1ページ内でSectionを用いて作業エリアを切り分けています。

これは予想していませんでしたが、作業エリアを区切ったことによって、デザインに関連する情報を今まで以上に書き込むようになりました。
現状の実装や、新たに利用しているコンポーネント・素材、参考にした他サービスの仕様などを書き込むことにより実装者との認識齟齬を減らすことが出来ていると感じています。
以前のマスターデータは後から他の場面でも参照されるものであったことや、俯瞰した際の一覧性が重要であったことからデザインデータ以外の情報としては仕様の補足程度に留まっていました。

目的に応じてプロトタイプを用意する

プロトタイプが必要な際には新規にJiraのチケットとして起票することにしています。これにより「プロトタイプのためのフレーム」も気兼ねなく使いながら、スピード感を持ってプロトタイプを設計することが出来ます。またチケット起票時にそのプロトタイプの使用用途も決定されるため、プロトタイプのスコープを必要最低限に留めることが出来、重要なタスクや遷移も把握しやすいため抜け漏れが大幅に減少しました。

最後に

このデザイン運用フローは下記のnoteを参考にさせていただき策定を行いました。素晴らしい内容なので是非読んでみてください。