|
作者：晴暻 全文共 3445 字，阅读需要 7 分钟 —— BEGIN —— 工欲善其事，必先利其器，在产品工作中，我所理解的具象的“器”便是原型、需求文档、各类图表等，虽然这些交付物只是辅助、起着最基本的作用，但必要的总结和思考可以把这几把“器”磨的更锋利，在战（ping）场（shen）上（hui）高效取胜、减少伤（si）亡（bi）。 原型图主要交付对象：开发、测试、UI设计师绘制注意点： 1. 中、低保真的原型，配色以黑灰白为主。超链接、按钮、其他需着重突出的元素可适当用红或蓝色。 以免颜色过多干扰UI设计师发挥，给其他人员演示原型时也不会因色块过而显得重点分散，减轻查看者的理解成本。 2. 控件规范使用。 该用什么控件就用什么，避免UI误解，便于开发和测试理解，降低理解成本。例如按钮习惯用圆角长方形，若突然换成直角，则在特殊场景下，UI可能会误解为标签；单选应该用Radio button，多选应用checkbox，乱用两者可能导致功能点被开发错。 3. 涉及页面都显示出来，尽量不用动态面板隐藏弹层及页面。 我目前是连提醒弹框都会单独开一个页面（允悲脸），并不是因为懒或者不精通动效，而是这样开发、UI、测试查看时才不会漏页面。 虽然页面增多了，动效也不炫酷了，但疏漏少了。毕竟技能要分场景使用才能锦上添花（比如你要演示给boss看时……） 4. 页面之间加跳转链接。 上一条说的是页面内动效尽量少，为的是降低出错率；这一条说的是页面间的跳转链接一定要加上，为的是减少沟通成本。 5. 页面上尽量模拟真实场景下的字段和数据。 例如，我在做产品初期就出过这样的乌龙，由于在设计原型时很不过脑的用“xxx企业”当占位字段，因为字数少，当时在有限的宽度内放置了三个也排列的很清爽。UI那关也没拦住，直接按我原型排列了。 结果可想而知：一般企业名十几个字都很常见，一行放不下三个企业名，前端哥哥很负责任的自动折行显示了，导致产品验收的时候才丑拒提了bug，如果当时画原型时把自己置入实际场景，就会少了后面这些不必要的改动。 原型举例（随手YY的）: * 功能设计碎碎念：这条其实算不上注意点，而是自己画原型时的小套路。在设计功能时，一般我会遵循画纵向形成闭环+横向尽量延伸。 纵向操作闭环指的是除了考虑某一操作本身的设计（操作起始点——操作结束点间各个节点），还要考虑改操作会辐射到的其他元素。 比如某toB产品新增了附件上传需求，那么除了在相关页面加好上传功能、上传成功／失败的显示、删除／重传的交互等基本点以外，还要考虑上传完，其他协作用户（非上传者）是否也可以看到，要在页面哪个位置看到。 横向尽量延伸指的是对纵向梳理的每个节点进行穷举。例如上传功能这个节点，还要考虑上传附件的格式规定、上传附件的数量规定、上传完文件名称显示是要直接提取文件名，还是统一显示成某个字段、上传成功／失败的显示、删除／重传的交互；查看附件这个节点，是要预览查看，还是下载查看等等。 流程图在工作中，我一般用流程图来阐明系统逻辑或功能操作逻辑。其中又因描述粒度的不同，而分为系统流程图和功能操作流程图。 1. 主流程图主要交付对象：开发／测试／运营／业务／UI 特点： 偏重描述大逻辑，不需要拘小细节，一般用于初次系统讲解或次相关人员培训。 粒度很粗，偏重描述大逻辑，不需要拘小细节，其中大多数节点可细化出一个功能流程图。下面以某外卖从选择商家到下单完成的流程来举个栗子： 例如： 只描述最主要的步骤，将系统中某个环节概述清楚即可。 2. 操作流程图主要交付对象：开发／测试 特点：粒度细，至少描述完全实现功能所需的每步操作，根据需要也可细化到异常状态处理操作。 以上图中对应功能操作流程图为例： 因未从事过外卖产品，并且为了方便举例，粒度也没有特别细，只包含了基本操作。 根据公司文档交付习惯不同，若粒度需更细，也可加入操作异常或失败（eg：网络中断反馈；下载失败处理；未保存输入内容里开页面等）流程。 绘制tips：可在流程图节点旁边适当添加注解，尤其是系统流程图，这样有助于查看者理解。 个人感觉，查看流程图时比查看原型图更容易在脑中建立整体回路，而在重要节点旁加上注释或其他信息，就更方便查看者联系前后节点场景进行理解，也更加会留下印象。 泳道图特点：
在流程图中划分用户角色或系统阶段时，会加入泳道，即绘制成泳道图。 绘制tips：一般我在绘制时用横向划分角色，纵向按时间顺序划分业务或操作阶段。若泳道长度较长，可给不同角色使用不同颜色，以便于下拉至看不到泳道标头的时候快速区分对象。 例如：（下图中对涉及商业信息的字段模糊描述） 产品设计说明书交付对象：开发、测试特点：1. 产品讲解从粗到细，快速建立产品概念 其实平时工作中不常写产品说明书，之前接触过的的产品说明书更像是先于PRD交付给开发人员查看的的产品讲解物。 拿我们的2B产品设计说明书为例，一般包含：
个人觉得：产品设计说明书就像是各种产品说明的大杂烩，用于先为查看者（特别是初次接触该产品者）建立产品概念，之后由粗（业务场景）到细（界面说明）逐步推进，使查看者可以快速进入产品状态。 说明书中要放什么内容，则要视部门合作习惯等因素而定。 系统操作手册交付对象：运营人员、业务人员、用户在toB产品中，由于流程复杂、参与角色众多，编写不同角色对应的系统操作手册能够帮助其快速掌握操作流程。 下面是笔者惯用的编写步骤： 1. 编写文档概述（非必写） 文档概述一般包括网站背景、系统简介、手册应用对象、专业名词及缩写解释、软硬件环境、版权声明等。 |
|
|
