【giszz笔记】产品设计标准流程【5】

（续上回）

目录

五、原型设计

1.写在前面的话

2.原型是什么

3.画原型的工具

4.产品经理的复合能力

5.关于原型图

---

PS：这个系列，主要讨论的是产品设计的一般标准流程。这个流程也许每天都发生在我们的身边，我们也常常对此熟视无睹，实际上，更系统的理解每个环节的核心目标，成果，对提高团队的效率，确保产品的成功，有很重要的作用。

五、原型设计

1.写在前面的话

在本流程中，UX设计过程被单独拿出来放一个章节来讨论，但是设计最初的原型图，我的建议是产品经理来主导，UE设计师参与。此外，评审我也当做一个独立的章节来讨论，但是在设计原型时，如果你有一个极大POWER的甲方，最好能经常去沟通和汇报，不要总怕太快被否定，导致你多花工时，永远不要让你的设计作品等到最后评审会上，去大家一起来“掀开盖头”。实际上，在一些最佳实践的案例中，经常和甲方沟通，可能会让你的产品设计中，体现了很多甲方关键人的思路，在评审时，他就会自动的，成为你的辩护者，让你的产品设计更轻轻和顺利的过审。

评审会，当然要求，提前发会议物料到各个干系人的手中，但是你能强力要求他们提前看、并且规定好完成的时间、反馈的详细程度吗？即使要求了，他们就能很好的执行吗？执行了，就能真的理解你的设计吗？

等到会上，大量的信息涌入，……，这种沟通实际上是效率比较低的。大家经常有感受，自己的思路，不被anyone else理解，感觉领导不专业，客户太傻X，实际上，我们和自己的亲爹亲妈，也是很难沟通的吧。所以，并不是这个世界和我们格格不入。

好吧。

原型设计，是最重要的激动人心的环节了，因为大家一直期待的产品，到底长什么样子，即将小荷露出尖尖角。

2.原型是什么

原型（prototype）这个词来自拉丁文的词proto，意谓“最初的”，意义是形式或模型。在这里我们主要讲的是软件原型，便于快速沟通、确定明确需求。在软件开发中，一个原型是产品或数据系统的一个基本的实用模型。
软件原型包含但不限于：功能、交互、UI。

3.画原型的工具

工具非常多，在线设计，团队协作，几乎成了时代的主旋律，但有时一些产品的服务器能力，确实还不过关，当然，客服会赖带宽。

比较经典的，人人都知道的，就是Axure。实际上，全名是Axure RP，文件的扩展名也是rp，啥意思呢，RP则是Rapid Prototyping（快速原型）的缩写。
Axure RP的使用者主要包括商业分析师、信息架构师、产品经理、IT咨询师、用户体验设计师、交互设计师、UI设计师等，另外，架构师、程序员也在使用Axure。

人人都可以用Axure，就像人人都可以用思维脑图一样。

此外在线的工具，基本都是互相参考，并且做集成。参考（重点是拷）、模仿国外优秀产品、集成各种功能、加自己的理解改造、设置付费节点和套餐、发布、买流量，这也是一个标准流程吧。

4.产品经理的复合能力

产品真是无所不能，在大的集团，有PMO等部门和职位，或者另一种PM，项目经理，但是很多公司，产品经理，就是一个项目的全部入口和出口。客户来访，产品经理来聊下，顺便给客户倒杯水；内部协调资源，产品经理做个脑图汇报下；领导要预算，产品经理牵个头，把产品分解下和技术开个会，拍个数出来；前端技术储备不足，想要的页面效果无法按期达成，产品经理过去干一架，打赢了前端加个班，自己买会员发问答去，大输了就简化下设计；外采个系统，产品经理参与下，去谈谈价格，调研下竞品；……

当然，这都是极端的情况，可能碰到，碰到了也是纯属巧合。不管是几百人的团队，还是几十人的团队，产品确实是产品最大的owner，产品的再生父母，就是要对这个孩子负责的。即使没有人让做的，很多产品也会主动去做，因为一个负责人的产品，真的希望做出来的东西，人人喜爱，客户点赞。

当然，上面说的产品经理都是十项全能，再加上专业的画线框，画原型，做分析，做设计…….。

但是真正检验一个产品经理的业务能力和设计素养的就是他做的prototype。通过这个原型，产品经理要把你独特的理解、能力，淋漓尽致的表达出来，准确的传递出去。

有些复合型的产品经理，确实在交互设计上，有更深入的理解，有设计方法，而不是简单的把客户的用例画成简单的界面，还缺这缺那。也不是狂热的加上很多自己的理想抱负，让客户害怕，让技术抓狂。

5.关于原型图

低保真的原型图，在前面的PRD的环节，实际都做了。有的公司，PRD中，就已经包含了高保真的原型。这看项目的大小和类型。

低保真：包括页面的框架逻辑，导航逻辑，交互逻辑，标签逻辑，内容组织逻辑等。低保真在实际项目中，并不是可以“粗略”的做，只是不用配置更多的美化，图糙理不粗。

高保真原型在低保真原型的基础上，还加入了信息内容，视觉元素，交互细节等。

两种原型的用法也略有不同：

一般在产品团队中，大多是出低保证原型。因为，在设计之初，最怕的是偏离设计方向而浪费资源，所以通过低保真原型可以快速的发现问题，通过不断的迭代设计完善产品框架和主体构造。有的产品经理是强迫症，宁肯熬夜，也要出漂亮的原型，这也挺好的，避免产品设计理念由于表达不“具象”被误伤，也行。

一般在与外部进行产品工作成果说明和演示时，用高保真原型更好。因为客户就看颜值。用户更喜欢关注产品的实际模样，因为他们骨子里是代表未来实际使用者的利益，如果他们觉得色彩不好，交互细节有问题，那么他们会坚持要求团队做出响应，直至他们满意为止，我们最好将这个过程安排的越早越好，至少不要因为他们的意见而导致后期的开发工作重复。

我比较喜欢Scrum的敏捷模式，高频的沟通，确保每一天的成果都最大程度的有效，关于scrum，可以参考我的文章Scrum好用吗-CSDN博客

这里的原型图，特指高保真原型图。

原型图包括如下的要素：

• 页面布局：页面的整体结构，包括导航栏、页眉、页脚和内容区域等。
• 功能模块：网站或应用程序的各个功能模块，如登录、注册、搜索、商品展示、购物车、结算等。
• 页面元素：页面的各个元素，如文本框、按钮、下拉框、复选框、单选框、图像、视频等。
• 交互效果：用户与页面元素相互作用时的效果，如弹出框、提示框、动画效果等。
• 页面跳转：各个页面之间的跳转关系，如首页跳转到商品列表页，商品列表页跳转到商品详情页等。
• 用户反馈：用户与页面交互后的反馈，如错误提示、成功提示、警告提示等。
• 页面细节：页面的其他细节，如页面颜色、字体、大小、边距等。

对于流程相对复杂的业务，原型图的辅助标注或者说明，无法准确的表达业务流程，比如跳转的逻辑。这时要注意对前述PRD进行更新，通过一些图表，来更准确的描述业务。尽管后续有交互设计，但是随时发现问题，随时更新，同时内部拉通，这总是好的。

（未完待遇，下次我们讲如何组织高效的评审）