关于产品原型的制作技巧(关于产品原型的制作技巧有哪些)

不管是前台PM还是后台PM,在工作中或多或少都要进行原型设计。原型可以说是产品、开发、测试之间进行交流沟通最重要的文档之一,那么怎么把原型画得又快又好呢?

从设计流程上看,原型设计节点包括但不限于梳理需求大纲、规划页面结构、完善信息结构、绘制原型及进行说明标注。前面三个节点个人有个人的方法,今天主要想和大家分享一下后两个——绘制原型及说明标注的提效小技巧,希望对你有帮助。

一、制作全局说明

通俗地说,全局说明就是那些你懒得写第二次的东西。比如说网络异常/加载失败/没有数据,这些这是任意页面都可能会出现的情况,如果分开写,每个页面都要写一次,改的话得同时改很多地方,费事费力而且不利于需求的统一管理。所以,把这些通用性的东西写在一个地方,既可以简洁原型文档,降低开发、测试、设计等人员的阅读成本,又可以少写点字,何乐不为呢(๑•̀ㅂ•́) ✧

全局说明可以是适用于全文档的,也可以是适用于某个迭代的。像是一些和迭代相关度高的名词解释。写在全文档性的说明里就有些冗余,写在迭代内全局说明中就刚刚好(个人见解)。

根据通用性,可以将全局说明分成两种:通用说明和业务说明。通用说明是在大多数产品/页面内都可以通用的,比如页面状态、加载状态、通用手势、弹窗遮罩等;而业务说明则不同,这类说明和业务高度相关,相同内容在不同业务间有较大差异,比如时间展示规则、昵称长度等。下面给大家举几个栗子:

通用说明

移动端全局说明具体可见浪子写的文章,很详细(查看)

业务说明

  • 最近一条消息是展示规则

图中是微信的展示规则。手动试出来的,不对的地方欢迎指正

关于产品原型的制作技巧(关于产品原型的制作技巧有哪些)

  • 最近一条消息展示规则

图中微信的展示规则。手动试出来的,不对的地方欢迎指正

关于产品原型的制作技巧(关于产品原型的制作技巧有哪些)

  • 产品上架/下架/浏览时间展示规则

第一版设计的规则里跨年时间也是带「时时:分分」的,后来因为产品列表地皮实在放不下,就把后面的具体时间砍掉了(都跨年了,具体时间没那么重要了叭)。所以具体的展示规则是和实际系统密切相关的。

关于产品原型的制作技巧(关于产品原型的制作技巧有哪些)

二、建立字段说明表

可以把用到的数据用表格的形式罗列出来,清晰且一目了然。

关于产品原型的制作技巧(关于产品原型的制作技巧有哪些)

三、取用元件库进行原型绘制

在绘制原型时,有一些控件会经常用到。如果每次用到都重新制作,不仅无法保证交互效果的统一性,而且会占用很多工作时间。为了咱岌岌可危的发际线,我向大家使用Axure元件库功能。

什么,你说Axure自带的元件库丑?

网上有不少大公司设计的软件库,找个你喜欢的导入就行。比如蚂蚁金服、饿了么、有赞等。

什么,你说懒得找?

那我这给大家推荐几个。

Vant 移动端组件库

非常全面的一个组件库,自带交互能力。除了通用组件,还有带有电商业务组件,用来绘制移动端原型很方便。

设计网站:Zan Design (查看)

资源下载:Zan Design 移动端软件库

关于产品原型的制作技巧(关于产品原型的制作技巧有哪些)

Ant Design 移动端组件库

支付宝风格的组件库,组件没有Vant那么多,但是通用性强。

设计网站:Ant Design (查看)

资源下载:Ant Design 移动端元件库

关于产品原型的制作技巧(关于产品原型的制作技巧有哪些)

Ant Design 后台组件库

这个不用多说了吧,后台产品必备。UI 样式可配置,拓展性强,大多数产品风格都能轻松适应。

设计网站:Ant Design (查看)

资源下载:Ant Design 移动端元件库

关于产品原型的制作技巧(关于产品原型的制作技巧有哪些)

大厂设计的组件库当然不错,但是用起来也会碰到一些问题。比如和自己的设计风格不一致呀,有无用的组件呀,部分组件需要微调等等。所以建议每个PM都自己积累元件并长期更新。不用一次完成,平时工作中碰到新的就维护进去,这样不会占用很多时间,而且可以保证原型整体的视觉统一。

我司后台部分用的是蚂蚁金服组件库,基本不用修改,所以没有制作软件库。APP端因为有些特殊组件,通用组件库里没有就积累了一些,基本是Ant Design 和Vant 的混合版,这里就不献丑了.....((/- -)/

四、建立交互需求说明库

如果系统用的是某个开源的UI项目的话,组件的交互基本都是确定好了的,交互说明文档可以少些甚至不用写。如果没有开源项目,所有的轮子都是百度或者自己造的话,那交互说明文档就必不可少了。碰到一些常见、使用频率高的组件,可以建立一个“交互说明库”,用到的时候贴一个链接或者copy一下,可以减少开发的理解成本。

PM或多或少会碰到被开发围攻的情况,大部分情形可能都是因为需求描述不准确导致的。如果有一个规则模板参考,是不是就可以减少遗漏的情况呢?

需求说明基本分为三个部分:需求说明、交互说明、交互预览。

  • 需求说明一般包含:前置事件、后置事件、初始化、加载/分页、排序、正常和异常结果等,具体看组件类型;
  • 交互说明一般包含:不同组件的说明会有较大差异,如果想描述得很详细,可以参考开源项目的API文档;
  • 交互预览一般包含:输入状态/选中状态/聚焦状态、静止状态、加载状态等等。

关于产品原型的制作技巧(关于产品原型的制作技巧有哪些)

五、进行交互自查

输出完后先对照交互自查表把每个细节梳理一遍,让原型更加更加全面和缜密。

自查表是之前存的,忘记是哪篇文章了。如果你知道的话欢迎补充~

需求类型 检查模块 自查问题 自查结果
(示例)
辅助理解举例
前端需求
(用户能得见的需求)
前置判断
(进入界面时的判断)
是否考虑不同账号的区别 银行App上【我的】页面:已注册账号与游客账号展示差异
是否考虑不同权限的区别 流程审批的界面,审核者权限有审核与查看按钮;但提交者,只有查看按钮
是否考虑同账号不同时间进入的区别 同一个用户晚上登录自动开启夜间模式,如读书类App
是否考虑同账号不同状态的区别 同一个用户也会有前后状态的差异。如优惠券列表,领券前后;活动页面,达标前后
展示内容 展示逻辑 是否考虑内容为空显示什么? 用户的购物车为空的时候,该如何展示
是否考虑横竖屏问题 微信公众号横屏和竖屏查看情况下的兼容
是有有考虑单位/计量单位/位置的统一 积分商品的价格,是统一用:99元+100积分,还是:¥99+100积分;积分价在前还是在后
是否考虑文字过多的换行或者.... 商品列表页,商品名称过长的展示处理方案
是否考虑特殊符号、敏感信息的处理 部分场景,用户手机号展示需要脱敏,如加上***
排序逻辑 是否考虑内容排序的逻辑:时间/热度/相关度 优惠券列表,以用户获取时间还是附近可用的优惠券
是否考虑内容展示方式:翻页/瀑布流 电商商品的为你推荐区,一般使用瀑布流的方式
刷新逻辑 是否考虑刷新方式:是自动刷新还是手动刷新 支付宝首页的信息览,用户可手动下拉刷新
是否考虑刷新数量:一次刷新多少/多久,如何刷更多 交易记录页面,上滑动刷新最多拉取数据库8条信息,最久能够拉取到近3个月的数据
是否考虑刷新异常:当刷不出新内容时提示什么 刷不出内容,页面提示已经到底啦~已经是最新数据啦~等
缓存逻辑 是否考虑页面的缓存数据,存储地方 表单类录入产品,出现返回上一页面操作时,当前页面信息也需要保存
是否考虑缓存触发场景,清理数据逻辑 当下操作场景信息对用户很重要,或对平台校验、分析有用时,需要缓存
用户操作 跳转操作 是否考虑返回:如物理、home键、侧边栏返回 不同的返回按键需要考虑到与用户预期一致
录入操作 是否考虑录入的进度提示 表单填写信息较多时,会给用户展示进度条
是否考虑录入时候的控件变化 输入框,录入时候边框高亮展示
是否考虑录入的结果反馈 录入信息不正确,toast/页面引导用户正确录入
查询操作 是否考虑查询中的状态提示:loading、进度 输入准考证,查询成绩单过程的进度条展示
是否考虑查询结果的展示:查询中/成功/失败 百度搜索查不到相关信息场景下的猜你想查
异常场景 操作异常 是否考虑用户连续操作异常的情况 连续5次输错手势密码要求验证用户身份
是否考虑用户高频操作的禁用逻辑 连续用户连续点击优惠券领取按钮提示:你已经领取过啦/优惠券置灰不可点
网络异常 是否考虑没网场景下的页面提示 支付宝无网络状态下的提示:当前网络不可用,请检查你的网络设置
是否考虑弱网场景下的页面展示 网络太慢,建议用户切换网络
是否考虑网络差,重新加载的按钮 当页面加载不出来,给用户提供重新加载按钮
版本异常 是否考虑新旧版本兼容/强制更新/显示版本更新提示 功能需要最新版本才能体验到,需要引导用户更新版本
接口异常 是否考虑接口异常:查不到数据的情况 服务器挂掉了,功能不可用情况下的页面提示
其他 数据埋点 是否考虑页面埋点,增加操作行为上报 页面的PV/UV,按钮的PV数据上报,方便数据分析
新手引导 是否考虑新手引导,方便新用户了解新功能 人人都是产品经理App上的新功能引导:朕知道了
后端需求 数据处理 新增字段 是否考虑新增字段后,新老数据如何兼容 商品表增加了积分价字段后,在查询时要对老数据进行特殊对兼容处理
系统迁移 是否考虑升级服务器后,老数据如何迁移:全量/增量 系统升级后,用户历史的积分交易数据也需要同步迁移过去,
数据更新 是否考虑数据的更新机制:更新频率/更新方式/更新量 对方系统推数、还是主动拉取,多久更新一次,更新是增量还是全量
系统解耦合 是否考虑单个接口已经包含足够的业务功能 会员查询,应该尽可能将会员相关的信息通过一个接口查询出来
性能保障 是否考虑系统的性能:支持多大的并发量 秒杀功能,订单系统支持多大并发量
权限考虑 是否考虑权限的拆分:查询、编辑、审核等 积分管理后台,业务配置和财务对账区分用户角色
异常场景 是否考虑业务流程异常情况的处理 订单取消后,用户支付已取消订单成功会怎样
数据需求 数据埋点类 必要性 是否以真实的业务分析需求提交埋点位置 不以实际分析需求出发的数据埋点都是不负责任的
完整性 是否包含用户、页面、行为、区域、内容,来源等信息 数据埋点都会把用户的设备信息、操作行为、操作时间、页面、具体位置详尽记录
可追溯 是否埋点之后可以追溯用户的上一级页面来源 无法追溯来源就分析漏斗,难以看出转化效果
数据报表类 数据时效 是否考虑不同表之间数据获取差异而设定跑批时间 过早的跑批时间,会导致有数据依赖的表无法获得数据
数据安全 是否有考虑敏感信息应该脱敏处理 姓名、手机号、身份证号一般会进行加密,如哈希加密
数据获取 是否考虑所需数据字段已经从业务库下传至数据仓库 数据未下传无法满足数据报表需求,因此首先要确认

好了,以上就是个人平时画原型积累的一些技巧和感悟,完全是出于个人习惯和主观经验得来的,可能不太对,如果你有补充或者不一样的看法,欢迎一起探讨~

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发表评论

登录后才能评论