最近工作中，总是会遇到一些在需求理解、UI设计上和开发产生分歧的地方，有的东西可能产品经理认为是常规设计，都能理解，不一定需要标注出来，但实际过程中并不一定所有的开发会这样思考，对于需求的理解也可能存在差异。这个时候就需要对产品或项目进行标准化规范，以解决需求设计、UI设计、开发流程上容易被忽视的问题。

产品规范的存在，就是为了让设计更容易也更方便，团队之间步调一致、配合默契。

产品规范就是队伍里的队规，让团队成员遵循一致标准，这样才能打造成风格统一、易用性强的优秀产品。

大家可以根据实际工作流程来编写自己内部的产品规范，下面我根据我的工作流程整理了一份产品规范文档，仅供参考。

1. 项目流程规范

1.1. 产品开发流程

1.2. Bug提出与处理流程

Bug提出与修复
1. Bug及时上报。评估严重程度、优先级、受影响的范围、时间范围、影响用户量，同步测试同学复现 bug。
2. Bug 处理方案的决策。
  - 根据 bug 的严重程度和优先级来做第一轮判断。不严重的 bug、低优 bug 可以先进 backlog；
  - 未来版本可能改版或者废弃的模块产生的 bug，可放弃修复。
3. 处理需要修复的 bug。第一步是复现 bug，第二步是分析产生原因；第三步是给出修复方案。
4. 根据优先级和开发成本，在有了修复方案之后，需要在决策重新对 bug 进行修复的优先级排序。因为可能一个中优的 bug，需要巨大的修复成本。这种时候我们可能就需要将优先级稍稍往后，同时选择从产品或者流程上规避这个 bug。所以这个是对 bug 的再次梳理，给出新的方案。（可能涉及到跨部门协同）
复盘
1. 先从 bug 的影响上开始分析，再从解决方案的决策上给出解释
2. 复盘研发链路上是否有疏漏
3. 整体上分析和回顾大的流程上是否存在问题，再从细节出深挖问题的根结
4. 给出避免的方案，不论是加强沟通还是统一编码风格，还是 code review 的加强
5. 从整体到细节，给出完整的 bug 原因，以及完整的避免思路

2. 需求输出规范

2.1. 需求设计规范

需求设计时，要考虑或遵守如下7个方面：

需求背景与目标
- 介绍该需求设计的业务背景、市场环境和目标用户群体。
- 明确项目的业务目标和预期的用户收益。
梳理需求背景与目标，便于讨论需求合理性、可行性，便于后续需求归档。
用户需求
- 详细列出目标用户群体的具体需求。
- 对这些需求进行优先级排序，划分紧急度与优先级。
功能需求
- 基于用户需求，详细描述系统所需实现的功能。
- 包括功能的交互行为、约束条件、权限要求和性能要求等。
非功能需求
- 安全性：包括用户数据保护和系统访问控制。
- 性能：如系统响应时间、并发用户处理能力。
- 可扩展性与可维护性。
- 操作日志要求等。
数据管理
- 如何收集、存储、处理和显示数据。
- 数据初始化、存量数据处理等要求。
- 数据保护和隐私方面的要求。
设计原则
需求设计时，需遵循如下原则：
- 操作简便：确保所有功能易于访问和使用。
- 一致性：维持整个系统的设计风格和操作逻辑一致性。
- 容错性：系统应能妥善处理用户的错误操作。
- 反馈：用户在操作中能得到适时的响应与反馈。
修订历史记录
- 文档的版本控制。

2.2. 需求文档输出规范

传统需求文档，常常以纯文档形式输出，交互图写在文档内，对于开发者来说总是晦涩难懂。
采用新的形式来呈现：依托于Axure制作的原型图，需求说明和设计说明直接融合在原型交互中。Axure文档结构如下：

需求概述
- 概述：需求背景、需求价值、功能点
- 竞品分析
- 版本更新日志
需求说明
- 功能需求：在原型图进行标注（页面说明、功能说明、交互注释）
- 非功能性需求

可以根据自己业务需求，编写自己的需求文档模板，注意如下内容：

功能说明：
- 对于每个原型图，都应该有一个简短的文本说明，描述该图所代表的功能或用户故事，确保开发人员不看文字描述时也能理解。
交云层注释：
- 使用Axure的“注释”功能，在原型上标注更加详尽的说明，如功能逻辑、交互规则、异常处理等。
版本控制：
- 原型的迭代很快，需要有一个清晰的版本控制机制，有修改请及时更新到原型或及时备注出来，确保团队成员总是在查看最新版本的文档和原型。
非功能需求：
- 性能指标、安全策略、响应时间等不方便在原型上表达的内容，需要在文档中另行说明。
数据字典：
- 如果产品处理复杂的数据，应该有一个数据字典或数据模型的说明，方便开发人员理解并按需设计数据库。
附件与链接：
- 将相关的技术文档、市场研究报告或其他参考资料以附件形式提供，或在文档中插入链接。
导航和目录结构：
- 如果需求文档内容繁多，应该有清晰的导航和目录结构，便于团队快速找到对应的部分。
反馈和修订历史：
- 文档应允许团队成员提供反馈，并记录修订历史，让每个人都能看到需求的变更。

2.3. 数据埋点规范

数据分析当前使用的神策数据，数据埋点请遵守神策埋点要求：数据融合 (sensorsdata.cn)

埋点及数据分析等相关名词及使用指南参考神策帮助中心：产品使用指南 (sensorsdata.cn)

3. 开发基础规范

3.1. 基础控件使用规范

3.1.1. 移动端

当前我公司的小程序、APP未使用固定框架或组件，功能设计时需遵循一致性原则。以下罗列了常用的一些移动端框架或组件：

WeUI：微信官方设计团队专门为微信内网及小程序量身定制的、同微信原生视觉体验一致的基础样式库。
Material Design：Google Material 推出的全球顶级 React 组件库。
Taro UI：京东凹凸实验室发布的 React 移动端组件库。
NutUI 3.0：京东发布的 Vue 3 移动端 UI 组件库。对移动端友好，特别针对移动端电商业务场景优化测试。
Tdesign：腾讯内部近 300 名设计师与开发者共同打造，经由 500+ 项目使用和验证过的企业级设计体系。
Cube UI：滴滴团队开源的 Cube UI 移动端 Vue UI 组件库，轻巧趁手、质量可靠，由滴滴内部组件库精简提炼而来。
Vant 4：赞团队开源的移动端 UI 组件库，性能极佳，组件平均尺寸小于 1KB （min+gzip），内置 65 + 个高质量组件，覆盖了主流使用场景中的多数需求。

3.1.2. PC端

当前后台系统前端框架使用的是Ant Design 3.x版本，组件及功能设计需遵循一致性原则，避免重复开发和风格不一致问题。下面会对Ant Design组件、功能等增加设计规范，以解决功能设计过程中、开发过程中出现的常见问题：

基础控件的使用规范：Ant Design基础控件使用规范，需求设计与开发时请遵循一致性原则，尽量使用统一风格的组件库，增加复用性，同时一些组件在使用时要注意使用规范。

3.2 开发常见功能规范

3.2.1. 表格

表格可采用多种展示形式，根据需求选择，数据展示时注意如下几点问题：

表格排序。数据查询时，若未规定默认排序方式，使用id正序，避免无查询条件造成数据展示每次顺序不一致。排序还需考虑全局排序还是当页排序，非特殊情况，均为全局排序。
表格分页，数据查询后，考虑是否可以做分页，聚合内容较为复杂时，根据数据量、用户需求考虑是否需要分页。
查询数据类表格，尽量少使用表格直接编辑，容易造成数据误操作。
表格操作列，表格操作列，无特殊说明，操作按钮不进行换行，操作列冻结。若操作按钮过多时，根据重要性，使用更多下拉按钮操作。
表格数据统计，表若增加统计展示，统计与筛选数据统一。

3.2.2. 数据查询

在需求设计和开发过程中，有几个关键方面需要仔细考虑，以确保数据查询既有效又直观：

查询条件
- 应当从用户的视角出发，确定哪些字段是用户最有可能用于搜索的。
- 条件的筛选复杂度，能否进行多条件组合查询，如范围查询、精确匹配、模糊搜索等。
- 查询条件的默认值或最常见值，以简化用户操作。
- 下拉筛选框，非单选必填选项，增加全部筛选项，避免多条件搜索时，无法去除单个条件。
- 条件的输入方式，例如下拉菜单、输入框、复选框、日期选择器等。
查询效率
- 数据索引策略，确保常用的查询条件都有合适的索引。
- 查询算法优化，避免慢查询或者超时。
- 如何处理大量数据的分页和加载，可能涉及前端分页或后端分页等技术。
- 缓存机制的使用，特别是对于那些不经常改变的查询结果。
搜索框提示文字
- 应简明直观，告知用户可以搜索哪些内容。
- 可以使用引导性语言或者示例来辅助用户理解。
- 在用户输入时，提供实时的自动完成功能。
用户体验（UX）方面
- 查询响应时间和进度反馈，避免用户由于不知进度而感到迷茫。
- 查询结果的呈现方式，如何使结果清晰易懂且信息层次分明。
- 如何提供有效的排序、过滤和高级搜索功能。
安全性和权限
- 限制对敏感数据的搜索，确保遵守隐私和合规要求。
- 用户权限的控制，不同级别的用户可见和可查询的数据可能不同。
技术和资源限制
- 根据现有的服务器资源和技术栈来调整查询系统的设计。
- 考虑在不同的设备和平台上的查询性能和体验。
数据产品的反馈与升级
- 设定日志和监控系统以追踪查询功能的使用情况。
- 根据用户反馈对查询功能进行持续的改进。

每个方面都需要根据用户需求分析来具体化，制定出符合实际应用场景的设计方案，并结合UI/UX设计来提高用户满意度。在开发阶段，以上方面也需持续迭代和完善，以确保查询系统的性能和易用性。

3.2.3. 权限规范

数据权限
1. 命名规则
  - 数据权限的命名需体现数据的范围和关联的模块，格式为 “模块 - 数据范围 - 数据内容”。其中，数据范围包括 “个人”“部门（主管）”“全公司” 等，数据内容为具体的数据对象。
  - 示例：“订单 - 订单审核管理 - 个人申请数据”“订单 - 订单审核管理 - 所有申请数据”。
2. 管理方式
  - 个人只能查看自己的客户信息，经理可查看本部门的客户信息，公司高管可查看全公司的客户信息。
3. 控制方式
  - 可通过 SQL 过滤或数据视图的方式实现数据权限的控制。对于 “个人” 数据权限，在查询数据时通过用户 ID 进行过滤；对于 “部门” 数据权限，通过用户所属部门 ID 进行过滤；对于 “全公司” 数据权限，则不进行额外过滤。（当前系统只有个人、主管及所有数据控制，暂无部门控制）
页面权限
1. 命名规则
  - 页面权限的命名应关联页面的 URL 或菜单路径，格式为 “菜单层级 - 页面名称 - 页面类型”。其中，菜单层级体现页面在系统菜单中的位置，页面类型可分为 “列表页”“详情页”“表单页” 等。
  - 示例：“系统管理 - 用户管理 - 用户列表页”“订单 - 订单查询 - 订单详情页”。
2. 管理方式
  - 权限层级：页面权限分为菜单级和页面级。菜单级权限控制用户是否能看到某个菜单，页面级权限控制用户是否能访问该菜单下的具体页面。只有拥有菜单级权限，才能拥有该菜单下相应页面的页面级权限。
3. 分配原则
  - 基于用户角色分配页面权限集合。例如，管理员角色拥有所有系统管理相关页面的权限，普通用户角色仅拥有与其业务相关的页面权限。
操作权限
1. 命名规则
  - 操作权限的命名需结合所在页面和具体操作，格式为 “页面名称 - 操作对象 - 操作类型”。其中，操作类型包括 “新增”“编辑”“删除”“查询”“导出” 等。
  - 示例：“用户列表页 - 用户信息 - 新增”“订单详情页 - 订单状态 - 编辑”“商品管理 - 商品数据 - 导出”。
2. 管理方式
  - 与页面权限的关联：操作权限依赖于页面权限，只有用户拥有某页面的页面权限，才能拥有该页面内相应的操作权限。
  - 粒度控制：操作权限的粒度应适中，避免过粗或过细。过粗可能导致权限滥用，过细则会增加管理复杂度。例如，在用户管理页面，“用户信息 - 编辑” 权限可涵盖对用户基本信息的修改，无需再细分为修改姓名、修改电话等权限。
  - 分配方式：根据用户在页面中的具体职责分配操作权限。例如，数据录入员拥有 “新增” 和 “编辑” 权限，审核员拥有 “查询” 和 “审核” 权限。
  - 操作日志记录：系统应对所有操作权限的使用情况进行日志记录，包括操作人、操作时间、操作内容等，以便进行权限审计和问题追溯。

3.2.4. 国际手机号规范

国际手机号组成规范

国际手机号通常由国家 / 地区代码、地区号（可选）和本地号码三部分组成，具体规则如下：

国家 / 地区代码：以 “+” 号开头，后续为 1-3 位数字（遵循国际电信联盟 ITU 规定），例如中国为 “+86”、美国为 “+1”、英国为 “+44”。
地区号：部分国家 / 地区的手机号包含地区号，用于区分不同城市或区域，例如美国手机号的地区号通常为 3 位数字（如纽约为 212）。
本地号码：除去国家 / 地区代码和地区号后的部分，长度因国家 / 地区而异，一般为 5-10 位数字。

示例：

中国手机号：+86 138 0013 8000（国家代码 + 86，无地区号，本地号码 13800138000
美国手机号：+1 212 555 1234（国家代码 + 1，地区号 212，本地号码 5551234）

存储规范
1. 字段类型：采用字符串类型（VARCHAR）存储国际手机号，禁止使用数字类型（避免因前导零丢失、超长数字截断等问题导致数据错误）。
2. 字段长度：设置为 20 位字符（满足全球最长手机号存储需求，如某些国家 / 地区手机号含国家代码可达 15-18 位）。
3. 存储格式：统一存储为 “+ 国家代码 + 号码本体” 的紧凑格式，不包含任何分隔符（如空格、连字符 “-” 等），例如：
  - 正确：+8613800138000、+12125551234
  - 错误：86-13800138000、+44 7911 123456（含分隔符）

3.2.5. 脱敏规范

系统内脱敏遵循相同脱敏规则，使用相同脱敏方法，避免多地方显示脱敏规则不一致。

姓名脱敏
- 脱敏原则
  - 默认脱敏显示，增加权限控制可查看明文，但不可明文显示
  - 保留姓氏和名字的首尾字，中间部分用*代替。
- 脱敏规则
  - 对于两个字的名字，如“张三”，脱敏后显示为“张*”，总字数为 2 个字。
  - 对于三个字的名字，如“李四强”，脱敏后显示为“李*强”，总字数为 3 个字。
  - 对于四个字的名字，如“司马相如”，脱敏后显示为“司**如”，总字数为 4 个字。
  - 对于六个字符的名字，如“爱新觉罗·溥仪”，脱敏后显示为“爱**仪”，总字数为6个字符。
  - 以此类推
手机号脱敏
- 脱敏原则
  - 默认脱敏显示，增加权限控制可查看明文
- 脱敏规则
  - 前三后四显示，中间用四个*代替
  - 例如：188**8888
账号、ID类脱敏
- 脱敏原则
  - 对于系统内有一定安全信息的ID，需进行脱敏显示，如果复制使用，则增加复制按钮
- 脱敏规则
  - 前四后二显示，中间用四个*代替
  - 例如：U328**32
发货、收货信息脱敏
- 脱敏原则
  - 默认脱敏显示，增加权限控制可查看明文
- 脱敏规则
  - 省市区三级地址不脱敏，详细地址脱敏后三分之一，后部分用四个*代替
  - 例如：广东省深圳市龙华区民治街道布龙公路南侧梅观高速公路**

3.2.6. 导入

导入功能看似简单，需要考虑的问题很多，涉及的交互也很多。下面针对如下问题进行规范：

数据校验。
a. 数据校验方式采用校验完成后返回全部错误或处理完成后返回全部错误，根据实际业务场景采用报错方式。
b. 优先是必填项不能为空，单元格内容格式正确。
c. 然后才是核对数据是否存在于基础数据库中。
d. 最后检测本次导入与已存在数的冲突性校验，比如重复。
数据处理结果，部分成功还是全部成功。处理数据支持部分成功，则需要考虑可能返回的错误数量，20条以下，可以在弹框说明错误原因。过多就需要使用返回错误文件，让用户进行下载。
导入方式：同步导入还是异步导入。若数据量较大的导入，请尽量使用异步导入，且增加异步导入进度框或进度条。若对数据有严格要求，若数据量小或需要进行下一步操作时，请使用同步导入，且增加导入进度框或进度条。
数据处理：考虑导入覆盖，还是更新。数据导入时按固定模板解析，还是按字段进行解析。

3.2.7. 导出规范

注意按钮页面布局，焦点按钮一般放在左侧，导出、导入、下载类可选择放在右侧。

导出全部时，必须筛选条件
导出遵循所见即所得规则，不要导出的内容和显示的内容不一致
导出条件，导出全部：导出筛选条件下的全部，导出勾选，导出勾选的数据

操作反馈
当前系统内的操作提示没有统一规范，报错和提示当前是混用的，后续需求设计与开发时，请严格遵守操作反馈规范
1. 警告提示 Alert。常用于分步骤表单、页面顶部提示等。
2. 全局提示 Message。常用于系统报错等。
3. 通知提醒框 Notification。常用于系统通知、异步导入导出操作等。