Design Harnessという名前を付けているが、これ自体を新しい方法論や規格として広げたいわけではない。
言いたいことは、もはやデザインハーネスをMarkdownで定義する必要がほとんどない、ということだけである。
デザインを文章へ変換する必要がなくなった
以前は、AIにデザインを渡すために、配色、余白、タイポグラフィ、動き、避ける表現などをMarkdownへ書く必要があると考えていた。
現在のモデルは、既存のリポジトリやURLを渡すだけでも、実装と完成状態を観察し、かなりの精度でデザインを再現できる。文章へ変換しなくても、画面、コード、素材、動きの関係を参照できる。
デザインテーマをMarkdownにまとめる利点が残るとすれば、主にトークン効率の問題である。大きなリポジトリや複数の画面を毎回すべて読ませるより、必要な特徴だけを短く渡したほうが速くて安い場合はある。
ただし、それは情報を圧縮するための都合であって、Markdownのほうがデザインを正しく定義できるという話ではない。
FableへMVだけを渡した
cookie-demo は、FableにYouTube上のNewJeans「Cookie」のMVを見せ、その一部をWeb上で再現させたものである。
こちらから、どの要素を重要とみなすか、どのようなデザインテーマとして解釈するか、何をコードへ変換するかといった追加のコンテキストは渡していない。Fableが映像を観察し、構成、動き、質感を解釈して実装した。
それでも、スクロールに合わせて進む一つのWeb表現として成立した。
この結果が示しているのは、優れた design.md の書き方ではない。そもそも映像を文章へ置き換えてから渡さなくても、モデルが一次資料を見て解釈できるところまで来ている、ということである。
デザインは文脈から切り離せない
デザインは、背景や文脈、見る側の解釈によって良くも悪くもなる。
同じ色、同じ書体、同じ余白を使っても、何を伝える画面なのか、前後に何があるのか、どのタイミングで動くのかによって意味は変わる。要素を個別のルールとして切り出すほど、なぜその表現になっているのかが失われる。
文章で定義しようとすると、書き手が言語化できた特徴だけが残る。「黒い背景」「大きな文字」「Y2K」「粒子感」のような単語は渡せても、それらが画面の中で成立している理由までは保持しにくい。
デザインの解釈が文脈に依存するのに、その文脈を捨ててMarkdownへ変換し、あとからAIに再構成させるのは不自然である。
一次資料をそのまま渡す
動いているURLがあるならURLを渡す。実装があるならリポジトリを渡す。映像が参照なら映像を見せる。
モデルは一次資料から、画面の階層、要素同士の関係、動きの因果、実装上の制約をまとめて読める。再現先に合わせて何を残し、何を変えるかも、その場の文脈から判断できる。
もちろん、見たものをそのまま複製すればよいわけではない。権利、目的、媒体、利用者が違えば、再現すべき範囲も変わる。その判断も含めて、固定されたデザイン定義より、参照元と現在の用途を一緒に渡すほうが自然である。
Design Harnessは、デザインをMarkdownで完全に定義するためのプロダクトではない。
デザインを説明し直すより、モデルに見せたほうが早い。cookie-demo は、それを確かめた実験である。本当に言いたいのは、それだけである。