この記事の概要
一口にモックアップ（デザインデータ）といっても、作り方によって堅牢さには幅が生まれます。
堅牢であればあるほど良いわけではありませんが、ある程度は堅牢な方が使いまわしやすく、制作の指針にもなります。
この記事では、私がこれまで見てきたデータをもとに、堅牢さをレベル分けしてみました。
自分達の組織が○レベルとか、今後○レベルを目指したいとか、そういった指標に使っていいただけたら嬉しいです。
あくまで私が見たことのあるものを基準にしているだけなので「レベル1と2の間にこれくらいの堅牢度があると思う」などの意見は歓迎です。
分かりやすさの都合上、この記事では「堅牢であること」を高レベルなものとして記載しています。
しかし実際は「堅牢であればあるほど良い」というものではなく、あくまで「自分達の組織とデザインデータがフィットしているかどうか」が重要です。
その前提で読んでいただければ幸いです。
レベル0：コンポーネントがない
同一の情報1を表す要素であるにも関わらず、コンポーネント化せずコピー＆ペーストで対応している状態です。
このレベルでは、何か1つの情報に変更があっただけでもデザインデータ全域を見て変更・修正する必要があります。
また、見た目に関するちょっとした不統一（色の違い、枠線の有無、影の濃さなど）は、大抵の場合気づかれません。
結果的に意味を持たないバリエーション違いが乱立し、後になって「いつどのデータを使うのが正なのか分からず制作やレビューに時間がかかる」などの問題を引き起こしがちです。
レベル1：コンポーネントがあるが、統一されていない
以下のような場合があります。
- コンポーネントにはなっているものの
- デザイントークンが使われず、直接色や数値が指定されている
- バリエーション違いのものなのに、グルーピングや命名や一貫しておらず乱立している
レベル0と比べればコンポーネント化されているだけ堅牢ではあります。
しかし、同じもののはずなのに別の値、別のコンポーネントとして定義されている場合、段々とバラバラになってしてしまいがちです。
使用頻度の低いコンポーネントがあると「当時はこの内容で正しかったけど、今では間違っている」「このバージョンにだけこの情報が残ってしまっている」などの状態になりがちで、それを察知するのも大変です。
また、もともとがバラバラだと、つい「少し使い勝手が悪いから、どうせ乱立しているし、私の考えた最強の別バージョンコンポーネントを新たに作ろう」という動きが生まれがちです。
レベル2：コンポーネントがあり、見た目の観点としては統一されている
同一の情報は同一のコンポーネントであり、見た目の観点としては問題ない（ただしコードの観点では不十分な）状態をレベル2としています。
少し古い話ですが、よくある例で言えば、同じような内容のDOMを複数描画し、条件にあわせてdisplay: noneを付け替えてバリエーション違いを表現するような実装です。
多くの場合、もともとのデザインデータがちゃんと考えられていれば、最低限のDOMだけで済みます。
これに限らず、見た目上（あるいは人間の知覚上）は問題なくても、コードの観点ではやや問題あり、というデータはよく見ます。
最終的にはコードで表現するのがWebやアプリなので、見た目の観点だけでの制作だと堅牢さは半減します。
レベル3：コンポーネントがあり、コードとしての観点とも合致している
デザインデータ上で表現されるレイヤーの有無と、コード上で求められるバリエーションなどの有無が一致しているような状態を指します。
どこまでいっても完全な一致は難しいとは思いますが、概念的には一致しているとか、例外はあれどメモ書きを読めば理解できるとか、そういう状態まで持っていけると良いでしょう。
どこはカスタムできてどこは固定にするのか、どんな型のデータを受け取れる（弾く）かとか、そういう部分まで考えられているといないとでは大きな違いがあります。
レベル4：レベル3までを踏まえたコンポーネントがあり、かつデザインデータとしても例外を生みづらい
例えばFigmaでいえば、テキスト内容や要素の表示非表示はpropertyで制御されているとか、simplify all instancesが適用されいているとか、そういった観点です。
複数人でデザインデータを制作すれば、どうしても「ここを変更したい」とついつい（変更すべきでない場所ですら）変更してしまう人もいます。
組織でインターフェースデザインをする場合、そういう「うっかり変更」を発生しづらくする必要がありますが、人間に任せるのではなく「うっかり」では変更できないデータを作るのが重要です。
自由さと堅牢さは相反する関係で「デザインシステムの導入や浸透を頑張りたい」という意見があるのであればまず間違いなく「不必要な箇所をうっかりでは変更できない」データを作るのは大事です。
レベル5：実装をベースにデザインデータが存在しており、そこから外れたものはレビューで弾かれる
既存のコンポーネントは完全にコードと合致しており、新規に作る際コードと合致しないような部分があればレビューが通らずリリースできないような状態です。
ここまでくるとデザインデータだけの問題だけではなく、レビュー体制など組織的な話の方が多いかもしれません。
よくある「デザイナーが見た目を作成→エンジニアがコードで再現」というフローでは「実装上の都合が考慮されていないデザインデータ」は大なり小なり生まれます。
そしてそれが生まれる度に議論をしたり落とし所を探っていては時間がかかります。
そのため、はじめから実装上の制約を前提とし、それにそぐわないデザインデータが生まれた時点でリジェクトする方がスムーズではあります。
実装をした後に、振り返りや次の企画を円滑にするためのものとして、デザインデータを視覚的に整理し直す、という考えは堅牢にはなります。
-
例えば通販サイトにおける
商品名と画像と価格がセットになったものなど。場所によって微妙に情報が違うことはあれど、メンタルモデル的には商品サムネイルなどと同一のものとして認識されるであろうものを指します。 ↩