design-distinctive-ui

独自性のあるUIをデザインする

要件に即した明確な視点、適切なインタラクション設計、そして本番環境での検証を備えたインターフェースを作成します。ありきたりなデザインを避けることは、決まった見た目のスタイルではなく、推論の規律として捉えてください。

モードを選択する

• Build（デフォルト）：新しいページ、画面、またはアプリケーションを作成します。
• Component：1つのコンポーネントを作成または改良し、その動作に当てはまるすべての状態を実装します。
• Audit：調査して報告します。ユーザーが修正も依頼していない限り、編集は行いません。
• Redesign：合意済みのプロダクトの範囲を維持しながら、視覚的な構成を変更します。
• Study：スクリーンショットまたは公開URLから応用可能なデザインの特徴を抽出します。ピクセル単位で複製してはいけません。
• Polish：既存の成果物に、効果が明確で検証済みの変更をいくつか加えて改善します。

Audit、Redesign、Study、またはPolishを行う場合は、references/audit-redesign-study.mdを読んでください。BuildとComponentでは、以下のワークフローを使用します。

必ず守ること

1. 考案する前に調査します。 アクティブなホストで認識されるリポジトリの指示を読みます。AGENTS.md、CLAUDE.md、または同等のファイルがあれば確認します。編集前に、既存のデザイントークン、フォント、ルート、コンポーネント、依存関係、コンテンツ、実際の検証コマンドを調べます。
2. プロジェクトを尊重します。 ユーザーから変更を求められていない限り、ルート、コンポーネントの所有関係、分析フック、フィールド名、SEO、ブランドアセット、動作中の機能を維持します。広範囲を暗黙に削除または置き換えてはいけません。
3. プロジェクトで有効なパッケージポリシーに従います。 リポジトリで実際に使用されているパッケージマネージャーを特定し、その指示に従います。WERIXO /Users/rootml ポリシーが適用される場合は、pnpmのみを使用します。npm、npx、yarnは使用せず、一時的なバイナリにはpnpm dlxを使用します。
4. 根拠を捏造してはいけません。 指標、推薦コメント、顧客、受賞歴、仕様、製品の機能を作り上げてはいけません。提供された事実、明示されたプレースホルダー、または根拠を必要としない構成を使用します。
5. アクセシビリティは最低条件です。 WCAG 2.2 AA、セマンティックHTML、キーボード操作、隠れない視認可能なフォーカス、十分なターゲットサイズ、動きの抑制、リフロー、コントラストを目指します。references/accessibility-and-quality.mdを読んでください。
6. 該当する状態を実装します。 すべてのインタラクティブ要素に、その動作で実際に起こり得る状態を用意します。静的リンクにエラー・読み込み・成功状態を勝手に追加してはいけません。必要な非同期コントロールでは、そうした状態を省略してはいけません。
7. 想像力ではなく、システムを固定します。 視覚的なトークンを選んだら、意味に沿ったトークンを一貫して使用します。プロジェクトに十分なシステムがすでにある場合、新しいトークンファイルを無理に作成してはいけません。
8. レンダリング結果を検証します。 静的なコードレビューでは、リズム、重なり、クリッピング、レスポンシブ動作は判断できません。ツールが使える場合は、レンダリングして確認します。
9. ありきたりなデザインを避けるルールを、新たなテンプレートにしてはいけません。 中央揃えのヒーロー、セリフ体、グラデーション、カード、イラストも、要件に合っていれば適切な場合があります。要素単体ではなく、根拠のない組み合わせを指摘します。
10. 特定のホストに依存しないでください。 ベンダー固有のツール名ではなく、目的に応じて機能を使用します。相対リソースは、このSKILL.mdがあるディレクトリを基準に解決します。このスキルのインストール、配布、トラブルシューティングを行う場合は、references/platform-compatibility.mdを読んでください。

BuildとComponentのワークフロー

0. 事前確認

以下を調べます。

• ローカルの指示と、実際のビルド・テスト・lint・型チェックのコマンド。
• フレームワーク、パッケージマネージャー、スタイリング手法、コンポーネントライブラリ、モーションのスタック。
• 既存のトークン、タイポグラフィ、余白、角丸、影、アイコン、画像、ブレークポイント、テーマ。
• ルート、ページ階層、コンテンツソース、ブランドアセット、分析に影響する名前、アクセシビリティのパターン。
• すでにレンダリング可能な場合は、現在の画面をデスクトップとモバイルの両方で確認します。

重要な調査結果のみを伝えます。依頼されたプロジェクトの改善につながらない限り、キャッシュ、ログ、トークン、デザインシステムのファイルを作成してはいけません。

1. デザインを読み解く

次の要素を推測して明示します。

サーフェス・対象ユーザー・主な目的・トーン・制約

結果を大きく左右する可能性のある答えが2つ考えられる場合に限り、質問は最大1つまでにします。それ以外の場合は、前提を明示して進めます。

状況に応じた3つの指標を1〜10で設定します。

• 変化度：対称的・慣習的 → アートディレクション重視・意外性がある
• 動き：静的・フィードバックのみ → 映画的・スクロール主導
• 密度：ゆとりのある・エディトリアル → 実務的・コックピット型

これらは意思決定の補助指標であり、ユーザー向けの設定ではありません。公共部門、規制対象、アクセシビリティが重要な領域、情報密度の高いプロダクト画面では、通常、変化度と動きを抑えます。ブランド、エディトリアル、体験重視の制作では、高めてもよいでしょう。

ビジュアルの方向性を選ぶ前に、references/direction-and-structure.mdを読んでください。

2. ひとつのビジュアルコンセプトに決める

インターフェースの素材感、リズム、タイポグラフィ、エネルギーを1文で表現します。次に、以下を選びます。

• ユーザーの行動の流れに合った、構造上の特徴をひとつ。
• セクションまたはワークスペースの領域ごとに、支配的なビジュアルアイデアをひとつ。
• ひとつの書体システム、ひとつの配色ロジック、ひとつの角丸ロジック、ひとつのアイコンファミリー、ひとつのモーション表現。
• プロダクトまたはブランドに根差した、記憶に残る要素をひとつ。

流行の効果を積み重ねてムードを作らないでください。装飾よりも先に、コンテンツの階層、プロポーション、リズム、具体性によって独自性を生み出します。

3. タスクに合わせてコンテンツを構成する

• マーケティングコンテンツは、ユーザーの不確実性に沿って、課題、仕組み、根拠、アクションの順に並べます。
• プロダクトUIは、マーケティング用のヒーローではなく、実際に作業する画面から始めます。
• セクションまたは領域ごとに、目的をひとつに絞ります。
• 実務向けのUIには実用的なコピーを、マーケティングUIにはブランドを表現するコピーを使います。
• 繰り返し、曖昧な形容詞、装飾的なメタデータ、根拠に見せかけた埋め草を取り除きます。
• 画像は、ストーリーやプロダクトの情報を伝える場合にのみ選びます。タイポグラフィだけでも成立しますが、意図のないストック画像では成立しません。

4. デザインの契約を定める

既存のセマンティックトークンを優先します。ない場合は、必要最小限の契約を定義します。

• サーフェス、テキスト、ミュートテキスト、ボーダー、アクセント、アクセントテキスト、フォーカス、危険、成功。
• 必要な場合に限り、ディスプレイ／本文／等幅の役割を定義します。
• スペーシング、文字サイズのスケール、角丸、エレベーション、モーションの時間・イージング、z-indexレイヤー。
• レスポンシブなコンテンツ幅とレイアウトのブレークポイント。

生の値を使うのはトークン定義の中だけにします。コンポーネントではトークンを使用します。

単独のインタラクティブコンポーネントでは、実用上可能な場合、該当するすべての状態をプレビューまたはストーリーでまとめて表示します。

5. プロジェクト標準のパターンに従って実装する

• 既存のフレームワークとコンポーネントの規約に合わせます。
• インストール済みのパッケージを再利用し、インポート前に存在を確認します。
• 依存関係の追加は、必要性があり、プロジェクトのポリシーで承認されている場合に限ります。
• セマンティックHTMLとネイティブコントロールを優先します。
• 可能な場合はアニメーションをtransformとopacityに限定し、クリーンアップと動きを抑える設定への対応を行います。
• ユーザーが提供した実際のコンテンツとアセットを使います。一時的なプレースホルダーには、その旨を明記します。
• 変更範囲を限定します。無関係なコードの再フォーマットや書き換えはしません。

6. 品質確認を繰り返す

references/anti-slop-gates.mdとreferences/accessibility-and-quality.mdを読んでください。

1. リポジトリで見つかったチェックを実行します。

2. 読み込まれたこのSKILL.mdがあるディレクトリを見つけ、そのディレクトリから同梱の静的ヒューリスティックを実行します。

   python3 scripts/ui_quality_lint.py --html <file> --css <file> --format text

   検出結果は確認の手がかりとして扱い、デザイン品質やWCAG適合性の証明とは見なしません。

3. プロダクトに適した基準幅でレンダリングして確認します。特に指定がない限り、一般向けのウェブページでは320、375、414、768、1280 pxを含めます。

4. キーボード操作の流れ、フォーカス、ホバーとタッチの同等性、長いコンテンツ、空・エラー・読み込み状態、ズームとリフロー、動きを抑える設定、両方に対応している場合は両テーマをテストします。

5. 表示されるすべてのコピーを読み直し、すべての主張を確認します。

6. 問題を修正し、関連するチェックを再実行します。

7. 引き渡し前の自己評価

1～5で評価します。

• 目的：このデザインは、この製品やページが存在する理由を表現していますか？
• 階層：最優先のタスクが数秒以内にわかりますか？
• 独自性：変更を加えなくても、別のブランドのものとして自然に見えますか？
• 一貫性：書体、色、余白、形、アイコン、動きに一貫性がありますか？
• 簡潔さ：画面上のすべての要素に、そこにあるだけの理由がありますか？
• 堅牢性：実際の状態、コンテンツ、デバイス、入力方法でも問題なく機能しますか？

3未満の評価がある場合は、もう一度見直してください。ユーザーが監査証跡を求めない限り、評価を本番コードに追加しないでください。

出力に関する期待事項

結果を最初に示してください。次の内容を報告します。

• デザインの解釈と、中心となるビジュアルの考え方。
• 変更した重要なファイル。
• 検証コマンドとその結果。
• 未検証の項目。
• 残っているプレースホルダー、前提、リスク。

監査では、ユーザーへの影響が大きい順に指摘事項を並べ、ファイルと行番号、または画面上の領域を示してください。根拠と好みは分けてください。

参考資料

• references/direction-and-structure.md：方向性、調整項目、構造の類型、デザインシステムの選択、画像。
• references/anti-slop-gates.md：文脈に応じたアンチパターンと独自性のレビュー。
• references/accessibility-and-quality.md：WCAG 2.2、レスポンシブ対応、状態、パフォーマンス、ビジュアル品質の検証。
• references/audit-redesign-study.md：読み取り専用の監査、安全な再設計、参考資料の調査、仕上げのワークフロー。
• references/platform-compatibility.md：共通の Agent Skills 形式、検出パス、Claude Code、OpenCode、Codex、Kimi Code での呼び出しと移植性の確認。

出典

これは、Hallmark（MIT）、design-taste-frontend、frontend-skill、frontend-design、impeccable-design-polish、design-auditorを参考に独自にまとめたものです。役立つ手法は活用しつつ、それぞれの固有のスタイルを模倣したり、単一のカタログを唯一の正解と見なしたりしないでください。