デザインファイルを設計図としてみなし、使い捨てる向き合い方

初めに

こんにちは。株式会社ナレッジワークで業務向けソフトウェアをデザインしているsadakoaと申します。先日、Figmaにバージョン管理機能(Branching)が追加されたニュースが話題になりましたね。

Branching is officially here. ✨

You can now iterate on new ideas while preserving the main file, giving you just the right amount of structure to support creative freedom.

Available for Figma Orgs. https://t.co/kL8x7gJjUn pic.twitter.com/JzQNMTKsxD

— Figma (@figmadesign) October 12, 2021

デザインファイルをバージョン管理することは目新しいことではなく、過去にAbstractといったツールを導入していたデザイナーも少なくはないのでしょうか。
前職ではSketch × Abstractで機能追加/改善ごとにブランチを切り、マージリクエストでデザイン差分を取り込んでいましたが、振り返ってみるとGitでコードをバージョン管理するように、デザインファイルを管理して得られるメリットはあまり感じられなかった記憶がありました。その背景の理由として大きく3つの課題が挙げられます。

デザインファイルをバージョン管理する課題

1.製品上の画面とデザインファイルで乖離が生まれていく

大前提としてバージョン管理をするためにはマスターの概念が必要です。そしてデザインファイルのマスターは、製品上で提供されている画面構成と一致している必要があります。しかし現実的な運用では「ある程度揃っていれば良い」ぐらいの温度感で管理されているケースが多く、画面要素や文言が製品と乖離していることが多いです。

そのように割り切ってマスターを管理するのも運用の捉え方としてはありなのですが、製品上と比較して乖離しているマスターを管理する必要性については疑問があります。なぜなら画面仕様を確認する際、多くはマスターのデザインファイルからキャッチアップされることが多く、画面要素が乖離していることで仕様の認識齟齬が生まれる可能性が高いからです。

2.デザイン上のコンフリクトを解決しにくい

デザインファイルのコンフリクトを解消することは、コードと比べて非常に手間がかかります。当時(2019年頃)のAbstractでは、コンフリクトが画面単位の比較になるため、本来マスターと別ブランチで共通している箇所ですらコンフリクトの対象となっていました。

そのためコンフリクトを解消するためには、アートボードを比較してどこが古く、新しいのかを目Diffで発見する必要があり、非効率な修正対応を求められていました。

抜粋 - Merging Designs in Abstract — Part 1

ただこの課題については、reg-suit等のビジュアルリグレッションテストツールに実装されている差分ハイライト機能のようなものが実装されれば解決できそうですが、コンフリクトの対象がコンポーネント単位なのか、文言単位なのか、それらの見極めと判断はユーザーに委ねられます。

3.マージリクエストを受け入れるタイミングが難しい

バージョン管理においてブランチは、いずれマスターに取り込まれる必要があります。しかしその取り込みのタイミングの判断はとても難しいものです。もしマスターをすでにリリースされている製品上の画面郡と捉える場合は、デザインが完了した段階でマスターに取り込むことは難しいでしょう。

ではリリースされてからブランチを取り込むのが得策と思われますが、すでに完了されたデザインに対してすぐ開発に取り掛かることができないブランチは、結果的にマスターとの差分を多く生み大量のコンフリクトを起こしてしまう問題があります。

その問題を防ぐためにマスターから反映を取り込む（Pullと呼ばれる）仕組みがありますが、実際の業務では完全に独立している画面、機能のデザインをずっと別ブランチで管理することは難しく、結果的に一部でコンフリクトを起こしてしまうでしょう。（このあたりの問題はデザインファイル特有のものではなく、Gitでのコード管理でも同じだと思います）

1.製品上の画面とデザインファイルで乖離が生まれていく
2.デザイン上のコンフリクトを解決しにくい
3.マージリクエストを受け入れるタイミングが難しい

以上3つが個人的に感じている大きい課題です。その他にもプロダクトが成長、機能が増えるに従って管理せざるを得ない画面も増え、管理コストは右肩上がりで増え続けていくでしょう。

デザインファイルにどう向き合っているか

前提として、弊社ナレッジワークではマスターとして利用されるようなデザインファイルを管理していません。デザインファイルはあくまで実装上における「設計図」としての役割とみなし、スプリントごとに都度使い捨てることでデザインファイルの管理/運用コストを0にし、業務効率を上げています。

今回の記事では、3つの取り組みを例として紹介します。

1.StorybookとFigma Componentが一致している状態を保つ

Storybookとは、UIコンポーネント開発環境を提供するオープンソースのツールで、平たく言えば製品で利用されているUIカタログのようなものです。

StorybookとFigma Componentが一致している状態は、実装上で定義されているUIコンポーネントのみを利用してデザインできるため、結果的にデザインの一貫性が保たれます。また新規でUIコンポーネントを作成する場合は、Storybookに反映されてからFigmaでコンポーネント化しています。

StorybookからFigmaに逆輸入することで、プロダクト内に存在しないUIコンポーネントを用いてデザインがされるといった問題をなくすことができます。

UIコンポーネントはデザインを効率的に進める上で非常に重要な要素です。反面、その影響範囲も大きく管理/更新がうまくなされていないと、画面が崩れたり要素がコンフリクトを起こしやすい問題があります。そのため、マスターを運用するためのUIコンポーネントではなく、あくまで機能追加/改善のデザインを効率的に進めるためのUIコンポーネントと定義することで、それらの問題を防いでいます。

2.製品画面を.fig形式に変換してデザインする

すでにリリースされている製品画面をもとにデザインすることで、画面要素や文言の些細なズレを無くすことができます。このズレをなくすことは非常に重要で、特にQAのメンバーが確認する時に本来チェックする以外の箇所でズレがあると余計な確認コストを生んでしまうからです。

ナレッジワークではWebページをPDFとして保存し、そこから.fig形式に変換することで、上記フローを実現しています。具体的な参考例としてTripAdvisorのWebページを変換してデザインを調整している図を挙げていみました。以下のように文言変更や、機能追加/改善のUIデザインを行っています。

3.minispec単位でドキュメントにデザインファイルを埋め込む

デザインファイルをあくまで実装上における「設計図」としての役割とみなし、スプリントごとに都度使い捨てるために、開発中、QA、また振り返りのminispec粒度で振り返れるように管理する必要があります。

ナレッジワークではminispec単位に作成されたデザインをドキュメントサービスの中にiframeとして埋め込むことで、管理しています。

Figma上では2週間区切りにファイルを作成し、それぞれのPageに関連したJIRAのチケットナンバーを載せます。またPage単位でドキュメントを作り、そこにiframeで埋め込むことで、デザインに更新が入るたびにドキュメントも自動で更新されます。（ファイルを区切る理由は単純に重くなることを防ぐためです）

minispec単位でドキュメントにデザインファイルが埋めこむ利点として、「あの時のデザインどこにあったかな」とFigma上で探す必要はなく、ドキュメント側で探すことができるので、検索体験の向上とデザインファイル自体を当時のバージョンとして管理でき、必要なタイミングで最新のデザインと比較することができます。

以上3つがナレッジワークなりのデザインファイルとの向き合い方で行っている具体例です。それなりに課題もまだあり、Storybookの更新をSlackで通知できないか等、日々メンバーと議論しています。

まとめ

ソフトウェアにおけるUIデザインフローを新しい視点から最適化できないか、その一環として今記事ではわかりやすい例としてデザインファイルとの向き合い方を紹介しました。

当たり前のようにデザイナーが画面をソフトウェアツールで描き、エンジニアがそれを参考に実装する。従来実践されてきたこのフローに対して「本当にこれは効率的か？」そんな疑問を持っています。なぜならER図やEER図のようにエンジニアリングは適切に設計を理解するためのメソッドがあるのに対して、デザインはとても属人的だと考えているからです。

日々の業務に向き合いながら、最適化のために様々な試みをしています。この記事を読んで更に興味がある人や悩んでいる方が、ぜひお互いに意見交換や情報共有などできると嬉しいです。

どんなフローでUIデザインをしているのか一緒に意見交換しませんか？