怎么样的原型图才算是专业的原型图呢?文章总结了一些经验,希望对你有所帮助。
本篇(原型篇-下)主要内容:
- 原型图标注,画开发看得懂的图
- 同一个页面展示所有的交互状态
- 页面跳转关系图(不要做孤立的设计)
- 流程图,梳理业务逻辑
一、原型图标注,画开发看得懂的图
首先明确原型图标注是给谁看的,谁最关心原型标准呢?一般而言,开发和设计最关心原型图标注,开发最关心的是边界条件、页面跳转关系,而设计最关心有页面和功能遗漏,如反馈状态和空页面。画出功能的所有交互状态,清晰地显性化表示交互状态是作为交互或产品的基本功。一个好的标注满足以下几个条件:
- 标注点的含义,发生的事件
- 用梳理所有对象和逻辑关系、状态
- 模块化区分和标记
定义好每个标注点的含义和事件
在做交互稿标记之前,定义规范好每个标记的含义,形成统一的规范,使得团队成员易于理解。如,我比较喜欢用水滴表示标注的功能,用圆圈+箭头的形式来标识页面跳转关系。
用脑图梳理所有对象和逻辑关系、状态
下面的原型图标注以在饿了么商家详情页结算订单为例,先用思维脑图梳理功能状态,这样能避免遗漏一些边界条件。
模块化区分和标记
梳理好状态后再在原型图上写产品用例,每个功能做成一个模块,有利于往后的维护和迭代,例如下面是饿了么的订单结算功能
二、在同一个页面展示所有的交互状态
很多的开发和设计,很多耐心看原型图上的各种标注,特别是时间一长,标注就非常多。如果是做版本的迭代,一要做好标注的版本区分,让他们第一眼能看到当前版本要做的事情。如果是特别是复杂的功能,尽量在一个页面上显示出所有的交互状态,避免在看原型图时遗漏。有时候测试验收阶段的很多坑,各种状态一楼,其实是由于前期没有做好标注引起的。
下面以微信消息列表页为例(梳理思路用脑图是一个好习惯),先用脑图画出所有的状态,补齐所有交互状态,后面再画的时候效率会高很多。
如下图,为微信消息列表页所有交互状态的列表呈现:
三、页面跳转图(不要做孤立的设计)
页面跳转图,从用户的视角,系统化看流程的合理性。页面流程图有助于梳理页面之间的关系。交互设计师或产品经理在工作中,很容易把一个功能做成“孤岛型功能”,即这个功能跟其他功能建立联系,跟其他功能是孤立的关系。
如在“美啊教育”中要增加一个评论功能,那么评论机制应该怎么与现有系统对象建立联系?在分析这个问题之前先看看评论和教程的关系,如下图:
教程中可以看到相关评论,评论系统与教程之间已建立联系,但只是单线的关系。
我们再看看美啊这个产品中,还有什么对象是可以跟评论建立联系的?假如,为了刺激用户去评论,我们可以用积分奖励的方式,当用户评论教程后,可以获取一定的积分,即教程-积分通过评论建立了联系,跟现有的积分兑换优惠券、商品也是有联系的,仍是于是建立了用户-教程,教程-积分,用户-积分的关系,整个积分体系不再是孤立的功能。
用户-教程
- 用户去评论教程
- 教程的得分可以帮助用户筛选出更优质的教程
教程-积分
- 通过评论教程可以获得积分
- 积分可以免费兑换观看教程
用户-积分
- 积分可以刺激用户去评论
- 用户用积分可以获取商品,如优惠券等
于是整个评论体系的页面关系图为(补充了部分可能存在的需求):
四、流程图,梳理业务逻辑关系
画流程图示产品经理的基本功,产品需求,也是流程上的需求。画流程图的目的有以下几点:
- 确保产品流程的合理性
- 有效传达需求
- 检验异常分支
在画流程图过程中,切勿遗漏异常状态,产品经理一般比较关心主要流程,可是开发同学在写代码时,要做条件边界判断,这个条件边界即为异常情况。测试同学在写测试用例时,要穷尽所有的场景,包括正常场景和异常场景,否则出了问题,是要背锅的…为了避免开发和测试同学不断询问你边界条件,最好在交付交互稿之前用流程图梳理出来。
常用的流程图分为单向流程图和泳道图(涉及到多个角色),单向流程图一般描述单一角色完成某个任务的整体过程,如登录注册过程、支付流程、填写资料等。
流程图包含以下内容:
- 事项:用户要完成什么任务
- 角色:分别会有哪些人会参与到流程中
- 信息传递:信息在整个过程中是如何传递的
- 异常:有哪些异常情况,如何处理
- 如快手的登录注册流程,先来梳理思路:
- 事项:用户要完成快手的登录注册
- 角色:普通用户
- 信息传递:在触发登录注册框时,获取用户的注册信息,检验手机验证码,关联通讯录数据,获得第三方登录数据
- 异常:最近登录过该如何处理?手机号无效该如何处理?手机号已注册该如何处理?
泳道图
除了要明确事项、角色、信息传递、异常等内容,在画复杂的泳道图之前,要明确参与角色,再梳理出不同的角色要完成的任务,各个角色之间的交接,整个流程的阶段划分。
如天猫的退货流程图作图思路:
1.明确角色
参与角色有:买家、系统、卖家、客服
2.各个角色要完成的任务
买家:买家收到商品不满意,可以在天猫上发起退货,填写退款申请。如果卖家同意退货,买家可将商品寄到卖家的收获地址,寄送方式可选择自行寄件或者上门取货。如果卖家收到货后,拒绝退款,买家可以申请客服介入。
卖家:处理买家退款申请;如果订单满足退货条件,将退货地址发给买家;卖家收到商品;退款给买家。
系统:判断买家收获状态;检测买家的退款申请的原因、金额等,生成退款记录;判断是否平台先垫付退款;将卖家地址发给买家;系统将买家上门服务申请发送给合作的物流公司;变更退款状态。
客服:客服介入,判断双方责任
3.角色交接
买家将退款申请发送给系统,系统发送给卖家,卖家处理退款申请,卖家将退货地址发送给买家,买家寄件给卖家,卖家收货退款。如卖家拒绝退款,买家申请客服介入,客服处理买家或卖家的责任。
4.阶段划分
为了方便理解整个流程,小编把流程分为5个阶段:
- 买家发起退货申请
- 系统处理买家申请
- 买家寄件给卖家
- 处理退款
整个泳道图如下:
第五部分的“功能模块化,可复制”已进化成“交互设计规范”,过年后小编献上~