web-taste

Web Taste

テイストはピクセル単位から始まるものではありません。「これは誰で、何を必要としているのか？」から始まります。ビジュアルを洗練させるのは最後のステップです。最初のステップは、ユーザーの世界を深く理解し、インターフェースのデザインが必然に感じられるようにすることです。ほかの方法では設計できなかったと思えるようなデザインにします。

デフォルトの進め方では、レイアウトに直行します。その結果、技術的には正しいものの、実在する人のニーズに根差していないため、ありきたりな見た目の React ができあがります。カードの積み重ね、サイドバー、設定リストなどです。このスキルでは、作業の順序を変えます。まずデザイナーのように考え、それからコードを書きます。

フェーズ 0：0.5 秒テスト（何よりも先に方向性を定める）

何かをデザインする前に、次の質問に一つだけ答えてください。

ユーザーは最初の 0.5 秒で、ひとつも言葉を読む前に何を目にするでしょうか？

これはコンテンツの話ではありません。画面の形の話です。目を閉じて、画面を思い浮かべてください。何が目を引きますか？

• スパークラインを添えた単一のヒーロー数値？ → 分析／指標ダッシュボード
• 太字の白いテキストが載ったグラデーションカード？ → ステータス／請求／ヒーローページ
• スティッキーな画面上部の要素と検索バーを備えたテーブル？ → データコンソール／管理画面
• メディアカードのグリッド？ → ライブラリ／ギャラリー／コンテンツコレクション
• 十分な余白をとった中央揃えのフォーム？ → 登録／認証／単一アクション
• 一覧と詳細の 2 ペイン表示？ → メール／受信トレイ／CRM
• イベントのタイムライン？ → アクティビティフィード／監査ログ

答えが「サイドバーと、コンテンツ領域にいくつかのカード」なら、 そこで止まってください。それは CMS のテーマであり、プロダクトではありません。戻って、このユーザーが本当に必要としているものに合った視覚的な形を見つけてください。

0.5 秒で見えるものを、体験設計ブリーフの最初の行として、ルート上の JSDoc コメントに記述してください。

// 0.5s: One huge revenue number on black, sparkline pulsing below
export default async function DashboardPage() { ... }

この一文が、その後のすべての判断の軸になります。書いたコードがその形を実現していなければ、何かが間違っています。

フェーズ 1：デザイン思考（React に触れる前に）

JSX を 1 行でも書く前に、次の質問に答えてください。答えをコメントとして書くか、自分の考えとしてまとめてください。このフェーズを省くと、出力はほかの AI 生成 UI と同じようなものになります。正しくても、魂のないものです。

1. ユーザーは誰ですか？

「SaaS の管理者」ではなく、具体的な状況にいる実在の人です。

• このページを開いたとき、どんな状況にいますか？（朝のアラートを確認している？ 会議中にリンクを共有している？ 役員会議の前に四半期を振り返っている？）
• ここにたどり着く直前に何をしていましたか？（通知メールをクリックした？ 検索した？ Slack のディープリンクをたどった？）
• 10 秒以内に何を達成したいですか？

この点がすべてを形作ります。Slack のディープリンクからページにたどり着いたユーザーには、状況をすぐに把握できる大きな見出しが必要です。一日中ページを開いているユーザーには、控えめな UI と広い作業スペースが適しています。デモ中に評価しているユーザーには、スクロールせずに価値提案が見える必要があります。

2. ユーザーにどんな気持ちになってほしいですか？

この問いが、デザインされたプロダクトと CRUD の管理パネルを分けます。Linear はカンバンを見せるのではなく、プロダクトのリリースに夢中になる感覚を生み出します。Stripe は決済フォームを見せるのではなく、コマースが解決済みの課題だと感じさせます。デザインの選択はすべて、その感情的な目標に役立ちます。

コンポーネントを選ぶ前に、意図する感情を決めてください。

• 集中／生産的 → 落ち着いた色調、モノクロの UI、アクセントカラーは 1 色、ゆとりのあるスペース、Inter または system-ui sans
• 自信／信頼感 → 深みのある青や緑、分かりやすいデータ表示、十分な余白、古典的なプロポーション
• 喜び／プレミアム感 → 意外性のあるマイクロインタラクション、豊かなグラデーション、控えめな 3D、吟味されたタイポグラフィ（Söhne、Inter Display）
• 活気／大胆さ → 彩度の高い色、大きなディスプレイ書体、非対称なレイアウト、印象的な写真
• 落ち着き／エディトリアル → セリフ体のタイポグラフィ、幅の狭いテキストカラム、十分な余白、抑制された色使い

意図する感情が、その後のあらゆるビジュアル上の判断を左右します。カラートークン、スケール、間隔、データを一覧表示するか視覚化するか、ページを密度の高い印象にするか、広々とした印象にするか、といった判断です。

3. ユーザーの目標とペインポイントは何ですか？

ページごとに、次の点を特定します。

• 主な目標 — ほとんどのユーザーがそのページで達成したい、最も重要なこと
• 副次的な目標 — 一部のユーザーがときどき必要とすること
• ペインポイント — この領域でユーザーが不満に感じること

請求ページでの主な目標は、「請求情報をすべて確認する」ことではありません。「期限切れになった支払い方法を変更する」または「経費精算用に先月の請求書をダウンロードする」ことです。ペインポイントは、必要な操作を見つけるためにプランの概要や機能の比較を延々と読み進めなければならないことです。

4. 目標を達成するために、どの機能が必要ですか？

目標と機能を結びつけます。「このページにどんな機能を追加できるか」ではなく、「主な目標を手間なく達成するために必要な最小限の機能は何か」を考えます。目標に役立たない機能はすべて、余計な要素です。

機能を優先度ごとに分類します。

• 必須 — これがないと主な目標を達成できない
• あるとよい — エクスペリエンスが大幅に向上する
• あってもよい — あると便利だが、なくてもユーザーは困らない

5. 機能をどのようにルートに割り当てますか？

これは情報アーキテクチャです。App Router のどこに何を配置するかを決めます。

• 1 つのルートにつき主なアクションは 1 つ。 1 つのページで 2 つのことをしようとする場合は、2 つのルートに分けるか、副次的なタスクにはシートやダイアログを使います。
• データの種類ではなく、ユーザーの意図ごとにグループ化する。 ユーザーは「通知設定を見たい」とは考えません。「集中して作業している間、Slack の通知を止めたい」と考えます。機能は技術的な分類ではなく、解決する問題ごとにまとめます。
• ナビゲーションはユーザーのメンタルモデルに沿わせる。 /settings → /settings/billing は直感的です。一方、/admin/organizations/{org}/members/{member}/preferences/notifications は、一度設定すれば済む項目にたどり着くまでに 6 階層もあります。完全な画面遷移が過剰な場合は、並列ルート（@modal）とインターセプトルートを使い、「オーバーレイとして開く」パターンを実現します。

6. 各機能にはどのコンポーネントが適していますか？

ここで初めて React について考えます。ただし、ユーザーの意図を軸に考えます。

• Server Component と Client Component — デフォルトでは RSC を使います。インタラクティブ性が必要な場合にのみ 'use client' を使います。必要のないリストのためにハイドレーション境界を追加してはいけません。
• Dialog、Popover、Sheet、フルページ — ux-modality を参照してください。要件を満たす中で最も軽量なコンテナーを選びます。
• フォームと個別フィールド — データを変更する処理には、Server Actions と <form action={}> を使います。設定をリアルタイムに保存する場合は、useOptimistic を使った単独のフィールドを使用します。
• テーブル、カードグリッド、リスト — 列を見比べることが目的なら、テーブルを使います（並べ替え、フィルタリング、値の比較に対応）。さまざまな項目を閲覧するなら、カードグリッドを使います。同種の行が並び、各行に主な識別子が 1 つある場合は、リストを使います。
• shadcn/ui とカスタム実装 — デフォルトでは shadcn/ui の Radix ベースのプリミティブを使います。適合するプリミティブがない場合にのみ、カスタムコンポーネントを使います。

コンポーネントの選択がデザインそのものです。金融ダッシュボードに固定ヘッダー付きの <DataTable> を使うと、正確で事務的な印象になります。同じデータにグラデーションのカードグリッドを使うと、探索的で編集的な印象になります。どちらも間違いではありません。適切な選択は、ユーザーが誰で、どのような状況にいるかによって決まります。

フェーズ 2：ビジュアルデザイン

フェーズ 1 を終えると、ユーザーが誰で、何を必要とし、どのように感じるべきか、そしてそのニーズに応えるコンポーネントが何かが分かります。次は、それを美しく仕上げます。フェーズ 1 で定めた感情的な意図が、ここでのあらゆる選択の指針になります。

1. スケールによる階層

フォントの太さだけではなく、スケールに大きな差をつけます。画面上で最も重要なものは、太字にするだけでなく、物理的に大きく表示します。

• ディスプレイサイズのヒーロー数値 — 売上高、件数、割合はページの中でひときわ目立たせます。text-6xl または text-7xl と font-semibold tracking-tight tabular-nums を使います。Linear の速度チャートでは、64〜72 px のディスプレイサイズの数値が使われています。重要なデータを text-sm の行に押し込まないでください。
• 補足テキストは控えめに — ヒーロー要素以外はすべて、text-muted-foreground の text-sm または text-xs にします。ヒーローと補足のコントラストこそが、階層を生み出します。
• 余白を贅沢に使う — 空白を残します。背景の広がりの中に浮かぶ数値は、同じ数値を密度の高い DataTable に詰め込むよりも印象的です。余白は重要性を伝えます。

// Hero metric — scale dominates, whisper labels
<section className="p-8">
  <p className="text-sm text-muted-foreground">Net revenue · last 30 days</p>
  <p className="mt-2 text-7xl font-semibold tracking-tight tabular-nums">
    ${(revenue / 100).toLocaleString()}
  </p>
  <p className="mt-2 flex items-center gap-1 text-sm text-emerald-600">
    <ArrowUpRight className="size-4" aria-hidden="true" />
    +12.4% vs prior period
  </p>
</section>

2. 色は感覚ではなく数学

色を手作業で選んではいけません。色の調和は、数学的に解決された問題です。このスキルには、単一のシード色相からすべての色を計算するパレットジェネレーターが含まれています。類似色相による調和、WCAG 準拠のコントラスト検証、CSS カスタムプロパティと Tailwind 設定スニペットとして出力されるライトモードとダークモードのバリエーションに対応しています。

ビューのコードを書く前に、パレットジェネレーターを実行してください：

python scripts/generate_palette.py \
  --seed <hue-degrees> \
  --mode both \
  --items <collection-count> \
  --app "App Name"

シード色相の目安：

• 0〜30° = 暖色系（クリエイティブ、ソーシャル、デーティング、食品）
• 30〜60° = ゴールデン系（金融、生産性、メール）
• 60〜150° = グリーン系（健康、フィットネス、サステナビリティ）
• 150〜210° = シアン／ティール系（開発者ツール、インフラ、クラウド）
• 210〜270° = ブルー系（信頼、フィンテック、エンタープライズ SaaS）
• 270〜330° = パープル系（クリエイティブ、AI、プレミアム）
• 330〜360° = ピンク／レッド系（エネルギー、ゲーム、eコマース）

生成された :root と .dark の CSS カスタムプロパティを app/globals.css に貼り付け、Tailwind ユーティリティ（bg-primary、text-muted-foreground、border-border）を使って、それらのトークンだけを使用してください。パレットは計算済みです。すべての色はシード色相と数学的に関連付けられ、コントラスト比は事前に検証され、ライトモードとダークモードのバリエーションも含まれています。

必ず守るルール：

• アプリごとにシード色相は1つ。 すべての色はそこから導きます。
• **コレクションには類似色相のバリエーション（--items フラグ）を使用し、**ランダムな色相は使いません。シード色相から±30°の範囲にあるため、調和します。
• bg-blue-500、text-red-600、border-gray-200 のような Tailwind の標準パレットクラスは使わないでください。 テーマに対応せず、コントラストも監査されていません。セマンティックトークンを使います。
• bg-background、text-foreground、border-border、text-primary を使ってください。 Color(...) のような場当たり的な呼び出しや、コンポーネントのコード全体に散らばった任意のクラスは使わないでください。

3. データは並べるのではなく、見せる

データがコンテンツそのものである場合（分析、財務統計、進捗）は、LabeledRow に入れるのではなく、可視化してください：

• スパークラインとエリアチャート：時間経過に伴う傾向（Recharts、Tremor、または手書きの SVG）
• ゲージとリング：目標に対する進捗
• 大きなヒーロー数値：増減を示す矢印と割合チップを添える
• ヒートマップ：時間帯別または曜日別のアクティビティ
• 色分けしたバー：構成（収益の源泉別内訳、時間配分）

<dl><dt>Revenue</dt><dd>$8,432</dd></dl> は情報です。スパークラインを下に添えた text-6xl tabular-nums の大きな「$8,432」は、体験です。どちらを使うべきかは、フェーズ1で定めた感情的な意図から判断します。

4. カードベースの構成

すべてを1つの枠線付きコンテナーに入れるのを、既定にしないでください。コンテンツに多様性がある場合は、rounded-xl border bg-card のコンテナーを組み合わせます：

• rounded-xl border bg-card text-card-foreground p-6 を指定したカード
• 各カードは、独自の階層を持つ独立した視覚単位です
• 視覚的な豊かさを加えるため、カードにグラデーション背景を使用できます（Vercel のデプロイカードや Linear のサイクルカードをイメージしてください）
• CSS グリッドで auto-rows-fr を使い、高さのそろったカードグリッドを作成します

テーブルは、均質で一覧性が求められるデータに適しています。カードは、各項目が独自のストーリーを持つダッシュボード、概要、情報量の多いページに適しています。

5. コンテンツのリアリティ

データこそがデザインです。すべてのプレビューが一貫したストーリーを伝えます。

• 実在感のある名前（「Elena Marsh」）、もっともらしい数値（「$47.83」、「4.3K」）、 長さに変化をつけ、時間表現にもリアリティを持たせます（「2時間前」、「昨日」）
• 意味の通るデータの関連性（デザイナー → デザイン部門）
• プレビューのデータが不自然（"Item 1"、"Lorem ipsum"、 [email protected]）なら、デザインも不自然に見えます

フィクスチャであっても、一貫したストーリーのあるシードデータを生成してください。

6. 控えめにする

何を省くかが、センスを決めます。説明用の見出し（「ダッシュボードへようこそ」）は不要です。すべての行に同じアイコンを飾る必要もありません。チュートリアルのオーバーレイも不要です。デモらしい命名も避けます。要素ごとに「これを取り除いたらどうなるか？」と考えてください。何も変わらないなら、取り除きます。

7. 細部へのこだわり

目立たなくても、しっくりくる細部です。

• 数値が変化しても桁がずれないよう、変化する数値には tabular-nums を指定します
• ディスプレイ見出しには tracking-tight を指定します
• すべてのインタラクティブ要素に transition-colors duration-150 を指定します
• すべてのボタンに hover: + focus-visible: + active: の状態を設定します
• 変形には motion-safe: を指定します（acc-reduce-motion を参照）
• overflow hidden + 省略記号の JS ではなく、truncate + line-clamp-N を使います
• 数値が変化する場所にはすべて font-variant-numeric: tabular-nums を指定します
• アクセシビリティはコンプライアンスではなくデザインです（web-rules を参照）

8. 個性

各ページには独自の個性があります。個性は次の要素から生まれます。

• ドメインに合ったカラーパレット（フィンテックならクールな青、工芸なら温かみのある黄土色、サステナビリティなら鮮やかな緑）
• コンテンツに合ったタイポグラフィの組み合わせ（セリフ体の見出し + Inter の本文なら編集記事風、クローム部分にモノスペース体を使えば開発者向けの印象）
• ナビゲーションバーを隠してみてください。それでもどのアプリか分かりますか？

ナビゲーションバーを隠した状態でページを開いたユーザーは、どのアプリを使っているか分かるでしょうか？ Linear の個性は、シャープなクロームとサイクルの可視化にあります。Stripe の個性は、完璧に整列したデータテーブルと信頼感のある青のアクセントにあります。あなた自身の個性を見つけてください。

両方のフェーズを適用する

ルート、レイアウト、コンポーネントの構築を依頼されたとき：

1. フェーズ 1 — ユーザー、目標、機能のグループ分け、ルート構造、コンポーネントの選択について考えます。デザインの判断理由を示す簡潔なメモを（コードコメントまたは回答内に）記述します。これは省略できません。これが、デザインされた体験と装飾されたレイアウトを分けるものです。

2. フェーズ 2 — 8 つすべての基本原則を適用して、React/Next.js/Tailwind のコードを書きます。リアルなデータとシード用フィクスチャから始めます。最小限のものを作り、必要なものだけを加えてから、細部にまでこだわって仕上げます。

3. セルフチェック — 仕上げる前に、次のように問いかけます。「フェーズ 1 で想定した状況でこの製品を使う実際のユーザーは、このページが自分のためにデザインされたと感じるだろうか？」そうでなければ、フェーズ 1 に問題があります。戻って見直してください。

センスの有無 — 具体例

汎用的な AI 風ダッシュボードと Stripe に着想を得た収益ページの完全なコード（変更前と変更後）、および反射的な選択とセンスに基づく選択を対応付けた コンポーネントパレットのクイックリファレンス表については、references/code-examples.md をお読みください。

違いを簡潔に説明すると、「センスのない」ページはレイアウトにいきなり取りかかります。説明用の見出し、番号付きのプレースホルダー、ハードコードされた text-gray-* と bg-blue-*、汎用的なコンポーネント名が使われます。「センスのある」ページは、ユーザーと感情的な意図を示すデザインコメントから始まり、最も重要な数値を tabular-nums を使ってヒーローサイズで表示し、セマンティックトークン（text-muted-foreground、bg-card）を使います。スパークラインはヒーローと競合せず、それを引き立てます。

参考にするとよいアプリ：Linear、Stripe、Vercel、Notion、そして細部まで作り込まれたコンシューマーアプリ（Cash App、Things、Arc）。どのアプリも、クローム、タイポグラフィ、データの見せ方に対する意図的な選択によって、独自の個性を生み出しています。

画面そのものがコンテンツになる

Linear の課題詳細画面を見てみましょう。このページは、課題「について」のフォームではありません。画面全体が課題そのものです。タイトルはヒーローサイズのページ見出しで、説明は本文そのものです。アクションは、徐々に消えていくクロームに配置されています。「課題を編集」するためのページはなく、その場で編集できます。

これは、最も高度なセンスの表れです。UI がコンテンツに溶け込みます。ページがデータを囲むのではなく、ページそのものがデータになります。

そのための手法：

• その場で編集 — タイトルと本文に contenteditable を使い、ページそのものをエディターにします。Server Action を使ってフォーカスが外れたときに保存します。
• クロームはモノスペース、コンテンツはサンセリフ — 本文の読みやすさを損なわずに、開発者ツールに独自の個性を与えます。
• リストでのスマートなタイポグラフィ — Linear は課題 ID の接頭辞を太字にし、タイトルは通常のウェイトにしています。この小さな工夫で、識別子を探す速さが大幅に向上します。あなたの領域に合った同様のタイポグラフィ階層を見つけましょう。
• 詳細画面は閲覧モードのように見せる — 編集可能なプロダクトでも、詳細画面にフォーム UI は表示しません。同じコンテンツを美しく読めて、その場で編集できます。

参考：Web デザインの DNA

具体的なデザインを決める際は、このスキルのディレクトリにある references/web-design-dna.md を読んでください。Linear、Stripe、Vercel、Notion、そして細部まで丁寧に作り込まれたコンシューマーアプリ（Cash App、Things、Arc）を体系的に調査し、パターンをまとめています。実際のコンポーネント、実際の寸法、実際のデザイン分析を確認できます。

参照する主なセクション：

• Web アプリデザインの 3 つのモード — ダッシュボード（データ中心、ダークなクローム）、ユーティリティ（CRUD 中心、明るいサーフェス）、エディトリアル（コンテンツ優先、表現豊かなタイポグラフィ）
• 汎用的な寸法 — カードの角丸（12-16 px）、ヘッダーの高さ（56-64 px）、コンテンツの最大幅（1024-1280 px）
• オンボーディングのテンプレート — 機能一覧とヒーローイラストのパターン
• ボタンの階層 — 塗りつぶしのプライマリ、アウトラインのセカンダリ、ゴーストのターシャリ。破壊的な操作は色だけでなく配置によって分離します
• 詳細ページがコンテンツになる — Linear / Notion の手法
• 空の状態 — 「データがありません」というメッセージではなく、構造を示します

マインドセット

デザインもできる開発者ではありません。人々のことを第一に考え、その成果を React、Next.js、Tailwind で表現するデザイナーです。コードは表現の手段です。プロダクトとは、人がブラウザーを開いたときに、そのインターフェースが自分のために作られたように感じられる瞬間です。