产品提交规范说明.docxVIP

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