197 行
14 KiB
Markdown
197 行
14 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 和企业微信/手机端都遵循同一品牌色和控件语义，只根据屏幕密度调整布局。
|
||
|
||
## 国内同类系统体验基线
|
||
|
||
R6 之后的 PC、移动和审批体验参考国内主流协同/OA 产品的共性，而不是复制任何单一产品。公开资料显示，钉钉审批强调模板化审批、假勤/财务场景和移动处理，飞书审批强调一站式入口、即时消息通知、移动端处理、流程配置和催办，企业微信自建应用适合作为工作台入口、身份和个人消息 deeplink。PC 端的工作台、表格、表单和导航可参考 Ant Design 的信息密度和后台系统模式，移动端参考微信生态常见的 WeUI/Ant Design Mobile 控件语义。
|
||
|
||
落到 hyb-oa 的原则：
|
||
|
||
- PC 是高密度工作台，服务筛选、批量查看、审批、财务复核、导出和管理配置。
|
||
- 移动端是消息驱动的轻入口，服务提交、补材料、查状态、处理待办和从企业微信消息回流。
|
||
- PC 高密度、移动轻任务是双端分工底线；不得把桌面表格和批量管理能力原样搬到手机端。
|
||
- 企业微信只做入口、绑定、免登录、个人应用消息和 deeplink，不替代 OA 正式审批页。
|
||
- 审批体验以“待办聚合、清晰状态、明确下一步、可催办和可追溯”为目标；催办、超时提醒和效率统计属于 R6 后续优化，不混入 R6 首轮试运行门禁。
|
||
- 竞品资料只用于抽象原则；不得复制钉钉、飞书、企业微信、WeUI 或 Ant Design 的页面文案、视觉细节和专有交互。
|
||
|
||
参考资料：
|
||
|
||
- 钉钉审批：https://page.dingtalk.com/wow/dingtalk/act/approval-web
|
||
- 飞书审批：https://www.feishu.cn/content/article/7584390246654037188
|
||
- 飞书审批催办：https://www.feishu.cn/content/134344362384
|
||
- 企业微信应用消息：https://s.apifox.cn/apidoc/docs-site/406014/api-10061693
|
||
- Ant Design 表单页：https://4x.ant.design/docs/spec/research-form-cn
|
||
- Ant Design 表格：https://012x.ant.design/docs/pattern/table
|
||
- Ant Design 导航：https://ant.design/docs/spec/navigation/
|
||
- Ant Design Mobile/Mini TabBar：https://0x-mini.ant.design/components/tab-bar
|
||
- Ant Design Mobile/Mini SafeArea：https://0x-mini.ant.design/components/safe-area
|
||
- WeUI：https://github.com/Tencent/weui
|
||
|
||
## 文案规则
|
||
|
||
禁止：
|
||
|
||
- 口语化标题，例如“先处理这几件事”。
|
||
- 内部评价词，例如“清爽”。
|
||
- 对用户解释设计意图，例如“低频模块放在这里，避免干扰移动首页”。
|
||
- 路由式标题，例如直接显示 `/invoice-pool`。
|
||
- 长段功能说明占据表单、弹窗、列表首屏。
|
||
|
||
推荐：
|
||
|
||
- 首页模块标题用“待处理”“常用”“我的申请”“通知”。
|
||
- 操作按钮用“新建报销”“继续编辑”“提交审批”“删除草稿”“上传发票”。
|
||
- 空状态只说明现状和下一步，例如“暂无草稿”“暂无待处理审批”。
|
||
- 表单说明放在字段错误、帮助文本或 hover/折叠信息里，不放在首屏大段文案。
|
||
|
||
## 色彩规则
|
||
|
||
- 主色：品牌蓝/青色系，用于主按钮、选中态、链接和轻量提示。
|
||
- 中性色：白色、浅灰、浅蓝灰用于背景、卡片和分隔。
|
||
- 状态色：红色表示危险或失败，橙色表示待处理，绿色表示完成。
|
||
- 禁止移动端主卡、底部导航选中态和核心 CTA 使用黑色大块背景。
|
||
- 卡片圆角保持 8px 左右；移动端可使用 12px 到 16px，但不做营销式大圆角堆叠。
|
||
|
||
## PC 页面模式
|
||
|
||
列表页：
|
||
|
||
- 顶部只保留标题、核心筛选、主操作。
|
||
- 表格列优先显示业务编号、申请人、金额/天数、状态、更新时间、操作。
|
||
- 筛选区默认收敛为关键字段：状态、申请人、时间、业务编号或关键词；高级筛选折叠，不压缩列表首屏。
|
||
- 分页、空状态、批量操作和导出入口必须清楚区分；员工页少配置，财务和管理员页可更高密度。
|
||
- 操作列至少区分“查看/编辑”和状态允许时的“删除草稿”。
|
||
- 长 ID、调试字段、路径字段默认不进入主列。
|
||
|
||
明细页：
|
||
|
||
- 标题显示业务编号或摘要，例如“报销单 BX20260506001”。
|
||
- 状态、金额、申请人、更新时间作为摘要条。
|
||
- 主流程操作固定在页头或底部操作区，危险操作靠右或二次确认。
|
||
- 审批流、附件、发票和日志分区展示，避免混在一个长表单里。
|
||
- 审批、财务和管理员视角可以展示更多审计信息，但普通员工主视角只展示与下一步动作有关的信息。
|
||
|
||
表单和弹窗：
|
||
|
||
- 表单先收集必要字段，非必要字段折叠或后置。
|
||
- 发票、附件上传使用自定义中文控件，不暴露浏览器原生 `Choose File` 文案。
|
||
- 弹窗只承担单一任务，不在弹窗里解释整个业务流程。
|
||
|
||
## 移动统一页面范式
|
||
|
||
- 所有 `/mobile` 页面默认复用同一套移动 Shell、响应式 token、底部导航、安全区和视觉矩阵；不允许单页自造布局体系解决局部拥挤。
|
||
- 专用 `/mobile` 页面包括移动首页、审批、报销列表、报销详情、我的、个人设置、通知、票据上传、请假和资产扫码；这些页面必须先使用统一移动组件和样式，再按业务差异裁剪内容。
|
||
- 手机端默认隐藏 PC 侧边栏和顶栏，使用移动首页、底部导航和轻量卡片。
|
||
- 菜单不应占用大量空间；常用入口放底部导航，更多入口放“我的”。
|
||
- 移动底部导航固定为“首页、审批、报销、我的”；票据上传作为首页快捷入口和报销页内操作，不作为底部一级 Tab。
|
||
- 移动端必须按响应式规则自动适配，不按单个机型写补丁；验收至少覆盖 320、360、375、390、393、414、430px 宽度。
|
||
- 移动首页一级快捷入口使用图标宫格：图标在上、短标题在下，4 项等宽，辅助说明不在小屏常驻展示，避免图标和文字挤压；标题单行省略，不允许逐字换行。
|
||
- 移动端页面边距、卡片间距、底部导航高度和吸底操作高度使用统一 token；不通过 viewport 缩放字体解决拥挤问题。
|
||
- 次级入口和信息字段可按最小宽度自动从两列变一列；核心操作按钮必须保持明确可点，不得被内容、安全区或底部栏遮挡。
|
||
- 报销详情、审批详情等深层 Push 页隐藏底部导航，使用顶部返回和上下文吸底操作，避免底部 Tab 在深层页面假选中。
|
||
- 企业微信个人应用消息 deeplink 应直达移动待办或业务详情；首次进入如需点击进入工作台，应保持后续可直接回到目标页。
|
||
- 移动列表使用卡片和状态标签，首屏优先展示“谁提交、什么事项、金额/天数、当前状态和下一步”。
|
||
- 列表使用卡片，不直接显示桌面表格。
|
||
- 详情页按摘要、业务字段、发票/附件、审批流、日志分区展示；普通员工移动端不默认展示后台审计细节。
|
||
- 表单单列优先，字段纵向排列，按钮宽度稳定，首屏优先完成“新建/继续编辑/提交”。
|
||
- toast、dialog、actionsheet、tabbar、cell、button 等语义参考微信生态习惯；样式必须回到 hyb-oa 自身品牌和组件规则。
|
||
- 企业微信入口应尽量免登录；绑定失败或权限不足时显示明确下一步，而不是让用户反复登录。
|
||
- 头像 fallback 遵循国内中文习惯：中文/CJK 姓名默认取首个可见字符，英文或拼音姓名保留两段首字母。
|
||
- “我的”页和更多入口使用组件级自适应槽位：头像/图标槽固定，文字槽使用 `minmax(0, 1fr)` 可收缩，间距使用移动 token 或 `clamp()`；不按具体 iPhone/Android 机型写补丁，不通过放大字号、放大卡片或改成单列来规避图文拥挤。
|
||
- 所有专用 `/mobile` 页面统一使用移动槽位和移动卡片：图标/头像/状态槽固定，文字槽可收缩，列表项使用移动列表卡片，提示、空状态和表单分组使用移动 token；不得把桌面 `card-std p-4` 当作移动主容器重新引入。
|
||
- 移动卡片保持白底、浅边框、轻阴影，不显示 PC 端 `SectionPanel` 的蓝青色顶边装饰线。
|
||
- 移动角色差异采用“同框架、按角色裁剪内容和动作”：员工、审批人、财务、管理员、负责人看到不同入口、摘要、动作和敏感信息，但不做多套角色专属移动 UI。
|
||
- 移动验收必须包含跨视口自动化和代表性真机确认；若真机验证暂缓，只能记为 `PAUSED`，不能把相关移动阻断标为完成。
|
||
|
||
## 报销专项规则
|
||
|
||
报销是下一批 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 当作完成项提交，避免和设计规则、报销重构混在一起。
|
||
|
||
## 后续批次
|
||
|
||
R6 小范围试运行准备：
|
||
|
||
- 先新建独立 R6 合同，固定 2-3 个内部用户、角色、时间窗口、回滚联系人、问题登记表和每日收口节奏。
|
||
- R6 范围限定为报销、请假、采购、审批、企业微信入口/通知、财务付款/导出。
|
||
- R6 不扩预算、ERP、AI、完整差旅、复杂 BPM；发现需求只登记为新 Issue。
|
||
- 试运行反馈按“阻断、严重、一般、体验建议”分级，不能现场扩大实现范围。
|
||
|
||
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 审查并写清回滚路径。
|