「どのデザインがFixしてるのか分からない」を無くす。
「どのデザインがFixしてるのか分からない」を無くす。
「どのデザインがFixしてるのか分からない」そんな意見を聞いたことはありませんか？これはよくあるコミュニケーション摩擦で、これがフォローされているかそうでないかで、開発の体験やデザイナー-エンジニア間の関係性も変わってきます。そこで今回は、私たちがDesignOpsの基礎として行っているFigmaのProject構成を、目的や経緯とともにお見せします。
Figmaをご利用の皆さんの会社では、自社のFigmaの構成はどのようになっていますか？
仕事をする環境の優秀さ・効率は生産性に直接的に影響します。
これを鑑みて、私の関わるプロジェクトではおよその場合、より本質的な機能開発に集中できる環境を用意すべく、デザインの環境構築や仕組み化に力を入れています。
今日はその内の1つであるFigmaの構成についてシェアします。
Project構成
FigmaにはTeamやProjectという機能があります。これはフォルダに近い機能で、シンプルな機能ですが工夫することで一定のワークフローを構築するのに役立ちます。
まず結論として、現在携わっているSTANDS社の「Onboarding」では、UIデザイン用のProjectを下記の2つに分けています。
Structured：fixしたコンポーネントのみを使って構成するUIデザイン
Not Structured：
必ずしもfixしたコンポーネントを使わないUIデザイン。プロトタイピングなどの探索的な設計を行う
Projectを分けるべき理由
このようにUI用のProjectを2つに分ける理由は何でしょうか？ 1つのProject内に混在させてはいけないのでしょうか？
ハンドオフ
端的に言えば、異なるステータスのデザインファイルが1つのProject内に混在していると、許容できない問題が発生します。
それは、ファイルが増えるごとに(つまり時間が経つごとに)ハンドオフフローが少しずつ不透明になり、フロントエンドに関わるスループットを下げていくということです。
この原因は、UIデザインはFigmaで作って終わりではなく実装まで行って完了である という現実にあります。
この現実の中で重大になってくるのは、数多くあるデザインの内どれがfixしていてどれがデザイン中なのか分からないという問題です。
これはハンドオフフェーズのよくある課題で、様々なチームで様々なデザイナーが、様々な解決策を模索しています。
よくある対処法
解決法としてよくあるのは、サムネイルにステータスを表記し、ひと目見ればそのファイルのステータスを判断できるようにする という運用です。
例えばYahoo社では、起きた課題の1つとして次のように記述されており、その回答としてサムネイルを工夫することによる解決策を採用されています。
2. デザイナーによってコンポーネント作成の有無やタイミングが異なり、正誤さまざまなUIが入り乱れFigma上のUIが信じられない ── Yahoo Japan Tech Blog
属人性を排除する
私たちも例に漏れず、このアプローチを採用しようとしていました。ファイル内にサムネイル用のページを作り、更新用のコンポーネントを揃え、更新しやすいよう準備を行いました。
しかし、いざこの運用を行ってみると、ある問題が浮上します。
面倒くさいのです。
そして更新を忘れやすいのです。
このため人によって更新したりしなかったりして、とても健全にステータスが分かる状態にはなりません。
開発やデザインチームにおける戦略の基礎として、属人性のある運用は避けるべきです。よってこの運用は却下し、それ以外のものを求めました。
そこで再度冷静にUIデザインのステータスを振り返ってみると、あることに気づきます。
UIデザインのステータスは2種類でいいのではないかということ、そして各ファイルをFIXまで育てなくてもいいのではないかということです。
2種類のUIデザイン
細かいステータスを1つ1つフォローするという発想を一旦忘れ1、ステータスをちょうどいい粒度まで抽象化すると、UIデザインは大きく2つに分けることが出来ます。
それは、探索的なデザイン（以下、Not Structured）と 構築済みのデザイン（以下、Structured）です。
Not Structured
UIデザインで最初に行われるのはNot Structuredな仕事です。リサーチや基礎設計, プロトタイピングなどの探索フェーズですね。
検証すべき仮説とそのソリューションとしてのアイデアが数多くアウトプットするフェーズで、Figmaなどデザインツール上で行うUIデザインのほとんどを占めます。
これらを “まだ完成していない”, “まだ構築途上である” という意味を込めて、私たちは「Not Structured」と呼称しています。
この中に入っているデザインは全てfixしていないことを社内的に宣言しています。
Structured
一方で、探索が終わったUIデザインもあります。
探索の結果fixしたコンポーネントのみを使っていたり、fixした画面, 遷移を確認できるアートボードやプロトタイプです。最終的な実装のために参照したり実装された姿をFigma上で再現するためのアウトプットということですね。
これらを “すでに検証済みである”, ”構築済みである” という意味を込めて、私たちは「Structured」と呼称しています。
この中に入っているデザインは全てfixしていることを社内的に宣言しています。
達成していること
ワークフロー
ステータスが各デザインファイルではなくProjectに紐付いたことは、直感されるよりも大きな変化をもたらします。ワークフローへの変化です。
従来の場合
従来のように各デザインファイルにステータスを設けるアプローチには、ある前提がありました。それは、作ったデザインファイルはfixまで育てるという前提です。
この前提では、探索し、要件を決め、探索時に作った草稿やプロトタイプを整理し、ファイルをキレイにするという工程が標準的なワークフローとなります。
しかし、このワークフローには、具体的な無駄が2点あります。
検証のために作ったファイルは様々な箇所が破綻しがちなため、それらを修正しファイルを完全にするのは作り直すよりも時間がかかることがある上に、古い仕様を更新し忘れる蓋然性がある
探索は仮説検証が主目的なため、「後でキレイにしやすいように」といったことを気にしながらデザインファイルを作ることは検証の本質を見失わせ得る
さらに言えば、一般的に探索の中に多分に含まれるプロトタイピングという工程は、そもそもその要件に「捨てやすいこと」があります。この点から考えても、探索したものは捨てて然るべきで、保守の対象ではないのです。
それでも従来のフローでは、Fixまでデザインファイルを育てきることが前提になるわけです。これはどうも非効率的に思えます。
声を上げ「肥大化しすぎたのでこのファイルを捨てて新しくファイルを作っていいですか？」と要望すれば例外的に脱却できるかもしれません。
しかし正規のワークフローでないためこの選択には消極的にならざるを得ないでしょう。一部のデザイナーにとって窮屈で、排他的です。
分けた場合のワークフロー
一方でStructuredとNot Sturedが分かれている状態は、ワークフローに柔軟さをもたらします。
デザインFixまでのワークフロー
まず、必ずしもNot Structuredで作ったファイルをfixまで育てる必要がありません。fixしたアウトプットを作る際はStructuredに新規ファイルを構築すればいいわけです。
正確には、下記のどちらのやり方を行ってもよいことになります。
Not Structuredで作ったファイルを、
捨ててStructuredに新規作成してもいい
キレイにしてStructuredに移動させてもいい
統制しつつも、懐の深いワークフローを実現していると言えるでしょう。
その上で、Structuredに新規に作り直す方が効率的だと私たちは考えており、公式にはそちらを推奨しています。
アジャイルなフローにもウォーターフォールなフローにも対応
また、開発の体制変更やプロジェクト特性, エピック特性への対応の冗長性として、下記のようにアジャイルでもウォーターフォールでも対応できるようになっています。
アジャイルに進める場合：Not Structuredの状態で実装も行う
ウォーターフォールに進める場合：Structuredのもののみ実装を行う
コンポーネント文化の醸成
さらにこの手法には、附則的な目的があります。コンポーネント活用への習熟度向上です。
シニアでないデザイナーやWEBデザインのみを行ってきたデザイナーにとって、コンポーネントを使ってUIを設計することは不慣れなことがあります。
よって、Projectを分けるという明示的なフローを敷くことによって次のようなことも同時に達成できればと考えていました。
探索の結果使い回すべきものをコンポーネント化していくナッジを作ることで、コンポーネントまわりの作業や文化, 思想に慣れる
一方でどんなプロジェクトや工程でもコンポーネントを必ず使わなければならない窮屈さは避ける
現時点ではコンポーネントの文化はきちんと浸透しルールの窮屈さも観測されていないため、成功であると評価しています。
まとめ
UIデザインのファイルについてFigmaのProjectをStructuredとNot Structuredに分けることで、属人性を排除しつつ次のことを達成しています。
デザインをどこで作ればいいのか, どこに置くべきか明確に
あるデザインがfixしたものかどうか明確に
ファイルのステータスを更新する手間を削除
デザインファイルを整理する時間・工数を排除
柔軟な形で、コンポーネントを使ってデザインする文化, 思想を浸透
アジャイル, ウォーターフォールどちらにも対応可能な冗長性