adapt

既存のデザインを、さまざまなコンテキスト（画面サイズ、デバイス、プラットフォーム、ユースケース）で効果的に機能するよう適応させます。

必須の準備

ユーザーは /adapt でこのワークフローを開始します。このスキルが有効になったら、$frontend-design を読み込んでください。デザインの原則、避けるべきパターン、コンテキスト収集プロトコルが含まれています。先に進む前に、このプロトコルに従ってください。デザインコンテキストがまだない場合は、必ず先に $setup を読み込んでください。さらに、対象となるプラットフォーム／デバイスと使用コンテキストも収集してください。

狭い画面を優先した適応、流動的な挙動、コンテナークエリーの方針については、レスポンシブデザインのリファレンスを参照してください。 適応の問題が実際にはグループ化、リズム、幅の規律に関するものなら、スペーシングシステムを参照してください。 小さい画面や制約のあるコンテキストで、一度に表示される選択肢が多すぎる問題が顕在化する場合は、認知負荷を参照してください。

---

適応の課題を評価する

何を、なぜ適応させる必要があるのかを把握します。

1. 元のコンテキストを特定する：

   • もともと何向けに設計されていましたか？（幅の広いウェブレイアウト？コンパクトなレスポンシブウェブ？）
   • どのような前提がありましたか？（大画面？マウス入力？高速な接続？）
   • 現在のコンテキストでうまく機能している点は何ですか？

2. 対象のコンテキストを把握する：

   • ビューポート／コンテキスト：狭い画面、中程度の画面、広い画面、テレビ、組み込み、印刷？
   • 入力方法：タッチ、マウス、キーボード、音声、ゲームパッド？
   • 画面の制約：サイズ、解像度、向き？
   • 接続環境：高速な Wi-Fi、低速な 3G、オフライン？
   • 使用コンテキスト：外出先かデスクか、ざっと確認するのか集中して読むのか？
   • ユーザーの期待：このプラットフォームで、ユーザーは何を期待していますか？

3. 適応の課題を特定する：

   • 何が収まりませんか？（コンテンツ、ナビゲーション、機能）
   • 何が機能しませんか？（タッチ画面でのホバー状態、小さすぎるタッチターゲット）
   • 何が不適切ですか？（狭いレイアウトでの幅広レイアウト向けパターン、粗いポインターのコンテキストでのホバーだけに依存するパターン）

重要：適応とは、単に拡大縮小することではありません。新しいコンテキストに合わせて体験を再考することです。

小さい画面は、洗濯機で縮んだデスクトップレイアウトではなく、実際の制約として扱ってください。

適応方針を計画する

コンテキストに適した方針を立てます。

基本原則

• まずキャンバスを縮める：小さい方の制約から始め、そこで中核となるタスクを解決します
• 狭いレイアウトは独立したレイアウトとして設計する：幅広レイアウトの関係性をそのまま比例して圧縮するだけにしないでください
• 自然な幅を保つ：幅をパーセンテージに過度に依存せず、max-width とコンテンツに適した幅を使います
• 大きな要素ほど小さな要素より速く縮める：ブレークポイントをまたぐと、要素間の関係性は変わります

狭いレイアウトへの適応（幅広 → コンパクト）

レイアウト方針：

• 複数列ではなく単一列にする
• 横並びではなく縦に積み重ねる
• コンポーネントは実際に必要な幅を使います。全幅は有用な場合に使い、反射的に適用しないでください
• 常時表示される上部またはサイド構造を前提とせず、コンパクトなナビゲーションにする

インタラクション方針：

• タッチターゲットは最小 44x44px とし、ホバーに依存させない
• 適切な場合は、見つけやすいジェスチャー操作に対応する
• スペースが限られている場合は、窮屈なドロップダウンではなく、端に付く、または固定されるオーバーレイを使う
• コンパクトなタッチ対応レイアウトでは、繰り返し使う操作を手の届く範囲に配置する
• ヒット領域を広げ、間隔も大きくする

コンテンツ方針：

• 段階的開示を取り入れる（一度にすべてを表示しない）
• 主要なコンテンツを優先する（二次的なコンテンツはタブやアコーディオンにする）
• テキストを短くする（より簡潔にする）
• テキストを大きくする（最小 16px）

ナビゲーション方針：

• ドロワー、アコーディオン、折りたたみメニューなど、明確でコンパクトなナビゲーションの入口を用意する
• ナビゲーションの複雑さを軽減する
• コンテキストを保つため、ヘッダーを固定する
• ナビゲーションの流れに戻るボタンを設ける

中程度の幅への適応

レイアウト戦略:

• 2 カラムレイアウト（1 カラムや 3 カラムにはしません）
• 補助コンテンツ用のサイドパネル
• マスター詳細ビュー（リスト＋詳細）
• 画面の向き（縦向きと横向き）に応じて適応

操作戦略:

• タッチとポインターの両方に対応
• 最も狭いビューポートよりも高密度なレイアウトにしつつ、十分なターゲットサイズを維持
• サイドナビゲーションドロワー
• 適切な場合は複数カラムのフォーム

広いレイアウトへの拡張

レイアウト戦略:

• マルチカラムレイアウト（横方向のスペースを活用）
• サイドナビゲーションを常に表示
• 複数の情報パネルを同時に表示
• 最大幅の制約を設けた固定幅（4K 幅まで引き伸ばさない）
• フォームや本文の幅を広げすぎるのではなく、カラムを使って幅の狭いコンテンツのバランスを調整

操作戦略:

• 追加情報を表示するホバー状態
• キーボードショートカット
• 右クリックのコンテキストメニュー
• 便利な場合はドラッグ＆ドロップ
• Shift/Cmd を使った複数選択

コンテンツ戦略:

• より多くの情報を最初から表示（段階的開示を減らす）
• 多数のカラムを含むデータテーブル
• より充実した視覚化
• より詳細な説明

印刷への適応（画面 → 印刷）

レイアウト戦略:

• 論理的な箇所で改ページ
• ナビゲーション、フッター、インタラクティブ要素を削除
• 白黒（または限られた色）
• 製本に適した余白

コンテンツ戦略:

• 短縮されたコンテンツを展開（URL 全体や非表示のセクションを表示）
• ページ番号、ヘッダー、フッターを追加
• メタデータ（印刷日、ページタイトル）を含める
• グラフを印刷に適した形式に変換

メールへの適応（ウェブ → メール）

レイアウト戦略:

• 幅を狭くする（最大 600px）
• 1 カラムのみ
• インライン CSS（外部スタイルシートは使用しない）
• テーブルベースのレイアウト（メールクライアントとの互換性のため）

操作戦略:

• 大きく目立つ CTA（テキストリンクではなくボタン）
• ホバー状態を使わない（確実に機能しないため）
• 複雑な操作はウェブアプリへのディープリンクを使用

適応を実装する

変更を体系的に適用します。

レスポンシブブレークポイント

適切なブレークポイントを選びます。

• 狭い幅：320px-767px
• 中程度の幅：768px-1023px
• 広い幅：1024px 以上
• またはコンテンツに応じたブレークポイント（デザインが崩れる位置）

レイアウト適応の手法

• CSS Grid/Flexbox：レイアウトを自動的に再配置
• コンテナークエリ：ビューポートではなくコンテナーに応じて適応
• clamp()：最小値と最大値の間でサイズを流動的に変更
• メディアクエリ：コンテキストごとに異なるスタイルを適用
• Display プロパティ：コンテキストに応じて要素を表示／非表示
• 最大幅：ビューポートの変化を強いられるまでは、フォーム、テキストブロック、サイドバーを自然な幅に保つ

タッチへの適応

• タッチターゲットのサイズを大きくする（最小 44x44px）
• インタラクティブ要素の間隔を広げる
• ホバーに依存する操作を取り除く
• タッチフィードバックを追加（波紋、ハイライト）
• 親指が届く範囲を考慮する（上部より下部のほうが操作しやすい）

コンテンツへの適応

• display: none の使用は控えめにする（それでもダウンロードされます）
• プログレッシブエンハンスメント（コアコンテンツを先に表示し、大きな画面では機能を拡張）
• 画面外のコンテンツには遅延読み込みを使用
• レスポンシブ画像（srcset、picture 要素）

ナビゲーションの適応

• 狭いレイアウトでは、複雑なナビゲーションをコンパクトなメニュー、ドロワー、またはアコーディオン構造に変換します
• デスクトップではサイドナビゲーションを固定表示します
• 幅の狭いレイアウトでは、パンくずリストや簡潔なコンテキスト表示を使います

重要：ブラウザーの DevTools だけでなく、実機でテストしてください。デバイスのエミュレーションは便利ですが、完全ではありません。

絶対にしないでください：

• 狭いレイアウトでコア機能を隠す（重要な機能なら、動作するようにしてください）
• デスクトップなら高性能なデバイスだと思い込む（アクセシビリティや旧式のマシンも考慮してください）
• コンテキストごとに異なる情報アーキテクチャを使う（混乱を招きます）
• その入力コンテキストにおけるレスポンシブなウェブ動作へのユーザーの期待を損なう
• 狭い画面の横向き表示や中程度の幅のウィンドウ状態を忘れる
• 汎用的なブレークポイントを考えずに使う（コンテンツに基づいたブレークポイントを使ってください）
• デスクトップでのタッチ操作を無視する（タッチ対応のデスクトップデバイスは多くあります）
• デスクトップでの要素間の関係を比例縮小し、それをレスポンシブデザインと呼ぶ
• 拡大縮小しても実際にはメリットがないコンポーネントを流動的にする

適応を検証する

さまざまなコンテキストで十分にテストしてください。

• 実機：実際のタッチ対応ブラウザー、ノートパソコン／デスクトップ、および該当する場合はリソースに制約のあるハードウェアでテストします
• 異なる向き：縦向きと横向き
• 異なるブラウザー：Safari、Chrome、Firefox、Edge
• 異なる OS：Windows、macOS、Linux、ChromeOS、および該当する場合はタッチ対応ブラウザー環境
• 異なる入力方法：タッチ、マウス、キーボード
• エッジケース：非常に小さな画面（320px）、非常に大きな画面（4K）
• 低速な接続：ネットワークを低速に制限してテストします

忘れないでください。あなたはレスポンシブウェブデザインの専門家です。ブランドと機能の一貫性を保ちながら、それぞれのウェブコンテキストに適した使い心地を実現してください。意図を持って適応させ、十分にテストしてください。