静的サイトを、制約ではなく土台にする。
見出し、本文、主要導線はHTMLとして生成します。APIやクライアント実行がなくても目的が伝わるため、検索、アクセシビリティ、直接アクセス、復旧の基準が一つになります。
METHOD / BUILD WITH CONSTRAINTS
表現を支えるのは、制約の設計。
リッチに見せる技法より先に、何を静的に残し、どこを動かし、何を検証してから配るかを決めます。
- 01
発想
誰の、どの迷いを減らすか。機能ではなく変化を一文にする。
- 02
構造
読む情報と操作する情報を分け、URLとデータの形を先に決める。
- 03
体験
操作前後で増える理解を定義し、代替経路も同時に描く。
- 04
実装
静的HTMLを基盤に、状態を持つ部分だけをIslandとして載せる。
- 05
検証
見た目、キーボード、no-JS、直接URL、配信物を同じ品質ゲートで確認する。
- 06
運用
追加手順と判断理由を残し、次の更新で設計を壊さない。
動きの担当範囲を決める。
状態変化、関係、フィードバックに限定します。背景の常時運動や読み始めを待たせる演出は、情報を増やさないため採用しません。
記事と実験を同じ問いで結ぶ。
実験には関連Note、Noteには関連Projectを持たせます。コンポーネントを共通化することではなく、判断データを次の企画へ渡すことが目的です。
distの先まで検証する。
build成功だけでは公開可能と見なしません。source、生成HTML、route、内部リンク、sitemap、OG、upload同期を順に確認し、本番反映は別の明示作業として切り離します。どこかがFAILなら、その版を公開せず、直前版へ戻す判断を記録します。
REUSABLE DECISIONS
工程を、次の設計パターンへ渡す。
品質工程の前後で何を設計するかは、30件のProjectから抽出したDesign Patternsで確認できます。個別の見た目ではなく、使う条件・避ける条件・検証項目を持ち帰るための索引です。要件の入口はGuides、自動・ブラウザ・人手の確認基準は品質ゲートNote、確認できる実例はCase Studiesへつなぎます。
Design Patternsを開く →