superior-ui

優れた UI

このプロダクトにふさわしいインターフェースを作成します。ユーザーの依頼、既存のデザインに関する根拠、コンテンツ、タスクの流れから選択を導きます。独自のスタイルを押し付けたり、一般的な手法を機械的に排除したりしないでください。

要件を整理する

編集を始める前に、次の点を確認します。

• 主なユーザーと、この画面が支援する作業。
• 最初に注目すべきコンテンツとアクション。
• 既存のデザインの基盤となるもの：トークン、タイポグラフィ、コンポーネント、レイアウト、ブランドアセット、文書化された決定事項。
• 実装上の制約、影響を受けるルートと状態。
• 変更してはならないもの。

可能であれば、レンダリングされた画面を確認します。方向性が定まっていない場合は、プロダクトに合う、最小限で元に戻せる仮定を置きます。結果に大きく影響する選択をした場合は、その旨を明示します。

ビジュアルの方針を選ぶ

「控えめな装飾と、重要な状態を際立たせる色を使った、高密度な運用コンソール」のように、方向性を実際に役立つ一文で示します。その一文によって、階層、密度、書体、色、形状、動きに関する具体的な判断が定まる必要があります。どのプロダクトにも当てはまるような、雰囲気だけのラベルは避けます。

全体を統一するビジュアルの方向性がない場合は、プロダクトに合う、明確に異なる候補を2〜3案挙げ、それぞれのタスクへの適合性、特徴、主なリスクを説明します。ユーザーから複数案を並行して求められていない限り、実装前に主軸となる方向性を1つ選びます。補助的な要素を一部に取り入れることはできますが、複数のスタイルを混ぜて一貫性のないトレンドの寄せ集めにしないでください。

新しいビジュアルの方向性を作成する場合、複数のコンポーネントを変更する場合、または大幅なビジュアルの磨き込みが必要な場合は、references/visual-system.mdを読みます。名前の付いた UI スタイルから選ぶ場合、新しいカラーパレットを作る場合、または本文、コンポーネント、タイポグラフィの役割に色を割り当てる場合は、references/style-and-palette-direction.mdも読みます。対象を絞った編集では、どちらのリファレンスも読み込まず、既存のデザインシステムを維持します。

ランディングページ、ホームページ、複数セクションから成るマーケティングページ、フッターを新規作成または大幅に再設計する場合は、references/page-closure-and-footer.mdを読みます。ページの締めくくりも構成の一部として意図的に設計します。ただし、すべてのサイトに大規模な複数列のフッターが必要だとは限りません。

ランディングページ、ホームページ、記事、ドキュメント、カタログ、公開詳細ルートなど、コンテンツを発見、リンク、インデックス登録できる必要がある公開ページを新規作成または大幅に変更する場合は、references/semantic-html-and-search-discovery.mdを読みます。プロダクトの仕様で定められていない限り、プライベートダッシュボードや認証が必要なツールには、検索向けの要件を適用しないでください。

非対称な構成、重なり合う奥行き、エディトリアルな緊張感、または独自の手触りを感じさせるコンポーネントの細部を方向性に取り入れる場合は、references/expressive-composition-and-component-craft.mdを読みます。こうしたパターンは、コンテンツやタスクに根拠がある場合に候補として使い、必須の装飾やランダムなスタイル選択として扱わないでください。

アニメーション付きナビゲーション、オーバーレイ、スクロール時の表示、連動する状態遷移、表現力豊かなマイクロインタラクションなど、動きが体験の重要な要素となる場合は、references/motion-and-rendering-performance.mdを読みます。動きは目的に沿い、アクセシブルで、実行時のコストに見合ったものにしてください。

タスクを中心に構築する

• セマンティックな構造と情報の順序から始め、装飾はその後に加えます。
• 各領域に役割を持たせます。よくあるテンプレートを完成させるためだけに存在するセクションは削除します。
• 必要な階層を表現できる既存のプリミティブを再利用します。既存の仕様では表現できない場合にのみ、バリアントを追加します。
• コンテナーやエフェクトを加える前に、余白、文字、コントラスト、配置、グループ化で階層を作ります。
• 繰り返し登場するコンテンツには、繰り返し使われるコンポーネントを使います。性質の異なる情報を、無理に同じカードに押し込みません。
• レスポンシブ対応とアクセシビリティの動作を維持します。どちらかが依頼の主要な要素である場合は、専用のスキルを読み込みます。

作業の中心が、ジャーニー、情報アーキテクチャ、タスクフロー、画面をまたいだ一貫性、フィードバック、または復旧時の仕様である場合は、superior-ux を読み込みます。通常のページ階層と視覚的なインタラクション設計は、このスキルで扱います。

プロダクトの整合性を守る

対象にダッシュボード、マーケティング上の主張、フォーム、ナビゲーション、非同期データ、または複数の UI 状態が含まれる場合は、references/product-integrity.md を読みます。

最低限、次の点を守ります。

• 指標、顧客、推薦文、アクティビティ、コンプライアンス、遷移先を決して捏造しません。
• コントロールは動作させるか、削除するか、利用できないことを正直に表示します。
• 該当する場合は、読み込み、初回利用、フィルター適用後の該当なし、権限拒否、入力検証、エラー、成功の状態を区別します。
• プロダクトで使われている用語に沿って、具体的なラベルと操作を記述します。
• 依頼された変更の範囲外では、ユーザーデータと既存の動作を維持します。

提出前に批評する

次の3つの視点から結果を確認します。

1. ページ： 主なタスクは明確か、構成には意図的なリズムがあるか、ページの終わりは視覚的にも情報的にも適切にまとまっているか。
2. コンポーネント： 各コンポーネントに、境界、強調、インタラクションを設けるだけの理由があるか。
3. 詳細： ラベル、アイコン、状態、フォーカス、配置、コンテンツに一貫性があり、誠実さが保たれているか。

一般的なテンプレートから借りてきたように見える要素には疑問を持ちます。根拠や機能に裏付けられている場合は残し、単なる装飾上の習慣である場合は修正します。

検証する

変更したインタラクションと関連する状態を実際に動かして確認します。代表的な狭い画面と広い画面、コンテンツの極端なケース、キーボード操作の流れ、およびプロジェクトで通常使われる lint、型チェック、ビルドの確認を、変更内容に応じて行います。具体的な結果と、未検証のリスクがあれば報告します。

読み込み、レンダリング、レスポンシブ動作、バンドルサイズ、またはクライアントメモリが、測定に基づいて取り組むべき主要な課題である場合は、superior-performance を読み込みます。専用のパフォーマンス調査が必要ない場合は、このスキルで通常のモーションとレンダリングの規律を保ちます。