design-engineering について
design-engineeringは、デザインとエンジニアリングの協業に関する実践ガイドです。早い段階で実装上の制約を取り入れ、デザイン構造をコードに対応させる考え方を示し、コンポーネント、トークン、アクセシビリティ、本番品質の確認項目を扱います。
主な機能
- 01早期にエンジニアリング制約を反映
- 02デザイン構造をコードに対応
- 03個別スタイルではなくトークンを使用
- 04アクセシビリティとエラー状態を考慮
- 05プロトタイプと本番要件を照合
活用シーン
- 01デザインと開発で画面案を共同検討
- 02デザインのコンポーネントモデルをAPIに対応
- 03デザインシステムのトークン利用を確認
- 04プロトタイプの本番要件への対応を点検
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/design-engineeringを入力して読み込まれたか確認します。
詳細
デザインエンジニアリング
デザインエンジニアリングとは、本番環境のインターフェースを共同で担う責任であり、完成したモックアップからチケット化された実装へとバトンを渡すリレーではありません。
基本方針
- 引き継ぎではなく、早い段階から実装上の制約を共有しましょう。
- デザインの構造とコードの構造を意図的に対応させましょう。
- 学びのためにプロトタイプを作り、本番品質の厳密さをもってリリースしましょう。
- 美的感覚を、素材に関する知識（CSS、フレームワークのレンダリング、トークン、アクセシビリティ）と結び付けましょう。
- 意図から実装への翻訳で失われるものを減らしましょう。
対応関係
| デザインの概念 | コードの概念 |
|---|---|
| フレーム／オートレイアウト | スタック、フレックス、グリッド |
| コンポーネント＋バリアント | コンポーネント API＋props／state |
| ローカルスタイル | トークン＋セマンティッククラス |
| プロトタイプのインタラクション | 実際の状態、ルート、モーション |
| レッドライン | コンポーネントに組み込まれたデフォルト |
推奨／非推奨
| 推奨 | 非推奨 |
|---|---|
| 品質に対する共同責任 | 「デザインは完了」／「開発で仕上げる」 |
| 検討段階で制約を考慮する | ビジュアルが確定してから実現可能性に驚く |
| プロトタイピング中に本番環境の要件を考慮する | 雰囲気重視のデモをリリース可能なものとして扱う |
| トークン化されたシステム | テーマに対応できない単発の値 |
レビューチェックリスト
- エンジニアリング上の制約は、早い段階でデザインの方向性に反映されましたか？
- コンポーネント API は、デザイナーが使うバリアントモデルに合っていますか？
- 個別の生の値ではなく、トークンを使っていますか？
- アクセシビリティと空状態／エラー状態は、先送りせずに設計されていますか？
- プロトタイプは、本番対応に必要な作業を正直に示していますか？
- デザインとエンジニアリングは、振る舞いに関する共通の信頼できる情報源を参照できますか？
参考エッセイ
- 引き継ぎではなく、早い段階から連携するためのデザイン
- デザインエンジニアリング宣言
- デザインコードで考える
- デザインエンジニア
コメント
Markdown 対応