Adobe XD Advent Calendar 2019 6日目の記事です。新機能のステートについて検証した中で、気になったことをまとめました。あと、その過程で「リンクされたアセット」の事例に触れるため、ついでにその機能紹介もします。ステートコンポーネントごとに、スタイルやレイアウトのバリエーションをステート（状態、state）として定義し呼び出すことができます。※画像は公式サイトより引用Adobe XD Advent Calendar 2019 ２日目のえびさんの記事では、その登録や活用方法を詳しく紹介されています。メリットAdobe公式マニュアルではこう説明されています。ユーザーの操作によって外観が変化するコンポーネントは、忠実度の高いプロトタイプを作成するうえで非常に役立ちます。 コンポーネントを作成し、複数のバリエーション（ステート）を追加した後、それらを接続することで、実際のユーザービヘイビアーを模倣できます（コンポーネントを複数回コピーする必要はありません）。 またコンポーネントにステートを定義すると、アセットの管理とインタラクティブデザインシステムの作成も容易になります。主にプロトタイプの精度を高める用途のようで、従来アードボードを複数に分ける必要があったインタラクションも、ステートを活用すれば簡単に表現できます。「ホバーステート」機能がわかりやすいですね。プロトタイプ上でそのコンポーネントにカーソルを載せると、「ホバーステート」として定義した外観に自動で変化します。ユニークなところは、ホバー以外にも、定義を好きなだけ追加できることです。何をどう定義するのかはユーザー次第であり、CSSの擬似クラスに留まらず、サイズ違い、配色違いなど、様々なバリエーションを持たせることもできます。これはプロトタイプの精度を高めるのみならず、アセットの管理、デザイン制作の効率化にも役立つ可能性があります。デメリットアセット管理用途だと、現状使い勝手が悪いです😅。定義したステートの並び替えや階層化はできませんし、アセットパネルと違い検索できないので命名規則での管理も不可能です。後からの編集・変更も大変面倒なので、ガンガン自由に定義していくなら早めの段階でルール（どんな順番でどんなステートを登録するのか）を整える必要があります。また、定義は良くも悪くもユーザーの自由なので、あまりに大量・複雑にしてしまうと、データの共有・引継ぎが大変かもしれません。BootstrapXDへのステート定義検討本題です。ここでは、私が配布しているテンプレートドキュメントBootstrapXD（Mac用）を例に考えてみます。このデータは「アセットのリンク」活用を前提とし、多数のアセット（カラー・文字・コンポーネント）を登録しています。現状はカラーを中心としたアセット構成になっていますが、コンポーネントに何かステートを新しく定義することで、ソースドキュメントとしてより使いやすいものにならないかどうか検討しました。例えば、Bootstrapの「.btn」コンポーネントは、一体どんなステートを定義すると良いでしょうか。次のような候補が思いつきます。状態（default, hover, active, disabled）配色（.primary, .secondaryなど8種）サイズ（lg, default, sm）装飾（default, outline）これら全てを定義してしまうと、192ものステート数になります。現状のステート選択UIでは並び替えも検索もできませんから、これほどの数を扱うのは無謀です。最も数の多い「配色」のステート定義は諦めます。かといって、それぞれコンポーネントにすると、例えばボタンの角丸サイズを変更したい時に配色毎のコンポーネントを個別に編集する必要が生じ、非効率です。背景・枠それぞれ必要となりますが、配色はアセットのカラーで管理するべきです。装飾（outline）についても同様です。サイズについては、少なくともアセット管理用途ではコンポーネント・ステート定義どちらでも良いのですが、Bootstrapにおいてはプロトタイプでインタラクションを扱う際のステート選択肢に「サイズ」があっても無駄なので、コンポーネントにするのが無難でしょう。以上より、個人的には状態（default, hover, active, disabled）のみをステート定義するのが良いと考えました。ところが実際やってみるとうまくいきません。Bootstrap4では :hover, :active それぞれの色が、配色毎に異なっているため、配色毎のコンポーネントまたはステート定義も必要だったのです。つまり .btnの一元管理と、配色毎のステート管理とがトレードオフにあり、ドキュメント管理者がいずれかを選択するならば、利用者にその内容と意図をどこかで伝えなければなりません。唯一、disabledに関しては不透明度を .65 にするだけなので、ステート定義が活かせます。が、disabledだけ定義されているのも不自然ですし、こうした意図や注意事項を利用者に伝えるのも困難です。結果、現段階では、BootstrapXDでのステート定義を見送ることにしました…。まとめステート機能は便利ですが、アセットの管理という視点では、既にあるガイドライン（Bootstrapなどフレームワーク含む）との相性が悪いケース、どこで折り合いをつけるのか判断が難しいケースなどあるだろうなと思いました。ステート定義は自由ですから、客観的にわかりやすい定義を心がけ、独自な定義をするなら共同作業メンバーにもしっかり共有しなければなりません。そんなこんなで現状、「アセットの管理」目的では積極的に使うべきではないし、使うにしても事前のルール整備が欠かせないでしょう。「ホバーステート」は用途もルールもわかりやすいのでとっかかりとして良さそうです。そこから少しづつXDとステートの特性に慣れ、プロジェクト・プロダクトのドキュメントに工夫して取り入れてみてはいかがでしょうか。おまけ：リンクされたアセットXDでは、あるクラウドドキュメント(ソースドキュメント)上のアセットを、今開いている別のドキュメントに読み込ませることができます。この操作をアセットをリンクする（Link Assets）、読み込んだアセット群はリンクされたアセット（Linked Assets）と呼びます。※画像は公式サイトより引用メリットこの機能によって、複数ドキュメントを用いた制作と、そのドキュメント(デザインデータ)の運用が効率化されます。例えばこのようなドキュメント構成です。ソースドキュメント ... プロダクトの最新アセットを管理ドキュメントA ... プロダクトの新機能Aのデザイン・プロトタイプドキュメントB ... プロダクトの新機能Bのデザイン・プロトタイプドキュメントC ... プロダクトの実装済み機能Cのリデザイン・プロトタイプ実装側で何か既存のアセットに変更があった場合、ソースドキュメントだけを更新しドキュメントA〜Cのアセットも「更新」すれば、各進行中のドキュメントも簡単に最新の状態にアップデートできるのです。そこそこ規模の大きい開発では、全ての画面のデザインデータを最新に保ち続けるのは相当なコストです。ソースドキュメント（最低限のアセット）のみ最新として他のデザインデータは使い捨て、くらいの向き合い方が現実的ではないでしょうか。また、ソースドキュメントとそれ以外とで役割を分けると、間違えて最新アセットを上書きしちゃった！みたいなリスクも減ります。かつソースドキュメントの変更操作が限定されバージョン管理がしやすくなり、ミスがあっても気付きやすくリストアも容易です。あと、この構成であればドキュメントごとにプロトタイプ発行も可能です。従来、一つのドキュメントの元でプロトタイプを分けようとすると、いわゆる「目次ページ」を手動で作って管理し関係者にも説明する必要がありましたがその手間が省けます。デメリットリンクされたアセットは、「デザインデータ一度作って終わり」のようにドキュメントを分ける必要自体ないプロジェクトではほとんどメリットがないでしょう。一つのドキュメント内にアセットも制作中の画面もプロトタイプも全てまとめた方が作業効率が良いはずです。