产品提交规范说明

产品提交规范说明为精确描述产品，方便开发理解产品，避免理解上的误差和需求遗漏，产品人员在将产品设计的方案提交给开发的同时要提供文档：原型+文字描述或PRD文档+原型。下文提出了针对这两个文档的最低要求。一、版本管理文档需要在头部说明每次修订的版本，日期和修订人二、文字描述原型务必要有文字说明；原型务必给出必要的交互，页面级别的交互更不能省；对于专用术语，需在文当前面给出说明或者专门给出文档讲解，例如：设备开壳设备铅封联单清算，结算等言简意赅，能10个字说清楚的不要20个字，能一句不要两句，能两句的不要一段；需用词严谨，避免词语歧义或失准，不能省略的词不要省略，多次自查错别字；经常用到诸如“维度”、“颗粒度”、“参数”、“字段”、“项”、“列”、“表”等词汇，往往省略了会导致歧义，常见用法例如：以“订单号+产品编码”的[维度]进行唯一性判断；按照“订单”[颗粒度]进行汇总；以“时间”作为请求[参数]；数据库的[字段]为“number”；页面搜索栏的“姓名”搜索[项]；页面列表的“年龄”[列]。前因后果，需求目标，场景上下文需要写清楚，但是也不要写一大段文字；三、产品结构、用例列举、界面分区和命名需提供产品结构图，即使有原型也需要提供产品的结构图，建议使用xmind逐级列举；建议根据结构图的层级，列举每一层级内的用例（业务规则）；结构清晰：按模块层级，页面层级，区域层级归类具体规则，列举项逐条编号；命名要简洁统一，达到设计者，技术人员，用户都能理解：需对功能和页面有简短的合理的命名，这些命名会在接下来的沟通中直接使用，以防大家沟通的不是一个事物，这些命名甚至会直接体现到代码里；用户界面达到一定复杂度需要对界面的不同区域进行命名和说明，比如页头，页脚，头部导航栏，左侧导航栏，底部导航栏，搜索区等；对于操作的命名简洁易懂，尽量避免专有名词整个产品同类功能展示统一，比如：空数据展示统一异常提示格式统一表单，表格样式统一默认条数统一等用户界面的操作要能符合操作习惯，体现引导性，比如：同类分组，先左后右，先上后下，给出当前位置指示，必要时给出上一步下一步；四、流程、角色和场景如果针对某个功能的操作步骤比较长，或某几个功能关联较多，需要提供流程图，如果是多角色或多系统参与的需要使用泳道图；通常操作步骤超过5个，或者这些步骤里超过30%的步骤有分支，就需要提供流程图；如果分支太多建议反思提出的设计是否需要优化，尤其在需要用户操作的步骤中分支不宜过多；流程图需要体现触发的时机和条件，以及流程内每一步间的流转条件，明确完整的列举这些条件；建议设计时对流程中的选择操作和循环保持敏感，对这些地方进行精确的文档说明；用户界面上要能对应到流程内的节点，条件，用户需要做的操作和操作结果；设计流程或操作时考虑逆向流程和异常流程：业务必须的逆向流程，比如：撤单、退款等；误操作恢复机制；数据请求或加载过程中、加载无数据时和加载出错时的交互，给用户必要的重试机制；数据状态、角色和权限：需明确不同角色用户的权限：功能和操作范围的可见性，数据可见性，越权操作提示；需要明确不通数据状态下的查看、编辑、删除等权限；场景全面拆解方法建议：按业务顺序，想象或模拟用户操作顺序；按目标生命周期，比如草稿、待审核、审核中；按正常、异常、正向、逆向，形成交叉矩阵；按照不同用户角色与其他场景组合（尤其不要忽略用户登录与否，登录过期等场景）；五、类型，精度和边界对于设计文档中出现的输入输出项需要说明其类型：文本，图片/文档，数字，列表等；基本上每一项需要说明是否必填、可选、多选；给出各界面的空值，默认值，默认条件，默认排序等；数字需要指明：是整数还是小数，取值范围，小数精度，进位规则；文本需要给出字符数的限制；专用数据，需要指明对数据格式的要求，比如邮箱、手机号、身份证号、日期、数据编号等；列表类的需要指明条数范围、去重分组、排序等规则；图片要给出其体积（小于2M），长宽，像素等限制文档要给出对其体积的限制，通常小于5M；提交空值，超越边界等不符合规范的要给出是否提示，如何提示及对应文案；内容较多的要说明如何排版：换行，省略，隐藏等；需给出常用技术类需求，例如：预计的访问量，最低响应时间，频繁访问的响应方式等；重复提交、恶意