产品设计流程系列如何进行原型设计上
⇨⇦
经历了漫长的产品设计流程，我们终于来到了最后一个环节，也就是根据之前梳理的产品流程来进行产品的界面设计了。
产品经理其实都知道，在这样一个看重颜值的时代，一个赏心悦目的网站（或者移动APP）是多么重要。每一个产品经理，也都希望自己的创造的产品是与众不同的，在茫茫的互联网产品海洋里，能够闪出耀眼的光芒，就好比每个人都希望自己是人群中独一无二的那一个。嗯，这么说来，其实每一个产品经理的内心深处，都有着一颗文艺青年的心灵，也正是拥有了这样一颗感受丰富、细腻的产品之心，才使得我们能够对产品设计的细节有着更为透彻和深入的理解。
在大公司内部，通常来说不需要产品经理去进行具体的界面交互设计，多数是由产品团队与UED团队合作进行产品原型的设计，出具的交付物是产品原型和页面交互图，而产品经理则需要产出产品需求文档（PRD文档）。但是在绝大多数创业公司团队里面，则没有配置那么豪华的产品设计、交互设计团队，常见的搭配往往是一个产品经理加上一个UI设计师，所以一般都是产品经理自己身兼交互设计的工作职责，输出交互设计稿，也就是产品原型。
什么是产品原型
说的简单一点，产品原型是设计方案的表达，是产品经理、交互设计师的重要产出物之一，也是项目团队的其它成员（尤其是设计师、开发人员）的重要参考和评估的依据。
结合我们前面了解的知识，产品界面原型其实就是页面级别的信息架构、文案设计、及页面和页面之间的交互流程，它是产品功能与内容的示意图。
直接上几个原型图，可能会更加清晰明了，如下图：
原型设计稿
产品设计原型按照精细程度来分，可分为低保真产品原型和高保真产品原型、设计成品
低保真产品原型
所谓低保真原型，其实是对产品较简单的模拟，它只是简单的表述了下产品的外部特征和基本功能构架，很多时候都是用简单的设计工具迅速制作出来，用来表示最初的设计概念和思路。
比如用纸和笔进行的手绘，用画图软件做出的简单线框图，都算是低保真产品原型。
这样的原型图有几个好处：
可以快速产出：有时候一个需求的开发周期很短，低保真原型可以快速满足同事的时间要求。
修改成本低：一个产品策划很可能会被修改很多次，低保真的原型修改起来很方便。
当然，低保真原型也会有几个问题，比如交互细节不清楚，容易造成误解等。通常来说，一般只有时间比较紧迫，需求也比较简单的时候，我们才会去产出低保真产品原型。
高保真产品原型
高保真产品原型，则是高功能性、高互动性的原型设计，是忠实展示产品功能、界面元素、功能流程的一种表现手段。原型图中无论是功能模块的大小，还是文案设计甚至是所用的图标、图例、交互动作，都使用真实素材，或者说和最终UI设计师的产出非常接近，就算是高保真产品原型了。
高保真的好处：
便于梳理产品细节：制作高保真原型的过程中可以让产品经理提前发现产品潜藏的各种问题，提前处理风险。
更容易让其他成员了解产品设计：有时候简单的线框图无法让别人想象出你要做的事情，也不清楚你要放的是哪几个字段，而高保真原型就可以。
相对而言，劣势就是制作周期比较漫长，涉及到产品流程的修改，那基本原型就得回炉重造一遍。
对于刚入门的产品经理，我一直建议有时间的话，还是尽可能多的画高保真原型。因为在一开始产品设计经验不多的情况下，通过设计一些高保真原型，对梳理自己的产品思维、了解产品设计是很有帮助的。对于已经入门很久的同学来说，则看需求的复杂程度和时间安排，比如产品的关键页面是必然要用高保真原型去设计和梳理的。
设计成品
设计成品在这里，你也可以理解为是视觉设计师产出的UI设计稿，也就是设计师对你的产品原型进行美化之后得出的作品。设计师会运用一定的设计规范，来将你的原型变成可以让开发进行实现的作品。
在设计成品出来的那一刻，产品经理需要做的就是和设计师进行PK就好了，我们在这里就不再过多来描述了。
放上一张图来比较下三种原型的区别：
三种原型比较
原型设计工具
这里给大家介绍几款产品经理常用的原型设计工具：
Axure RP ，推荐指数 ✦✦✦✦✦
axure官网
Axure RP是一个专业的快速原型设计工具。Axure（发音：Ack-sure），代表美国Axure公司；RP则是Rapid Prototyping（快速原型）的缩写。
Axure是产品经理的必备工具，其他的不多说了，去看看招聘网站上关于PM的招聘信息，基本所有职位描述里，都包含了这么一句＂熟练使用Axure＂，所以你懂的。
墨刀，推荐指数 ✦✦✦✦
墨刀
墨刀也是一款原型设计软件，虽然可能功能没有那么完整，相对来说对于一般使用也是足够的，目前分为网页版和客户端，网页版可以直接使用，客户端其实也是网页版的功能，一般来说会下载客户端，使用过程中需要联网。
墨刀想对来说有这么几个优势：
简单、易上手；
支持团队多人协作；
控件什么的都是现成的；
可以直接在手机上预览；
当然缺点也很明显：
依赖网络，网络不稳定或者服务器不稳定的时候则没法使用；
很多交互功能不够强大；
Visio 2013，推荐指数 ✦✦✦
visio官网
很多老牌的产品策划人员、产品经理都使用过它来设计产品原型，算是线框图专业户，比较灵活，Office使用习惯接受程度较高。另一个好处是支持各种平台尺寸设计。有些产品设计团队从原先的Axure 调整至 Visio ，是因为Visio 可以更便捷地输出标准大小的PDF文档，方便在同事之间交流。
在学习伊始，很多刚刚入门的产品经理就热衷于上网找网络课程学习Axure等工具教程来学，乐此不疲；希望通过精通的工具使用能力展示来为自己求职或在交互学习路上的发展加一把力。然而这并不是重点，工具只是用来承载我们思想和内容的一个载体，所以没有必要把太多的时间消耗在掌握工具技巧上，产品设计的内容才是真正需要用心去考量和思索的。
设计原型时需要注意的事项
通过上面的介绍，其实我们已经了解了，一个好的产品原型可以让其他人迅速理解我们想要做什么事情，减少团队沟通成本，并确保接下来要推进的事情没有什么误会。
产品经理在将原型图画好之后，往往会特别欣喜，恨不得立马就让全体团队成员看到自己的设计成果。但是，这时候的原型图通常是不完整的，很多场景、因素缺少考虑，小到一个按钮的位置，字段展示、大到功能的流程设计、逻辑设计。如果你就轻易把这么一份不完整的原型交付给技术，不但技术会喷你，搞不好用户也来喷你，甚至Boss也来喷你。所以，打磨好产品原型，尽量考虑各种场景、因素，设计原型时尽量细化分析，让所有人从原型就能看到你的态度，是一件非常重要的事情。
总体来说，原型设计需要表达清楚这么几个地方：
1. 界面元素
什么是界面元素，比如文字，下拉框，按钮，图标、图片等等这些都属于界面元素。我们在运用原型设计工具（如axure、墨刀、visio等）设计产品原型的时候，需要明确界面上的元素是什么，如何展现，鼠标移动或者点击上去是怎样的效果。
2. 数据逻辑
这一点往往也是非常多创业团队和新手产品经理容易忽视的。比如一个直播列表界面，上面有三个tab，分别是关注直播、热门直播、最新直播，那么最新直播是基于怎样的数据逻辑获取的，你就需要在你的原型设计上进行说明了。当然，最新直播的数据获取逻辑是比较简单的，也许你不和研发人员说明清楚，他们也能知道是按时间倒序排列；但如果碰到稍微复杂一点的数据逻辑呢，就比如刚刚说的关注直播的数据获取，是获取关注的机构的直播呢，还是获取个人的直播呢，这都是需要说明清楚的。
3. 操作逻辑
一个原型界面上可以进行操作元素的有哪些，哪个可以点击，哪个可以选择，操作后出现怎样的反馈，比如弹出浮层？进入新页面？或是跳出新页面？还是给一个怎样的提示？ 这些也是需要在原型设计里面说清楚的。
这三个点是一份完整的原型设计基本需要包含的东西，再配合上之前画好的产品结构脑图和流程图，就基本可以与开发进行轻松愉快的交流了。只有这样，开发者才能明确这个原型设计的开发需求，而不是让开发工程师自己去猜，去揣测数据逻辑、算法应该是什么样的。
如下图，可以在原型设计上做相关的注释说明：
原型设计说明
谈谈产品需求文档（PRD文档）
很多公司都要求产品经理写产品需求文档，我们来看下一份完整的产品需求文档包含哪些部分：
产品需求文档内容
通常来说，产品经理往往不会写的那么详细，能够覆盖到前面四个部分便已经算是一份基本合格的产品需求文档了。
我们一起来看下文档里面都具体包含什么内容：
1．概述
概述部分是概括地说明产品背景、产品目标等。
1.1产品概述及目标—-包括背景介绍和产品目的
1.2名词解释—-声明文档中出现的名词含义
1.3数据词典—-介绍本产品中数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等。
1.4文档阅读对象—-声明本文档输出的阅读对象和注意事项
2．产品描述
产品描述介绍了产品的整体逻辑流程，概括性的描述产品需求、产品版本规划、产品整体的框架结构以及功能列表。产品整体流程与产品框架都需要使用相应的图表展现方式
2.1产品整体流程-—展示产品框架图和用户流程图。
2.2产品需求描述—-描述产品核心功能，解决哪些情景下的哪些需求。
2.3产品版本规划—-叙述产品版本迭代计划，版本号、主要模块、功能点、计划开发时间、计划结束时间、备注。
2.4产品框架—-展示页面层级及备注信息
2.5功能列表—-展示产品功能名称、对应模块、功能说明、备注等信息。
3．功能描述
功能需求这部分需详细描述产品所涉及的各个功能点。将整体框架拆成数个独立的功能点，分别描述每个功能点的逻辑流程图、界面、字段说明以及业务说明。统一采用Use Case的方式进行描述。
3.1流程图
3.2界面原型
3.3字段说明（包括数据字典）
3.4业务说明（Use Case）
4．非功能需求
非功能需求，也就是关于产品的其它方面的要求。
4.1安全需求
4.2统计需求
4.3性能需求
4.4可用性需求
嗯，我们已经看到了常规的产品需求文档长什么样了。有一次和一个朋友聊天，说起他们公司的产品需求文档，是一份长达200多页的word形式的产品需求文档，其实这样的文档看起来相当费劲，也不容易更新同步；
很多开发人员和产品经理之间产生的矛盾，其实都是因为这份又臭又长的产品需求文档。因为无论是谁，都不喜欢看这么长的文字，开发人员其实根本不需要这份文字式的需求告白书，他们喜欢＂看图＂，这种文字式的需求文档应该是产品经理脑中的思路，而不应该直接把思路描述成文字转交出来。其实我个人也不喜欢这样的风格，沟通成本太高，所以对于创业公司而言，还是尽可能简单直接有效最好。 做好如上几点，对于大部分产品沟通场景来说，应该就可以满足。