产品交付物反思总结：好文档（图表）会措辞

原型图紧张交付工具：开拓、测试、UI设计师

绘制把稳点：

中、低保真的原型，配色以黑灰白为主。
超链接、按钮、其他需着重突出的元素可适当用红或蓝色。
以免颜色过多滋扰UI设计师发挥，给其他职员演示原型时也不会因色块过而显得重点分散，减轻查看者的理解本钱。
控件规范利用。
该用什么控件就用什么，避免UI误解，便于开拓和测试理解，降落理解本钱。
例如按钮习惯用圆角长方形，若溘然换成直角，则在分外场景下，UI可能会误解为标签；单选该当用Radio button，多选运用checkbox，乱用两者可能导致功能点被开拓错。
涉及页面都显示出来，只管即便不用动态面板隐蔽弹层及页面。
我目前是连提醒弹框都会单独开一个页面（允悲脸），并不是由于

功能设计碎碎念：这条实在算不上把稳点，而是自己画原型时的小套路。
在设计功能时，一样平常我会遵照画纵向形成闭环+横向只管即便延伸。

纵向操作闭环指的是除了考虑某一操作本身的设计（操作起始点——操作结束点间各个节点），还要考虑改操作会辐射到的其他元素。
比如某toB产品新增了附件上传需求，那么除了在干系页面加好上传功能、上传成功／失落败的显示、删除／重传的交互等基本点以外，还要考虑上传完，其他协浸染户（非上传者）是否也可以看到，要在页面哪个位置看到。

横向只管即便延伸指的是对纵向梳理的每个节点进行穷举。
例如上传功能这个节点，还要考虑上传附件的格式规定、上传附件的数量规定、上传完文件名称显示是要直接提取文件名，还是统一显示成某个字段、上传成功／失落败的显示、删除／重传的交互；查看附件这个节点，是要预览查看，还是下载查看等等。

流程图

在事情中，我一样平常用流程图来阐明系统逻辑或功能操作逻辑。
个中又因描述粒度的不同，而分为系统流程图和功能操作流程图。

1. 主流程图

（1）紧张交付工具

开拓／测试／运营／业务／UI

（2）特点

侧重描述大逻辑，不须要拘小细节，一样平常用于初次系统讲解或次干系职员培训。

粒度很粗，侧重描述大逻辑，不须要拘小细节，个中大多数节点可细化出一个功能流程图。
下面以某外卖从选择商家到下单完成的流程来举个栗子：

例如：

只描述最紧张的步骤，将系统中某个环节概述清楚即可。

2. 操作流程图

（1）紧张交付工具

开拓／测试

（2）特点

粒度细，至少描述完备实现功能所需的每步操作，根据须要也可细化到非常状态处理操作。

以上图中对应功能操作流程图为例：

因未从事过外卖产品，并且为了方便举例，粒度也没有特殊细，只包含了基本操作，根据公司文档交付习气不同，若粒度需更细，也可加入操作非常或失落败（eg：网络中断反馈；下载失落败处理；未保存输入内容里开页面等）流程。

绘制tip：可在流程图节点阁下适当添加表明，尤其是系统流程图，这样有助于查看者理解。

个人觉得，查看流程图时比查看原型图更随意马虎在脑中建立整体回路，而在主要节点旁加上注释或其他信息，就更方便查看者联系前后节点场景进行理解，也更加会留下印象。

泳道图

特点：

流程中涉及2个及以上角色；多个别系阶段；多用于描述业务流程

在流程图中划分用户角色或系统阶段时，会加入泳道，即绘制成泳道图。

绘制tip：一样平常我在绘制时用横向划分角色，纵向按韶光顺序划分业务或操作阶段。
若泳道长度较长，可给不同角色利用不同颜色，以便于下拉至看不到泳道标头的时候快速区分工具。

例如：（下图中对涉及商业信息的字段模糊描述）

产品设计解释书1、交付工具

开拓、测试

2、特点

产品讲解从粗到细，快速建立产品观点

实在平时事情中不常写产品解释书，之前打仗过的的产品解释书更像是先于PRD交付给开拓职员查看的的产品讲解物。
拿我们的2B产品设计解释书为例，一样平常包含：

文档概述业务场景描述：场景图、笔墨系统流程描述：系统流程图、流程节点表系统逻辑描述：改动逻辑整理表（若有）、新增逻辑整理表及描述、其他补充逻辑产品规则：编码规则（例如条约编码规则、订单编码规则）+用度打算规则+其他规则主界面设计解释：紧张界面原型图、对应原型界面描述

个人以为产品设计解释书就像是各种产品解释的大杂烩，用于先为查看者（特殊是初次打仗该产品者）建立产品观点，之后由粗（业务场景）到细（界面解释）逐步推进，使查看者可以快速进入产品状态，解释书中要放什么内容，则要视部门互助习气等成分而定。

系统操作手册交付工具：运营职员、业务职员、用户

在toB产品中，由于流程繁芜、参与角色浩瀚，编写不同角色对应的系统操作手册能够帮助其快速节制操作流程。
下面是笔者惯用的编写步骤：

1、编写文档概述（非必写）

文档概述一样平常包括网站背景、系统简介、手册运用工具、专业名词及缩写阐明、软硬件环境、版权声明等。

2、 撰写操作解释

（1）拆分流程

按照主流程进行顺序，依次划分出多少个子模块。
例如注册登录流程、认证开户流程、资产登记流程等等，至于非常情形处理可单独汇总为一个模块，好处是方便查找，也可视情形分布在其他流程中，领悟到实际操作场景里。

（2）分解功能点

对子模块按照操作顺序拆分出紧张功能点。

（3）配图及笔墨解释

配图：截取流程中依次会跳转到的页面（主要的提示弹框也可以截取），将该页需操作的区域或元件用红框框出。
在同一页面不同位置进行连续操作，可用箭头指引。
截取的图最好进行图注，一是可以让利用者查找时快速定位，而是方便理解当前页面用场。
笔墨解释：写清楚当前处于哪个页面，须要进行哪个（些）操作（若需更详细也可对该操作哀求进行讲解，例如必填／非必填等），操作完成后干系流程会进入什么状态，接下来会进入哪个页面。
主要提示可用能干的红字标出。

例如：

UI验收图交付工具：开拓、测试

常日UI设计师们按照产品原型给出效果图后，产品要进行验收，验收后才能交付给开拓及测试职员。

验收容意事变

个人总结UI验收紧张需把稳以下几点：

元素是否画全，字段是否精确元素间“组”的关系是否保留：干系的元素要附近，有时UI为了整体布局都雅会将某些元素均匀分布，但忽略了它们间的干系性。
页面中重点是否突出：或弱化的元素是否达到效果：页面中第一眼望上去该当被关注的模块或元素是否在视觉上被突出了？有没有产生喧宾夺主的不佳情形？页面中需弱化的元素是否达到效果：不肯望用户把稳到或利用率很低的元素（例如举报按钮）是否被弱化？设计是否符合用户操作习气：这里指的紧张是B端用户，由于对付大部分此类用户，习气性的操作可以让效率更高，或者线下的干系操作长期遵照某一模式，线上用同样办法可以降落理解本钱，便于快速上手。
此时在审查UI图时，都雅就不是放在第一位的，而应更侧重于用户习气。
比如条约的干系信息展示就最好按照纸质条约来布局。

为了避免验收涌现上述问题，可以在交付给UI原型中加以特殊标注，或者UI设计的过程中紧迫盯人、加以提醒（微笑），当然最好的办法是在产品UI设计前期培训设计师们，为其讲清楚场景或业务需求，这样设计师童鞋们在设计的过程中自然会更佳贴近需求。

其他交付物

当然根据产品类型、公司规程、互助习气的不同，还存在着许多其他交付物。
例如业务节点表（适宜汇总比拟业务各阶段的状态、干系要素的增减情形）、字段订正表（金融等干系产品页面上的字段都须要风控过审）、场景演示图（用人-人／人-物等模型演示产品场景，适宜做产品低级培训）……不过所有交付物的浸染实在都是更好的传达自己的想法或需求，以是交付物的形式也不必拘泥于形式，毕竟黑喵白喵，抓到老鼠的便是好喵～～～

末了，以上仅为个人事情中对交付物的小总结，未考虑全面的地方希望大家辅导沟通，本文也该当会在未来有所更新。

本文由 @ 晴暻 原创发布于大家都是产品经理。
未经容许，禁止转载。