Nothing風UI/UXデザインシステム
スイス・タイポグラフィ、インダストリアルデザイン（ブラウン、ティーンエンジニアリング）、そしてモダンなインターフェース技術に精通したシニアプロダクトデザイナーのツールキット。モノクローム、タイポグラフィ主導、情報量が多くても雑然としない。ダークモードとライトモードの両方を厳格に設計。
デザイン作業を開始する前に、必要なGoogle Fontsとその読み込み方法を宣言すること（references/tokens.md セクション1参照）。フォントがすでに利用可能であると想定してはいけません。
1. デザイン哲学
- 足すのではなく、引くこと。 すべての要素は、そのピクセルの価値を証明しなければならない。デフォルトは削除。
- 構造そのものが装飾である。 グリッド、データ、階層そのものを露出させる。
- モノクロームがキャンバスである。 色はイベントであり、デフォルトではない — ただし、データステータスをエンコードする場合を除く（セクション3参照）。
- タイポグラフィが重責を担う。 スケール、ウェイト、スペーシングが階層を生み出す — 色ではなく、アイコンでもなく、境界線でもない。
- 両モードは第一級である。 ダークモード：有機ELブラック。ライトモード：暖かみのあるオフホワイト。どちらも「派生」ではない — 両方に完全なデザイン的注意を払う。どのモードから始めるかユーザーに尋ねること。
- 工業的な温もり。 技術的で正確だが、決して冷たくならない。人間の手の温もりが感じられること。
2. クラフトルール — 構成方法
2.1 視覚的階層：3層ルール
すべての画面は、正確に3つの重要度の層を持つ。2つでも5つでもない。3つである。
| 層 | 内容 | 方法 |
|---|---|---|
| プライマリ | ユーザーが最初に目にする「たった一つのもの」。数字、見出し、状態。 | DotoまたはSpace Groteskをディスプレイサイズで。--text-display。48～96pxの余白。 |
| セカンダリ | 補足的なコンテキスト。ラベル、説明、関連データ。 | Space Groteskを本文/小見出しで。--text-primary。プライマリに密接にグループ化（8～16px）。 |
| ターシャリ | メタデータ、ナビゲーション、システム情報。表示はされるが、決して競合しない。 | Space Monoをキャプション/ラベルで。--text-secondaryまたは--text-disabled。すべて大文字。端または下部に押しやる。 |
テスト方法： 画面を細めて見る。最も重要なものがまだわかるか？もし2つの要素が競合しているなら、一方を縮小、減色、または移動させる必要がある。
よくある間違い： すべてを「セカンダリ」にしてしまうこと。均等なサイズの要素と均等なスペーシング = 視覚的な平坦さ。勇気を持って — プライマリを途方もなく大きく、ターシャリを途方もなく小さくせよ。そのコントラストこそが階層である。
2.2 フォント規律
画面ごとに、以下を最大で使用する：
- 2つのフォントファミリー（Space Grotesk + Space Mono。Dotoはヒーロー的な瞬間のみ。）
- 3つのフォントサイズ（大1、中1、小1）
- 2つのフォントウェイト（レギュラー + あと1つ — 通常はLightまたはMedium、稀にBold）
予算だと考えよ。サイズやウェイトを追加するたびに、視覚的な一貫性が失われる。新しいサイズを追加する前に、代わりにスペーシングや色でこの区別を作れないか自問せよ。
| 決定 | サイズ | ウェイト | 色 |
|---|---|---|---|
| 見出し vs. 本文 | はい | いいえ | いいえ |
| ラベル vs. 値 | いいえ | いいえ | はい |
| アクティブ vs. 非アクティブなナビ | いいえ | いいえ | はい |
| ヒーロー数字 vs. 単位 | はい | いいえ | いいえ |
| セクションタイトル vs. 内容 | はい | 任意 | いいえ |
経験則： 新しいフォントサイズに手を伸ばそうとしているなら、それはおそらくスペーシングの問題である。代わりに距離を追加せよ。
2.3 意味としてのスペーシング
スペーシングは、関係性を伝えるための主要なツールである。
狭い（4～8px） = 「これらは一緒に属する」（アイコン + ラベル、数字 + 単位）
中程度（16px） = 「同じグループ、異なるアイテム」（リストアイテム、フォームフィールド）
広い（32～48px） = 「ここから新しいグループ」（セクション区切り）
非常に広い（64～96px） = 「これは新しいコンテキスト」（ヒーローからコンテンツ、主要な分割）
もし区切り線が必要なら、おそらくスペーシングが間違っている。 区切り線は、スペーシングのコントラストが不十分であることの症状である。アイテムが構造的に同一であるデータ密度の高いリストでのみ使用せよ。
2.4 コンテナ戦略（上部を優先）
- スペーシングのみ（近接性でアイテムをグループ化）
- 単一の区切り線
- 微妙な境界線の輪郭
- 背景が変化したサーフェスカード
各ステップで視覚的な重みが増す。機能する最も軽いツールを使用せよ。最も重要な要素を決して囲まない — 背景の上に浮かせておけ。
2.5 階層としての色
モノクロームシステムでは、グレースケールが階層そのものである。画面ごとに最大4レベル：
--text-display (100%) → ヒーロー数字。画面に1つ。
--text-primary (90%) → 本文、主要コンテンツ。
--text-secondary (60%) → ラベル、キャプション、メタデータ。
--text-disabled (40%) → 無効、タイムスタンプ、ヒント。
赤（#D71921）は階層の一部ではない。 割り込みである — 「ほら、今、ココを見ろ」という意味。緊急のものがないなら、画面上に赤はない。
データステータス色（成功の緑、警告の琥珀、アクセントの赤）は、データ値をエンコードする場合、「ワンアクセント」ルールの例外とする。色は値そのものに適用し、ラベルや行の背景には適用しない。完全なカラーシステムについてはreferences/tokens.mdを参照のこと。
2.6 一貫性 vs. バリエーション
一貫させるもの： フォントファミリー、ラベルの扱い（常にSpace Mono、すべて大文字）、スペーシングのリズム、色の役割、コンポーネントの形状、配置。
パターンを正確に1か所だけ破ること： 特大の数字、長方形の中の円形ウィジェット、グレーの中の赤いアクセント、Dotoの見出し、他のすべてがタイトな中での広大なギャップ。
この唯一の破綻こそがデザインである。それがない場合：無菌的なグリッド。2つ以上ある場合：視覚的な混沌。
2.7 構図のバランス
非対称 > 対称。 中央揃えのレイアウトは平凡に感じられる。意図的に不均衡な構図を好め：
- 左大、右小： ヒーローメトリック + メタデータスタック。
- 上部重視： 上部に大きな見出し、下部にまばらなコンテンツ。
- 端に固定： 重要な要素を画面端に固定、中央にネガティブスペース。
重い要素は、より多くの重い要素ではなく、より多くの空きスペースでバランスをとれ。
2.8 Nothingの雰囲気
- 空虚さによる自信。 広く途切れのない背景領域。スペースを埋めようとする衝動に抵抗せよ。
- 細部の正確さ。 文字間隔、正確なグレー値、4pxのギャップ。マイクロな決定が熟練の技へと積み重なる。
- データとしての美しさ。 48pxのSpace Monoで表示された
36GB/sがビジュアルそのものである。イラストは不要。 - 機械的な正直さ。 コントロールはコントロールのように見える。トグル = 物理スイッチ。ゲージ = 計器。
- ひとつの驚きの瞬間。 ドットマトリックス見出し。円形ウィジェット。赤い点。抑制が、唯一の表現の瞬間を力強くする。
- 打楽器的で、流動的ではない。 UIサウンドを想像せよ：スウッシュではなくクリック、チャイムではなくチック。機械的で正確に感じられるトランジションをデザインせよ。
2.9 データ密度の高い画面における視覚的バリエーション
1つの画面に3つ以上のデータセクションがある場合、視覚的な形式を変えること：
| 形式 | 最適な用途 | 重み |
|---|---|---|
| ヒーロー数字（大きなDoto/Space Mono） | 単一の主要指標 | 重い — 1回使用 |
| セグメント化されたプログレスバー | 目標に向けた進捗 | 中程度 |
| 同心円 / 弧 | 複数の関連するパーセンテージ | 中程度 |
| インラインコンパクトバー | 行内の二次的指標 | 軽い |
| 数字のみ + ステータス色 | 比率を伴わない値 | 最も軽い |
| スパークライン | 経時的な傾向 | 中程度 |
| 統計行（ラベル + 値） | 単純なデータポイント | 軽い |
先頭セクション → 最も重い処理。二次 → 異なる形式。三次 → 最も軽い。形式は変わるが、声は変わらない。
3. アンチパターン — 絶対に行わないこと
- UIフレームにグラデーションを使用しない
- 影、ぼかしは使用しない。フラットなサーフェス、境界線による分離。
- スケルトンローディング画面は使用しない。代わりに
[LOADING...]テキストまたはセグメント化されたスピナーを使用する。 - トーストポップアップは使用しない。インラインステータステキストを使用する：
[SAVED]、[ERROR: ...] - 悲しそうな顔のイラスト、かわいいマスコット、複数段落の空状態は使用しない
- テーブルにゼブラストライプを使用しない
- 塗りつぶしアイコン、マルチカラーアイコン、UIとしての絵文字は使用しない
- パララックス、スクロールジャッキング、または過剰なアニメーションは使用しない
- スプリング/バウンスのイージングは使用しない。微妙なイーズアウトのみ。
- カードのボーダー半径は16pxを超えないこと。ボタンはピル（999px）または技術的（4～8px）。
- データ可視化：色を導入する前に、不透明度（100%/60%/30%）またはパターン（実線/ストライプ/点線）で区別する。
4. ワークフロー
- フォントを宣言する — どのGoogle Fontsを読み込むかユーザーに伝える（
references/tokens.md参照） - モードを尋ねる — ダークかライトか？どちらもデフォルトではない。
- 階層をスケッチする — コードを書き始める前に3つの層を特定する
- 構成する — クラフトルール（セクション2.1～2.9）を適用する
- トークンを確認する — 正確な値については
references/tokens.mdを参照する - コンポーネントを構築する — パターンについては
references/components.mdを参照する - プラットフォームに適応させる — 出力規則については
references/platform-mapping.mdを参照する
5. リファレンスファイル
詳細なトークン値、コンポーネント仕様、プラットフォーム固有のガイダンスについては、以下を参照：
references/tokens.md— フォント、タイプスケール、カラーシステム（ダーク + ライト）、スペーシングスケール、グリッド、モーション、アイコン、ドットマトリックスモチーフreferences/components.md— カード、ボタン、入力、リスト、テーブル、ナビ、タグ、セグメントコントロール、プログレスバー、チャート、ウィジェット、オーバーレイ、状態パターンreferences/platform-mapping.md— HTML/CSS、SwiftUI、React/Tailwind、紙への出力規則