Design Decisions — /app/ceo Variant C (Bold / Narrative-first) — Round 1

Generated by kashi-ui-mockupper | Surface: /app/ceo | Picked variant: C | Companion: ./index.html | Date: 2026-05-27

このファイルの目的: Variant C の mockup で行った 非自明な 設計選択を、 Justine と将来の React 実装エンジニアが追跡できる形で記録します。 「なぜ B ではなく C を picked variant に沿って作ったか」 ではなく 「C を選んだ前提で、 mockup で行った具体的選択の根拠」 を 1 件ずつ立てます。

Round 1 mockup の役割: Justine が共同創業者・友人・メンターに開いて見せ、 「longitudinal moat が画面で picture-visible になっているか」 「narrative card が AI 生成と誤読されないか」 の 2 点を 定性的 に評価する素材。 数値・テンプレ文・hub の粒度は Round 2 で改修される前提。

1. Variant C の本質と本 mockup での体現

決定: narrative card 1 個 + 4 drill-down hubs + sparkline 群 の 3 階層構成を採用

Variant C 提案 02_proposals/app-ceo__variants.html の中核は 「俯瞰 → 興味あるところだけ深掘り → trend で longitudinal を画面で示す」 model。 本 mockup は以下の順で上から並べます:

  1. narrative card (今週の集計概要、 固定テンプレ、 3 行集計 + 1 行 trend mini-spark)
  2. 4 drill-down hubs (Review Candidates / Plan C / Positive / Governance)
  3. sparkline trend section (3 sparkline: cleared 2 つ + suppressed 1 つ)

これにより 「30 秒で今週の状態が分かり、 興味のある軸を 1 つ選んで hub に drill in、 longitudinal trend は別 section に明示分離」 という Variant C の意図が単一画面で picture-visible になります。

canon: permanent-ui-principles §7 (progressive disclosure) + §8 (cognitive load)。 02_proposals Variant C 「一文要約」 verbatim 採用

2. Narrative card 設計 — 「固定テンプレ」 を視覚的に証明する

決定: narrative-headline は 4 つの差し込み変数を持つ 1 つの定型文 + 「固定テンプレート」 pill を視認可能にする

X-04 (AI narrative diagnosis) は permanent-ui-principles §1 §2 で 厳禁。 ただし narrative card 自体は P-01 (executive metric 集約) として最も強い研究信号。 衝突を解決するため:

これにより、 friend / mentor が画面を見て 「AI が組織の状態を診断したような印象」 を持っても、 pill が即座に否定する design defense になります。

canon: permanent-ui-principles §1 forbidden (「detects illegality / detects intent」 連想を排除) + 02_proposals X-04 verbatim 「narrative card は AI 生成ではなく固定テンプレート + 集計数」

決定: narrative-list は 3 行 (reviewer 対応待ち / insufficient window / governance) に固定

02_proposals Variant C の wireframe では narrative card 内に 3 行の集約 (reviewer 対応待ち / insufficient / governance) を提示。 これを <ol class="narrative-list"> の semantic な 3 つの <li> として実装。 各行は左から (1) 数字 (Fraunces 大) (2) 文章 (3) trend 表示。 3 列 grid layout で 「数字が読みやすく、 trend が左端で揃って見える」 視覚規則を強制。

3 行目 (governance) は .governance modifier で border-left 色を ink-soft に落とし、 1〜2 行目とは 性質が違う (件数ではなく状態) ことを border 色で示しています。

canon: design_system_v1 「色 + テキストラベル」 — 件数 vs 状態の差は border 色 + 数字 vs 列挙文の差、 両方で表現

決定: 3 行目の数字 「4」 は 「ガバナンス 4 lane」 の意。 単一スコアではない

X-03 (organizational health single score) NG。 narrative card 内に 「82/100」 のような単一スコアを置くと即 canon 違反。 そのため 3 行目の数字 「4」 は 件数 ではなく lane の個数 (Structural / Semantic / Reviewer / Labor) を示し、 直後の文章で 「structural = OK / semantic = OFF / reviewer = OK / labor = 要確認」 を明示します。

意図的に他の 2 行 (3 / 2 = teams 件数) と数字種類を変えていますが、 視覚的には同じ Fraunces big number として並ぶことで 「3 つの軸 で見ろ」 とユーザーを誘導します。

canon: permanent-ui-principles §2 forbidden 「organizational health score」 / DATA_VISIBILITY_MATRIX Executive 行

3. Sparkline 設計 — gateKanonSparkline() の挙動を画面で見せる

決定: sparkline は 3 個 (cleared 2 + suppressed 1)、 「k-anon clear」 pill と 「suppressed」 pill を card 右上に常時表示

02_proposals Variant C の最大リスクは sparkline の k-anon hard-gate 漏れ。 mockup の役目は 「実装時に何を担保すべきか」 を React 実装者に画面で示すこと。 そのため:

これにより、 開発者は実装時に 「gateKanonSparkline() が 2 つの状態 (clear / blocked) を返し、 UI はどちらかを condition rendering する」 ことを画面から逆算できます。

canon: DATA_VISIBILITY_MATRIX §5 k-anon floor (hard-gate) / 02_proposals Variant C 「最大リスク」 段落 verbatim

決定: suppressed sparkline の copy は WORKER_FACING_TRUST_CANON §6.2 verbatim style

「観察ウィンドウ内のチーム規模が比較可能になるまで時系列表示は抑制されます」 を suppressed box 内に大文字 LABEL + 本文の 2 段構成で表示。 加えて gate-reason 段落で 「直近 3 バケットで team_count_per_bucket < 5 が発生」 という technical reason も併記。 これは React 実装時に i18n key として 1:1 で対応する想定の copy。

canon: WORKER_FACING_TRUST_CANON §6.2 verbatim / design_system_v1 「suppression copy は user-facing で technical reason は audit/debug 双方に有用」

決定: trend arrow は色 + 矢印テキスト + コンテキスト文 の 3 重表現

permanent-ui-principles §13 「色 only NOT」。 上方向 (↗) は warning amber、 下方向 (↘) は info blue、 flat (→) は ink-faint。 ただし色だけでなく arrow 文字 も併用、 さらに 「↗ = 注視 amber 方向」 等の補足文を caption に。 色覚多様性 + screen reader 両対応。

赤は使いません (X 系 alert NG)。

canon: permanent-ui-principles §13 chart rule / design_system_v1 「赤は真の障害のみ」 / P-08 research pattern

4. 4 Drill-down Hubs — 数 4 個に固定する根拠

決定: hub は 4 個 (Review Candidates / Plan C / Positive / Governance) — それ以上も以下もダメ

P-01 「executive metric 5-8 limit」 + permanent-ui-principles §8 「everything looks equally important = fail」 から逆算。 4 個 hubs が:

5 個目以降は scope creep。 仮に 「個別 manager hub」 が欲しくなっても、 それは DATA_VISIBILITY_MATRIX §6 (executive default = aggregate only) 違反なので絶対追加しない。

各 hub card は左上に Hub 番号 (Hub 01〜04) を monospace eyebrow で表示し、 順序を明示。 これは Plan C を 2 番目に置くのが 「review 後の対応の集約だから」 という設計意図を camera で示します。

canon: permanent-ui-principles §8 / DATA_VISIBILITY_MATRIX §6 / P-01 research pattern

決定: hub card は anchor (<a>) として実装、 hover で border-color が emerald-700 に変化

「card 全体が clickable」 を一目で示すには cursor pointer + hover transform + border-color の 3 要素必須。 React 実装時は Next.js Link で wrap、 keyboard 操作も Tab → Enter で動作するよう role="listitem" + focus-visible outline を明示。

canon: design_system_v1 a11y rules / Lattice + Linear pattern

5. 3-level Breadcrumb — Variant C の階層を picture-visible にする

決定: 「Overview › Executive › 今週の signal」 の 3 階層を <nav class="breadcrumb"> で常時表示

Variant C は cross-page IA rethink。 mockup でも実装時の階層を視覚的に予告する必要があり、 page title の に breadcrumb を配置 (header sticky の直下、 main の最上部)。

3 階層は研究 P-02 (3-4 level drill-down + breadcrumb)。 lvl 1 = Overview (org-wide landing)、 lvl 2 = Executive (CEO 用 landing)、 lvl 3 = 「今週の signal」 (今日表示中の slice)。 hub drill-in 時は lvl 4 「Executive › Roster (営業部)」 が増える想定だが、 mockup では landing のみ表示。

クリックで toast が出る demo affordance を script に入れています (実装時は Next.js router push)。

canon: permanent-ui-principles §7 progressive disclosure / P-02 research pattern (DataBrain + Linear + Stripe)

6. 採用した token (どこに何を使ったか)

箇所token意図
narrative card border --color-kashi-evergreen-deep 2px landing の主役を強調 (B の polaris-card 同等 weight)
narrative-line border-left --color-emerald-700 (件数行) / --ink-soft (governance 行) 「件数」 と 「状態」 の性質差を border 色で表現
narrative-line count digit Fraunces 600 + --fs-h2 + --color-kashi-evergreen 3 行の big number を視覚的に揃える
「固定テンプレート」 pill --ink-soft + dashed --ink-faint border AI 生成連想を打ち消す柔らかい neutral pill (高彩度の警告色は使わない、 設計選択)
hub card hover border --color-emerald-700 + transform: translateY(-1px) clickable affordance、 evergreen 系で統一
sparkline polyline stroke --color-kashi-evergreen solid 2px §13 chart rule: solid = actual data、 dashed = projection (本 mockup は actual のみ)
k-anon clear pill --color-emerald-50 bg + --color-emerald-700 border 「通過した」 を緑系で表現、 ただし高彩度ではない
k-anon blocked pill --kashi-state-blocked-bg + --ink-faint border 「抑制」 を neutral gray で表現 (赤は X 系 alert に予約)
trend arrow up --kashi-state-warning #B45309 amber = 注視 (赤ではない)
trend arrow down --kashi-state-info #3B82F6 blue = 情報、 「減った」 が良いか悪いかは context 依存なので neutral
breadcrumb current --color-kashi-evergreen + font-weight 600 現在位置の強調 (リンク色との差別化)
window-infobar --kashi-state-info-bg + --kashi-state-info border P-04 「時間窓 honest disclosure」 を info blue で表現

7. 採用した evidence-grade 表現

本 mockup の landing は aggregate-only 表示 なので、 evidence grade badge そのもの (WEAK / EMERGING / STABLE 等) は表示しません。 これは意図的:

ただし sparkline では 「trend up = amber / down = blue / flat = faint」 という 方向の color を使用、 これは grade ではなく direction なので canon 内。

8. 削った要素 (現状 Kashi / B mockup から)

削った要素削った理由
polaris-card (B の北極星 H1 = 1 数字 + 1 desc) C は narrative card に統合。 「3」 だけを巨大に出す B 方式は 「single KPI に注目」 を生むが、 C は 「3 軸を 1 視野で並べる」 が本質
secondary stat strip (B の 3-col 副次) narrative-list の 3 行に統合。 stat strip → narrative-list は 「数字 + 1 行 caption」 から 「数字 + 文章 + trend」 に拡張する設計
roster カード群 (B の review candidate cards × 3) landing から完全排除、 Hub 01 (Review Candidates) drill-in 先に降格。 02_proposals Variant C の核心仕様
accordion 群 (B の 「ロスター全表示 / Plan C / Positive」 折りたたみ) Hub 02 / Hub 03 / Hub 01 への drill-in に置換。 accordion = 同一 page 内、 hub = sub-route。 IA 階層が違う
governance compact panel (B の 4 chips) narrative-list の 3 行目 (4 lane status) + Hub 04 (Governance) に分離。 landing では state のみ、 詳細は hub

9. 追加した要素 (現状 Kashi / B mockup にない)

追加要素根拠 (研究パターン / canon)
3-level breadcrumb P-02 (DataBrain / Linear / Stripe) + cross-page IA への移行を mockup で予告
narrative aggregate card (1 ヘッドライン + 3 行 list) P-01 (executive metric 集約) + 02_proposals Variant C 仕様
「固定テンプレート」 pill X-04 (AI narrative NG) への design defense。 mockup 独自の追加要素 (proposals では UI 文言中立化のみ言及、 pill は本 mockup の補強)
4 drill-down hub grid P-06 (Workday / Stripe progressive disclosure) + 02_proposals Variant C 仕様
narrative-list 内の inline mini-sparkline (7 bars) P-07 (sparkline) を narrative card 内でも 軽く 提示。 ただし aggregate count の時系列のみ
sparkline trend section (3 sparkline、 1 つは suppressed) P-07 + DATA_VISIBILITY_MATRIX §5 (k-anon hard-gate)、 「実装時に gate 状態を 2 つ rendering せよ」 を画面で明示
k-anon clear / blocked pill 02_proposals Variant C 「最大リスク (research が hard-gate 指定)」 への画面 evidence
gate-reason 段落 (technical reason) debug / audit / 実装者向けの 「なぜ gate が通った/塞いだ」 の内訳。 user-facing copy とは別段落で分離

10. 既知のトレードオフ / 未解決

10.1 narrative-headline の copy は 1 文ずつ canon owner と詰める必要あり

本 mockup の文 「今週、 demo株式会社 全体で 14 teams 中 3 teams が reviewer 対応待ち window に入りました。 主要な変化は…」 は 仮の copy。 「window に入りました」 という表現が judgement (判定) に読まれないか、 「主要な変化は」 が AI 解釈に読まれないかは worker-facing trust canon owner の judgement が必要。 Round 2 で固定する copy 候補を 3 案出して合意取る想定。

10.2 narrative-list 3 行目 (governance 4 lane) が単一スコア感を出す可能性

数字 「4」 が他 2 行 (件数) と並ぶことで 「4 = score」 と誤読されるリスク。 mockup ではテキスト 「governance lane の現在状態」 + 内訳 「structural = OK / semantic = OFF / reviewer = OK / labor = 要確認」 で打ち消しているが、 friend / mentor feedback で 「これスコアに見える」 と言われたら 3 行目を別 visual treatment (例: 数字なし、 4 mini chips のみ) に変える検討余地あり。

10.3 「先週比 +1」 が judgment に読まれるリスク

narrative-list 1 行目の 「先週比 +1」 は ↗ amber 表示。 「悪化した」 と読まれる可能性。 worker-facing canon の立場では 「signal の変化は judgment ではなく review 起点」 なので、 Round 2 で 「先週比 +1 (review 必要 window が増加)」 のように 意味補足 を入れる必要があるかもしれない。

10.4 sparkline 「7 週」 の固定は他画面と矛盾しないか

narrative card の observed window は 「直近 90 日固定」、 sparkline は 「7 週」。 これは 90 日 = 約 13 週分を 7 バケット (約 2 週/バケット) で aggregate した結果と読めるが、 実装時に観察窓と sparkline バケット幅の関係を明示する必要あり。 mockup では 「直近 7 週」 とのみ label。 Round 2 で 「観察窓 90 日 / バケット 14 日 / 計 7 点」 等の technical disclosure を gate-reason に追加する候補。

10.5 muscle memory 破壊 — 既存 5-section landing からの移行

02_proposals でも risk block に明記された通り、 既存ユーザーが現 landing を期待している。 mockup には migration banner を入れていない (Round 1 では 「新 landing の見た目」 を評価することが目的のため)。 実装時には 「現 landing に戻る一時リンク」 等の migration affordance が必要。

11. B との比較 (Justine 判断材料)

B (Moderate)C (Bold / this mockup)
核心 metaphor北極星 1 数字 (3 = reviewer 対応待ち)narrative 1 段落 (3 軸を 1 視野)
landing の主役polaris-card (big single number)narrative-card (headline + 3-line list)
roster 表示位置landing 直下 (review-candidate 3 cards)Hub 01 drill-in 先 (landing からは数字のみ)
governance 表示位置landing 下部 (compact 4 chips panel)narrative-list 3 行目 + Hub 04 drill-in 先
longitudinal moat の可視化言葉のみ (window note + counts)sparkline 3 個 (1 つ suppressed) で完全可視
k-anon hard-gate既存 suppression footer のみsparkline 抑制 + 「k-anon blocked」 pill の 画面 evidence
cognitive load (上から下まで)北極星 → 副次 → roster → accordion 群 → governance (5 ブロック)narrative → hubs grid → sparkline trend (3 ブロック)
VC demo 適合性「reviewer 対応待ち = 北極星」 で 「経営判断 1 軸」 を訴求「narrative で組織の状態を picture / longitudinal trend を picture」 で moat 訴求
scope creep risk低 (同一 page 内 IA 改修)中 (sub-route 4 つ追加、 既存 muscle memory 破壊)
実装工数 (02_proposals 推定)M (4-6 day FE)L (12-18 day FE + RLS)

B mockup の polaris-card は 「1 つの数字に注目を集める」 デザイン、 C mockup の narrative-card は 「3 つの軸を並べて読ませる」 デザイン。 Justine が friend / mentor に共有する際、 どちらが longitudinal moat の picture-visible 化に効くか が Round 2 picked variant の判断軸になるはず。

12. VC demo 適合性

C を VC demo に出す場合の 「watch out」:

  1. sparkline 3 個は longitudinal moat の最大武器。 ただし suppressed sparkline 1 個を 必ず混ぜる ことで 「我々は k-anon を本気で gate している」 という誠実性を同時に訴求。 これは competitor (Otter / SmartHR / カオナビ等) が真似しにくい differentiator。
  2. 「固定テンプレート」 pill は VC にとって紛らわしい可能性。 「AI じゃないんだ?」 「じゃあ何ができるの?」 と聞かれた瞬間に 「集計 + 観察 + review-support signal」 の 3 点で即答できる準備が必要。 mockup の pill は defense として正しいが、 demo trial では tooltip を 「集計値を差し込んだ定型文。 判断は人が行います」 のように positive framing に書き換える候補。
  3. narrative-list 3 行目 (governance 4 lane) で 「semantic = OFF」 が見える。 demo org が semantic lane OFF だと 「機能の半分が無効化されていますね」 と読まれるリスク。 demo tenant では semantic_lane_enabled=true (memory 確認済) なので Round 2 で sample data を OFF → ON に差し替える検討。

13. canon-conflict 自己審査

canon結果本 mockup での該当箇所
X-01 個人離職リスクスコア NG PASS sparkline はすべて aggregate counts (teams 件数 / Plan C エスカレーション件数)。 個人 risk score 一切なし
X-02 manager grade ranking NG PASS landing は aggregate-only。 個別 manager / team は表示せず。 Hub 01 drill-in 先で 「alphabetical sort 固定」 (B mockup と同等仕様、 本 mockup の hub-helper にも明示)
X-03 org health single score NG PASS narrative-list 3 行は独立メトリクス。 narrative-headline も 3 行の要約のみ。 「82/100」 のような単一スコアなし。 governance 「4」 は lane 個数
X-04 AI narrative diagnosis NG PASS narrative-headline は固定テンプレ + 4 差し込み変数のみ。 「固定テンプレート」 pill で常時可視化。 「AI が組織問題を診断」 連想を打ち消す design defense あり
X-05 k-anon 未満 silent 表示 NG PASS suppression footer verbatim + sparkline 1 個を suppressed 状態で visible 表示。 「k-anon clear / blocked」 pill で gate 状態自体を画面に出す
個別 drill-down 制限 PASS landing から個人 drill-down 不可。 Hub 01 経由でも unlock 4 条件は B mockup と同等仕様 (mockup helper text で明示)
Role boundary 表示 PASS h1 直下に role-boundary-note 常時表示。 breadcrumb 直下にも eyebrow + Enterprise badge
赤 alert (X 系 NG) PASS trend up は amber、 sparkline 全て evergreen、 k-anon blocked は gray。 赤一切なし
eye icon / surveillance UI NG PASS icon は info circle / clock / lock のみ。 eye / camera / target icon なし

14. Justine 判断点 (Round 2 までに詰めるべき項目)

  1. narrative-headline の 1 文は canon owner と 1 文ずつ詰めるべき。 「window に入りました」 「主要な変化は」 等の修辞が判定や AI 解釈に読まれないか確認 (worker-facing trust canon owner = haseruida@? に確認)。
  2. 「固定テンプレート」 pill の copy は positive framing にすべきか defensive framing のままにするか。 friend / mentor feedback で 「pill 自体が攻撃的に見える」 と言われたら見直し。
  3. narrative-list 3 行目 (governance) の visual treatment。 数字 「4」 が単一スコアに読まれるリスクあり。 「4 mini chips のみ、 数字なし」 案が次善。
  4. sparkline 「7 週」 と observed window 「90 日」 の関係を画面で明示するか否か。 mockup では gate-reason 内のみ。 Round 2 で sparkline title 横に 「(7 週 × バケット 14 日 = 観察窓 98 日)」 のような technical disclosure を出す候補。
  5. VC demo で suppressed sparkline を 1 個必ず出す方針を Round 2 で固定するか。 「綺麗な画面」 vs 「誠実な画面」 のトレードオフ。 mockup は誠実側に振っている。
  6. hub 順序 (Review Candidates → Plan C → Positive → Governance) を変えるか。 現状は 「対応必要度の高さ順」。 「ガバナンスを最後尾」 は意図的だが、 「ガバナンス第一」 主張する mentor もいるかもしれない。

15. 実装フェーズへの引き継ぎ

このモックアップを React 実装する際の注意:

Generated by kashi-ui-mockupper · 2026-05-27 · Round 001 / Stage 3 (mockup) · Surface: /app/ceo · Variant C · companion to ./index.html