デザインシステムをSKILLにして、実際の現場で使ってみました。使ってみて分かったのは、デザインを作る工程とフロントエンドを実装する工程とでは、SKILLに求める役割が違うということです。この記事では、その違いと、最終的にどう組み合わせる形に落ち着いたかを書きます。
デザインとフロントエンドでは工程が違う
同じデザインシステムを元にSKILLを定義しても、デザインとフロントエンドの工程の違いは消えません。デザインの工程では、キャンバスの上でフレームを起こし、画面の構成を形にしていきます。フロントエンドの工程では、その構成をコードに落とし込みます。
そのため、共通のSKILLを作ったとしても、使い方は工程ごとに分けたほうがよいと感じました。
フロントエンドのSKILLには実寸値が要る
違いがいちばんはっきり出たのは、フロントエンドの工程です。フロントエンドでデザインシステムのSKILLを使うときは、値が明確であることがポイントになります。
たとえば「通知バッジは右上に配置する」という書き方は、デザインシステムの説明としては自然です。しかし、この文章だけでは、右上のどこに、どれだけの余白を取って置くのかといった細かな配置が、AIの判断に委ねられます。その結果、コードへ落とし込まれたときに「どこか違う」という違和感が出てしまいます。
フロントエンドの実装で使うSKILLは、文章で意図を伝えるより、具体的な値まで落とし込んでおくほうが、コードに適用したときのズレが生じにくくなります。
デザインシステムのSKILLは抽象度にとどめる
では、デザインシステムのSKILLそのものに実寸値まで書き込めばよいのかというと、そうではありません。実寸値はフロントエンドの工程で必要になる情報で、デザインの工程ではキャンバスにフレームを起こす手順やルールのほうが必要になるからです。
デザインシステムのSKILLを1つ作っても、それだけではすべての工程をカバーできません。デザインシステムのSKILLは、どの工程からも共通して使える抽象度にとどめておき、工程ごとのSKILLやルールとセットで使う仕組みにしました。
デザインの工程で組み合わせるもの
デザインの工程では、キャンバスにフレームを起こす工程や、ツールの使い方を整備します。たとえば、MCPを使ってキャンバスに起こすときのルールを、デザインシステムのSKILLと組み合わせて使えるようにします。
フロントエンドの工程で組み合わせるもの
フロントエンドの工程では、Reactのベストプラクティスや、コンポーネントにロジックを組み込まないといった基本ルールを、SKILLとして組み合わせます。実寸値などCSS固有の値による肉付けは、デザインシステムのSKILLとは別に用意します。
デザインリンターでブレを拾う
フロントエンドでは、SKILLに加えてデザインリンターも取り入れました。デザインの意図を静的にチェックする仕組みです。
SKILLで意図を伝えても、AIの実装にはブレが出ます。デザインリンターを入れておくと、そのブレをリンターが拾ってくれます。自分が確認する前の段階で、AIがリンターの指摘から意図を汲み取って修正してくれるようになりました。修正の方針に迷うときは、AIのほうから実装の相談が来ることもありました。
工程ごとの組み合わせ
ここまでの構成を図にすると、次のようになります。
デザインシステムのSKILLは共通の意図を伝え、工程ごとのSKILLは具体的なやり方を補い、リンターはブレを拾います。どれか1つで完結させようとせず、それぞれの役割を分けて組み合わせることで、SKILLが工程の中で効くようになりました。
デザインシステムのSKILLだけでは足りず、工程ごとのSKILLが別途必要になる。これが、実際に現場で使ってみていちばん実感したことでした。