146 行
8.0 KiB
Markdown
146 行
8.0 KiB
Markdown
# 产品设计规则基线
|
||
|
||
本文件是 R100 之后 PC 网页和企业微信/手机网页统一优化的事实源。目标用户是 10 人以下的国内科技公司：使用频次高、角色重叠、审批链短，系统应当像工作台，不像宣传站，也不应像重型 ERP。
|
||
|
||
## 设计目标
|
||
|
||
- 首屏只放今天最该处理的事，避免解释系统功能。
|
||
- PC 端服务批量查看、对账、审批和管理；手机端服务提交、补资料、查状态和处理待办。
|
||
- 页面文案使用国内 OA 常见表达：待处理、草稿、审批中、已通过、已支付、已驳回、提交、保存、删除、撤回。
|
||
- 所有业务对象使用业务编号或摘要展示，不把 UUID 当作主编号展示给用户。
|
||
- 颜色以浅色工作台为主，黑色只用于正文或弱边框，不作为移动主按钮、底部导航、首屏卡片背景。
|
||
|
||
## 品牌视觉参考
|
||
|
||
OA 页面应参考公司主页 `www.hyinda.com` 的视觉气质，但不能做成营销页。R111 起以 2026-05-08 对官网首页“海音达 Hyinda”的实际视觉抓取作为基线，截图和颜色摘要保存在 `output/playwright/r111-hyinda-design/`：
|
||
|
||
- 品牌识别：使用“海音达 Hyinda”的稳重科技感，页面干净、留白充足、边界清晰。
|
||
- 主色倾向：官网核心蓝约为 `rgb(0,57,138)`，用于主按钮、选中态、重点链接和关键状态。
|
||
- 中性色：白色、浅灰蓝、浅边框和深 slate 文本为主，避免大面积黑色块。
|
||
- 圆角与卡片：控制在工作台风格，卡片边界清晰，不使用营销式大面积渐变、装饰光斑或夸张大圆角。
|
||
- 字体气质：官网使用偏现代无衬线风格；OA 继续使用系统无衬线字体，但字号、行距和按钮高度要克制。
|
||
- 双端一致：PC 和企业微信/手机端都遵循同一品牌色和控件语义，只根据屏幕密度调整布局。
|
||
|
||
## 文案规则
|
||
|
||
禁止：
|
||
|
||
- 口语化标题，例如“先处理这几件事”。
|
||
- 内部评价词，例如“清爽”。
|
||
- 对用户解释设计意图，例如“低频模块放在这里，避免干扰移动首页”。
|
||
- 路由式标题，例如直接显示 `/invoice-pool`。
|
||
- 长段功能说明占据表单、弹窗、列表首屏。
|
||
|
||
推荐：
|
||
|
||
- 首页模块标题用“待处理”“常用”“我的申请”“通知”。
|
||
- 操作按钮用“新建报销”“继续编辑”“提交审批”“删除草稿”“上传发票”。
|
||
- 空状态只说明现状和下一步，例如“暂无草稿”“暂无待处理审批”。
|
||
- 表单说明放在字段错误、帮助文本或 hover/折叠信息里，不放在首屏大段文案。
|
||
|
||
## 色彩规则
|
||
|
||
- 主色：品牌蓝/青色系，用于主按钮、选中态、链接和轻量提示。
|
||
- 中性色：白色、浅灰、浅蓝灰用于背景、卡片和分隔。
|
||
- 状态色：红色表示危险或失败，橙色表示待处理，绿色表示完成。
|
||
- 禁止移动端主卡、底部导航选中态和核心 CTA 使用黑色大块背景。
|
||
- 卡片圆角保持 8px 左右；移动端可使用 12px 到 16px，但不做营销式大圆角堆叠。
|
||
|
||
## PC 页面模式
|
||
|
||
列表页：
|
||
|
||
- 顶部只保留标题、核心筛选、主操作。
|
||
- 表格列优先显示业务编号、申请人、金额/天数、状态、更新时间、操作。
|
||
- 操作列至少区分“查看/编辑”和状态允许时的“删除草稿”。
|
||
- 长 ID、调试字段、路径字段默认不进入主列。
|
||
|
||
明细页：
|
||
|
||
- 标题显示业务编号或摘要，例如“报销单 BX20260506001”。
|
||
- 状态、金额、申请人、更新时间作为摘要条。
|
||
- 主流程操作固定在页头或底部操作区，危险操作靠右或二次确认。
|
||
- 审批流、附件、发票和日志分区展示，避免混在一个长表单里。
|
||
|
||
表单和弹窗：
|
||
|
||
- 表单先收集必要字段，非必要字段折叠或后置。
|
||
- 发票、附件上传使用自定义中文控件，不暴露浏览器原生 `Choose File` 文案。
|
||
- 弹窗只承担单一任务，不在弹窗里解释整个业务流程。
|
||
|
||
## 手机和企业微信页面模式
|
||
|
||
- 手机端默认隐藏 PC 侧边栏和顶栏，使用移动首页、底部导航和轻量卡片。
|
||
- 菜单不应占用大量空间；常用入口放底部导航，更多入口放“我的”。
|
||
- 移动底部导航固定为“首页、审批、报销、我的”；票据上传作为首页快捷入口和报销页内操作，不作为底部一级 Tab。
|
||
- 报销详情、审批详情等深层 Push 页隐藏底部导航，使用顶部返回和上下文吸底操作，避免底部 Tab 在深层页面假选中。
|
||
- 列表使用卡片，不直接显示桌面表格。
|
||
- 表单字段纵向排列，按钮宽度稳定，首屏优先完成“新建/继续编辑/提交”。
|
||
- 企业微信入口应尽量免登录；绑定失败或权限不足时显示明确下一步，而不是让用户反复登录。
|
||
- 头像 fallback 遵循国内中文习惯：中文/CJK 姓名默认取首个可见字符，英文或拼音姓名保留两段首字母。
|
||
|
||
## 报销专项规则
|
||
|
||
报销是下一批 R101 的主流程，不在 R100 直接改数据模型。R101 必须单独处理：
|
||
|
||
- 后端生成业务编号，例如 `BX20260506001`，前端不再用 UUID 作为主展示。
|
||
- 草稿允许删除；审批中使用撤回；已通过和已支付不提供删除。
|
||
- 报销明细存在且只有一条时，上传发票默认绑定该明细。
|
||
- 多条明细时优先按金额匹配；无法匹配时自动生成新明细，不向普通用户暴露“绑定整单”。
|
||
- 发票上传支持批量 PDF，OCR 显示明确状态和可重试入口，不长期停留在“上传中/处理中”。
|
||
- PC 端适合完整明细和对账；手机端适合上传 PDF 发票、补充说明、继续编辑草稿和查状态。
|
||
- 报销详情等深层页的底部主操作在 iPhone 11 等小屏上仍保持同行双按钮，不因适配降级为单列。
|
||
|
||
## 请假、票据、采购、差旅规则
|
||
|
||
- 请假手机端应提供新建、编辑草稿、提交和查看记录，不显示桌面表格。
|
||
- 票据中心应显示票据号码、销售方、金额、OCR 状态和绑定状态，不把内部 ID 放在主位置。
|
||
- 采购和差旅页使用和报销一致的列表、状态、操作区和移动卡片规则。
|
||
- 所有上传控件都使用中文按钮和文件名回显。
|
||
|
||
## R99 WIP 处置
|
||
|
||
当前工作区存在 R99 企业微信移动端整改 WIP，涉及：
|
||
|
||
- `client/src/pages/MobilePortalPage.tsx`
|
||
- `client/src/pages/MobileMePage.tsx`
|
||
- `client/src/components/mobile/MobileBottomNav.tsx`
|
||
- `client/src/layouts/AppShellLayout.tsx`
|
||
- `client/src/pages/MobileReimbursementsPage.tsx`
|
||
- `client/src/pages/MobileLeavePage.tsx`
|
||
- `client/src/router/index.tsx`
|
||
- `client/src/router/lazy/index.ts`
|
||
|
||
这些改动方向与本设计基线基本一致，但仍需要在 R103 中统一吸收或经批准清理。本 R100 批次不把这些 WIP 当作完成项提交，避免和设计规则、报销重构混在一起。
|
||
|
||
## 后续批次
|
||
|
||
R101 报销主流程重构：
|
||
|
||
- 后端业务编号、权限和删除规则。
|
||
- 报销列表、明细页、发票绑定和草稿编辑体验。
|
||
- PC 与手机报销流程的自动化回归。
|
||
- 需要 reviewer 检查权限、状态机和回滚策略。
|
||
|
||
R102 跨页面一致性：
|
||
|
||
- 票据、请假、采购、差旅页面统一列表、表单、上传和状态文案。
|
||
- 清理路径式标题、原生上传控件和 UUID 主展示。
|
||
- 补齐页面级 Playwright 视觉诊断。
|
||
|
||
R103 企业微信/手机端统一清理：
|
||
|
||
- 吸收或清理 R99 WIP。
|
||
- 固定移动首页、我的、报销、请假、审批、票据上传的移动页面。
|
||
- 手机端不再复用桌面表格作为主要体验。
|
||
|
||
## 验收规则
|
||
|
||
每个后续批次至少满足：
|
||
|
||
- Issue CSV 中明确业务流程级 `Test_Method`。
|
||
- `node scripts/qa/check-ui-design-rules.mjs` 可运行并记录问题。
|
||
- 前端改动执行 `cd client && npm run typecheck` 和 `cd client && npm run build`。
|
||
- 涉及移动端或视觉问题时，补充 Playwright 截图或视觉诊断。
|
||
- 涉及状态机、权限、数据迁移时，单独 reviewer 审查并写清回滚路径。
|