产品新人应该如何用好“原型”? 文档 资料 免费

文新Wénxīn. 普通用户 2020-6-11 2082

原型,是产品经理日常生活中必不可少的一样东西,画原型、讲原型,每天几乎占了一个产品新人50%的时间。如何做好这件事情,成为了每一个产品新人心中的困扰。本文作者就以自身一年多以来的实习经历,来总结一下如何做好一份令大家满意的原型。


刚开始实习的时候,上级会分配到一些新功能需求,往往会需要去从0-1去画原型。

这个时候为了完成好任务,向上级展示自己的原型能力,此时就会花大量的时间去想,我的原型究竟要怎样去设计,配什么样的颜色,然后找来一堆的竞品,再结合自身产品的设计调性,将所有的页面都配好了颜色。

经过一段时间的努力后,一份自己看上去“酷炫到爆炸”的原型就这样设计出来了,并且自我感觉非常良好,感觉没人会设计得比我更好看了。

这个时候拿到上级面前展示,会出现以下情况:

你的上级比较忙,粗略地看了一下:

设计方面基本ok,但是漏了XXX功能和一些细节的描述,需要回去补充一下,补充好就可以跟UI进行沟通了。

然后拿到UI设计师面前讲解,UI心里:你这家伙怎么把颜色全填上去了,这样我怎么设计啊。况且这颜色搭配的也太丑了吧,简直就是干扰我的设计思路。这个实习生还是太年轻了,就爱搞这些花里胡哨的,难不成还想把我们UI的工作给干完了。

你的上级比较有空,并且很认真去研究你的原型方案:

功能设计上基本没什么问题,但是作为一名产品经理,不应该花太多的时间去搞UI层面的工作,你只需要把你的功能、逻辑设计好,就足够了,颜色尽量不要去配。这些都是有UI的设计规范的,回去可以把颜色都去掉,产出一份线框图原型即可,把元素、控件检查清楚是否有漏掉的。

你看,由于你花太多的时间去做UI层面的工作,导致有些功能的描述并不够详细,这样UI同学和开发同学会很难开展工作的,回去继续修改下,修改好再给我过一遍,然后就可以跟UI进行沟通了。

然后将改好的原型拿到UI设计师面前讲解,UI心里:这个实习生弄的原型还不错,各个方面描述的也挺清晰的,终于遇到一个靠谱的产品了,设计起来轻松多了。

可以看出,作为一名产品新人,其实设计原型时样式并不需要太复杂,只需要产出一份线框图就已经足够了。难的地方而是在于如何把功能、逻辑描述清楚,让UI和开发更易懂。

尽管在我们眼里设计得多么好看炫酷的原型,在别人眼里也许就是一个四不像的东西。因此,没必要过于追求样式和特效,这并不是产品经理核心的工作,能用几句话描述清楚的交互动作,也没必要去弄复杂的交互动效。

一般如果做的是C端产品,团队中都会有专门负责UI设计的同学,此时作为一名产品,需要产出的原型就不需要太过于高保真,完成一份比较完善的线框图即可,当我们明确了需求之后,要开始设计原型了,我们可以这样去做:

1. 画原型前需准备的东西

1)将需求内容整理为脑图

无论需求是出自于产品自己,还是其他需求方,当我们确认要做某一个需求后,就应该将需求的内容整理为一份脑图,以发散的思维去考虑每一个功能点具备哪些内容,以便画原型时参照。

2)画一份页面流程图

我们首先清楚需要设计的分别有哪些页面,将页面都列出来之后,标注好页面之间是如何跳转的,检查跳转无遗漏后,初步的页面流程图可以已经算完成了。在画页面流程图的时候,不需要去考虑美观的问题,甚至手写在草稿纸上也是可以的。画页面流程图的目的是让我们提前想好要设计什么页面,在真正画原型的时候可以边画边核对,防止漏掉页面。

3)手绘/用axure画一份原型草图

为什么需要先画一份简单的原型草图呢?

因为作为一名产品新人,画出来的原型是基本不可能直接拿出去开需求评审会的。在开评审会之前,必然需要给自己的leader过一遍,一份好的原型,对新人来说通常都要经过三番五次的修改才能产出最终稿。

如果一开始就花了大量的时间去画了一份非常详细的原型,那么需要修改的时候,就非常惨了。你会发现改着改着跟你原来的画的有着天壤之别,跟重新画一份一样。

因此,画草图的目的就是更方便我们去修改,节省下更多的时间。当我们拿着草图在我们的leader、需求方处讨论时,及时收集好需要修改的地方,当草图符合他们的要求时,我们就可以参照着草图来画出一份最终版的原型。

2. 正式开始画原型

1)梳理界面元素

当我们设计一个页面的时候,必然具备大量的元素,此时就要我们仔细地去检查、梳理页面的元素布局。

此处以京东APP中我的订单“全部tab”举例进行分析:

页面顶部:返回键、搜索框、筛选功能按钮、消息中心按钮。

页面中上方(订单状态):全部tab、待付款tab、待收货tab、已完成tab、已取消tab。

页面中上方:常购清单跳转图片。

页面中下方(商品信息):商品来源卖家名称、商品状态、删除按钮、物流信息文案、物流信息最新更新时间、商品图片、商品名称、商品价格、辅助功能按钮(卖了换钱、查看物流、评价晒单、再次购买)。

2)梳理点击情况

在APP的页面中,大部分的元素都是可点击的,此时我们需要考虑的就是每一个元素点击的情况是怎样的:

  • 点击是否可以跳转,跳转什么页面。
  • 跳转的页面是已存在页面,还是新页面。
  • 点击后元素样式是否改变。
  • 点击后的跳转是否可逆。
  • 元素是否需要配置埋点,方便日后统计埋点数据。

3)列举异常状态,并给出解决方案

每一个功能在一些特殊的条件下都会出现异常的状态,导致页面无法正常地展示给用户。因此在设计的时候,我们就要尽可能去考虑有可能出现的异常状态,并给出对应的解决方案:

  • 无网络:固定元素依然展示,自定义变化的元素(如商品信息)不展示,页面提示用户网络出现问题。
  • 访问次数过多,服务器过载:页面告知用户加载不出来的原因,提示用户稍后尝试或继续刷新等待。
  • 未登录状态:如果用户此时是未登录状态(游客),那么就要去分析该页面是否需要提供给游客进行浏览,如上方的订单信息页面,是无法展示给游客进行查看的,因为未登录是无法与平台之间发生交易行为,此时需要提示用户进行登录/注册,并提供入口引导用户操作,当用户登录/注册后,还需自动跳转回原页面。

这几种是比较常见的异常状态,还有很多的异常状态需要我们去提前考虑,甚至有些是在上线后我们才发现到,发现后需及时去寻找解决方案。平时在工作中也可以积累一个“产品异常情况库”,将平时遇到的情况都记录好,下次在考虑异常状态时可以拿出来进行核对。

4)转换角色,体验功能流程

虽然我们按照已有的流程图去画好原型了,但这仅仅是站在产品的角度去设计产品,而产品上线后是给用户去使用的。因此当我们设计好原型后,特别是比较大的功能需求,我们应转换成用户的角色去体验产品。以一个普通用户的使用习惯去使用功能,使用过程中观察是否有难用、反人类的功能设计.如果觉得自身体验产品比较难发现问题,可拉上身边的同事一起体验。

1. 撰写需求文档

在项目协同管理产品广泛被使用的现在,tapd、禅道等协同软件已经可以起到传统word等需求文档的作用了。因此,我们需要将画好的原型,结合在线上需求文档中,一份合格的需求文档,应具备以下内容:

  • 需求背景:需求背景可以用几句话简单的表达一下,告诉各方你这个需求是来源于哪里?为什么要做?做了之后能解决什么问题?
  • 期待上线时间:产品经理可以根据开发迭代周期,定下一个预估的上线时间,让研发人员心里有个底,能够合理去安排资源。
  • 修改内容:需求文档尽管在开完需求会后也会存在修改的情况,产品经理需将每一次修改的内容概括到此处,让项目组成员能及时知悉。
  • 需求描述:如果在原型上已经把功能描述、交互细节备注的非常完善了,那么原型就是你的需求描述,只需把原型存为图片,放在需求文档上即可,也可提供axure的链接,让研发人员点击即可。

2. 召开需求评审会

当需求文档完善好,leader评审没问题了。此时就可以拉上UI、研发、测试同学一起召开需求的评审会议,作为会议的发起人,需要时刻注意以下这些要点:

  • 提前传达信息:在需求会召开前,需提前1~2天拉好群,并将需求文档发到群里告知项目组成员,如果发现问题能提前改好。
  • 有逻辑地去讲原型(需求文档):很有可能一个需求会涉及到多个页面,在向项目组成员讲解原型前,应提前将原型进行归类,按照页面逻辑的顺序去讲,这样做的目的是方便自己讲得通顺的同时,也让项目组成员能更好地理解需求。
  • 记录要点,迭代需求文档:在需求会中,大家可能会提出非常多的疑问,无论疑问是当场解决,还是之后再解决,都要将问题和解决方案记录下来,在会议后将修改的内容迭代到需求文档中,文档补充完成后,需在群里告知项目组成员需求修改的内容。
  • 确定项目排期:一般在需求会的最后,产品需要跟各方确定项目的排期:UI什么时候给到设计图、服务器什么时候给到接口、前端什么时候完成页面的开发、测试是否能在上线前完成等等。

3. 原型存档,及时复盘

成为一名产品新人后,自己做的原型会变得越来越多,对于原型文件,分门别类是非常有必要的。可以每个月归类为一个文件夹,也可以一个项目归类为一个文件夹,原型的命名可以写得更加规范:“原型名字”+“版本号”+“时间”(例:我的订单V1.0_0609)。

每一次完成的原型,都是我们宝贵的财富。一些可重复使用的组件、设计规则,我们可以抽离出来独立保存,当重复设计的时候,可以尽量减少我们自身的工作量。

1. 原型丑、慢、有问题

很多人会问到:“我原型画的好丑怎么办?”、“我原型画的好慢,经常被别人催”、“同事总说我设计的原型有问题”等等的一系列问题,如何解决?

其实我认为这是一个熟能生巧的过程,画的丑,就多观察别人设计的优秀案例,培养自己的审美;画的慢,就多练,多画,画多了,速度就自然提上来了;设计有问题,就多参考行业内的优秀产品,分析别人设计背后的逻辑和目的是怎样的,参考借鉴,再结合自身产品特性去设计。

2. 团队中无UI设计师

这种情况大多出现在一些做B端产品的团队,团队中无UI设计师怎么办,这个时候UI的工作就落到了产品的头上了。现在网上有大量原型设计的模板,例如Ant Design、Element UI等平台上的一些设计案例、模板我们都是可以去借鉴的,在别人的基础上修改,也是一种不错的办法。

最后,笔者想说的是,作为一名产品新人,我们应该以正确的态度去看待原型,我们没必要把原型过于妖魔化。市面上有很多关于如何设计原型的课程,多学点是没错的,复杂的交互、动效会了固然更好,但不会也不用过于担忧,毕竟在实际工作中,效率是非常的重要的。

我们做原型,目的就是为了向项目组成员更好地传达需求的信息,需求明确,项目才会进展得更顺利。因此,把原型设计得“详细”,比“美观”是更加重要的。因为上线产品的背后,是UI、研发同学一步一步照着你的原型去做,你出错,必然导致最终出来的产品也会出错,所以重视原型细节,是我们每一个产品新人都需要去关注的事情。

登录后回复
最新回复 (0)
返回