张翔
dc8bb76266
- Document design audit findings and recommended direction - Add implementation plan for Bain-aligned content differentiation
205 lines
8.7 KiB
Markdown
205 lines
8.7 KiB
Markdown
# Bain 对标深化设计规格：页面差异化与可信度升级
|
||
|
||
## 概述
|
||
|
||
基于 `impeccable` 评估报告与已完成的第一轮 Bain 化改造，当前网站在代码层面已移除大部分 AI 模板痕迹（大写 eyebrow 标签、装饰性编号、侧边条纹边框），但仍有以下内容与信任层面的差距未闭环：
|
||
|
||
1. **列表页模板同质化**：产品、解决方案、服务三页使用同一套“图标 + 标题 + 描述”卡片语言。
|
||
2. **残余 AI 痕迹**：服务页流程仍使用 `01/02/03/04` 编号；`sections.tsx` 服务流程时间线仍有 `uppercase` 英文标签。
|
||
3. **案例可信度不足**：案例客户均为匿名描述，缺乏可审计的业务维度。
|
||
4. **零视觉资产**：全站无产品截图、团队照片、客户场景图。
|
||
|
||
本规格确定在不引入外部摄影图片的前提下，通过**数据可视化、结构化文案、页面模块差异化**提升 Bain 式的“编辑式信任平台”质感。
|
||
|
||
---
|
||
|
||
## 设计目标
|
||
|
||
1. **产品 / 解决方案 / 服务三页具有明显不同的信息架构**，让访问者一眼识别所处页面类型。
|
||
2. **从“功能列表”转向“问题-结果叙事”**：每页都回答“客户遇到什么 → 我们怎么做 → 得到什么结果”。
|
||
3. **移除所有残余 uppercase / 装饰编号**：统一使用中文标签系统。
|
||
4. **案例数据可验证化**：即使客户匿名，也提供行业、规模、周期、部门、数据规模等可审计维度。
|
||
5. **零新增图片依赖**：所有视觉增强通过 CSS / SVG / 数据图实现，为后续替换真实图片预留数据接口。
|
||
|
||
---
|
||
|
||
## 设计原则
|
||
|
||
- **Consulting Professional 审美**：参考 Bain、McKinsey 的排版驱动、数据前置、模块克制。
|
||
- ** purposeful 动效**：仅保留必要动画，不引入新装饰性动效。
|
||
- **可访问性优先**：颜色对比度维持 WCAG AA，不降低现有可访问性。
|
||
- **测试前置**：修改前先补充/更新相关 E2E 与单元测试，确保改造后验证通过。
|
||
|
||
---
|
||
|
||
## 任务 1：产品页差异化改造
|
||
|
||
**文件**：`src/app/(marketing)/products/products-content-v3.tsx`
|
||
|
||
### 当前问题
|
||
- Hero 标题含“产品矩阵”一词，偏功能列表。
|
||
- 产品卡片以 Lucide 图标为中心，6 张卡片视觉重复。
|
||
- 缺少产品组合关系说明。
|
||
|
||
### 改造后结构
|
||
|
||
1. **Hero**：标题改为问题-结果叙事，例如“用自研产品组合，支撑企业核心系统升级”。
|
||
2. **套装关系图**：在 Hero 下方或产品列表上方，增加一个轻量模块，展示 6 款产品如何组成“企业套装”与“专业产品”。
|
||
3. **产品卡片新结构**：
|
||
- 第一行：产品名 + 一句场景定位（如“面向中大型制造与零售企业的核心运营系统”）。
|
||
- 第二行：3 个量化能力指标（如“10 万级 SKU / 200+ 报表模板 / 99.5% 数据准确率”）。
|
||
- 第三行：所属套装标签（企业套装 / 专业产品）+ 核心能力 pills。
|
||
- 移除：大图标居中的设计。
|
||
|
||
### 数据结构
|
||
- 在 `src/lib/constants/products.ts` 的 `Product` 接口中新增可选字段：
|
||
- `scenario?: string` — 一句话场景定位
|
||
- `metrics?: { value: string; label: string }[]` — 能力指标
|
||
- `bundle: 'enterprise' | 'standalone'` — 所属套装
|
||
- `capabilities?: string[]` — 核心能力 pills
|
||
|
||
---
|
||
|
||
## 任务 2：解决方案页差异化改造
|
||
|
||
**文件**：`src/app/(marketing)/solutions/solutions-content-v3.tsx`
|
||
|
||
### 当前问题
|
||
- 卡片使用行业图标 + 标题 + 描述，与其他页面同质化。
|
||
- 缺少“痛点 → 结果”的叙事。
|
||
|
||
### 改造后结构
|
||
|
||
1. **Hero**：保留“深耕行业场景”定位，但增加一句结果承诺。
|
||
2. **行业卡片新结构（问题-结果卡）**：
|
||
- 顶部：行业名 + 1 个核心痛点（如“库存周转慢、线上线下数据不同步”）。
|
||
- 中部：1-2 个可量化结果（如“库存周转提升 30% / 全渠道库存准确率 99%”）。
|
||
- 底部：推荐产品组合（以小型 pills 呈现，如 ERP + CRM + BI）。
|
||
- 移除：大图标居中的设计，改用小型行业标识。
|
||
|
||
### 数据结构
|
||
- 在 `src/lib/constants/solutions.ts` 的 `Solution` 接口中新增可选字段：
|
||
- `painPoints?: string[]` — 核心痛点
|
||
- `outcomes?: { value: string; label: string }[]` — 可量化结果
|
||
- `recommendedProducts?: string[]` — 推荐产品 ID 列表
|
||
|
||
---
|
||
|
||
## 任务 3：服务页差异化改造
|
||
|
||
**文件**：`src/app/(marketing)/services/services-content-v3.tsx`
|
||
|
||
### 当前问题
|
||
- 服务卡片使用图标 + 描述。
|
||
- 流程部分使用 `01/02/03/04` 装饰编号。
|
||
|
||
### 改造后结构
|
||
|
||
1. **Hero**：保留“从规划到运维全程陪伴”的情感定位。
|
||
2. **服务卡片新结构**：
|
||
- 服务名 + 一句话价值主张。
|
||
- 3-4 个能力条目（以勾选清单形式）。
|
||
- 2 个关键指标（如“90%+ 方案落地率 / 50+ 咨询项目”）。
|
||
- 移除：大图标居中的设计。
|
||
3. **流程时间轴**：
|
||
- 移除 `01/02/03/04` 编号。
|
||
- 改为中文阶段名：“需求分析 → 方案设计 → 敏捷交付 → 持续支持”。
|
||
- 每个阶段显示：阶段名、周期、3-4 个具体交付物（清单形式）。
|
||
|
||
### 数据结构
|
||
- 服务数据结构已基本完整，本次主要调整 UI 呈现。
|
||
- `SERVICE_PROCESS` 常量从 `{ step, title, desc }` 改为 `{ phase, duration, deliverables[] }`。
|
||
|
||
---
|
||
|
||
## 任务 4：sections.tsx 服务流程时间线改造
|
||
|
||
**文件**：`src/components/content/sections.tsx`
|
||
|
||
### 当前问题
|
||
- 流程时间线卡片使用 `STEP 1` 等 `uppercase` 英文标签。
|
||
- “交付物”使用 `uppercase` 标签。
|
||
|
||
### 改造后结构
|
||
- 阶段标签改为中文，如“第一阶段：诊断评估”。
|
||
- “交付物”改为“阶段产出”。
|
||
- 移除 `tracking-[0.2em] uppercase` 和 `uppercase tracking-wider` 样式。
|
||
- 保持时间轴视觉，但降低装饰性。
|
||
|
||
---
|
||
|
||
## 任务 5：案例数据可信度升级
|
||
|
||
**文件**：`src/lib/constants/cases.ts`
|
||
|
||
### 当前问题
|
||
- 客户名均为“某上市制造企业”、“某区域零售龙头”等匿名描述。
|
||
- 缺少项目周期、涉及部门、数据规模等可审计维度。
|
||
|
||
### 改造后结构
|
||
|
||
为每个案例增加以下字段（可选，但推荐填充）：
|
||
|
||
- `projectDuration?: string` — 项目周期（如“8 个月”）
|
||
- `departments?: string[]` — 涉及部门（如“生产、财务、供应链”）
|
||
- `dataScale?: string` — 数据规模（如“10 万级 SKU、日均 50 万笔订单”）
|
||
- `businessProblem?: string` — 更具体的业务问题描述
|
||
- `verified?: boolean` — 是否可公开验证（为后续真实客户背书预留）
|
||
|
||
同时，在案例详情页展示上述维度，形成“行业 → 规模 → 问题 → 方案 → 结果 → 周期 → 涉及部门”的可审计叙事链。
|
||
|
||
---
|
||
|
||
## 任务 6：视觉呈现规范
|
||
|
||
### 不引入外部图片
|
||
- 本次不使用 AI 生成图、图库摄影或客户提供照片。
|
||
- 所有视觉增强通过以下方式实现：
|
||
- **数据指标**：大号数字 + 中文标签。
|
||
- **套装关系图**：使用 SVG 或 CSS 布局展示产品组合。
|
||
- **时间轴**：纯 CSS 线条与节点。
|
||
- **Pills / 标签**：小型中文标签展示产品组合、能力、交付物。
|
||
|
||
### 颜色与排版
|
||
- 维持现有设计令牌系统。
|
||
- 品牌红 `#C41E3A` 仅用于：Hero 关键词、CTA 按钮、关键数字、模块标签、链接强调。
|
||
- 标题行高不低于 `leading-[0.92]`，避免 `leading-[0.88]` 等过度紧凑的排版。
|
||
- 中文标签不使用 `uppercase`、`tracking-wider`。
|
||
|
||
---
|
||
|
||
## 任务 7：测试与验证
|
||
|
||
### 改造前
|
||
- 更新相关 E2E 测试，确保选择器不因结构变化失效。
|
||
- 更新相关单元测试，确保数据结构和组件渲染正确。
|
||
|
||
### 改造后
|
||
- 运行全量 E2E（排除视觉回归）：171 项必须通过。
|
||
- 运行单元测试：718 项必须通过。
|
||
- 运行 `npm run type-check` 与 `npm run lint`：无错误。
|
||
|
||
---
|
||
|
||
## 成功标准
|
||
|
||
1. 产品、解决方案、服务三页在信息架构上可明显区分。
|
||
2. 所有 `uppercase` eyebrow 标签与装饰性编号（`01/02/03/04`）被移除。
|
||
3. 案例数据包含至少 3 个可验证维度（周期、部门、数据规模）。
|
||
4. 全量功能 E2E、单元测试、type-check、lint 全部通过。
|
||
5. 不引入任何外部图片资产。
|
||
|
||
---
|
||
|
||
## 参考文件
|
||
|
||
- `src/app/(marketing)/products/products-content-v3.tsx`
|
||
- `src/app/(marketing)/solutions/solutions-content-v3.tsx`
|
||
- `src/app/(marketing)/services/services-content-v3.tsx`
|
||
- `src/components/content/sections.tsx`
|
||
- `src/lib/constants/products.ts`
|
||
- `src/lib/constants/solutions.ts`
|
||
- `src/lib/constants/services.ts`
|
||
- `src/lib/constants/cases.ts`
|
||
- `docs/superpowers/specs/2026-07-03-phase2-bain-depth-upgrade-plan-c.md`
|