最近工作中，总是会遇到一些在需求理解、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个方面：

1. 需求背景与目标

   • 介绍该需求设计的业务背景、市场环境和目标用户群体。
   • 明确项目的业务目标和预期的用户收益。

   梳理需求背景与目标，便于讨论需求合理性、可行性，便于后续需求归档。

2. 用户需求

   • 详细列出目标用户群体的具体需求。
   • 对这些需求进行优先级排序，划分紧急度与优先级。

3. 功能需求

   • 基于用户需求，详细描述系统所需实现的功能。
   • 包括功能的交互行为、约束条件、权限要求和性能要求等。

4. 非功能需求

   • 安全性：包括用户数据保护和系统访问控制。
   • 性能：如系统响应时间、并发用户处理能力。
   • 可扩展性与可维护性。
   • 操作日志要求等。

5. 数据管理

   • 如何收集、存储、处理和显示数据。
   • 数据初始化、存量数据处理等要求。
   • 数据保护和隐私方面的要求。

6. 设计原则
   需求设计时，需遵循如下原则：

   • 操作简便：确保所有功能易于访问和使用。
   • 一致性：维持整个系统的设计风格和操作逻辑一致性。
   • 容错性：系统应能妥善处理用户的错误操作。
   • 反馈：用户在操作中能得到适时的响应与反馈。

7. 修订历史记录

   • 文档的版本控制。

2.2. 需求文档输出规范

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

• 需求概述

  • 概述：需求背景、需求价值、功能点
  • 竞品分析
  • 版本更新日志

• 需求说明

  • 功能需求：在原型图进行标注（页面说明、功能说明、交互注释）
  • 非功能性需求

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

1. 功能说明：

   • 对于每个原型图，都应该有一个简短的文本说明，描述该图所代表的功能或用户故事，确保开发人员不看文字描述时也能理解。

2. 交云层注释：

   • 使用Axure的“注释”功能，在原型上标注更加详尽的说明，如功能逻辑、交互规则、异常处理等。

3. 版本控制：

   • 原型的迭代很快，需要有一个清晰的版本控制机制，有修改请及时更新到原型或及时备注出来，确保团队成员总是在查看最新版本的文档和原型。

4. 非功能需求：

   • 性能指标、安全策略、响应时间等不方便在原型上表达的内容，需要在文档中另行说明。

5. 数据字典：

   • 如果产品处理复杂的数据，应该有一个数据字典或数据模型的说明，方便开发人员理解并按需设计数据库。

6. 附件与链接：

   • 将相关的技术文档、市场研究报告或其他参考资料以附件形式提供，或在文档中插入链接。

7. 导航和目录结构：

   • 如果需求文档内容繁多，应该有清晰的导航和目录结构，便于团队快速找到对应的部分。

8. 反馈和修订历史：

   • 文档应允许团队成员提供反馈，并记录修订历史，让每个人都能看到需求的变更。

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基础控件使用规范，需求设计与开发时请遵循一致性原则，尽量使用统一风格的组件库，增加复用性，同时一些组件在使用时要注意使用规范。

一些常见规范：

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

  1. 表格排序。数据查询时，若为规定默认排序方式，使用id正序，避免无查询条件造成数据展示每次顺序不一致。排 序还需考虑全局排序还是当页排序，非特殊情况，均为全局排序。
  2. 表格分页，数据查询后，考虑是否可以做分页，聚合内容较为复杂时，根据数据量、用户需求考虑是否需要分页。
  3. 查询数据类表格，尽量少使用表格直接编辑，容易造成数据误操作。

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

  1. 查询条件

     • 应当从用户的视角出发，确定哪些字段是用户最有可能用于搜索的。
     • 条件的筛选复杂度，能否进行多条件组合查询，如范围查询、精确匹配、模糊搜索等。
     • 查询条件的默认值或最常见值，以简化用户操作。
     • 条件的输入方式，例如下拉菜单、输入框、复选框、日期选择器等。

  2. 查询效率

     • 数据索引策略，确保常用的查询条件都有合适的索引。
     • 查询算法优化，避免慢查询或者超时。
     • 如何处理大量数据的分页和加载，可能涉及前端分页或后端分页等技术。
     • 缓存机制的使用，特别是对于那些不经常改变的查询结果。

  3. 搜索框提示文字

     • 应简明直观，告知用户可以搜索哪些内容。
     • 可以使用引导性语言或者示例来辅助用户理解。
     • 在用户输入时，提供实时的自动完成功能。

  4. 用户体验（UX）方面

     • 查询响应时间和进度反馈，避免用户由于不知进度而感到迷茫。
     • 查询结果的呈现方式，如何使结果清晰易懂且信息层次分明。
     • 如何提供有效的排序、过滤和高级搜索功能。

  5. 安全性和权限

     • 限制对敏感数据的搜索，确保遵守隐私和合规要求。
     • 用户权限的控制，不同级别的用户可见和可查询的数据可能不同。

  6. 技术和资源限制

     • 根据现有的服务器资源和技术栈来调整查询系统的设计。
     • 考虑在不同的设备和平台上的查询性能和体验。

  7. 数据产品的反馈与升级

     • 设定日志和监控系统以追踪查询功能的使用情况。
     • 根据用户反馈对查询功能进行持续的改进。

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

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

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

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

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

• 操作反馈
  当前系统内的操作提示没有统一规范，报错和提示当前是混用的，后续需求设计与开发时，请严格遵守操作反馈规范

  1. 警告提示 Alert。常用于分步骤表单、页面顶部提示等。
     
  2. 全局提示 Message。常用于系统报错等。
     
  3. 通知提醒框 Notification。常用于系统通知、异步导入导出操作等。
     

其余操作反馈详见Ant Design基础控件使用规范

4. UI 设计规范

UI设计规范需结合系统使用框架与内部自有设计进行规范化，由UI同学主导输出一套完整的规范化的设计规范文档。

• 设计原则
• 配色元素
• 字体元素
• 按钮元素
• 图标元素
• 图片元素
• 基础控件元素
• 动效规范
• 不同尺寸适配
• 间距大小
• IOS、Android设计尺寸
• 市场手机屏幕尺寸参考