layout-paradigms-and-consistency

レイアウトのパラダイムと一貫性

レイアウトは、コンテンツを流し込むだけの中立的な容器ではありません。選ぶレイアウトのパラダイムは、コンテンツをどのように読み、比較し、行動に移すべきかという主張の一部です。同じデータを表示していても、フィード、テーブル、ボードのどれを使うかによって、製品が伝える内容はまったく異なります。

このスキルが扱うのは、一貫性のマクロスケールです。[[component-family-consistency]]（メソスケール — ボタンや入力欄が共通の設計思想を持つこと）より上位にあり、[[button-states]]、[[status-colors-and-errors]]、[[modular-scale-typography]]のようなトークンレベルの一貫性（マイクロスケール）よりも上位に位置します。一貫性とは単一のルールではありません。同じ規律を3つの異なるスケールで適用することです。

一貫性は3つのスケールで機能します

スケール	一貫性を保つもの	該当する場所
エステート	個別のアプリケーション間で共有するブランドの基盤と共通のシェル	このスキル、Part 3 + [[app-shell]]
マクロ	画面間で共有するレイアウトのパラダイムとページの骨格	このスキル
メソ	コンポーネントファミリー — 共通の角丸、高さ、色のロジック	[[component-family-consistency]]、[[brand-visual-language]]
マイクロ	状態、トークン、文字サイズのスケール、セマンティックカラー	[[button-states]]、[[status-colors-and-errors]]、[[modular-scale-typography]]、[[algorithmic-color-palette]]

トークンが完璧で、コンポーネントファミリーにも一貫性がある製品でも、画面ごとにレイアウトが異なり、ユーザーが画面遷移のたびに状況を把握し直すことになれば、使いづらさを感じさせます。マクロな一貫性こそが、製品をひとつのアプリケーションだと感じさせる要素です。

---

レイアウトは上流の決定に従います — 何かのために機能します

レイアウトのパラダイムが出発点になることはありません。それは、先に行われた判断の結果であり、別の場所で定められた目的を達成するための手段です。レイアウトを切り離して選ぶ — 「ダッシュボードは見栄えがするので使いましょう」 — ことが、レイアウトがうまくいかない最もよくある原因です。

**情報アーキテクチャから導き出されます。**データモデルと構造（[[information-architecture]]）によって、候補となるパラダイムの大部分が決まります。状態が変化するエンティティにはボードが適し、共通のフィールドで比較するレコードにはテーブルが適し、コンテナと項目の階層にはマスター・ディテールが適しています。IAが「タスクはプロジェクトに属し、ステータスを持つ」と示しているなら、レイアウトはすでに半分決まっています。まずIAを正しく定め、それをもとにパラダイムを選びます。

**ブランドとストーリーに役立ちます。**同じコンテンツでも、落ち着いた印象にも、緊急性のある印象にも、高級感のある印象にも、実用的な印象にも、編集的な印象にも、業務的な印象にもできます。レイアウトは、ブランドのトーン（[[brand-visual-language]]）や、ユーザーに体験してほしいストーリー（[[motion-and-storytelling]]）を強く伝える要素のひとつです。同じデータでも、余白のあるシングルフォーカスのレイアウトは、情報が密集したダッシュボードとは異なるストーリーを伝えます。問いかけてください。ここでユーザーにどんな感情を抱いてほしいのか、何を伝えようとしているのか？ — そのうえで、それを伝えるパラダイムを選びます。

**ユーザー体験に役立ちます。**最終的な判断基準は、ユーザーのタスクと状況です。ユーザーは何をしようとしているのか、どれくらいの頻度で行うのか、どのデバイスを使うのか、どのようなプレッシャーのもとにあるのか（[[ui-density]]、[[responsive-paradigms]]）。より目を引く選択肢があっても、タスクに最も適したパラダイムを選びます。

つまり、順序は次のとおりです。**まずIAとブランドの意図を定める → それらを支えるパラダイムを導き出す → その後で一貫性を適用する。**Part 1ではパラダイムの導き出し方を、Part 2では一貫性の保ち方を説明します。

---

Part 1 — コンテンツに合ったパラダイムを選ぶ

既定のグリッドではなく、コンテンツの性質と主要なタスクから考え始めます。問いかけてみましょう。ここで最も重要な項目間の関係は何でしょうか？ その答えがパラダイムを示します。

コンテンツの性質／主要なタスク	レイアウトのパラダイム	適している理由	使用を避ける場合
新しく、均質な項目が連続し、上から順に閲覧される	フィード	新しさと流れが重要で、無限に気軽にスクロールできます	項目を項目ごとに比較する必要がある場合や、順序が時間順ではない場合
ワークフローの段階を移動していく項目	ボード／カンバン	列によって状態が見え、ドラッグ操作で遷移を実感できます	明確な段階がない場合や、項目の比較すべき属性が多い場合
同じフィールドで多数のレコードを比較する	テーブル	列がそろっているため値を直接比較でき、並べ替えやフィルタリングも自然です	レコードが視覚的または不均質な場合や、画面が小さい場合
視覚的で不均質な項目を閲覧する	ギャラリー／グリッド	成果物自体がコンテンツであり、サムネイルが意味を伝えます	視覚要素より正確な値が重要な場合
リストと、選択した項目の詳細	マスター・詳細／分割	コンテキストを保ったまま詳細を確認でき、すばやく一覧しながら深く読み込めます。詳細はリストの末尾ではなく、リストが終わるところから始まります。[[gestalt-ui-organisation]] を参照してください	2つのペインを表示できないモバイルでは、詳細画面へ移動する形式に切り替えます
多数の指標を一目で把握する	ダッシュボード	空間的に配置することで、注意が必要な対象を目で見分けられます	ユーザーに必要なのがモニタリングではなく単一のタスクである場合、ノイズになります
空間的な関係や自由な配置	キャンバス	ユーザーの空間モデルがデータそのものです（図表、デザイン、地図）	コンテンツが本質的に直線的または順序づけられている場合
時間順に並んだイベント	タイムライン	時間が主要な軸であり、間隔や密度にも意味があります	時間が、同等に重要な複数の属性のうちの1つにすぎない場合
地理データ	マップ	位置が主要な次元です	タスクに対して位置が付随的な場合
1つのオブジェクト、1つのタスク、集中できる環境	単一フォーカス／ウィザード	現在の判断に不要なものをすべて取り除けます	判断に周囲のコンテキストが必要な場合は、[[user-flows-and-guided-paths]] を参照してください
まだ納得していない初見の人を説得する	ナラティブなロングスクロール	セクションの順序が論拠そのものとなり、各セクションが次のスクロールへと導きます	ユーザーがすでに利用を決めており、作業をしたいプロダクト内

パラダイムは、ほかのレイアウトスキルとも連携します。一貫性のあるグループ化を行い（[[gestalt-ui-organisation]]）、明確な強調点を1つ定め（[[visual-emphasis-and-hierarchy]]）、データモデルや命名を反映し（[[information-architecture]]）、ブレークポイントに応じて単に縮小するのではなく適応させる必要があります（[[responsive-paradigms]]）。ボードのように、現実世界のメタファーがパラダイムを強化する場合は、それを活用しましょう（[[real-world-metaphors]]）。

1つのビューで複数のパラダイムを提供できます。 レコードのコレクションを、ユーザーがタスクごとに選べるテーブル、ギャラリー、ボードとして提供するのは妥当です。[[data-display-and-selection]] を参照してください。重要なのは、それぞれの選択肢が偶然ではなく、意図的に適合するよう選ばれていることです。

物語性のあるロングスクロール — プロダクトのナラティブフレームワーク

マーケティングページやランディングページでは、シーケンスそのものが主張です。 ほかのパラダイムでは、ユーザーがすでに求めているコンテンツを並べますが、このパラダイムでは、何も決めていない訪問者にスクロールを続けてもらう必要があります。ランディングページは、各セクションを個別に見たときの見栄えではなく、見知らぬ訪問者を次の流れに沿って導けるかで評価してください。

#	展開	役割	典型的な表現
1	フック	適切な訪問者の足を止め、読み進めたいと思わせます	大きな見出し、ゆとりのある余白、補足文、製品の画像／動画／デモを添える
2	課題への共感	訪問者の現在の状況を理解していることを示します	具体的な課題 — 遅い、高コスト、手作業が多い、信頼性が低い、情報が散在している、調達が難しい
3	USP	何であるか、誰向けか、何が違うのかを一文で伝えます	明確な一文を、ゆとりをもって配置する
4	価値提案	差別化につながる3〜5つの利点を示します	機能や仕様の名詞ではなく、得られるメリットを表現する
5	根拠	各主張を信じる理由を示します	分野に応じた証拠 — 顧客、数値、事例、認証、試験データ、素材、在庫と納期、導入前後の比較
6	仕組み	仕組みや必要な手間に関する不確実性を取り除きます	分野固有の言葉で3つのステップを示す — 注文／装着／計測、接続／処理／結果、閲覧／試用／返品
7	放置した場合の損失	何もしない場合に生じるコストを伝えます	ダウンタイムが続く、競合が先に進む、時間と費用が流出する、問題が再発する
8	行動喚起	次に取るべき明確な行動を示します	訪問者が実際に行う様子を思い描ける動詞

この流れは、B2BとB2C、ソフトウェアと物理的な製品、グローバルメーカーと地域の店舗を問わず共通です。変わるのは、各要素の比重と証拠の種類です。 産業製品や予備部品の購入者は証拠、仕様、適合性、在庫状況を求め、それを確認するためにさらに読み進めます。ファッションや消費者向けのページでは、画像そのものがフックとなり、はるかに短いスクロールで行動喚起にたどり着きます。社内ツールのページでは説得を省けますが、それでも訪問者に対して、これは何か、なぜ存在するのか、どう始めるのかを伝える必要があります。ページの見た目を決める前に、この読者にとって、どの要素が重要な役割を担うかを決めてください。

フックは要約ではなく、問いかけです。 優れたヒーローセクションは価値を一つ提示し、訪問者に「これがどう動くのか見てみたい」と思わせます。その効果は装飾ではなく、サイズと余白から生まれます（[[visual-emphasis-and-hierarchy]]）。短い見出しだけでは説明が足りない場合は、見出しを長くするのではなく、その下に小さな補足文を加えてください。製品が実際に動作している様子を添えます — スクリーンショット、動画、ライブデモを使い、製品にない動作を見せるモックアップは使わないでください（[[authentic-product-representation]]）。

価値提案は機能ではなく、メリットです。 「AI ダッシュボード」や「14 mm の焼き入れ鋼」は名詞ですが、「重要な数値をひと目で確認できる」や「砂利道を走るシーズンを乗り切れる」は、訪問者が得られる価値です。競合他社のページにそのまま載せられる文言は、価値提案ではありません。

すべての主張に根拠が必要です。 主張が大胆であるほど、強力な証拠が求められます。何が確かな証拠となるかは、流行ではなく分野によって決まります — 試験報告書や適合保証は、ほかの分野での顧客ロゴと同じ役割を果たします。裏付けのない最上級表現は、真実である主張への信頼まで損ないます。

放置した場合の損失は、圧力ではなく結果から伝えます。 現状維持にどのようなコストが伴うかを明示してください。偽のカウントダウンや、作り上げた「残り3枠」といった人工的な希少性は、ページのほかの部分で築いた信頼を損ないます。

CTAでは行動を明示します。 「詳しくはこちら」では、何が起きるのか伝わりません。「無料で始める」「適合性を確認する」「見積もりを依頼する」「自分のサイズを探す」なら、次に何が起きるのかが訪問者に伝わり、その内容どおりの体験を提供するフローへとつなげられます（[[user-flows-and-guided-paths]]）。

質問の流れ

訪問者に、疑問が生じる順に答えていくことで、ストーリーが機能します。

これは何ですか？ → 自分に合っていますか？ → 何が優れているのですか？ → 信頼できますか？ → どのように機能しますか？ → どれくらいの手間がかかりますか？ → 次に何をすればよいですか？

ここでは、これが最も厳しいテストになります。ページを上から下まで確認し、それぞれの答えがどこにあるかを記してください。訪問者が答えを探し回ったり、上に戻ってスクロールしたりする必要があるなら、各セクションの見栄えがどれほど良くても、ストーリーは破綻しています。早すぎる回答も問題です。ファーストビューに価格を載せると、「これは何ですか？」と考えている人に「どれくらいの手間がかかりますか？」と答えることになります。

優れたページに共通すること

あらゆる分野で優れたページ――開発者向けプラットフォーム、工作機械のサプライヤー、衣料品ブランド、地域の自動車整備工場――には、同じ原則が見られます。

• ビューポートごとにメッセージは1つ — 各セクションは、質問の流れにある問いに1つだけ答えます。
• その場面に必要なコピーだけを使う — 説得のためのセクションは短く保ち、余白を活かします。一方、仕様や根拠を示すセクションでは、本格的に検討する購入者が求める詳細を盛り込みます。
• 抽象的なイラストやストック写真よりも、実際の製品画像や動画を使います。
• メリットから根拠へ、素早くつなげる — 主張を根拠なしに積み重ねません。
• CTAをページの下部まで繰り返し配置します。訪問者が納得した瞬間に行動できるようにします。
• 視覚的なリズムを統一します — セクション間の余白、文字サイズのスケール、画像の扱い方を繰り返します（[[modular-scale-typography]], [[brand-visual-language]]）。
• 控えめなモーションで流れを支え、競合させません（[[motion-and-storytelling]]）。

ここでの情報密度は、エキスパート向けツールとは意図的に逆です（[[ui-density]]）。ランディングページは、注意を払う義務のない人に向けたものです。ダッシュボードは、すでに利用を決めた人に向けたものです。一方の習慣をもう一方に持ち込まないでください。

---

パート2 — アプリケーション全体で一貫して同じパラダイムを再利用する

ある種類のコンテンツに対してパラダイムを選んだら、その種類のすべての画面で、同じパラダイムとページの骨組みを使います。これにより、ユーザーは一度で製品の使い方を覚えられます。

ページの骨組みは、その都度作るのではなくテンプレートにする

少数のページテンプレートを定義し、再利用します。

• リスト／インデックスページ — すべてのリストページで、タイトル、フィルター、表示モードの切り替え、主要なアクション、コレクションの位置を統一します。
• 詳細ページ — すべての詳細画面で、同じ骨組みを使います。ヘッダー（名前＋ステータス＋主要なアクション）→ 主な属性 → 関連コンテンツ → アクティビティ。ユーザーは1つの詳細ページを覚えれば、すべての詳細ページを使えるようになります。
• エディター／フォームページ — フォーム本文、検証の概要、保存／キャンセルのアクションの配置を統一します → [[form-design]] を参照してください。
• 設定ページ — セクション構成とコントロールの配置を統一します。

ページ間で配置を統一する項目

• ナビゲーション — グローバルナビゲーション、パンくずリスト、戻るための操作要素は、画面ごとに移動しません（[[ui-context-and-scope]]）。
• 主要なアクション — メインのCTAは、同種のページで同じ領域に配置します。あるページでは右上、次のページでは左下、といった配置は避けます。
• 常時表示されるUI要素 — ヘッダーとツールバーの挙動を統一します（[[sticky-and-fixed-elements]]）。
• ステータスとフィードバック — トースト、バナー、インラインエラーを一貫した位置に表示します（[[notifications-and-recovery]]）。

これはNielsenの用語では内部的一貫性（ヒューリスティック4）です。[[nielsen-usability-heuristics]] を参照してください。アプリケーション内では、目新しいパターンよりも、使い慣れたパターンの方があらゆる画面で優れています。

ページ間で機能の比重を均衡させる

同じ種類のページは、機能やコンテンツの量をおおむね同程度にする必要があります。あるページに機能が増え続ける一方で、同種の別ページが薄いままなら、その不均衡は通常、コンテンツの書き方ではなく構造上の兆候です。つまり、負荷を分散するために機能を統合するか、分割する必要があります。ある時点で完全に均等にするのではなく、長期的にページ数とページの長さのバランスを保つことを目指してください。

ページの内容が薄すぎる場合 — 独立した画面として成り立つだけの内容がない場合：

• 隣接するページに統合するか、関連する機能を追加します。
• マーケティング向けまたは一般向けの画面では、画像や短い動画、関連ページへのリンクを加えることも、内容の薄いページに実質的な価値を持たせる正当な方法です。
• プロフェッショナル向け／エキスパート向けツールでは、見た目だけの埋め草は避けてください。パワーユーザーにはノイズと受け取られます。画像や動画でかさ増しするより、他の場所から本当に関連性のある情報を少しだけ文脈に沿って取り入れる（関連する指標、最近のアクティビティ項目、リンクされたエンティティなど）ことを優先してください。

ページが重すぎる場合 — 1画面に収まらないほど内容が増えた場合：

• 独立したページに分割します（H4〜H6の見出しが必要になるときと同じ場合がよくあります。[[modular-scale-typography]]を参照してください）。
• 内容の一部を、より自然に収まる場所へ移動します。
• 中心となる考えを明確にして機能を縮小します。あらゆる選択肢を提示するのではなく、必ず実行すべきことを1つに絞ります（[[information-architecture]]にある、最初からすべてを提示せず隠しておく判断と組み合わせてください）。

例外を設ける場合 — その方法

一貫性は基本方針ですが、縛りではありません。画面のタスクが本当に異なる場合は例外を設けてください（集中して取り組むチェックアウトのステップで、グローバルナビゲーションを省略するのは妥当です）。例外を設ける場合：

• 見た目に変化をつけるためではなく、タスクに結びついた明確な理由に基づいて行います。
• 例外は完全かつ明白に（明確なモードとして）設け、微妙な違いにとどめないでください。標準にほぼ似ているが完全には一致しないレイアウトは、バグのように見えます。
• 例外自体にも一貫性を持たせます。集中モードでナビゲーションを隠すなら、集中モードの画面すべてで同じように隠してください。

---

Part 3 — 独立したアプリケーション群における一貫性

Part 1と2では、アプリケーションが1つであることを前提としています。しかし、ある程度の規模の組織のほとんどは、アプリケーションを1つだけ運用しているわけではありません。公開サイト、ショップ、顧客ポータル、社内管理ツール、そして誰も手を入れたくない古いシステムなど、複数のシステムを抱えています。コードベースもチームも異なり、作られた時代も異なります。ユーザーは1日の業務の中でそれらを行き来します。また、社内向けソフトウェアも社外向けソフトウェアと同じようにブランド体験を担います。従業員もまたユーザーです。

こうした取り組みを進める際も、外枠の存在感は適切な範囲に保ってください。企業に対するユーザーの印象は、検索結果やそこに表示されるファビコン、ソーシャルメディアのチャネル、広告、パートナーやアフィリエイトのページ、アプリストアの掲載情報、取引に関するメール、請求書、サポートチャット、エラーページ、ステータスページ、求人広告など、接するあらゆるものを通じて形作られます。製品のクロームはその一部であり、多くの場合、最も大きな要素ではありません。これは朗報でもあります。独立したアプリケーションが同じブランドに属していると感じさせるには、適切なファビコンとブランドカラーを2〜3色、ロゴタイプがあれば十分なこともよくあります。

すべてを同じ見た目にしようと考えがちです。しかし、それは目指すべき姿ではありません。そこにこだわることが、システム群全体のデザインプログラムが失敗する原因になります。管理ツールにマーケティングサイトのゆとりある余白を取り入れた結果、使いづらくなることもあれば、マーケティングサイトに管理ツールの密度を取り入れた結果、生気のないものになることもあります。

すべてのアプリケーションが同じツリーに属するわけではありません

同じ会社のB2B向けマスターデータ詳細画面とB2C向けキャンペーンページは、見た目が異なっていて当然です。異なる人々が、異なる状況で、それぞれ別のことをするために使うものだからです。ただし、スタイルの下にあるレイヤーは変わってはいけません。

ブランドの基盤 — 例外なく、どこでも同一です。 ここに差異があれば、不具合です。

• ロゴタイプとそのクリアスペース
• ブランドカラーと意味を持つステータスカラー — 赤はどのツールでも同じ意味です（[[status-colors-and-errors]]）
• 書体ファミリー
• フォーカスリングの表現（[[wcag-accessibility]]）
• 破壊的な操作の見た目と、その確認画面の形状（[[information-architecture]]）
• 日付、数値、通貨の書式
• システムメッセージのトーン（[[notifications-and-recovery]]）
• アクセシビリティの最低基準

表現レイヤー — 対象ユーザーとタスクに応じて、意図的に変化させます。 ここに差異があれば、それはデザイン上の判断であり、明確に示すべきです。

軸	マーケティング／B2C向け画面	社内向け／業務ツール
情報密度	余裕を持たせ、1画面に1つのアイデア	高密度にし、一目で最大限の情報を把握できるようにします（[[ui-density]]）
文字サイズ比	1.333–1.5。表現力のあるディスプレイサイズ	1.2。コンパクトで機能的です（[[modular-scale-typography]]）
画像	中心的な役割 — 写真、イラスト、動画	ほとんど使いません。データそのものが画像です
モーションの予算	ストーリーテリングと段階的な表示（[[motion-and-storytelling]]）	フィードバックのみ — 操作の確認に限り、それ以上は不要です
エラーのトーン	安心感のある、平易な言葉	簡潔で、すぐに対応できる表現：412行目：VAT番号が未入力です
時刻と数値	親しみやすい相対表記 — 2日前	タイムゾーン付きの絶対表記。電話で問い合わせを受けている人がいるためです
空の状態	オンボーディングの機会	結果がありません — フィルターを広げてください
キーボード	必要になることはほとんどありません	習熟したユーザーにはショートカットが必須です（[[operational-expert-tool-ui]]）
パフォーマンスの重点	LCP — 第一印象（[[performance-and-web-vitals]]）	INP — シフト中の千回目の操作
役割と権限	表示しません	明確に示します。ユーザーは自分にできることを知る必要があります（[[ui-context-and-scope]]）

レイアウトのパラダイムとページの骨格は、基盤ではなくこのレイヤーに属します。 サービスを集約するランディングページ、業務ツール、コンテンツ作成画面で、同じ骨格を共有するべきではありません。無理に共通化すると、全社的なデザインプログラムがかえって状況を悪化させます。制約となるのはデザインシステム — トークン、コンポーネント、状態、振る舞い — であり、ページの形ではありません。

守るべき基準はこれです。タスクの性質が異なるなら、パラダイムも異なるべきです。内容だけが異なるなら、変えるべきではありません。 サービスを集約するダッシュボード、シフト中に操作するツール、エディターは、性質が異なります。異なるエンティティを表示する2つのリストは、そうではありません。

互いによく似たアプリケーション — 同じチーム向けの2つの社内ツールや、ポータルとそのモバイル版など — は、基盤だけでなく表現レイヤーも共有するべきです。新しい仲間のスタイルを決める前に、ファミリーを確立してください。よく似た既存のアプリケーションがあれば、ブランドからもう一度導き出すのではなく、それを継承してください。

一貫性の段階

2003年製のターミナルアプリケーションをリブランドすることはできませんし、それを求めるデザインプログラムはそのシステムひとつで行き詰まります。一貫性はあるかないかの二択ではありません。段階があり、各アプリケーションは現実的に到達できる段階に位置づけられます。

段階	意味	一般的なコスト
0 — アイデンティティ	適切なロゴ、名前、ファビコン、ページタイトルです。ユーザーは、どの会社のソフトウェアかが分かります。	数時間
1 — クローム	共通のシェルです。トップバー、サインイン、書体（[[app-shell]]）	数日
2 — トークン	ブランドカラーと余白を、アプリケーションに既にある変数に割り当てます。	数日から数週間
3 — コンポーネント	ボタン、入力欄、テーブルなど、実際に共有されるコンポーネントです（[[component-family-consistency]]）。	数か月

古いBootstrapアプリケーションは、Bootstrapには上書きできる変数が既にあるため、段階2にすぐ到達できることがよくあります。ターミナルアプリケーションは段階0にとどまりますが、それは失敗ではなく、正しい判断です。アプリケーションごとに目標とする段階を明確に決めることが、プログラムがいつまでも始まらない、全か無かの全面書き換えになるのを防ぎます。

新しいアプリケーションが次々と登場する——それもまたデザイン上の課題です

既存のコードベースに参加するより、新しく始めるほうが簡単なため、チームは新しいコードベースを立ち上げます。アイデンティティ、テナンシー、権限が本当の意味で共有されていないと、新しいログインの先に新しいツールを作るのが最も手軽な方法になります。そしてそのたびに、管理するアカウントが増え、デザインの一貫性が崩れていきます。

デザイン面での答えは、作り直すより参加するほうを簡単にすることです。すぐに導入できる共通のシェル、フレームワークを採用せずに利用できるトークン、そして最初から使えるひとつのアカウントを用意します。組織全体のデザインシステムを測る基準は、主力製品がどれほど美しいかではありません。次に作られるツールが、デフォルトでそのシステムに加わるかどうかです。

---

レビューチェックリスト

• レイアウトのパラダイムは、デフォルトのグリッドではなく、コンテンツの性質と主なタスクに意図的に適合していますか？
• このコンテンツにおいて、このパラダイムが他の選択肢より優れている理由を、一文で説明できますか？
• 同じ種類の画面（すべての詳細ページ、すべての一覧ページ）で、ページの骨格が統一されていますか？
• 画面が変わっても、ナビゲーションの位置は変わりませんか？
• 類似するページでは、主要なアクションが同じ領域に配置されていますか？
• ある詳細ページの使い方を覚えれば、他の詳細ページもほぼ使いこなせますか？
• 関連するページ同士で、機能やコンテンツの比重は同程度ですか？（特に専門家向けツールでは、過剰に重いページは分割し、内容の薄いページは水増しせず統合していますか？）
• 画面が標準テンプレートから外れる場合、タスクに基づく明確な理由があり、その違いは微妙ではなく明白ですか？
• プロダクト全体に統一感があり、複数のアプリケーションを継ぎ合わせたように感じませんか？

複数の独立したアプリケーションから成る環境の場合：

• すべてのアプリケーションで、ブランドの基本要素（ロゴ、ブランドカラー、セマンティックカラー、書体、フォーカスリング、書式、システムの語り口）が統一されていますか？
• アプリケーション間の違いは、積み重なったずれではなく、対象ユーザーとタスクに関する明示的な判断によるものですか？
• 新しいアプリケーションは、ブランドから一から設計し直すのではなく、最も近い既存アプリケーションを継承していますか？
• レガシーなものを含め、すべてのアプリケーションに一貫性の段階の目標がありますか？（段階が0で止まるものも含みます。）
• 顧客向けのアプリケーションだけでなく、社内ツールにもブランド体験が備わっていますか？
• チームにとって、この環境に加わるほうが新しいコードベースを一から始めるよりも容易ですか？

ランディングページまたはマーケティングページの場合：

• ページには8つの要素（フック、課題、独自の価値、価値提案、実証、仕組み、重要性、CTA）がすべて含まれていますか？
• この対象ユーザーと業界に合わせて各要素の比重を調整し、その業界で受け入れられる種類の証拠を提示していますか？
• ヒーローで価値を1つ伝え、訪問者がプロダクトの動作を見たくなるようにしていますか？
• 価値提案は機能名ではなくメリットになっており、重要な主張のすべてに、その近くで裏付けを示していますか？
• ページを上から下へ読み進めると、流れの中で生じる疑問にその場で答えていますか？（答えを先に出したり、スクロールして戻らないと答えが見つからなかったりしませんか？）
• CTAでアクションを明示し、作為的な希少性ではなく、実際の結果に基づいて緊急性を伝えていますか？