スキル自身の言葉で
ダッシュボード、管理パネル、SaaSアプリ、ツール、設定画面、データインターフェースなど、プロダクトのUIを構築するための、クラフト（技巧）を重視した規律です。トップクラスのデザインチームが下すであろう判断を反映します。コードを書く前に、ユーザーは誰か、彼らがやってきた目的となる一つの動作は何か、そしてインターフェースが意味のある言葉でどう感じられるべきかという、実際に機能するブリーフを作ることを求めます。
そこから、ドメインの探索（ドメイン、カラーワールド、シグネチャー、却下したデフォルト）、比率に基づくタイプスケール、太さと色で階層を表現する手法、単一のコミットされた奥行き戦略、ハードコードされた値ではなくセマンティックなトークン、そして仕上げとモーションの要点──等幅数字、同心円の角丸、300ms未満の持続時間、高頻度アクションにアニメーションを付けないこと──を規定します。ランディングページ、マーケティングサイト、キャンペーン、ブランドのみの作業には明示的に対応しません。
生成されるもの
- ドメイン、カラーワールド、シグネチャー、却下、方向性を明示したSuggest + Askの提案。
- レンダリングツールが存在する場合、パレットのスウォッチ、実際の書体によるタイプスケール、積み重ねたエレベーションカード、実コンポーネントとしてのシグネチャーなど、インラインでレンダリングされた見本。実装自体は依然としてコードベースに反映されます。
- ユーザーが承認した後にのみ書き込まれる、方向性、奥行き戦略、階層に関する決定、繰り返し使われるコンポーネントパターンを保持する保存済みの .interface-design/system.md。
仕組み
- 01作業用ブリーフを書く
コードを書く前に、対象となる人物は誰か、どの動作を達成すべきか、インターフェースがどのような印象を与えるべきかに答えます。方向性の確認が必要な場合を除き、簡潔にまとめます。
- 02プロダクトドメインを探索する
方向性を提案する前に、4つの成果物を作成します。少なくとも5つのドメインコンセプト、プロダクトの物理世界から得た5つ以上の色、1つのシグネチャー要素、そして却下すべき明白なデフォルト3つです。
- 03方向性を提案し確認する
ドメイン、カラーワールド、シグネチャー、却下、方向性を明示したSuggest + Askブロックを先に示し、構築に入る前にその方向性が正しいかどうかを確認します。
- 04可能な限り見本をレンダリングする
セッションにインラインの視覚レンダリングツールがある場合は、パレット、タイプスケール、エレベーションのステップ、シグネチャーを説明する代わりに実際のコンポーネントとして表示します。それ以外の場合はコードにフォールバックします。
- 05既存のものに対して構築し、その後検証する
アプリ、トークン、コンポーネントパターン、system.md を確認し、実装にパッチを当て、可能であればビルド、型チェック、テストを実行し、その後デスクトップとモバイルの幅で視覚的に検証します。
- 06パターンの保存を提案する
タスクの完了後、方向性、奥行き戦略、階層に関する決定、繰り返し使われるコンポーネントパターンを記録することを提案し、後のセッションでも一貫性を保てるようにします。