Kashi (対話不全の早期検知 SaaS) の UI を 2 領域 で A/B/C 比較するための試作集です。 (1) ポストログイン = 役割別 5 面 (Manager / Employee / Admin / CEO / Reviewer) の post-login dashboard、 A 保守 / B 中庸 (推奨) / C 大胆 inbox 統一。 (2) 公開サイト = marketing 6 page (top / why / why-now / product / pilot / contact)、 A ものすごく B2B / B ものすごく B2C / C 記事主体 (note 風) の **brand tone 振り切り** 比較。 すべて static HTML / dummy data で本番未接続。 視覚比較して 「ここは A の方が好き」 「この surface だけ C にすべき」 「全体的に AI 感が抜けない」 等の意見があれば surface/page 単位で Justine に渡してください。
1 surface につき A → B → C を順に開いて視覚比較してください。 各セルの DD = DESIGN_DECISIONS.html (なぜこの設計か / canon との関係 / trade-off)。 翻訳者 5 名が独立に B を推奨。
| Surface | A 保守的 visual cleanup のみ |
B 中庸 ★ Picked IA 再構成 + primary-task focus |
C 大胆 unified task-inbox |
|---|---|---|---|
| mirror-me (Manager 最優先 persona) |
mockup · DD | mockup · DD | mockup · DD |
| app-me (Employee / 一般従業員) |
mockup · DD | mockup · DD | mockup · DD |
| app-admin (Admin / 人事・組織管理) |
mockup · DD | mockup · DD | mockup · DD |
| app-ceo (CEO / 経営層) |
mockup · DD | mockup · DD | mockup · DD |
| app-reviewer (Reviewer / 第三者立会) |
mockup · DD | mockup · DD | mockup · DD |
公開サイト (marketing) の brand tone を 3 極で振り切った 試作。 「同じ Kashi でも、 どの読者を想定するかで見た目がここまで変わる」 を 6 page × 3 variants で並べました。 変種の意味が違う: ポストログインの A/B/C は 機能 IA の保守度、 公開サイトの A/B/C は brand tone の極。
| Page | A ものすごく B2B 大企業 / 人事部長 / dense data + keigo |
B ものすごく B2C 個人 Manager / warm + 「あなた」 |
C 記事主体 (note 風) long-form essay / 6 章物語 |
|---|---|---|---|
| top (/) | mockup · DD | mockup · DD | mockup · DD |
| why (/why) | mockup · DD | mockup · DD | mockup · DD |
| why-now (/why-now) | mockup · DD | mockup · DD | mockup · DD |
| product (/product) | mockup · DD | mockup · DD | mockup · DD |
| pilot (/pilot) | mockup · DD | mockup · DD | mockup · DD |
| contact (/contact) | mockup · DD | mockup · DD | mockup · DD |
サイト 3 variants の本質: A = 稟議書添付 / ROI 比較表 / ISO 27001 / 「貴社」 keigo / sticky CTA / corporate dense (大企業向け極) ・ B = 「あなたのチームで、 何が起きているか」 / cream+peach / warm photo / 二人称 / 「無料で試す」 / 1 列縦長 (個人向け極) ・ C = 6 page を 1 つの 6 章物語に再構成 / Fraunces 大きく / max-width 680px / cream / 末尾に控えめ 1 CTA / note 編集記事として転載可能な体裁 (思考的読者向け極)。 一番刺さる極を確かめるための試作集です。
各 mockupper が flag した 「これ Justine に確認してほしい」 1 件ずつ (18 件):
PilotRequestForm を完全削除、 唯一の engage は /contact への link → 「問いを持っている SaaS」 の literal 体現だが conversion を 80%+ 落とす役割: チームリーダーが週次 1on1 や チームミーティングを振り返り、 対話不全の早期サインを 自分自身の reflection として 見る画面。 部下を監視するツールではありません。
B の特徴: Tier 1-5 構造化 (Banner → 3 主要 metric card → Positive section → 詳細折り畳み → empty state)、 MetricCard 6 個 → 3 個に厳選 (Concentration / Persistence / Speaking trend は accordion 内)、 「Positive signals」 表示時には verbatim boundary copy で 「これは問題なしを意味しない」 明示。
確認してほしいこと: ① Manager として 「最初に何を見るか」 が一目で分かるか / ② 監視感 (部下を見ている感) が出ていないか / ③ 6 metric を 3 に絞った判断は妥当か / ④ もし C (inbox 統一) の方が直感的か
役割: 一般従業員が自分の発言を振り返り、 次の 1on1 に備える画面。 上司の評価などは見えません (DATA_VISIBILITY_MATRIX: Member 列 Y(self) のみ)。 「自分が監視されている」 と感じさせない reflection-driven 設計が肝。
B の特徴: 9 ブロックを 「Privacy banner upgrade + Today's Reflection card + 3 signal cards + Accordion 統合 (§G/§H/§I/§B)」 に再構成。 P1 Today-first / P2 Progressive disclosure / P3 Privacy ownership framing 採用。
確認してほしいこと: ① Today's Reflection の passive framing が安心感を産むか / ② privacy banner の上部昇格が監視感を煽るか or 安心感か / ③ §G (Kashi が見えていないこと) を accordion 封印は OK か
役割: テナント管理者 (人事 / IT) がユーザー管理・課金・組織設定を行う画面。 ミーティングの中身は見えない (DATA_VISIBILITY_MATRIX §3、 SmartHR / カオナビ-style HR surveillance との明確な差別化)。
B の特徴: P-1 setup checklist evolved → 完了後 Manager Mirror URL 共有 CTA / P-3 3-layer action architecture (Primary 1 / Secondary 4 / Tertiary 6 fold) / P-4 Scope Boundary Banner H1 直下恒久配置。 「分析 / ミーティング詳細 / メンバー発言」 系の CTA = 0 件 (canon 違反の構造的予防)。
確認してほしいこと: ① Scope Boundary Banner (「中身は見えません」) は安心感を産むか it's overbearing か / ② 11 アクションを 3 層に分けた判断 (B) vs flat grid (A) vs operational inbox (C) / ③ ラベル改訂 (Longitudinal → 稼働状況確認 等) の自然さ
役割: 経営層が全社・部門別の対話健全性傾向を 集約 metrics のみ で俯瞰する画面。 個別ミーティング・個人発言は不可視、 k-anonymity 5 名未満は suppress (「観察ウィンドウ内でチーム規模が比較可能になると更新されます」)。
B の特徴: 「Review Candidates 3 of 14」 を北極星 metric として H1 直下に昇格、 Plan C と Positive section を折り畳み、 ExecutiveAggregateSection を 4 chips に圧縮、 governance を sub-route 化。 P-07 sparkline は今回 hard-gate 未実装 (Round 2 候補)。
確認してほしいこと: ① 「Review Candidates 3 of 14」 を北極星にした判断は VC demo で 「経営層が何を見るか」 として正解か / ② C (narrative card + sparkline) は VC demo で longitudinal moat を picture-visible にするのに向くか
役割: 第三者立会的な役割 (人事中立観察者 / 産業医 / 外部メンター 等) が割り当てられた特定ミーティングを確認し、 介入要否を判断する画面。 全社俯瞰や他チームは不可視。
B の特徴: Active-first 並び替え + 各 card 直下に scope-safe inline ミニサマリー (evidence grade / reason code / meeting count / earliest date) + 4 決定 chip 「受理 / 却下 / 追加情報を要求 / エスカレーション」 を inline 常時表示。 hover preview は構造的に廃止 (identity 漏出経路を閉鎖)。 EyeOff → FileSearch 統一。
確認してほしいこと: ① Active-first IA の自然さ / ② 4 chip 密度 (1 card 内 4 つは多すぎないか) / ③ k-anon suppression 文言の自然さ / ④ ja_JP 全体の自然さ
全 15 mockup は以下の canon を厳守:
| 原則 | 意味 | 15 mockup の状況 |
|---|---|---|
| 監視感 NG | eye / camera / police アイコン無し、 「監視」 「予測」 言葉無し | 15/15 PASS |
| forbidden wording | 「検知 / 予測 / 健康スコア / 生産性スコア / at-risk」 一切無し | 15/15 PASS |
| anti-retaliation | 従業員のページビューが上司に見える UI 無し、 hover preview で identity 漏出無し | 15/15 PASS |
| No-Signal rule | 「all clear / safe team / 問題なし」 系ラベル 0 件、 verbatim 「観察ウィンドウ内に...」 採用 | 15/15 PASS |
| Progressive disclosure | Default visible = 必要最小限、 詳細は accordion / drill-down | 15/15 PASS |
| Evidence semantics | 全 signal に grade + reason + window + not-a-verdict 表示 | 15/15 PASS |
| a11y baseline | H1 1 個 / focus outline / aria-label / color+text 併用 / responsive | 15/15 PASS |
| DATA_VISIBILITY_MATRIX | 7 role rules: CEO 集約のみ / Admin 中身見えず / Reviewer scope 限定 / Member self only | 15/15 PASS |
気づいたこと・違和感・提案を surface 単位 で Justine に渡してください。 形式は何でも OK:
すべての mockup は dummy data (架空の人物名・架空のミーティング・架空の数値) で、 本番テナントには接続していません。
このラウンドの設計プロセス全体を追いたい時 (時間がある人向け):