Tortoise Shell

デザイン、システム開発、ライフハックについてゆるく書きます

デザインデータと本番環境を合わせるという幻想

Twitterを見ていると、ちょくちょく「デザインデータと本番環境を合わせておくのが難しい」という言説を見る。

そうしたいデザイナーの気持ちはよく分かるし、わたし自身も同じように思っていたことがある。しかし、今はこう思っている。デザインデータと本番環境を合わせるというのは幻想だ。

なぜなら、FigmaやXDで作ったデザインデータは、システムそのものではないからだ。というと当たり前に聞こえるが、理解できていない人は多い。

本来システムは有機的なもので、目まぐるしく変化するデータや操作の文脈によって、ほぼ無限にも思える状態を持っている。

一方で、デザインデータとは、システムの特定の時間軸を切り取ったスケッチに過ぎない。

テキストひとつ取っても、プレーンなテキストも、APIやDBから取得したテキストも、同じものとして扱われる。

一見すると本番環境を寸分の違いなく再現したように思えていても、Webアプリであれば、ブラウザによってもコンポーネントの見た目は変わることがある。

だから、本番環境の見た目というのは、1つではないのだ。デザインデータと本番環境を合わせておくという発想には無理がある。

また、デザインデータを常に正とする運用も、やめた方が良い。常に厳格なルールの下に、チームの全員がデザインデータを管理できれば良いのだが、そうでなければ、消し忘れたレイヤーや、試しに作ったレイヤーがたまたま残ってしまい、それが実装されるリスクを避けることはできない。デザインデータは、仕様書にもなりえないのだ。

では、どうすればいいのか。デザインデータのあり方について、見直せば良い。デザインデータとは青写真に過ぎないという限界を理解し、正しい仕様、正しい見た目は、本番環境に上がっているものが全てとすべきだ。

繰り返しになるが、デザインデータは、システムの特定の時間軸を切り取ったスケッチに過ぎない。しかしながら、開発をする上では、そのスケッチが開発の共通認識をもたらしてくれる。たかがスケッチでも、立派な青写真。理想像を描いたものとして機能するのだ。

一方で、そもそもなぜ、デザインデータと本番環境を合わせたいのか。そこにも留意しておきたい。ひとつの理由としては、本番環境と対になるデザインデータがあらかじめ用意されていることで、その画面を改修する際に、スムーズに検討に入れるのは大きなメリットだ。

そうでなければ、わざわざ既存の画面をデザインツールで起こしてから、やっと改修の検討に入らなければならず、大きな時間のロスにつながる。だから、本番環境とデザインデータを合わせておきたいのだ。

しかし、先にも述べた通り、それをすることは難しい。ひとつの提案としては、画面をそっくりそのままデザインデータで管理するのではなく、あくまでもコンポーネントを管理する方針に切り替えてはどうだろうか。

コンポーネントさえ揃っていれば、画面の改修が入ったときにも、速やかに組み合わせて既存の画面を構築することができる。これが、画面単位で正確に管理しようとすると、実装マターの改修で見た目が変わったしまったときや、スピード重視でデザインデータのメンテナンスの時間が取れなくなった途端に破たんするのだ。

管理の単位をコンポーネントにしてしまえば、コンポーネントそのものはある程度の堅牢製を持っているため、画面と比べれば破たんしづらい。

だから、デザインデータとして作った画面は、あくまでも一時的な青写真用として捉えるべきだ。仕様書として常に正しいものではなく、チームの共通認識が取れて一度実装されたのなら、ただちに捨ててしまっても構わない。

ただし、コンポーネントだけはしっかりと管理しておく。これが現在のところの、わたしの最適解だ。また考えが更新されたら、そのときはまたブログに書くこととにしよう。