design-system-ui

デザインシステム UI

製品で既に使用されているコンポーネント、ビジュアルスタイル、インタラクションパターンに合った UI を構築します。

複数ステップにわたる作業では、まず調査する製品のコンテキストを明示した、ユーザーに見える短い更新を行います。

目標

製品の他の部分との一貫性を保ちながら、依頼された画面やコンポーネントを読みやすく、使いやすくします。階層、グループ化、余白、インタラクションのフィードバックを活用して、主なタスクを支援します。

コンテキストの予算

コーディングの前に、UI を製品に適合させるために必要なコンテキストだけを確認します。

• 目的が似ている近隣のページ
• 共通コンポーネントとページシェル
• トークン、テーマファイル、Tailwind/CSS の設定、タイポグラフィ
• 余白、角丸、境界線、シャドウ、サーフェス、アイコン、モーション
• 既存の読み込み中、空、エラー、無効、フォーカス、レスポンシブのパターン

製品のコンテキスト、再利用可能なプリミティブ、スタイリングシステム、検証方法を十分に把握できたら、調査を終了します。不足しているパターンが正確性、ビジュアルの適合性、アクセシビリティに実質的な影響を及ぼす場合に限り、調査を続けます。

製品の方向性

一般的な本番環境向けの変更では、製品で確立された方向性を再利用し、依頼された画面に必要な選択だけを行います。小さな調整のために、新しいコンセプト、パレット、特徴的な要素を取り入れる必要はありません。

新しい画面や大幅な再設計では、利用可能なコンテキストをもとに、簡潔な方向性を定めます。

• 目的：インターフェースが担う役割
• ユーザー：誰が使い、何を判断または達成するのか
• 既存のパターン：再利用するレイアウト、タイポグラフィ、色、インタラクション
• 役立つ改善：ユーザーのタスク完了を支援する具体的な変更
• 特徴的な要素（有用な場合）：依頼内容に含まれる、または依頼内容に裏付けられた要素。画面に違いを出すためだけの装飾は追加しません

タイポグラフィ、レイアウト、色、サーフェス、モーション、状態に関する例がさらに必要な場合にのみ、references/design-moves.md を参照します。

品質基準

階層、配置、グループ化、コントラスト、余白を活用し、製品のコンテキストに沿って依頼された画面を明確にします。ページ単位の作業では、細部を磨き込む前に全体の構成を整えます。コンポーネントの変更では、ページ全体を再設計せず、周囲のページとの適合性を確認します。適切なトークンを適用するだけでは、ビジュアル品質は確立されません。以下のビジュアルチェックを参考に、改善を重ねます。

制約

• プロジェクトの規約に従った、実際に動作するフロントエンドコードを作成します。
• ユーザーが提供したコピー、ビジネス上の主張、インタラクションの意味、スクリーンショット、既存の情報設計は、ユーザーが見直しを求めない限り、製品上の制約として扱います。必要なコンテンツを削除したり、主張を弱めたり、製品の意味を変えたりして、見せ方の問題を解決しないでください。
• 変更は依頼された画面とコンポーネントの範囲内に留めます。共通プリミティブを変更するのは、それが問題の原因だと確認できた場合、または依頼された成果に本当に必要な場合に限り、影響を受ける利用箇所を検証します。
• 既存のプリミティブ、トークン、アイコンセット、アニメーションユーティリティ、アクセシブルな HTML、キーボードで操作しやすいインタラクション、レスポンシブ対応、明確なコンポーネント構造、スコープを限定したスタイルを優先します。
• 新しいビジュアルプリミティブは、デザインを改善し、製品システムに自然に組み込める場合にのみ追加します。
• 静的または同期的なコンテンツに、非同期の動作、読み込み状態、レイアウトシフトを導入しないでください。
• 根拠のないカスタムスタイル、製品上の目的がない装飾、既存のプリミティブで対応できる場合の余分なコンポーネント、デフォルトの中央配置カードレイアウト、あらゆるコンテンツグループを枠付きカードにすること、実際には操作できないのに操作できそうに見せること、控えめで均等に散らした配色、無関係な製品に安易に貼り付けた紫色のグラデーションによる装飾は避けます。

明確なデザインシステムがない場合

色の役割、タイポグラフィの階層、間隔、コントロールの表現、レスポンシブ動作やインタラクションの挙動など、依頼された画面に必要な、まだ定まっていない見た目の選択肢だけを定義します。小さなタスクのために、新しいデザインシステムを一から作る必要はありません。

無関係な効果をいくつも加えるのではなく、いくつかの明確な選択によって一貫性を持たせます。

見た目の検証

アクセス可能な場合は、実際のアプリケーションのルートとインタラクションを通じて実装を確認します。仕上げの際や最終確認では、次の項目を確認します。関連する実装、コンテンツ、状態に変更がない場合は、以前の確認結果を再利用してください。

• レイアウトやインタラクションのモデルに影響する可能性がある、代表的なデータ量、現実的なローカライズ済みの文言、長い値、規模の条件を使って確認します。
• 作業によって追加または影響を受ける、関連するビューポートサイズと遷移可能な状態で、キーボード操作やフォーカスの挙動を含むレスポンシブ動作を確認します。網羅性だけを目的に、状態を作り出してはいけません。
• 全体の構成と細部の両方を確認します。視線の流れ、グループ化、情報密度、余白、配置、入れ子になったパディング、テキストの折り返し、ベースライン、アイコンとラベルの組み合わせ、コントロールの寸法を確認します。隣接する製品画面と比較し、タイポグラフィ、サーフェス、インタラクションの表現に一貫性があるか確認します。
• 追加したサーフェス、アイコン、バッジ、フィードバックが、役立つ関連性や状態を伝えているか確認します。意図しない隙間、レイアウトのずれ、誤解を招くアフォーダンス、タスクの妨げになる装飾を解消します。

該当するコード検証も実行します。ただし、ビルド、型チェック、コンポーネント単位のテストを、見た目の品質の証明として扱ってはいけません。実際のルートを確認できない場合は、UI 全体を検証済みだと主張するのではなく、確認できなかった点と、代わりに行った最善の検証を報告します。

出力

実装する際は、ユーザーの技術スタックですぐに実行できる、対象を絞ったコードを提供します。最終回答では、完成した成果を最初に示し、その後に重要なデザイン上の選択、主な変更ファイル、実施した検証、結果に影響する前提をまとめます。通常の変更を説明するために、新しい概念を作り出してはいけません。

停止条件

依頼されたインターフェースが実装され、動作、ユーザビリティ、アクセシビリティ、レスポンシブ対応、製品との適合性に影響する重大な不一致が解消され、該当する検証が完了するか、その制限が明記された時点で停止します。さらに改良する場合は、具体的な未解決の不一致が必要です。主観的な完璧さを追い求めて、配置を変更し続けたり装飾を追加したりしてはいけません。