产品新人应该如何用好“原型”？

一、过于追求样式特效

刚开始实习的时候，上级会分配到一些新功能需求，往往会需要去从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、研发同学一步一步照着你的原型去做，你出错，必然导致最终出来的产品也会出错，所以重视原型细节，是我们每一个产品新人都需要去关注的事情。

本文作者 @Silence

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！