gridgeist

Gridgeist

概要

オーディエンス、コンテンツ、振る舞い、ブランドの意図をもとに、独自性があり、プロダクトに自然になじむインターフェースを作ります。グリッドを構造上のロジックとして使い、プロダクトに役立つ場合にのみ見えるようにします。

モードを選択する

意図と権限	モード	最初に確認すること
既存のデザインなしでインターフェースを構築する	作成	オーディエンス、主要なタスク、コンテンツ、根拠
編集権限を持って既存のインターフェースを変更する	再デザイン	維持する振る舞い、ブランドの特徴、状態の一覧
ファイルを変更せずに診断する	レビュー	レンダリング結果に基づく、優先順位付きの指摘

ファイルを変更するかどうかは、ユーザーの許可に従ってください。再デザインの許可は、実質的に異なる複数のビジュアル方針から選択する権限を与えるものではありません。方向性は、ユーザーの明示的な意図または確立されたブランドの根拠から導き出してください。オーディエンス、タスク、プロダクトカテゴリ、コンテンツは階層の検討材料にはなりますが、それだけではビジュアル方針を確定できません。方針に関する曖昧さが残る場合は、以下の合意形成ゲートを使用してください。

ワークフロー

1. 調査 — 対象ユーザー、主なタスク、ブランドの特徴、コンテンツ、製品を裏付ける情報、ルート、コンポーネント、トークン、レンダリングされたデスクトップ／モバイルの UI を把握します。既存のデザインシステムの資料を調べ、DESIGN.md がある場合はそれも確認し、内容が一致すると決めつけず、実装やレンダリング結果と照合します。重要なインタラクションの状態や制約を洗い出します。顧客、指標、成果、調査、コンプライアンスを捏造してはいけません。
   • 編集前に方向性を合わせる — 方向性をユーザー確認済み、ブランドから導出、暫定のいずれかに分類します。実装上の選択肢が未確定でも、一貫性のあるユーザーの方向性が示されていれば、確認済みとして扱います。同じ主旨の範囲内でのバリエーションは、重大な曖昧さではありません。既存のビジュアル実装、アセット、文書化されたルール、または繰り返し見られるブランドの慣習がひとつの主旨に収束している場合に限り、方向性をブランドから導出されたものと分類します。製品の題材やコピーだけでは不十分です。大規模な新規作成または再設計において、ブランド表現の中核、階層、画像、色、またはモーションを変えるような複数の主旨が依然として妥当な場合は、根拠に基づく方向性を2〜3案とそのトレードオフ、推奨案を提示し、ユーザーに選択または推奨案の承認を求めます。方向性が暫定の間は、置き換えるシステムを定義したり、実装ファイルを編集したりしません。意図や一貫したブランドの根拠が明確な場合は、重複する質問をせずに進めます。レビューや限定的な修正を妨げてはいけません。レビューにおける未確認の置き換え方向は、暫定と明記します。
   • 大規模な暫定作業は必ず停止する — 暫定の方向性は、実装可能な方向性ではありません。選択肢、トレードオフ、推奨案、方向性を合わせるための質問を提示した時点で、そのターンを終了します。ユーザーが方向性を選ぶか、推奨案を明示的に承認するまでは、主旨を決めたり、システムの仕様を読んだり、トークンを作成したり、ファイルを編集したり、実装を開始したり、再設計を検証したりしてはいけません。
2. 主旨を定める — 対象ユーザー、主なタスク、構造の論理、ブランド表現、製品固有のモチーフを組み合わせた、方向性を示す一文を書きます。方向性を選ぶ前にデザイン言語を読みます。特に、画像主導、温かみのある表現、遊び心のある表現、その他の非技術系ブランドの場合は必ず確認してください。
3. システムを定義する — システムに関する決定を新たに行う、または変更する前にシステム仕様を読みます。関連する色、タイポグラフィ、レイアウト、間隔、形状、サーフェス、コンポーネント、状態、メディア、モーション、レスポンシブのルールを、ひとつの簡潔な仕様として定めます。グリッドを見せるか、控えめにするか、見せないかを決めます。セマンティックトークンと既存のプリミティブを再利用します。限定的な修正は必要な範囲にとどめ、許可がない限り、継続的に使うデザイン成果物を作成しません。
4. 構成する — 細部より先に階層を組み立てます。ひとつの領域を主役にし、関連するコンテンツを揃え、共通の論理を保ちながらセクションに変化をつけます。最も真正性の高い素材（製品 UI、データ、文章、画像、アートワーク、コード、または主要なツール）に、視覚的な重みを持たせます。
5. 実装する — 必要な動作と状態を維持します。リポジトリの規約、セマンティック HTML、キーボードやタッチへの対応、既存のプリミティブに従います。デスクトップレイアウトを縮小するのではなく、モバイル向けに再構成します。単純な CSS 効果のために依存関係を追加しません。
6. 検証する —レビュー用チェックリストを使います。代表的な画面幅でレンダリングし、主要なフロー、状態、フォーカス動作、モーションの軽減、オーバーフロー、動的コンテンツを確認します。仕上げより先に、わかりやすさと階層を改善します。実際に確認したことと、推測または未テストのまま残っていることを分けて報告します。

インタラクティブな製品では、該当する場合、少なくともデフォルト、読み込み中、空、エラー、成功、無効、破壊的操作の各状態を洗い出します。プライバシー、安全性、データ、プラットフォームの制約は、任意の仕上げではなく、製品の動作として維持します。

連携するスキル

• Gridgeistを、プロダクトとビジュアルの方向性を決める唯一の主体として扱います。別の広範なフロントエンドデザインやアートディレクションのスキルと、自動的に組み合わせないでください。ユーザーが両方を明示的に依頼した場合は、デフォルトの方向性を黙って混ぜるのではなく、編集前に方向性を決める主体を一つ定めます。
• 明示的な重複確認 — ユーザーがGridgeistと別の広範なビジュアルデザインスキルを依頼した場合、方針を選んだり編集したりする前に、重複する点を示し、方向性を決める主体を一つにするよう提案します。プロダクトに根ざしたブランド適応型の作業では、デフォルトでGridgeistを使用します。依頼された連携スキルを黙って無視したり、両方のビジュアル方針を同時に実行したりしないでください。担当が明確になった後は、ユーザーがそのスキルを方向性の決定主体に選ばない限り、他方のスキルからは、競合しない実装や検証の支援のみを利用します。
• Inspectではコンテキスト機能を、方針決定後はアセット生成を、実装後は技術監査を、Verifyではブラウザー自動化を利用します。
• 連携スキルは任意として扱います。利用できないことを理由に作業を止めたり、依存関係を追加したりしないでください。

低品質なデザインを避けるための契約

• 方針は一つにし、一貫したシステムを構築します。
• 既存のブランドを尊重するか、意図的に発展させ、独自の美学を持ち込まないようにします。
• スケール、配置、密度、リズム、コントラストを通じて階層を構築します。
• グリッドの可視性、境界線、角丸、シャドウ、グラデーション、動きには、それぞれ明確な役割を持たせます。
• 信頼できるプロダクトの根拠を優先します。サンプルや架空の素材にはその旨を示し、根拠を捏造しないでください。
• 共通する構造の論理を保ちながら、セクションやワークフローごとに異なる構成を与えます。

角丸カードの反復、中央揃えのヒーローコピー、グラデーションの塊、過剰なピル型要素、均一なセクション、恣意的なアイコンボックス、ありきたりな主張、技術系ではないブランドへの技術的な装飾は、診断の手がかりであり、自動的に違反となるわけではありません。弱い構成は、プロダクトに即したより強いアイデアに置き換えます。

判断の指針

要素	判断基準
構造	情報の順序、タスクの流れ、共通の配置、ブランドの規則性の度合い
書体	ブランドの声、読みやすさの要件、役割の階層。モノスペースは、真に技術的なコンテンツに限って使用します
ビジュアルの主役	プロダクトUI、データ、文章、画像、アートワーク、コード、または主要なインタラクティブ領域
形状と表面	流行ではなく、ブランドの幾何学的特徴、包含、隣接、状態、インタラクション
色	既存のブランドパレットと意味上の役割。ニュートラルカラーにアクセントカラーを一色加える構成を前提にしません
コンポーネント	プロダクトのタスク、共通の構造、バリエーション、密度、状態の挙動、リポジトリの規約
動き	因果関係、フィードバック、空間の変化、トーン。動きを抑える設定にも対応します
レスポンシブ対応	各画面幅での優先度、順序、密度、入力方式、コンテンツの挙動

出力の契約

ユーザーが確認した、またはブランドから導き出したCreateまたはRedesignでは、方針と維持する制約を示す方向性、完全なレスポンシブ対応を含む実装、確認したビューポート、フロー、状態、残る課題を明記した証拠を含む検証を提示します。システム上の判断が大きく変わる場合は、関連する契約、またはトークンやコンポーネントのルールが実装されている箇所を明示します。暫定的な広範なCreateまたはRedesignでは、選択肢、トレードオフ、推奨案、質問のみを出力します。実装や、デザイン変更に関する検証の主張は含めません。Reviewでは編集せず、1行の評価、場所・根拠・影響・最小限の一貫した修正を添えた優先順位付きの指摘事項、置き換えとなる方向性を提示します。実際に確認していない内容について、検証済みと主張しないでください。

よくある間違い

間違い	修正方法
Gridgeist を目に見えるグリッドのプリセットとして扱う	グリッドは基盤となるロジックとして使い、ブランドにメリットがある場合にのみ表に出します
参考例をそのままコピーする	原則を抽出し、ユーザー自身のアイデンティティとコンテンツを保ちます
挙動を理解する前にスタイルを整える	構成を始める前に、タスク、制約、状態を洗い出します
ミニマリズムを中身のないものにする	役立つ根拠と、適度な情報密度を加えます
コンポーネントを一つずつスタイリングする	個々のインスタンスを仕上げる前に、共通の構造、トークン、バリエーション、状態を定義します
デフォルト状態だけを改善する	読み込み中、空、エラー、成功、無効、破壊的操作の各パスを設計します
デスクトップ UI をモバイルにそのまま積み重ねる	順序、情報密度、ナビゲーション、メディア、操作を再設計します
主観的な好みだけを報告する	指摘を理解度、使いやすさ、一貫性、ブランド、アクセシビリティに結び付けます
自動チェックの結果をユーザーの根拠として報告する	技術的な検証と、ユーザビリティ、安全性、調査に関する主張を分けます

対照的な例

情報密度の高い API ドキュメントを、目に見える情報グリッド、正確なコード状態、検証済みのモバイルナビゲーションで再設計します。

温かみのある画像主導のポートフォリオを、目に見えない配置システム、表現力豊かな書体、作品主導のテンポ、アクセシブルなプロジェクト紹介で再設計します。