frontend-design

このスキルでは、ありがちな「AI が生成したような」見た目を避け、個性があり、本番環境で使えるフロントエンドインターフェースを作成します。美的な細部や創造的な選択に細心の注意を払い、実際に動作するコードを実装してください。

Refactoring UI の運用モデル

エフェクトを使う前に、次の順序で判断してください。

1. 外枠ではなく機能から始める：まず、ユーザーが行う具体的なタスクを設計します。ナビゲーション、クローム、装飾的な構造は、機能のニーズに従って設計します。逆にしてはいけません。
2. グレースケールで階層を確立する：まず、余白、サイズ、ウェイト、コントラスト、グルーピングを使って、インターフェースをわかりやすくします。グレースケールで機能しないなら、色を加えても解決しません。
3. 細部より先にシステムを定義する：余白、タイポグラフィ、色、角丸、エレベーションには、選択肢を絞ったスケールを使います。選択肢を減らして判断の負担を抑え、意図が感じられる仕上がりにします。
4. 具体的な手段で個性を選ぶ：フォント、色温度、角丸、言葉遣いでトーンを表現します。無作為なエフェクトは使いません。
5. 仕上げは最後に行う：階層とシステムが機能してから、色、奥行き、装飾、動き、仕上げの工夫を加えます。

重要：装飾より階層を優先します。場当たり的な調整よりシステムを優先します。流行を追うより節度を優先します。

コンテキスト収集の手順

プロジェクトのコンテキストがなければ、デザインスキルはありきたりな結果になります。デザイン作業を始める前に、必ずデザインのコンテキストを確認してください。

必須のコンテキスト — すべてのデザインスキルで、最低限次の情報が必要です。

• 対象ユーザー：この製品をどのような人が、どのような状況で使いますか？
• ユースケース：ユーザーはどのような作業を行おうとしていますか？
• ブランドの個性・トーン：インターフェースにどのような印象を持たせますか？

個々のスキルで追加のコンテキストが必要な場合があります。詳細はスキルの準備セクションを確認してください。

重要：コードベースを読んで、このコンテキストを推測することはできません。コードからわかるのは、何が作られたかであり、誰のためのものか、どのような印象を与えるべきかではありません。このコンテキストを提供できるのは作成者だけです。

収集手順：

1. 現在の指示を確認する（即時）：読み込まれた指示に Design Context セクションがすでに含まれている場合は、すぐに作業を進めてください。
2. .better-web-ui.md を確認する（迅速）：指示にない場合は、プロジェクトルートにある .better-web-ui.md を読みます。ファイルが存在し、必要なコンテキストが記載されていれば、作業を進めてください。
3. 従来のコンテキストファイルを確認する（フォールバック）：.better-web-ui.md がまだ存在しない場合は、プロジェクトルートにある .better-ui.md、続いて .impeccable.md を読みます。どちらかに必要なコンテキストが記載されていれば、作業を進めてください。ただし、可能であれば .better-web-ui.md への移行を優先してください。
4. セットアップを実行する（必須）：どちらの参照先にもコンテキストがない場合は、ほかの作業を行う前に、必ず今すぐ $setup を実行してください。この手順を省略してはいけません。その代わりにコードベースからコンテキストを推測しようとしてはいけません。

フレームワークとライブラリに関するガイダンス

このスキルライブラリは、特定のフレームワークやライブラリに依存しないよう意図的に設計されています。

実装の詳細が重要な場合は、次の優先順位に従ってください。

1. まず、既存のプロジェクトスタックを検出し、それに合わせます
2. 次に、新規プロジェクトに関するユーザーの明示的な選択を尊重します
3. プロジェクトが新規で、指定がない場合に限り、デフォルトのマトリックスを使用します

優先順位の全体像、フレームワークのデフォルトマトリックス、問題の略記、注意事項については、フレームワークのデフォルトを参照してください。スタイリング、コンポーネントライブラリ、フォーム構成、テーブル構成、仮想化のデフォルトを決める必要がある場合は、必ずこのリファレンスを使用してください。

プロジェクトで特定のフロントエンドフレームワークまたはメタフレームワークを使用している場合は、フレームワーク固有の実装方針を決める前に、フレームワークの公式ドキュメントを参照してください。

特に Next.js では、プロジェクトにバージョンが一致するドキュメントが node_modules/next/dist/docs/ に含まれている場合は、コーディングの前に関連するローカルの Next.js ドキュメントを読んでください。インストール済みバージョンの信頼できる情報源として、古い記憶に頼るのではなく、同梱されているドキュメントを参照してください。

React ベースのフォールバックのデフォルトが関係する場合は、コンポーネントとブロックの戦略を使用して、shadcn/ui のプリミティブからいつ構成するか、ブロックが効果的な手段となるのはどのような場合か、汎用的なライブラリ出力を変更せずにそのまま提供しないためにはどうすればよいかを判断してください。テーマコントロール、同意、テキストモーション、お客様の声のパターン、ホイールピッカー、スライド操作など、リクエストが厳選されたコミュニティコンポーネントに当てはまる場合は、React 向け shadcn アクセラレーターを使用してください。

プロジェクトに成熟したコンポーネントライブラリがなく、プリミティブを一から構築または改善する必要がある場合は、コンポーネントの構造を参照してください。ボタン、カード、チェックボックス、ドロップダウン、タブ、テキストエリア、トースト、トグル、ツールチップ、アコーディオン、アバター、バッジ、境界線、パンくずリスト、アイコン、リスト、送信アクションなど、カスタムコンポーネントの実用的な構造に関するガイダンスを提供しています。

このフォルダーにある、アコーディオン、パンくずリスト、カルーセル、スライダー、日付入力、日時ピッカー、ナビゲーションメニュー、機能比較、コンフィギュレーター、複雑なテーブルのガイダンスなど、より対象を絞ったコンポーネントパターンのリファレンスも、同じデフォルトに従います。主に、カスタムプリミティブ、ヘッドレス構成、またはプレーンな HTML / CSS / JavaScript による実装を対象としています。成熟したコンポーネントライブラリがすでにプリミティブを適切に提供している場合は、ライブラリ側で確立された構造、セマンティクス、アクセシビリティの動作を再実装するのではなく、そのパターンが適切か、どのように構成するか、必要なデフォルトと状態は何か、ライブラリのコンポーネントを中心にレスポンシブにどう動作させるかを判断するために、これらのリファレンスを主に使用してください。

---

デザインの方向性

デザインの方向性は、曖昧な雰囲気を表す形容詞ではなく、意図的な制約の体系として扱います。

• 機能を最優先：画面を取り巻く要素をデザインする前に、この画面が支えるべき主要なワークフローや場面を特定します。
• 目的：このインターフェースはどのような課題を解決しますか？誰が使いますか？
• ブランドとの適合性：この企業、製品、対象ユーザー、提供価値にふさわしい印象とはどのようなものですか？
• コンテンツとの適合性：このレイアウトでは、コピー、根拠、画像、ナビゲーション、製品の詳細をどの程度扱う必要がありますか？
• 制約：技術要件、パフォーマンス予算、アクセシビリティ、保守コスト。
• 差別化：使いにくくすることなく、記憶に残る要素は何ですか？

スタイルを選択または維持する際は、デザインの方向性に従ってください。

このリファレンスでは、このライブラリで承認されているウェブサイトの方向性、それらの選び方、より大胆なスタイルをどこで限定的に使うべきか、そしてこのライブラリで生成すべきでないスタイルを定義しています。

デフォルトでは、次のルールに従ってください。

• 既存プロジェクトを優先：プロジェクトにすでにビジュアルシステムがある場合は、ユーザーからリブランドや大幅なスタイル変更を明示的に求められない限り、タイポグラフィ、カラーパレット、間隔のリズム、サーフェスの表現、インタラクションのトーンを維持します。
• 新規プロジェクトの幅広い依頼では、承認済みの方向性から選ぶ：スタイルの指定なしに、新しいランディングページ、マーケティングページ、または複数の異なる方向性を求められた場合は、ランダムな雰囲気のラベルを作り出すのではなく、製品のアイデアとブランドとの適合性に基づいて、承認済みのデザインの方向性から選びます。
• 効果より先に構造を選ぶ：まず主要な構造の方向性を1つ定め、その後、必要に応じてサーフェス、タイポグラフィ、モーション、表現のいずれかの補助的な要素を1つ加えます。
• 主要なフローは外枠より明快に保つ：マーケティング層をより表現豊かにする場合でも、フォーム、テーブル、設定、認証、料金プランの比較、エラー状態は、通常、ミニマリスト、スイススタイル、フラット、または同様に明快さを最優先する表現に寄せます。
• レトロ／サイバー／シンセウェーブ／ターミナル風の美学をデフォルトにしない：このライブラリでは、幅広い依頼を受けて、これらの方向性を自発的に提案しないでください。

最初に少し慎重に考えましょう。

• まず、役に立つ最小限のバージョンをデザインします。
• まだ実現できない機能があるかのように見せないでください。
• ラフな探索で素早く判断し、早い段階で実際のものを作り、短いサイクルで反復します。
• 重厚なスタイルの処理を重ねる前に、タイポグラフィ、間隔、階層、CTA の構成を固めます。

依頼内容がまだ曖昧な場合、仕上げの前にレイアウトやフローの判断を明確にする必要がある場合、またはワイヤーフレームからスタイルガイド、プロトタイプへとより明確に進める必要がある場合は、デザインプロセスを使用してください。 チーム内でより明確な共通の基準、強い製品価値、または何をすべきかだけでなく何を避けるべきかも示す、より長期的に有効な意思決定の視点が必要な場合は、デザイン原則を使用してください。 画面単位の実装に入る前に、ユーザーセグメントの焦点、優先事項、価値の高い UX の施策、実現可能性の枠組み、または製品・ビジネス目標とのリスクを考慮した整合性を明確にする必要がある場合は、UX 戦略を使用してください。 対象ユーザーそのものが UX に影響する場合（たとえば、Z 世代、子ども、保護者、高齢者、またはデバイスの利用習慣、信頼のパターン、アクセシビリティのニーズが特徴的な対象ユーザー向けのデザイン）には、対象ユーザーに配慮したデザインを使用してください。

重要：明確なコンセプトの方向性を選び、精度高く実現してください。強度よりも意図が大切です。装飾的な効果を一時的に取り除いても、タイポグラフィ、間隔、階層、コンテンツ構造が機能するようにしてください。

続いて、次の条件を満たす動作するコードを実装します。

• 本番環境に対応した機能的なコードである
• 見た目に強い印象を与え、記憶に残る
• 明確な美的視点を持ち、一貫性がある
• 細部まで緻密に仕上げられている

フロントエンドの美学に関するガイドライン

タイポグラフィ

→ スケール、フォントの組み合わせ、読み込み方法、フォント選択のヒューリスティックについては、タイポグラフィのリファレンスを参照してください。行の長さ、行の高さ、ベースラインの配置、ラベルと値の扱い、リンクの強調、数値の配置、意味上の階層と視覚上の階層については、テキストの階層と読みやすさを参照してください。

美しく、独自性があり、興味を引くフォントを選びましょう。個性のあるディスプレイフォントと洗練された本文用フォントを組み合わせます。

推奨：制約のある手作りのタイポグラフィスケールを使い、モジュラースケールの比率は参考にしつつ、縛られすぎないようにします 推奨：サイズだけに頼らず、ウェイト、色、間隔で階層を作ります 推奨：同じ行に異なるサイズのフォントが並ぶ場合は、ベースラインを揃えます 推奨：見出しの文字間隔は慎重に詰め、読みやすさが向上する場合は大文字のみのテキストに字間を加えます 推奨：ヒーローやディスプレイ見出しが複数行に折り返される場合は、行間を詰めすぎる前に文字サイズを小さくします。文字の上部や下部が切れないよう、十分な行の高さとブロック内の余白を確保します 非推奨：使い古されたフォント（Inter、Roboto、Arial、Open Sans、システムの既定フォント）を使います 非推奨：「技術的／開発者向け」の雰囲気を手軽に出すために、等幅フォントを使います 非推奨：入れ子になった UI に em ベースの文字サイズスケールを使います。すぐにシステムからずれてしまいます 非推奨：長文を中央揃えにします。中央揃えは短い文章には適していますが、情報量の多い文章には向きません 非推奨：すべての見出しの上に角丸の大きなアイコンを置きます。価値を加えることはほとんどなく、サイトがテンプレートのように見えてしまいます

色とテーマ

→ OKLCH、パレット、ダークモードについては、色のリファレンスを参照してください。意味のある状態、チャート、アクティブ状態、カテゴリの色を色覚特性にかかわらず区別できるようにするには、色覚特性に配慮した UXを参照してください。カラースケールを構築または修正する場合は、カラースケールのワークフローを参照してください。色でステータス、アラート、意味を伝える場合は、セマンティックカラーを参照してください。チャート、グラフ、プロットでデータを示す場合は、データビジュアライゼーションを参照してください。

統一感のあるパレットを選びましょう。控えめで均等に色を配したパレットよりも、支配的な色と鮮明なアクセントの組み合わせが効果的です。

推奨：まずグレースケールで始め、すでに明確な階層ができてから色を重ねます 推奨：知覚的に均一で、保守しやすいパレットには、最新の CSS 色関数（oklch、color-mix、light-dark）を使います 推奨：色合いは最初に定義します。グレーには実用的なスケールを用意し、プライマリカラーとアクセントカラーには使いやすい濃淡を複数用意します 推奨：ニュートラルカラーにブランドカラーの色相を加えます。わずかな色味でも、無意識の統一感につながります 推奨：アクセシビリティに配慮した、強調度の低い色付きパネルが必要な場合は、淡く色を付けた背景に濃い文字色を使います 非推奨：色付きの背景にグレーのテキストを使います。色あせた印象になるため、代わりに背景色の濃淡を使います 非推奨：lighten() や darken() をむやみに使って、よく似た色を35段階も作ります 非推奨：純粋な黒（#000）や純粋な白（#fff）を使います。必ず色味を加えましょう。純粋な黒や白は自然界には存在しません 非推奨：AI 風のカラーパレットを使います。暗い背景にシアン、紫から青へのグラデーション、暗い背景にネオンカラーといった組み合わせです 非推奨：「インパクト」を出すためにグラデーションテキストを使います。特に数値や見出しでは避けましょう。意味のある表現ではなく、単なる装飾です 非推奨：光るアクセントを使ったダークモードを安易に既定にします。実際のデザイン判断をしなくても「クール」に見えてしまいます

レイアウトと空間

→ グリッド、リズム、コンテナクエリについては、空間デザインのリファレンスを参照してください。構成やグループ分けが弱い場合は、スペーシングシステムと階層チェックリストを活用してください。

同じパディングをどこにでも使うのではなく、スペーシングに変化をつけて視覚的なリズムを生み出します。非対称性や意外性のある構成を取り入れます。強調したい箇所では、意図的にグリッドを崩します。

推奨：必要だと感じる以上の余白から始め、デザインのバランスが取れるまで減らします 推奨：スペーシングに変化をつけて、視覚的なリズムを生み出します。グループ内は狭く、グループ間は広く空けます 推奨：大きな画面でゆとりが生まれるよう、clamp()を使った可変スペーシングを採用します 推奨：非対称性や意外性のある構成を取り入れ、強調したい箇所では意図的にグリッドを崩します 推奨：スペーシングが曖昧にならないよう、グループ内よりグループの周囲に広い余白を設けます 推奨：長いページは、論理的に分かれた明確なブロックに分割します。同じ重要度のセクションでは、通常、外側のスペーシングを統一します。また、共通の背景は、狭い見出し部分だけでなく、関連するブロック全体を囲むようにします 推奨：コンポーネントには実際に必要な幅を与えます。サイドバー、フォーム、カードでは、可変幅より固定幅が適していることがよくあります 非推奨：すべてをカードで囲まないでください。すべてにコンテナが必要なわけではありません 非推奨：カードの中にカードを入れないでください。視覚的なノイズになるため、階層を整理してください 非推奨：同一のカードグリッドを使わないでください。同じサイズのカードにアイコン、見出し、テキストを配置する構成を延々と繰り返さないでください 非推奨：ヒーローメトリックのレイアウトテンプレートを使わないでください。大きな数字、小さなラベル、補足統計、グラデーションのアクセントで構成されるものです 非推奨：すべてを中央揃えにしないでください。左揃えのテキストと非対称なレイアウトのほうが、デザイン性を感じさせます 非推奨：ビューポートが広いというだけで、すべてのセクションを引き伸ばさないでください 非推奨：どこでも同じスペーシングを使わないでください。リズムがないと、レイアウトが単調になります

ビジュアルの細部

→ シャドウのレベル、浮き上がり／くぼみの考え方、奥行きの割り当てについては、エレベーションシステムを参照してください。スペーシング、境界線、シャドウ、重なり、背景の変化の使い分けには、サーフェスの分離を活用してください。センスのよい標準的な調整、アクセントの境界線、装飾的な背景については、仕上げの工夫を参照してください。トーンが曖昧に感じられる場合は、個性を出す方法を活用してください。デザインがありきたり、または流行の追随に見えるおそれがある場合は、AIスロップの検出を参照してください。

推奨：ブランドを強化する、意図的で目的のある装飾要素を使います 推奨：小規模なエレベーションシステムを作ります。シャドウは単なる飾りではなく、Z軸方向の奥行きを伝えるものにします 推奨：あらゆる場所に境界線を使う前に、背景の変化、スペーシング、控えめなシャドウを活用します 推奨：ガラス風、ソフトUI、クレイ、ブルータリスト風のアクセント、3D要素など、主張の強いスタイル表現は、選択した方向性が幅広い使用に本当に適している場合を除き、選択的に使います 非推奨：グラスモーフィズムをどこにでも使わないでください。目的に沿わず装飾として使われる、ぼかし効果、ガラス風カード、光る境界線は避けます 非推奨：片側に太い色付きの境界線がある角丸要素を使わないでください。安易なアクセントになり、意図的なデザインに見えることはほとんどありません 非推奨：装飾としてスパークラインを使わないでください。洗練されて見えても、有意義な情報を伝えない小さなグラフです 非推奨：汎用的なドロップシャドウ付きの角丸長方形を使わないでください。無難で印象に残らず、どのAI出力にもありそうな見た目になります 非推奨：エレベーションやインタラクションを明確にしないリアリティや奥行きの効果を加えないでください 非推奨：主役と補助の明確な階層がないまま、主張の強い複数のスタイルを混在させないでください 非推奨：本当にほかに良い方法がない場合を除き、モーダルを使わないでください。モーダルは安易な選択です

画像とメディア

→ 写真、スクリーンショット、アイコン、イラスト、ユーザーがアップロードしたメディア、オーバーレイ、画像の読みやすさを扱う際は、画像の扱いを参照してください。ファーストビューのビジュアル、ホームページの冒頭、ランディングページの第一印象について、明瞭さや根拠、パフォーマンスへの配慮を強化する必要がある場合や、そもそもヒーロー画像を設けるべきか判断する場合は、ヒーローセクションのUXを参照してください。メディアの比率やトリミングのルール、閲覧向けと比較検討向けのカードレイアウト、レスポンシブなカードやメディアのリズムが明瞭さや流れに大きく影響する場合は、アスペクト比とカードの向きを参照してください。

DO: 画像のコントラストの問題は、タイポグラフィの問題ではなく、まず画像の扱いの問題として考えてください DO: スクリーンショットは、有用な情報が伝わる大きさ、または焦点がわかる大きさを保ってください DO: アイコンは、イラスト的に拡大する目的で作られたものを除き、デザイン時のサイズに近い大きさで使ってください DO: ヒーローのコピーは画像内の視覚的に落ち着いた場所に配置し、顔や製品の詳細など、意味のある注目ポイントに重ねないでください DO: ユーザーがアップロードしたメディアは、形状を制御し、予測可能なコンテナに収めてください DON'T: スクリーンショットを、目を凝らさないと見えないほど小さくしないでください DON'T: 小さなアイコンを拡大して、本物のイラストの代わりになるような大きなプレースホルダーにしないでください DON'T: ユーザーがアップロードした画像にレイアウトの形状を決めさせたり、背景にはみ出させたりしないでください

モーション

→ タイミング、イージング、モーションの軽減については、モーションのリファレンスを参照してください。

影響の大きい場面に集中してください。段階的な表示を組み合わせた、よく練られたページ読み込みは、散発的なマイクロインタラクションよりも大きな満足感を生み出します。

DO: モーションで状態の変化（表示、終了、フィードバック）を伝えてください DO: 自然に減速する指数関数的なイージング（ease-out-quart/quint/expo）を使ってください DO: 高さのアニメーションには、高さを直接アニメーションさせるのではなく、grid-template-rows のトランジションを使ってください DON'T: レイアウトプロパティ（width、height、padding、margin）をアニメーションさせないでください。transform と opacity のみを使ってください DON'T: バウンスや弾性のあるイージングは使わないでください。古くさく、安っぽく感じられます。実際の物体は滑らかに減速します

インタラクション

→ フォーム、フォーカス、読み込みパターン、ヤコブの法則、フィッツの法則については、インタラクションデザインを参照してください。

フォームとバリデーション

• 無効化されたボタンのUX — ブロックされている主要な操作、処理中のロック、利用できない操作
• 破壊的な操作のUX — 削除、アーカイブ、除去、権限の取り消し、取り消しと確認の使い分け、一括での破壊的な操作
• アコーディオンのUX — FAQ、開閉式のグループ、製品詳細のアコーディオン、設定セクション
• リアルタイムバリデーションのUX — インラインバリデーションのタイミング、フォーカス喪失時とリアルタイムの使い分け、早く報酬を与え遅く罰する設計
• エラーからの復旧 — フィールドのエラー、エラーの概要、厳密なバリデーター、復旧可能な失敗への対応
• 日付入力のUX — 生年月日、覚えやすい日付の入力フォーム
• 日付と時刻のピッカーのUX — 予約カレンダー、日付範囲ピッカー、時間枠の選択

ナビゲーションと経路案内

• 情報アーキテクチャのUX — 大規模な製品スイート、設定のアーキテクチャ、製品間のナビゲーション
• サイドバーとフッターのUX — 右側のレール、サポートパネル、サポート情報が充実したフッター
• ナビゲーションメニューのUX — メガドロップダウン、ヘッダーナビゲーション、ホバーとクリックのメニュー
• パンくずリストのUX — 入れ子になったナビゲーション、パンくずリスト、現在地の手がかり、ドキュメントの階層構造
• 検索と見つけやすさ — サイト内検索、コマンドパレット、入力候補、自動提案、検索結果がない場合の復旧
• 検索とフィルタリングのUX — オートコンプリート、フィルターのアーキテクチャ、結果の表示、検索結果がない場合の復旧 コマースとコンテンツ
• コレクションの閲覧と絞り込み — 長い検索結果リスト、ファセットによる閲覧、フィルターオーバーレイ
• 複雑なテーブルのUX — データグリッド、固定列、ヘッダーフィルター、行の選択、テーブル内の検証
• データビジュアライゼーション — グラフの種類の選択、レスポンシブなパターン、アクセシブルなデータテーブル、ツールチップ、注釈
• 機能比較のUX — 比較テーブル、仕様の並列表示、候補リストの比較フロー
• コンフィギュレーターのUX — 商品ビルダー、ステップ形式の設定、オプションのリアルタイムプレビュー
• スライダーのUX — 範囲スライダー、ローンまたは価格の計算ツール、両端ハンドルのフィルター
• カルーセルのUX — カルーセル、ギャラリーのレール、推薦文スライダー、機能紹介のレール
• eコマースのUX — カテゴリーページ、商品ページ、ショッピングフロー、カート、チェックアウト
• レビューと評価 — 商品レビュー、おすすめの指標、顧客写真による証拠
• ソーシャルプルーフのパターン — 推薦文、顧客ロゴ、レビューバッジ、事例紹介
• 価格設定とパッケージ — 価格設定ページ、プランの比較、請求設定
• ペイウォールとアップグレードフロー — 機能のロック、利用制限、トライアル、アップグレードの促し

フィードバックとステータス

• 小さな不具合と品質の印象 — わずかなカクつき、弱いフィードバック、消えるメニュー、挙動が不自然に見えることによる、不安定な印象
• 読み込み時のフィードバックとパフォーマンスの印象 — スケルトン、古いデータの表示、楽観的UI、ストリーミングコンテンツ、待ち時間を正直に伝える状態
• ステータスの伝達 — 検証、通知、バッジ、受信トレイ、アクティビティフィード
• フォーム検証のパターン — 検証のタイミング、エラーの配置、複数フィールド間の依存関係、非同期検証、復旧の設計
• 通知と権限 — ブラウザーの権限プロンプト、プッシュ通知の戦略、通知センター、拒否後の復旧
• 空の状態のパターン — データがない場合の画面
• コンポーネントのアクセシビリティ — キーボード操作、フォーカスインジケーター、スキップリンク、モーダルのフォーカス管理、非表示コンテンツ、現在のページの状態

レガシーとレジリエンス

• 行動デザイン — 段階的な情報開示、プライミング、フレーミング、完了の合図、価格選択の設計
• オンボーディングのUX — 初回利用時の手順、アクティベーション、気づきの瞬間、ツアーとチェックリストの比較
• 予測型・意図駆動型UI — おすすめ、スマートデフォルト、再開フロー
• レガシーのモダナイゼーション — レガシーシステム、新旧フローの併用、移行ロードマップの判断
• オフライン対応とレジリエンス — Service WorkerのUX、stale-while-revalidate、同期キュー、競合の解決
• 認知負荷 — Hickの法則とMillerの法則の実践
• 認証とアカウント復旧 — サインイン、サインアップ、パスワード設定、セッションの有効期限切れ、二要素認証フロー、アカウントロック
• 権限とロールのUX — ロールモデル、アクセス権の申請フロー、権限の境界、管理者とメンバーの挙動
• 言語とロケールの選択 — 言語セレクター、市場ごとの上書き設定、通貨や配送の設定 破壊的操作の確認では、どのコントロールを優先し、目立たなくし、非表示にし、または強調すべきかを判断する際に、アクション階層を使用してください。

データがゼロの画面設計には empty-state を使用してください。より広範なアクティベーション戦略、アハ体験、ツアー、初回利用時の説明には onboard を使用してください。 頻繁な操作がもたついたり、流れを妨げたりする場合は optimize を使用してください。権限、破壊的操作、自動化、管理者権限に、より強力な保護策が必要な場合は harden を使用してください。

操作を素早く感じられるようにしてください。楽観的 UI を使用し、まずすぐに更新し、同期は後で行います。

推奨：段階的開示を使用してください。まずシンプルに始め、操作に応じて高度な機能を明らかにします（基本オプションを先に示し、高度な機能は展開可能なセクションに配置する、ホバー時に副次的なアクションを表示するなど）。 推奨：よく知られたタスクには、使い慣れたパターンを使用してください。ナビゲーション、検索、タブ、ドロップダウン、テーブル、フィルター、フォーム、ページネーション、設定は、優れた製品によってユーザーがすでに期待するようになった動作に従うべきです。 推奨：機能する範囲で、最も妨げにならないステータス表示パターンを使用してください。インライン検証、控えめなインジケーター、受信トレイ、サマリー、トーストが、すべて同じ緊急度を競い合う状態にしないでください。 推奨：レガシーシステムを一気に書き換えることを提案する前に、既存のワークフローに関する知識を活用してください。多くの場合、ハイブリッドな併用と段階的な移行こそが、より誠実に取り組むべき設計課題です。 推奨：「何もありません」と伝えるだけでなく、インターフェースの使い方を教える空状態を設計してください。 推奨：すべてのインタラクティブな画面を、意図的に設計され、すばやく反応するものにしてください。 推奨：アクションに明確な階層を設けてください。主要アクションを1つ、副次的なアクションをいくつか、控えめな第3階層のアクションを配置します。 推奨：よく使うアクションを実行しやすくしてください。十分な大きさの操作領域、適切な場合は行全体に広がるラベル、操作対象のコンテンツに近い配置を心がけます。 推奨：通知量が妨げになりうる場合は、落ち着いたデフォルト設定、ダイジェストモード、ミュート方法、スヌーズオプション、通知を控える時間帯などで、ユーザーが通知の多いシステムを制御できるようにしてください。 禁止：同じ情報を繰り返さないでください。見出しの重複や、見出しの内容を言い換えただけの導入文は避けてください。 禁止：明確で大きなメリットがない限り、標準的なコントロールに独自のインタラクションモデルを作らないでください。 禁止：すべてのボタンを主要アクションにしないでください。ゴーストボタン、テキストリンク、副次的なスタイルを使い分け、階層を明確にしてください。 禁止：システムから送信できるというだけで、あらゆるステータス更新を警告、トースト、プッシュ通知、成長促進のメッセージとして扱わないでください。 禁止：レガシー画面を一から置き換えることが、ワークフローを記録し、つなぎ目の問題を減らし、ユーザーとともに段階的に移行することよりも、自動的に安全だと決めつけないでください。

レスポンシブ

→ 狭い画面を優先する戦略、フルイドデザイン、自然な幅、列の再調整、コンテナクエリについては、レスポンシブデザインのリファレンスを参照してください。

推奨：コンポーネント単位のレスポンシブ対応には、コンテナクエリ（@container）を使用してください。 推奨：異なるコンテキストに合わせてインターフェースを調整してください。単に縮小するだけでは不十分です。 禁止：狭い画面のレイアウトで重要な機能を隠さないでください。インターフェースを調整し、切り捨てないでください。

UXライティング

→ ラベル、エラー、空の状態については、UXライティングのリファレンスを参照してください。文言、進捗表示、同意、配信停止／キャンセルのフロー、アップグレードの案内が、回りくどく、操作を誘導するように、または不自然に親しげに聞こえるおそれがある場合は、インターフェースの誠実さを参照してください。問題が単なるメッセージの文言ではなく、ユーザーが状況に応じてエラーを見つけ、理解し、修正する方法に関わる場合は、エラーからの復旧を参照してください。タスクに見出し、ランディングページ、製品のポジショニング、オンボーディングでの約束、ライフサイクルメッセージ、マーケットプレイスの掲載内容、CTA戦略が含まれる場合は、マーケティングコピーライティングを参照してください。お客様の声の見せ方、ケーススタディによる証明、認証、主張やCTAの近くに信頼性を示す要素を配置する方法にコピーが左右される場合は、ソーシャルプルーフのパターンを参照してください。既存のコピーをやみくもに書き直すのではなく、焦点を絞った見直しで改善する場合は、コピー編集の見直しを参照してください。プラン、請求、更新、アップグレード、価値を、強引な手法に頼らず説明する必要がある場合は、これらに価格設定とパッケージおよびペイウォールとアップグレードフローを組み合わせてください。

DO：すべての言葉に役割を持たせる DON'T：ユーザーがすでに見ている情報を繰り返さない

データがゼロの場合の画面設計にはempty-stateを使用してください。より広範なアクティベーション戦略、初回利用時の学習、アハ体験、ツアー、定着化の計画にはonboardを使用してください。

プロダクト倫理とデフォルト設定

トレードオフが生じた場合は、次の優先順位をデフォルトとしてください。

1. 明確さ
2. タスクを完了する速さ
3. エラーの防止
4. 慣れ親しんだインタラクションパターン
5. ビジュアルの仕上がり
6. 高度な柔軟性

下位の項目を改善するために、上位の項目を犠牲にしないでください。

ダークパターンは絶対に使用しない

プロダクトに有利な結果へ誘導するために、混乱、妨害、罪悪感、情報の隠蔽、誤解を招く階層構造に頼ってはなりません。

DO：

• 選択肢、価格、同意、結果を理解しやすくする
• 配信停止、キャンセル、プライバシー、ダウングレードの手順を分かりやすくする
• 誠実な警告、実際のオプトイン、公正なデフォルト設定を用いる
• 可能な限り、ユーザーの自律性、十分な情報に基づく同意、取り消し可能性を保つ

DON'T：

• コントラストを弱くしたり、分かりにくい場所に配置したり、誤解を招くラベルを付けたりして、重要な情報を隠さない
• 登録よりもキャンセルを難しくしない
• コンバージョンを高めるためだけに、搾取的な選択肢をあらかじめ選択しない
• 偽の緊急性や希少性、羞恥心をあおる文言、曖昧な破壊的操作の確認を用いない
• ユーザーの判断を不十分な情報に基づかせたり、取り消しにくくしたりして、指標を改善しない

---

AIスロップテスト

重要な品質チェック：このインターフェースを誰かに見せて「AIが作った」と伝えたとき、すぐに信じるでしょうか？ そうなら、それが問題です。

独自性のあるインターフェースを見た人には、「これはどうやって作ったの？」と思わせましょう。「どのAIが作ったの？」と思わせるのではありません。

上記のDON'Tガイドラインを確認してください。これらは、2024～2025年にAIが生成した成果物によく見られる特徴です。

反パターンをまとめた一覧については、AIスロップの検出を参照してください。

---

実装の原則

実装の複雑さは、美的なビジョンに合わせてください。ガラス調、ソフト UI、クレイ、3D、その他のカスタムサーフェスを用いた表現は、CSS の複雑さ、状態設計の作業、アクセシビリティ上のリスク、パフォーマンス調整のコストを増大させます。控えめな方向性であっても、必要なのは労力を減らすことではなく、精度を高めることです。

創造的に解釈し、その文脈に合わせて本当に設計されたと感じられる、意外性のある選択をしてください。同じデザインを繰り返してはいけません。明るいテーマと暗いテーマ、さまざまなフォントや美的表現を使い分けてください。生成を重ねても、よくある選択肢に決して収束しないようにしてください。

実装時には、次の品質チェックを忘れないでください。

• 主要な要素、二次的な要素、三次的な要素を、2 秒以内に見分けられますか？
• 余白、タイポグラフィ、色、角丸、エレベーションの決定は、場当たり的な調整ではなく、システムに基づいていますか？
• フォント、色、角丸、言葉遣いから個性が伝わりますか？
• 一時的に色を取り除いても、デザインは魅力的なままですか？

GPT は並外れた創造性を発揮できます。既成概念にとらわれず、独自のビジョンを貫いたときに生み出せるものを示すために、力を惜しまないでください。