UI Research — mirror-me (Manager Mirror) — Round 1

Generated: 2026-05-27T00:00:00+09:00  |  Agent: kashi-ui-researcher  |  Surface: /app/mirror/me → resolves to /app/mirror/[managerId]  |  References analyzed: 6  |  Strong-signal patterns: 5  |  Canon-conflict exclusions: 3

1. Kashi 現状サマリ

ソースコード読み取り結果 (kashi/src/app/app/mirror/[managerId]/page.tsx) および canon 文書 (permanent-ui-principles.md, DATA_VISIBILITY_MATRIX.md, CANONICAL_PRODUCT_TRUTH.md) に基づく。 スクリーンショットは Round 1 の skip 判断により未参照。

主タスク
「自分が主催した直近ミーティングで何が起きていたか」を時系列・対話の質の観点で振り返る (Personal Reflection)
副タスク
(1) 観測ウィンドウ切り替え (30/90/180 日)
(2) チームのカバレッジ確認 (comparable / total / excluded 件数)
(3) Recommended Actions で次の行動を確認
(4) Dispute ボタンでデータに異議を申し立てる
(5) (Admin/CEO のみ) 匿名解除 (RevealNamesButton) でサブオーディナリーの実名を確認
データ密度
MetricCard ×6 (interruptions / concentration / directionality / Gini / persistence / sustained-drop-days), InterruptionBars チャート, SpeakingTrendChart, IgnoredTurnCount リスト ×2 (受信・送信), ChillingEvents リスト, GracePeriod パネル, PositiveCount グリッド ×5, AdaptationWatch アラート, Evidence-grade + ReasonCodes, CoverageStrip — 合計 10 以上のデータ領域が単一スクロール縦積みで配置
アクション
Dispute ボタン 1 つ / RevealNamesButton (role-gated) / Upload CTA (empty state 時のみ)
ナビゲーション文脈
PortalHeader のみ。Back リンクが /app/ceo に向いており、Manager が自分の mirror を見る際のコンテキストが不明確。
既知の UI 不整合
r19 applicability audit 31/35 APPLIES: 色トークン未実装 (18 件インライン hex), タイポグラフィ階層の不統一, Card variant の混在, 開示パターン不統一 (native <details> vs カスタム)
Justine の不満 (推定)
complaints.md は Round 1 で未提供 (skip) のため推測: 「何を見ればいいか最初にわからない」(cognitive overload), 「数値の意味・文脈が把握しにくい」(no interpretation layer), 「empty state が何もなさすぎる / 怖い」(no-signal ambiguity), 「back リンクが CEO に行く — 自分のページなのに」(navigation confusion)

データ可視性の制約 (canon 由来、設計上絶対に変えられない)

2. 参照リファレンス (N = 6)

# Ref URL Archetype 取得方法 / 調査ソース
R1 Lattice 1on1 https://lattice.com/performance/one-on-ones Manager-employee 1on1 継続記録 + reflection WebFetch (2026-05-27), WebSearch, マーケティングページ + help docs
R2 15Five Check-ins https://success.15five.com/hc/en-us/articles/360002698971-Check-ins-Feature-Overview 週次 check-in / manager review 5 分フロー WebFetch (2026-05-27), Help center ドキュメント
R3 Linear (redesigned UI) https://linear.app/now/how-we-redesigned-the-linear-ui 高密度 issue tracker / sidebar IA / 情報密度 vs whitespace WebFetch (2026-05-27), 公式ブログ (Linear team)
R4 Vercel Dashboard https://vercel.com/blog/dashboard-redesign Status-first card grid / progressive disclosure / role-split WebFetch (2026-05-27), 公式ブログ (Vercel team)
R5 Stripe Dashboard https://docs.stripe.com/dashboard/basics Financial metrics card / sparse KPI → detail drill-down WebSearch + Orbix Studio analysis (2026-05-27), 公式 docs + UX analysis
R6 HiManager (ハイマネージャー) https://himanager.me/1on1 日本 B2B / 1on1 マネージャー機能 / OKR + weekly survey WebSearch + SaaS比較サイト (2026-05-27)

選定理由: R1/R2 は reflection-driven manager dashboard の直接的 archetype (私的な振り返り + チームへの介入ではなく自己改善)。 R3/R4 は情報密度・sidebar IA・progressive disclosure パターンのリファレンス。 R5 は sparse metric card + sparkline + drill-down パターン (Kashi の MetricCard 系に最も近い)。 R6 は日本市場 B2B SaaS かつ 1on1 中心のマネジメントフローで Kashi のターゲット文脈に最も近い。

3. 強信号パターン (≥3 references で観察)

各パターンは独立して ≥3 refs で確認済み。単一 ref 観察のパターンは §4 (弱信号) へ。

強信号 P1   Summary-first / 数値より解釈を先に見せる
Pattern 説明 Kashi 現状の課題との対応 観察 refs Kashi 互換性

KPI サマリー → 詳細 という 2 層構造

最初の viewport に「今期の状態を 1 行で表す文章 or 単一ステータス」を置き、 数値グリッドはその下に畳む。 Stripe: "revenue + sparkline" が fold 上、詳細は never more than 2 clicks away。 Vercel: "Production deployment status (1 badge)" が fold 上、ログは drill-down。 15Five: Manager が最初に見るのは pulse の概要 ("全員が check-in 済み / 未" 行)、個別回答は次ステップ。 Orbix/B2B SaaS analysis: "Primary metrics require no more than one click from dashboard home. If users cannot identify the most important number in under 10 seconds, the hierarchy needs revision."

現在の mirror-me は MetricCard が 6 枚 + チャート 2 枚 + リスト 3 系統 + GracePeriod + Positive が 縦スクロールで同一重みで並列している。 「今週の自分に最重要なシグナルはどれか」が一目でわからない。 これは Kashi のコア価値「longitudinal 構造を manager 自身が解釈できる」を損なう。 Stripe (R5), Vercel (R4), 15Five (R2), Orbix/B2B analysis — 4/6 ✓ 直接適用可

Kashi では「Evidence Grade」が既に summary-level signal として存在する (BLOCKED / INSUFFICIENT / WEAK / EMERGING / STABLE / HIGH_CONFIDENCE_STABLE)。 これを fold 上の 単一ステータスバナー として最優先で見せ、 MetricCard 群はその下の "詳細" 層に配置するだけで構造的に解決できる。

permanent-ui-principles.md §7 の "Default visible layer: one headline / one short explanation / 3-5 cards / one primary CTA" と完全一致。 canon が既にこの構造を要請している — 実装が追いついていないだけ。
強信号 P2   時系列 / 観測ウィンドウの明示と文脈の固定
Pattern 説明 Kashi 現状の課題との対応 観察 refs Kashi 互換性

「今見ているのは何日分か」を常時表示し、ウィンドウを切り替えたら全カード同時更新

GitHub contribution graph: rolling 12-month window が常にグラフに付記。 Vercel: deployment list は "Production + Preview" の 2 ウィンドウを明示。 15Five: "Check-in for week of YYYY-MM-DD" が見出しに固定。 Lattice: 1on1 ヒストリーが "recent meetings" として時系列で固定。 Stripe analytics: "Last 30 / 90 days" selector が全カードに連動。

現在の mirror-me には TimeWindowToggle (30/90/180) は実装済みだが、 MANAGER_MIRROR_WINDOW_AWARE flag = true になっている。 ただし coverage strip と MetricCard が 別々の場所に散在しており、 「何日分を見ているか」という文脈が画面の中で視覚的に統合されていない。 Back-link が /app/ceo を向いており、Manager が自分の mirror として認識できるのも遅い。 GitHub (longitudinal self-data design), Vercel (R4), 15Five (R2), Stripe (R5), Lattice (R1) — 5/6 ✓ 直接適用可

permanent-ui-principles.md §5: "Evidence grade is not a verdict. Every serious signal must show: observed window / data quality status / what this does NOT prove." — ウィンドウを常時表示することは canon 要求事項そのもの。

permanent-ui-principles.md §9 (Dashboard Rules): "Every dashboard card must answer: what is shown? who is this about? what window?" — 現状はウィンドウ情報が coverage strip に隠れており、カード個々に付かない。

実装レベルでは: window badge をページ H1 直下に固定し、全 MetricCard に windowDays prop を既に渡している設計を活かして small "last N days" テキストをカードに付ける。 これは AC-06 (mirror コードコメント内) でも要求されている。
強信号 P3   正直な empty/insufficient state — 「なぜデータがないか」を説明する
Pattern 説明 Kashi 現状の課題との対応 観察 refs Kashi 互換性

Empty state = 「理由を言う + 次のアクションを 1 つ示す」

Linear: no-issue state は "All caught up — no open issues" + next action "Browse projects"。 15Five: check-in 未提出の場合 "Your team hasn't submitted yet — reminder sent" という状態説明。 Vercel: 初回 deploy 前は "Deploy your first project" + explicit CTA — blank screen ではない。 Stripe: no-transaction state は "Awaiting your first payment — get started with test mode"。 B2B SaaS general pattern: "Good copywriting is the soul of an effective empty state — replace silence with tone, context, empathy, and direction."

現在の mirror-me の BLOCKED/INSUFFICIENT 状態は <Info icon> + blockedTitle + blockedBody + reasonCodes list という構成だが、「次に何をすればいいか」というアクションが欠落している (empty state では upload CTA が出るが BLOCKED/INSUFFICIENT パスでは出ない)。

また permanent-ui-principles.md §6 の "no signal rule" は 「No qualifying signal ≠ no issue」と明記しているが、 現状のコピーが十分に this-is-why-we-don't-know を伝えているかは スクリーンショット未取得のため不明 (Round 2 で検証)。 		Linear (R3), 15Five (R2), Vercel (R4), Stripe (R5) — 4/6 ✓ 直接適用可 (ただし canon セマンティクス要注意)

permanent-ui-principles.md §6 + CANONICAL_PRODUCT_TRUTH.md §4.3: empty state は "no qualifying signal in this observed window" + 実際の理由 (insufficient meetings / low diarization quality / etc.) を列挙しなければならない。

参照 SaaS の empty state パターン ("All caught up!" 系) は Kashi では使用禁止 — "no problem / all clear / no issue detected" は forbidden wording (permanent-ui-principles.md §2)。

適用できるのは「理由列挙 + 次の CTA」の構造のみ。 コピーは canonical empty state library (EMPTY_STATE_AND_NO_SIGNAL_COPY_LIBRARY.md) から引く。
強信号 P4   Progressive disclosure — 初期 view は interpretation layer、数値は fold 以下
Pattern 説明 Kashi 現状の課題との対応 観察 refs Kashi 互換性

「意味」→「数値の根拠」→「生データ」という 3 層の段階的開示

Lattice 1on1: agenda / action items が先 → sentiment data は "growth areas" として折りたたまれる。 15Five: pulse summary → individual responses は collapsible。 Stripe: KPI 数値先 → transaction list は separate page → raw export は 2 clicks away。 Linear: issue summary card → detail panel → sub-issues は expand。 Vercel: deployment status badge → log は inline expandable → specific function log はさらにフィルター。 Orbix/B2B: "summary first, detail on demand" が全 10 examples に共通。

現在の mirror-me は 3 層がフラットに縦積みされている: MetricCard (数値) → ChartPanel (ビジュアル) → ListSection (raw 件数) が同一視覚重みで並ぶ。 「この数値が意味するのは何か」という interpretation テキストは 各カードの sub prop に短文で入っているが、 hierarchy 上では数値と同重みのため読み飛ばされやすい。

r19 所見 (7.1): "ManagerMirrorSection.tsx:168 — dense paragraph with structural definition" = 同じ問題が demo page にも既に指摘されている。 		Lattice (R1), 15Five (R2), Stripe (R5), Vercel (R4), Linear (R3), Orbix/B2B — 6/6 ✓ 直接適用可

permanent-ui-principles.md §7 (Progressive Disclosure): "Default visible layer: one headline / one short explanation / 3-5 cards / one primary CTA. Fold or route: legal detail / technical doctrine / source lists / implementation notes / edge cases"

permanent-ui-principles.md §8 (Cognitive Load): "A screen fails if everything looks equally important."

実装では: Evidence Grade バナー (=interpretation) → MetricCard 3 枚 (=数値) → Chart (=tracing) → List (=raw events) という明示的な 4 層を付けるだけで対応可能。 GreacePeriod / Positive / AdaptationWatch は役割が異なるため、 translator が tier 配置を判断すべき事項。
強信号 P5   ポジティブシグナルを先出し / reflection を "審判" ではなく "自己認識" フレームで提示
Pattern 説明 Kashi 現状の課題との対応 観察 refs Kashi 互換性

「うまくいっていること」を先に見せてから「改善余地」を見せる

15Five: Priorities 達成 → High Five (peer recognition) → future priorities という順序。 Lattice: 1on1 ではまず "growth areas" の positive side → action items。 HiManager: OKR 達成度 (positive) → 1on1 での課題 という順序で weekly survey を設計。 Notion reflection templates: "Wins" section が "Challenges" より先に来るテンプレートが多数。 B2B coaching 全般: "Tell me what's working before what's not" が retention に繋がることが指摘されている。

現在の mirror-me にはポジティブシグナル表示 (PositiveCount グリッド) が実装済みだが、 GracePeriod パネルの直後に来ており、問題先出しの流れの中に埋まっている。 Manager が最初に目にするのは reveal-names プロンプト → AdaptationWatch アラート → BLOCKED/INSUFFICIENT の順序。

Kashi の mirror 命名意図 (鏡 = 自己認識) と、 問題点を先に出す現在の view 順序に矛盾がある。 		15Five (R2), Lattice (R1), HiManager (R6), Notion reflection templates, B2B coaching research — 5/6 △ 要調整 — canon の no-signal rule に注意

直接的な適用: PositiveCount セクションを view の序盤 (Evidence Grade バナーの直後) に移動。

注意点: ポジティブシグナルを先出しする際、 「問題なし / オールクリア」という impression を与えてはならない。 permanent-ui-principles.md §6: "No qualifying signal never means no issue." CANONICAL_PRODUCT_TRUTH.md §2: "no problem / safe team / clean manager" = forbidden wording。

適用形: PositiveCount 先出し + "これは観測されたポジティブパターンです。別の問題の不在を意味しません" という boundary コピー (1 行) をセットにする。 Canon の safe wording "no qualifying signal in this observed window" を流用可。

4. 弱信号 (1-2 refs のみ — 参考まで、推奨には至らない)

5. Kashi canon に反するため採用しないパターン

除外理由は全て canon 文書に根拠がある。単なる「好み」ではない。
除外パターン 参照 ref Canon 違反根拠
「AI があなたのチームリスクを分析しました」系バナー
15Five / HiManager の "pulse score" や "engagement risk alert" の出し方を Manager mirror に転用するパターン 		R2, R6 permanent-ui-principles.md §1: "HR decision automation / AI magic" NG
permanent-ui-principles.md §2 forbidden wording: "at-risk employee / organizational health score / team health score / predicts resignation"
CANONICAL_PRODUCT_TRUTH.md §2: "Kashi is NOT a culture-health / team-health / organizational-health score"

Manager mirror が「あなたのチームは危険信号です」系の UI になると、 「監視・予測ツール」のフレームを強化し、 Kashi の core doctrine (structure-not-content + observation only) を完全に破る。
サブオーディナリーの個人名 + 感情スコア表示
Lattice の 1on1 が "sentiment data / growth areas" を名前付きで表示するパターン 		R1 DATA_VISIBILITY_MATRIX.md §3: Manager は "Named subordinate reports" を見られない
permanent-ui-principles.md §4 (Manager 視認境界): "Must NOT see: named subordinate reports / private employee pages"
permanent-ui-principles.md §2 forbidden wording: "detects mental state / detects emotion / detects intent"

現在の Kashi も anonymized で表示しており (reveal は Admin/CEO + audit-log)、 Lattice のような「名前 + 感情状態」UIは RLS 違反となる。
リーダーボード / チーム内ランキング
HiManager の OKR 達成度ランキング表示や、 15Five の "top performing teams" バナー 		R6, R2 permanent-ui-principles.md §9 (Dashboard Rules): "No dashboard may: rank people morally / label people as risky / imply health score"
permanent-ui-principles.md §1: "real-time leaderboards of employees" は surveillance feel の典型

Kashi の mirror は Manager 自身の self-reflection。 他の Manager との比較や部下の達成度ランキングは surveillance feel を直接生み出す。

6. translator への引き継ぎメモ

最も解決インパクトが大きいパターン上位 3 つ (実装難易度も考慮)
  1. P1 + P4 の組み合わせ — Evidence Grade を fold 上に昇格し、全 MetricCard を fold 以下に移動する
    現在 fold 上はタイトル + window toggle + coverage strip だが、 Manager が最初に知るべきは「今期の自分のシグナルの信頼度がどのレベルか」であるはず。 Evidence Grade badge (STABLE / EMERGING / BLOCKED 等) を H1 直下に大きく配置し、 その下に 1 行 interpretation テキスト、その下に MetricCard 3 枚 (最重要 3 つに絞る) という順序に。 これで P1/P4 + canon §7/§8/§9 を一度に満たす。
    既存の Evidence Grade コンポーネントと MetricCard は実装済み — 順序の変更のみ。
  2. P3 — BLOCKED/INSUFFICIENT state に「次のアクション」を 1 つ追加する
    現状: reasonCodes リスト で終わる。 追加: "チームのカバレッジを確認する" → /app/admin/coverage へのリンク 1 つ、 または "新しいミーティングを追加する" → upload CTA。 Canon §6 (no-signal rule) は「なぜデータがないかを説明せよ」と要求しており、 これはその延長として「何をすればデータが増えるか」を示すことで doctrinal に安全。
  3. P5 — PositiveCount を GracePeriod より前に移動し、boundary コピーをセットにする
    「うまくいっていること」先出し → 「観測された課題」の順序に変更。 ただし必ず: "これらは観測されたポジティブ構造シグナルです。別の問題の不在を意味しません" という 1 行の canon-safe boundary copy をセットにすること。 forbidden wording ("nothing wrong / all clear") を使わずに実現する方法は EMPTY_STATE_AND_NO_SIGNAL_COPY_LIBRARY.md に canonical copy が存在する。
絶対に外せない Kashi 制約 (translator は必ず守ること)

リファレンス元 URL 一覧 (citation grading のため再掲): lattice.com/performance/one-on-ones | 15five.com Help Center: Check-ins | linear.app/now/how-we-redesigned-the-linear-ui | vercel.com/blog/dashboard-redesign | docs.stripe.com/dashboard/basics | himanager.me/1on1 | orbix.studio B2B SaaS Dashboard Design | memorable.design empty state examples