all-in-one-ui-ux-design

オールインワン UI/UX デザイン

このスキルを、エンドツーエンドの UI/UX システムとしてデフォルトで使用します。 このファイルではワークフローに焦点を絞り、必要な場合にのみ参照ファイルを読み込みます。

目標：記憶に残る、アクセシブルで保守しやすく、本番環境に対応したインターフェースを提供します。

まずはこちら

コードを生成またはレビューする前に、必要最低限のコンテキストを集めます。

1. プロダクトのコンテキスト：プロダクトの種類、対象ユーザー、トーン、ブランド上の制約。
2. 対象範囲：ページ／アプリ全体、コンポーネント一式、リデザイン、UI 監査。
3. プラットフォームとスタック：Web／モバイル、およびフレームワーク／ライブラリの選択。
4. 必要な状態：読み込み中、空、エラー、成功、無効、およびエッジケース。
5. 成果物：プロトタイプ、本番コード、監査結果、デザインシステム仕様。

詳細が不足している場合は、焦点を絞った質問を1～3件します。ユーザーが速さを優先する場合は、前提を明示して進めます。

モードの選択

意図に合ったモードを選びます。

1. build：新しい UI をデザインして実装します。
2. redesign：機能は維持し、ビジュアルとインタラクションのレイヤーを置き換えます。
3. audit：既存の UI をレビューし、実行可能な改善点を提示します。
4. design-system：コーディングの前に、トークン、タイプスケール、基本コンポーネントを定義します。
5. flow：複数画面にわたるユーザーフロー（オンボーディング、チェックアウト、設定、ダッシュボード）をデザインします。

複数のモードにまたがる依頼では、design-system -> build -> audit の順に進めます。

デフォルトの推奨事項

ユーザーから別の指定がない限り、以下をデフォルトとして使用します。

1. スタックの選択： コードベースにすでに存在するスタックを使用します。 スタックが存在せず、タスクが Web の場合は、デフォルトで html-tailwind を使用します。 スタックが存在せず、タスクがモバイルの場合は、プラットフォームネイティブのパターンを使用します。
2. 監査の深さ： デフォルトでチェックリスト全体を使って監査します。 網羅性より速さを明示的に優先するようユーザーから求められた場合のみ、簡易監査を行います。
3. 創造性： 主な成果物として、画一的なテンプレートに頼らないでください。 レイアウトを流用するのではなく、再利用可能な原則を活用し、プロジェクトごとに独自の方向性を採用します。 assets/primitives/ は組み合わせ可能な足場として使用し、最終的なビジュアルアイデンティティとしては使用しないでください。

参照ファイルの読み込みガイド

タスクに必要なものだけを読み込みます。

ファイル	読み込むタイミング
references/creative-direction.md	スタイルの方向性、タイポグラフィの個性、パレットの印象、レイアウト構成、ビジュアルの差別化を選ぶとき
references/system-build-playbook.md	実装計画の作成、スタックの選択、UX の優先ルールの適用、最終納品チェックリストの使用を行うとき
references/web-interface-guidelines.md	アクセシビリティ、インタラクション、パフォーマンス、コピーの品質、アンチパターンの検出について UI コードを監査するとき

アセットキット

オリジナリティを損なわずに実装を速めたい場合は、以下の任意のアセットを使用します。

アセット	用途
assets/primitives/tokens.css	タイポグラフィ、色、スペーシング、角丸、エレベーション、セマンティックトークンの足場
assets/primitives/motion.css	モーショントークン、表示時のエフェクト、視差効果を抑制する設定に対応した動作
assets/primitives/layout.css	レスポンシブなレイアウトの基本要素（コンテナー、スタック、クラスター、グリッド、セクション、サーフェス）
assets/primitives/component-states.css	ボタン、入力欄、カード向けのアクセシブルなデフォルト状態
assets/blueprints/semantic-shell.html	プロトタイプをすばやく作成するための、最小限のセマンティックなページ骨格

アセットのルール：

1. 必要なものだけをコピーします。
2. 最終納品の前にトークンをプロジェクトに合わせて変更します。
3. プロジェクトごとにレイアウトを再構成し、ブループリントのデフォルト設定を変更せずにリリースしないでください。

基本原則

1. 明確な美的方向性を定めます。ありきたりなテンプレートに見える UI は作成しません。
2. 画面全体でスタイルとインタラクションに一貫性を持たせます。
3. 装飾的な仕上げよりも、アクセシビリティと使いやすさを優先します。
4. モーションは意図的に使います。状態の変化を伝え、余計な動きは加えません。
5. 初回からレスポンシブな動作と実際のコンテンツを想定して構築します。
6. 場当たり的な値ではなく、読みやすく保守しやすいコードとトークン化されたスタイルを優先します。

妥協できない品質基準

すべてのモードで、次のルールを適用します。

1. タイポグラフィには意図が感じられる必要があります。デフォルトのフォントスタックや、ありきたりで無難な選択の繰り返しは避けます。
2. 色に一貫性を持たせます。プライマリー、セカンダリー、アクセント、セマンティックな状態には、デザイントークンまたは CSS 変数を使用します。
3. インタラクティブ要素には、視認できるホバー状態とキーボードフォーカス状態を設けます。
4. タッチインターフェースでは、タッチターゲットを少なくとも 44x44px にします。
5. 視差効果を減らす設定を尊重し、負荷の高いアニメーションプロパティは避けます。
6. すべての状態を網羅します。通常、ホバー、フォーカス、アクティブ、無効、読み込み中、空、エラー、成功。
7. メディアサイズを明示し、堅牢なテキストのオーバーフロー処理を行って、レイアウトシフトやクリッピングを防ぎます。
8. references/web-interface-guidelines.md に記載されているアンチパターンを避けます。

汎用的なデザインを避けるための確認事項（必須）

最終成果物を提出する前に、次のいずれかが残っている場合は、出力を不合格とします。

1. 明確な意図のない、デフォルトのようなタイポグラフィの選択。
2. ブランドとの適合性が低い、汎用的でグラデーションに頼った、またはテンプレート優先のビジュアル方針。
3. 少し変更するだけでどの製品にも当てはまるような、定型的なページ構成。
4. 階層、フィードバック、状態を伝えない装飾的なモーション。
5. タイポグラフィ、レイアウト、インタラクション、ビジュアルの質感に、記憶に残る差別化要素がないこと。

エンドツーエンドのワークフロー

1. 理解し、方向性を定める

1. 依頼内容を問題の説明と成功基準に落とし込みます。
2. ブランド、コンプライアンス、パフォーマンス、期限などの制約を抽出します。
3. コーディングを始める前に、成果物と受け入れ基準を定義します。

2. デザインの方向性を選ぶ

1. 主となるビジュアルの方向性を 1 つと、それを補完する影響を 1 つ選びます。
2. ムードを表す言葉、コントラストの強さ、質感の方針、モーションの特徴を定義します。
3. コンポーネントの実装前に、簡潔なデザインブリーフを作成して方向性を確定します。

方向性の選択肢と汎用的なデザインを避けるためのガードレールについては、references/creative-direction.md を参照してください。

3. デザインシステムを定義する

簡潔な仕様を作成します。

1. 色のトークン：背景、サーフェス、テキスト、ミュート、ボーダー、プライマリー、アクセント、危険、成功。
2. タイポグラフィシステム：ディスプレイ／見出し／本文／キャプションのスタイルと行の高さのルール。
3. 余白と角丸のスケール。
4. 高さ／シャドウのシステムとボーダーの処理。
5. モーションのトークン：継続時間、イージング、視差効果を減らす設定時の代替手段。
6. コンポーネントのプリミティブ：ボタン、入力、セレクト、カード、モーダル、ツールチップ、トースト、テーブル。

ルールの優先順位とスタックごとのガイダンスについては、references/system-build-playbook.md を参照してください。

4. レイアウトとインタラクションのアーキテクチャを構築する

1. まずレスポンシブな構造を設計します（特に指定がなければ、モバイルファーストのブレークポイントを使用します）。
2. 階層、グループ化、視線の流れを定義します。
3. ナビゲーション、フィルタリング、バリデーション、フィードバックなどのインタラクションパターンを割り当てます。
4. 後半の段階でのリグレッションを防ぐため、早い段階でエッジケースの状態を計画します。

5. スタックに合わせて実装する

1. ユーザーが選択したスタックに従います。指定がない場合は、上記の Default Recommendations セクションに記載されたデフォルトを適用します。
2. デザインシステムと一貫したスタイルで実装します。
3. セマンティックな HTML とアクセシブルなコンポーネント API を使用します。
4. 個別のクラスよりも、組み合わせ可能なプリミティブと再利用可能なトークンを優先します。
5. Asset Kit を使用する場合は、提出前にトークン、構成、インタラクションの詳細をカスタマイズします。

6. 納品前の監査

references/web-interface-guidelines.md に照らしてセルフレビューを実施します。

1. アクセシビリティとセマンティクスの正確性。
2. フォーカス、キーボード操作、タッチ操作の品質。
3. レスポンシブ動作とオーバーフローへの対応。
4. モーション、パフォーマンス、ハイドレーションの安全性。
5. 文言の明瞭さと操作ラベル。

監査モードの出力規約

リクエストがレビュー、監査、チェックの場合：

1. 重大度の高い順に指摘事項を最初に提示します。
2. file:line の位置情報を添えてファイルごとにまとめます。
3. 各指摘事項は簡潔で、対応可能な内容にします。
4. 問題がないファイルに限り、合格状況を記載します。
5. 残存リスクやテストカバレッジの不足を含めます。

デフォルトの動作：

1. ガイドライン全体に対して厳密なフル監査を実施します。
2. ユーザーが簡易レビューを求めた場合に限り、クイック監査に切り替えます。

形式：

## path/to/file.tsx

path/to/file.tsx:42 - issue summary
path/to/file.tsx:77 - issue summary

## path/to/another.tsx

pass

ビルドモードの出力規約

リクエストが実装の場合：

1. 最終的なコードまたはパッチを提示します。
2. デザインの方向性を2～4項目で要約します。
3. アクセシビリティとレスポンシブ対応に関する重要な判断を確認します。
4. 既知のトレードオフと今後の改善点を列挙します。

迅速なプロンプトのパターン

要件が曖昧な場合は、内部で次の構成を使用します：

1. 「このインターフェースの対象ユーザーと、中心となる操作は何ですか？」
2. 「UIでどのような感情的なトーンを伝えたいですか？」
3. 「技術スタックやプラットフォームにどのような制約がありますか？」
4. 「必須の品質要件は何ですか（a11y、パフォーマンス、ブランド、ローカライズなど）？」

ユーザーから回答がない場合は、前提を置いて進め、その前提を明確に伝えます。

完了チェックリスト

最終納品の前に、次の項目を確認します：

1. ビジュアルの方向性に独自性があり、一貫している。
2. 重要なすべての操作に、ホバー、フォーカス、アクティブ、無効の状態がある。
3. ラベル、セマンティクス、フォーカス、コントラストに関するアクセシビリティチェックに合格している。
4. モバイルとデスクトップのレイアウトを検証している。
5. パフォーマンスに影響する動作（画像、アニメーション、リスト）に対処している。
6. 文言とエラー状態が具体的で、ユーザーが次の行動を取りやすい。