/app/me は一般従業員 (role = member) がログイン後に着地するプライベートページ。
他ロールはリダイレクトで排除される。 このページの主タスクは
「自分の会議での構造的パターンを確認し、自分のデータがどう扱われているか把握する」 こと。
| 観点 | 現状 |
|---|---|
| 主タスク | 自分の発言機会 (speaking opportunity) / 割り込まれ率 / 無視・未回答率 の確認。 エビデンスが不足している場合はその理由の把握。 |
| 副タスク |
Notice 履歴の確認 (自分に何が通知されたか) ·
監査ログ /app/me/audit の参照 (誰が自分のデータを閲覧したか) ·
異議申し立て (DisputeButton) ·
Governance ページへのリンク
|
| データ密度 | セクション A–I の 9 ブロック (privacy banner / role-description / evidence readiness / speaking / interruption / ignored / what-Kashi-doesn't-know / notice history / audit link / disputes)。 時間窓トグル (30/90/180日) 付き。 1 ページが長く、一覧性が低い可能性。 |
| ナビゲーション文脈 | PortalHeader の nav bar に "My Personal" (myPersonal) リンクとして露出。 member ロールではこのリンクと "My Audit" の 2 項目のみ表示。 |
| 主な設計上の制約 |
|
| 対応する Justine の不満 (推定) | complaints.md は未提供のため仮説: (1) 9 ブロックの縦長ページがどこから読めばいいか分からない; (2) 「データが不足しています」系の空状態が冷たく、 next action が見えない; (3) Audit ログ・Dispute が下部に埋もれており、 Employee empowerment の訴求が薄い; (4) "What Kashi does not know" セクションが法的免責文のように読める。 |
#1F4A33 / #244A3D のインライン指定が admin/reviewer 配下に散見されるが、 me ページは emerald-* Tailwind クラスを直接使用しており、 token 統一待ち。
| # | Ref | URL / 調査ソース | Archetype | 取得方法 |
|---|---|---|---|---|
| R1 | Linear | linear.app (marketing page, product screenshots) | Personal task self-view ("My Issues", Inbox) | WebFetch 2026-05-27 |
| R2 | Stripe Dashboard | docs.stripe.com/dashboard/basics | Financial self-data view with role-aware density + audit trail | WebFetch 2026-05-27 |
| R3 | Lattice (Employee Updates) | lattice.com/platform/performance/updates | Employee self-reflection + 1on1 prep, privacy toggle | WebFetch + WebSearch 2026-05-27 |
| R4 | Notion Personal Dashboard | notion.com/help/guides/personal-work-dashboard | Personal workspace — today-first hierarchy, multi-view card | WebFetch 2026-05-27 |
| R5 | Superhuman | superhuman.com (marketing + reviews, clean.email review 2026) | Personal productivity — split inbox, auto-label, keyboard-first | WebSearch 2026-05-27 |
| R6 | GitHub Profile / Contribution Graph | github.com community docs + privacy discussion #4098 | Personal longitudinal self-data — heatmap + privacy controls | WebSearch 2026-05-27 |
補足: Plaid (Consumer Reports, Portal), SmartHR, Apple Health も WebFetch / WebSearch で調査したが、 公開 URL からパターン情報が十分に取れなかった (404 / login-required / 汎用マーケティングコピーのみ)。 これらはデータ不足として除外し、上記 6 refs で分析を実施した。
以下の各パターンは 3 つ以上の参照で共通して観察されたもの。 N=1 / N=2 の観察はセクション 4 (弱信号) に移動済み。
パターンの説明: 最も重要な「今の情報」を画面上部に固定し、 過去データや設定系コンテンツは下部またはドリルダウンに送る。 Linear の "Inbox" / "My Issues" では進行中タスクを先頭に、 Superhuman では"今日返信が必要なメール"を先頭に配置する。 Notion の personal dashboard は "Today's Tasks" セクションを最上部に置き、 過去の目標・履歴は別ビュー。
| Kashi /app/me への適用 | 対応する課題 | Kashi 互換性 |
|---|---|---|
| 現状は A–I の 9 ブロックがすべて同じ視覚重量で縦並び。 "直近の時間窓でエビデンスが出ている場合" にはそのシグナルを最上部に集約し、 "エビデンス不足の場合" には "次に必要なアクション (次の 1on1 準備、ミーティング参加数増加)" を最上部に表示する切り替えが検討できる。 | 推定不満 (1): ページがどこから読めばいいか分からない → landing focus の不在。 9 ブロック全部が equally important に見える (permanent-ui-principles §8 "a screen fails if everything looks equally important") |
✓ 直接適用可 「今日の状態」フレームは監視感と無関係。 エビデンス readiness を"お知らせ"として最上部に置くのは §7 progressive disclosure と整合。 ただし "高エビデンス状態" のシグナルカードを上部に出す際は §5 evidence semantics (grade + reason codes + observed window + what it does NOT prove) の全表示を維持すること。 |
パターンの説明: ランディングページには 3–5 枚の要約カードのみ置き、詳細 (数値の内訳・reason codes・証拠の根拠) はクリック/展開で出す。 Stripe dashboard は Home に「カスタマイズ可能なウィジェット」を置き、 "Add" ボタンで増やす仕組み。 Linear は issue 一覧でタイトル + ステータスバッジだけ見せ、 本文・コメントは issue ページへ。
| Kashi /app/me への適用 | 対応する課題 | Kashi 互換性 |
|---|---|---|
現状の "What Kashi does not know" (7 bullet) セクション、 Notice history テーブル、 Dispute テーブルは
折りたたみ or 別ページ (/app/me/notices, /app/me/disputes) に移すことで、
ランディング画面の視認性を高められる。
Evidence readiness + speaking + interruption + ignored の 4 カードを fold の上に集約し、
remaining は accordion / drawer で。
|
推定不満 (1) の延長: ページが長すぎる。 permanent-ui-principles §7: "default visible: 3–5 cards / one primary CTA / one trust note — fold or route: legal detail / source lists / long limitation lists" |
✓ 直接適用可 §7 が明示的にこのパターンを要求している。 折りたたみにしても governance 経路は残すこと (§11 internal screen requirements)。 evidence semantics (§5) は summary カードにも最小セット (grade + 1 reason code + window) を残す必要がある — 詳細を完全に隠してはいけない。 |
パターンの説明: ユーザーが自分のデータの「所有者」であることを UI で明示する。 Lattice はプライバシートグルを update 入力フォームに配置。 GitHub は contribution graph の "private contributions" 表示切替を profile 設定に置く。 Stripe は team member が自分のアクセス権限一覧を確認できる。 Superhuman は"your data stays on your device"をマーケティングレベルで前面化する。
| Kashi /app/me への適用 | 対応する課題 | Kashi 互換性 |
|---|---|---|
現状の privacy banner (§A) は上部に存在するが、 能動的なコントロール UI が不在。
「あなたのデータへのアクセス履歴を見る」→ /app/me/audit が最強の privacy ownership ツールだが、
現状は §H の audit-link-card として下部に埋もれている。
これを上部 (privacy banner の直下か、 banner 内) に "アクセス履歴を確認する →" ボタンとして露出することで、
「見られている感」ではなく「いつでも確認できる」安心感に転換できる。
|
推定不満 (3): Employee empowerment (監査・異議申し立て) が下部に埋もれている。 DATA_VISIBILITY_MATRIX §7: "audit log surface is the single most important visibility surface for the worker-trust posture" |
✓ 直接適用可 この方向は permanent-ui-principles §1 ("role boundaries before dashboards") および §4 ("May see: own audit log of access to their data / challenge / dispute controls") と完全一致。 監視感 NG ではなく逆 — 従業員が監視されていないことを確認できる UI が必要。 |
パターンの説明: 数値単体ではなく「その数値がどれだけ信頼できるか」「どの状態にあるか」を色 + テキスト badge で同時に示す。 Stripe は単一の数値リスクスコアを使わず、 複数の状態インジケータを組み合わせる。 Linear は priority + status + progress の 3 要素を常に同時表示する。
| Kashi /app/me への適用 | 対応する課題 | Kashi 互換性 |
|---|---|---|
現状の MetricCard は value + sub (evidence grade label) の 2 層だが、
CoverageReadinessPill は別カード (evidence-readiness-card) に置かれており、
個々のシグナルカードと readiness pill が視覚的に結びついていない。
Linear パターンを援用し、 speaking / interruption / ignored 各カードに
evidence grade pill を直接バッジとして重ねる (color + text、 §5 準拠) ことで、
「このデータはどれだけ確かか」が一目でわかる。
|
推定不満 (2): 「データが不足しています」系の空状態が何を意味するか不明。 permanent-ui-principles §5: "every signal must show evidence grade + reason codes + observed window" §8: "a screen fails if everything looks equally important" |
✓ 直接適用可 design_system_v1.md §1 が evidence-grade badge tokens ( --kashi-grade-*) を定義済み。
color-only NG — テキストラベル必須 (§12 a11y rule)。
"STABLE" badge が "harassment confirmed" に誤読されないよう reason code + "not a verdict" copy を同時表示すること (§5 rules)。
|
パターンの説明: 空状態 (データなし / エビデンス不足) を「エラー」ではなく「次のアクションへの入口」として設計する。 Linear は inbox ゼロを "You're all caught up" と肯定的に表現。 Superhuman は "Inbox Zero" を達成感として演出。 Lattice は空の update セクションを "respond to questions to show your team what you're working on" という行動を促すコピーで埋める。
| Kashi /app/me への適用 | 対応する課題 | Kashi 互換性 |
|---|---|---|
現状の "unavailable" 状態は dashed border + 灰色テキストの静的なブロック。
i18n key me.privatePattern.speakingOpportunityCard.unavailable の内容次第だが、
パターン上はここに "次のミーティングで何を確認するか" / "time window を変更してみる" / "ミーティングが追加されると自動更新されます" のような
next-step コピーを付けることで、 空状態が「行き止まり」でなくなる。
Notice history empty / Disputes empty も同様。
|
推定不満 (2): 「データが不足しています」系の空状態が冷たく next action が見えない。 permanent-ui-principles §6: "every no-signal screen must explain the actual state" (reason codes required). §7: "Fold or route: edge cases" — ただし empty state は fold ではなく explain が必要。 |
△ 要調整 §6 "No Signal Rule" が厳格に「理由コードの明示」を要求している。 Lattice / Linear スタイルの "次のアクションを示す" は使えるが、 コピーに "データが揃えば問題検知できます" 的なニュアンスを入れると §2 forbidden wording (predicts / detects) に抵触するリスクがある。 safe wording: "観察ウィンドウ内に比較可能なミーティングが増えると、このカードが更新されます" 等。 |
permanent-ui-principles §1 「CEO surveillance dashboard」フレームに抵触する。
また、 employer 側に自分の page view 履歴を見せる仕組みは §4 "Must NOT expose to employer by default: page views" に直接違反する。
/app/me/audit) は "who accessed YOUR data" のみ表示する現行設計を維持。 "あなたが何をいつ見たか" は記録・公開しない。
permanent-ui-principles §2
forbidden wording 「organizational health score」「team health score」「productivity score」 に抵触。
employee が自分の "risk level" を見せられると、 §1 "resignation prediction / mental-health prediction" のフレームを作る。
/app/me/audit へのリンクを privacy banner 内または直下に配置し直す。
DATA_VISIBILITY_MATRIX §7 が "most important visibility surface for worker-trust" と明言しているにもかかわらず、 現行 UI では §H (下から 3 番目) に埋もれている。
コード変更は最小 (リンク移動のみ)、 trust への影響は大。
design_system_v1 §1 + permanent-ui-principles §12)§5)DATA_VISIBILITY_MATRIX §3 の Member 列を必ずチェックMemberRevealButton 経由のみ| # | URL | アクセス日 | 取得情報 |
|---|---|---|---|
| R1 | linear.app (marketing/product page) | 2026-05-27 | Sidebar IA (Inbox / My Issues), status badge pattern, activity timeline, information hierarchy from marketing screenshots |
| R2 | docs.stripe.com/dashboard/basics | 2026-05-27 | 3-level IA, widget/card layout, progressive disclosure ("More" menu), role-aware density, empty state (shortcuts section), keyboard shortcut modal (?) |
| R3 | lattice.com/platform/performance/updates + WebSearch (lattice.com 2026) | 2026-05-27 | Employee update card UI, privacy toggle ("public or private"), longitudinal aggregation, export/CSV, engagement data coupling |
| R4 | notion.com/help/guides/personal-work-dashboard | 2026-05-27 | Today-first hierarchy, table/board/calendar multi-view, linked databases for personal vs shared data, task status badges (Not started / In progress / Done) |
| R5 | superhuman.com + clean.email review 2026 + efficient.app/apps/superhuman | 2026-05-27 | Split Inbox (auto-label categories), keyboard-first UX, <100ms response pattern, "Inbox Zero" positive framing, data-on-device privacy posture, SOC2 trust signal |
| R6 | github.com community discussions #4098 + GitHub Docs (contribution visibility settings) | 2026-05-27 | Contribution heatmap (longitudinal self-data), private contribution toggle, community push-back on forced public activity graph, opt-out privacy control pattern |