Files
danyang-match/docs/superpowers/specs/2026-09-11-dual-client-full-ui-redesign-design.md
T

8.3 KiB
Raw Blame History

善缘丹阳 V1.1 双端全量 UI 重设计规格

日期:2026-09-11 状态:已获用户方案批准,待规格复核 视觉来源:

  • ChatGPT Image 2026年9月11日 10_34_34 (1).png:管理端视觉基准;
  • ChatGPT Image 2026年9月11日 12_46_40.png:小程序导航页与 Tab 页视觉基准。

1. 目标

在不改变 V1.1 业务能力、接口契约、权限边界和核心不变量的前提下,重设计管理端全部现有页面及小程序全部 63 个页面,使双端具有统一品牌识别、清晰信息层级、完整交互状态和可验证的参考图还原度。

2. 已确认范围

  1. 只实现参考海报中的实际软件界面,不实现外围宣传标题、标语或城市背景画布。
  2. 保留 V1.1 全部功能、页面、路由、权限和接口。
  3. 小程序首页保留固定 8 个核心入口及现行文档规定的完整模块顺序。
  4. 管理端保留全部模块,通过一级分组与二级菜单整理,不隐藏或删除功能。
  5. 管理端全部现有业务路由、小程序全部 63 个页面均纳入本次重设计。
  6. 允许制作原创 Logo、Banner、丹阳城市插画、活动和内容封面、匿名演示头像及状态插画。
  7. 页面继续读取真实 API;参考图中的人物、活动和统计数字仅用于确定布局密度,不硬编码进业务页面。

3. 设计方向

3.1 统一品牌

双端共用“善缘丹阳”品牌名称、心形识别符号、字体层级、图标笔画语言和公益、真实、安全、温暖的表达原则。

正式视觉资产必须使用可交付图片或现有图标库。不得使用 Emoji、文字方块、CSS 拼图、临时占位框或手写 SVG 冒充正式资产。

3.2 管理端主题

  • 暖白页面背景;
  • 珊瑚红作为主操作和强调色;
  • 深蓝灰侧栏;
  • 浅粉、浅蓝、浅绿、浅紫用于状态卡片;
  • 信息密度接近参考图中央后台窗口;
  • 风格专业、可信、克制,避免霓虹化和过度装饰。

3.3 小程序主题

  • 紫蓝夜景作为品牌氛围;
  • 粉色作为主要操作和选中状态;
  • 内容区使用高对比白色或浅色卡片;
  • 保留参考图的温暖陪伴感和丹阳城市意象;
  • 长文本、表单、安全提示和敏感操作页优先保证可读性,不使用高饱和背景承载正文。

4. 技术边界

  • 管理端继续使用 Vue 3、TypeScript、Vite、Pinia 和 Element Plus。
  • 小程序继续使用微信原生框架和现有 TypeScript/JavaScript 页面,不迁移跨端框架。
  • 优先改造现有主题变量和公共组件,不引入大型 UI 依赖。
  • 默认不修改后端、数据库、API 和业务规则。
  • 如视觉流程暴露缺失接口或缺失业务路由,先记录并请求确认,不擅自扩展产品范围。
  • Mutual Match、Block、活动互选二阶段确认、Capability、数据范围和敏感信息权限保持不变。

5. 管理端信息架构

现有页面按权限动态显示,并归入以下导航组:

  1. 工作台;
  2. 用户与资料审核;
  3. 匹配与活动服务;
  4. 公益咨询与转介;
  5. 服务站、预约与专项服务;
  6. Banner 与内容运营;
  7. 举报、申诉与审计;
  8. 组织、人员与权限;
  9. 数据统计。

管理端整体框架包含品牌侧栏、分组菜单、顶部搜索、通知、当前操作员、面包屑、内容区和响应式收起状态。登录页、工作台、列表、详情、编辑、筛选、弹窗、分页和危险操作确认必须使用同一设计系统。

6. 小程序信息架构

底部导航固定为:

  1. 首页;
  2. 找对象;
  3. 消息;
  4. 活动;
  5. 我的。

首页 8 个入口固定为:

  1. 找对象;
  2. 公益红娘;
  3. 公益活动;
  4. 婚恋咨询;
  5. 婚恋课堂;
  6. 婚前辅导;
  7. 婚恋反诈;
  8. 善缘服务站。

63 个页面按以下领域统一改造:

  • 登录、手机号、实名、本地资格;
  • 用户资料、照片、兴趣、择偶条件和审核状态;
  • 推荐、人物详情、喜欢、匹配和聊天;
  • 活动、报名、签到、反馈和活动互选;
  • 公益红娘;
  • 婚恋咨询与婚前辅导;
  • 服务中心、服务站、预约、专项服务和服务记录;
  • 婚恋课堂、内容详情和婚恋反诈;
  • 举报、申诉、黑名单、隐私和账号生命周期;
  • 通知、帮助、关于及异常状态页。

7. 公共组件与状态

7.1 管理端

  • 页面标题与操作区;
  • 数据概览卡;
  • 筛选栏;
  • 数据表格;
  • 状态标签;
  • 详情分区;
  • 表单与弹窗;
  • 空数据、错误、无权限和加载状态;
  • 二次确认与操作结果反馈。

7.2 小程序

  • 品牌导航栏;
  • 自定义 Tab Bar;
  • 用户、推荐和活动卡片;
  • 服务入口与功能宫格;
  • 会话列表和聊天气泡;
  • 表单、上传和步骤状态;
  • 底部固定操作栏;
  • 加载骨架、空状态、网络错误、权限不足、审核中和服务不可用状态。

8. 素材策略

  • 制作独立 Logo 与小尺寸品牌图标,不从展示海报裁切。
  • Tab 图标提供普通态和选中态,并适配微信安全区。
  • Banner、活动封面、课堂封面和服务插画按实际组件尺寸生成。
  • 匿名演示头像只用于本地测试和验收,不冒充真实用户。
  • 真实用户头像、活动数据和统计值继续由 API 提供。
  • 素材在小程序包体限制内优化;需要远程托管的业务图片走现有私有对象存储。

9. 响应式与可访问性

  • 管理端验证 1280、1366、1440、1920 宽度,窄屏采用真实重排而非整体缩放。
  • 小程序验证 320、375、390、430 像素宽度及底部安全区。
  • 正文、按钮和状态标签满足可读对比度。
  • 状态不能只依赖颜色表达。
  • 交互目标尺寸、键盘焦点、表单标签、错误恢复和重要结果反馈均需验证。
  • 截图只能发现视觉风险,最终仍需真机、键盘和交互测试。

10. 实施阶段与门禁

Phase 01:基线冻结

建立完整页面矩阵,记录路由、角色、接口、状态和改造前截图;发现缺口只登记,不扩展功能。

门禁:页面覆盖率 100%,缺口均有归属。

Phase 02:品牌资产与设计系统

完成双端令牌、Logo、Tab 图标、核心插画和公共组件规范。

门禁:用户审核素材样张与设计令牌。

Phase 03:样板页面

管理端完成登录、框架、工作台、用户列表和用户详情;小程序完成首页、找对象、消息、活动、我的和 Tab Bar。

门禁:参考图与实现图同尺寸并排对比,用户确认视觉方向。

Phase 04:管理端全量页面

按导航业务域逐组完成全部页面和全部状态。

门禁:类型检查、构建、权限路由与核心操作流程通过。

Phase 05:小程序五个 Tab 页面

完成五个一级页面、导航联动、未读红点和安全区适配。

门禁:微信开发者工具编译无错误,多尺寸截图通过。

Phase 06:小程序其余页面

按业务领域分批完成其余页面,每批复用已批准组件和视觉令牌。

门禁:63 个页面均可进入、返回并正确展示主要状态。

Phase 07:全量验证与交付

完成构建、类型检查、接口联调、核心业务回归、视觉对比、响应式和可访问性检查。

门禁:输出页面完成矩阵、视觉验收报告、测试结果和剩余限制。

每个 Phase 完成后输出 Completion Report,未通过门禁不得自动进入下一阶段。

11. 验收标准

  1. 管理端全部现有路由有统一设计且权限行为不变。
  2. 小程序 63 个页面无遗漏,五个 Tab 与 8 个首页入口保持固定。
  3. 参考图中的颜色关系、卡片层次、圆角、间距、图标风格和信息密度得到一致实现。
  4. 页面不使用硬编码演示数据冒充接口成功。
  5. 加载、空数据、错误、无权限、不可用和危险操作状态完整。
  6. 管理端构建与类型检查通过。
  7. 小程序 TypeScript 检查及微信开发者工具编译通过。
  8. 核心业务不变量和权限矩阵无回归。

12. 非目标

  • 不删除或缩减 V1.1 功能;
  • 不新增参考图和现行需求之外的业务;
  • 不重写后端或数据库;
  • 不迁移前端框架;
  • 不引入微服务或额外基础设施;
  • 不为追求截图相似度牺牲隐私、安全、权限或真实数据流。