编辑导语：画一个好的产品原型，是每个产品经理的必修课。但是从零开始的项目比其他已经进入正常迭代节奏的项目难度更大。本文主要介绍如何根据个人实际工作经验绘制一个新项目的产品原型。感兴趣的朋友，一起来看看吧。 　　

　　每个产品经理在成长的道路上总会遇到一些全新的挑战，比如全新的功能，全新的项目，甚至全新的业务，全新的市场。 　　

　　每一个新的挑战都是对自己的磨练。 　　

　　其中，从零开始经历一个项目，手工打造一个全新的产品，是产品经理成长最快的方式，也是检验自己能力的绝佳方式。 　　

　　但是，负责一个全新的项目，不同于负责功能迭代和新的功能模块，其复杂程度已经大大提高，往往让人无从下手。 　　

　　关于新项目的市场分析、用户分析、需求分析等等，已经有很多文章和介绍了，这里就持个人拙见。 　　

　　本文主要从如何设计新项目原型的角度介绍一些个人的工作经验，希望对大家有所帮助和启发。 　　

一、新项目的难点

　　与功能特性迭代不同，新项目需要全局视角，但项目中的每个人(包括产品经理本人)对产品的最终形态都缺乏清晰直观的认识。新项目往往包含多个模块，原型设计容易专注于每个模块和页面本身，最终使得原型只是页面的堆积，而缺乏功能模块之间的联动；不同的功能模块有优先级，页面上不同的功能也有优先级，所以产品原型很难在体现不同模块和功能优先级的同时展现整体的功能特征；在项目的整个过程中，随着讨论的深入和项目的推进，原型会经历反复的修改，内部信息很难对齐。因为有这么多的困难，所以做好这件事是有意义的。 　　

　　去年，我开始负责部门一个旧系统的改造。因为新系统增加了很多功能特性，删除了旧系统很多多余的功能，整体流程和交互也有了很大的调整，所以某种程度上可以算是一个全新的项目。 　　

　　因为是后台项目，所以这个项目没有交互设计师和视觉设计师，产品经理提供的原型也直接用于项目研发。 　　

　　为了支持这一项目，该部还投入了一些新的研究和开发资金。d人力。这些新生对业务知识和旧系统的功能知之甚少。所以，如何通过需求原型统一大家的认识，实现项目的持续推进，就成了除了梳理系统需求之外的重中之重。 　　

　　我也会以这个项目的一些实际工作经验为例，介绍如何设计一个新项目的原型，以及原型的更新迭代。 　　

　　00-1010很多产品经理把产品原型等同于页面交互。 　　

　　事实上，产品原型本质上是一种交流工具，它使产品经理能够更方便地交流产品的功能特性，也使R & ampd和测试更快地了解产品的工艺和功能，从而更准确地评估方案。 　　

　　因此，许多沟通技巧也适用于产品原型。 　　

　　没有人喜欢在不了解背景的情况下，一下子进入交流的话题。 　　

　　产品原型也是如此，所以我们也需要在产品原型中为相关的业务背景和业务流程做铺垫，让团队成员先没有一个整体的了解，而不是突然进入具体的页面设计。 　　

　　下图00-1010是腾讯云备案审核系统的关键业务流程，整个审核系统的订单处理都是基于这个核心流程。 　　

　　00-1010除了描述核心业务流程，我们还需要介绍整个系统包含哪些模块，每个模块包含多少页面，页面之间的关系如何。 　　

　　如果某个功能模块相对复杂，涉及多个页面，那么清晰的页面流程图可以更好地帮助R & amp理解。 　　

3. 页面状态及交互说明

上面的部分，是不同页面之间的流转关系。

有些时候，同一个页面，在不同的状态或环节，其主要功能操作往往也有所区别，因此在特定的页面，最好也能加上页面状态及主要功能操作的说明。

4. 竞品资料

竞品调研也是产品分析环节非常重要的一环，在产品原型的设计中，友商的设计经常能开阔我们的视野，为我们带来一些启发。

我在进行功能体验的时候，对友商产品流程进行的整理，看看友商在哪些地方学习了我们，也看看友商有哪些地方值得我们学习。（在这里也给产品新人提一个建议，对于自己负责的项目，也可以根据类似的办法，整理相关的资料）

三、每个页面/模块增加功能点列表

在进行具体页面的设计时，往往很难在一个页面中讲述清楚所有的功能，尤其是涉及到状态变更，以及某些隐藏功能的时候。

此外，页面中不同功能的优先级是不一样的，追求页面功能完整性的话，就会显得页面非常臃肿，难以区分轻重缓急。

这个时候，我们可以在子页面中具体介绍每一个子功能点，大到一个重要的交互，小到一个具体字段的定义，都可以单独进行说明。

同时，在页面中增加一个功能点列表，并对每一个功能进行编号，以及定义好相关的优先级。

这个项目，因为开发工作量较大，我们分为了好几期进行开发，PM和研发也主要根据这里定义的优先级进行排期。

四、不制作过于复杂的交互效果

没有人不喜欢高保真原型，但高保真原型是有代价的。

在我看来，具有复杂交互效果的高保真原型，主要是面向老板（投资人）、产品核心用户的，并不适合敏捷开发流程。

在实际的研发流程中，高保真原型是存在一些缺点的：

（1）不直观

某一些弹窗必须通过特定的条件或特定的按钮才能触发，如果研发比较粗心，没有注意到原型中的这个点击动作，那就漏过了这个产品经理精心设计的功能了。

（2）容易让人聚焦于细节

产品实现需遵循粗放到精致的过程，如果原型中使用了过于复杂的需求，容易让人聚焦于细节，而忽略整体流程中的问题。

（3）维护困难

项目初期，产品原型会经历非常多的改动，甚至会出现删掉某个大模块的情况，具体到每一个页面，也时常经历着大改的考验，因此过于复杂的交互，会给后续产品原型的维护带来诸多困难。

（4）职责不明

如果项目还有交互、视觉同学参与进来，那么太过于精细的产品原型，反而会限制交互、视觉的发挥，让交互、视觉的工作沦为“画图”，反而少了许多对项目的思考及参与，长此以往，对整个项目反而是不利的。

目前包括Axure在内的很多原型设计工具，都支持制作复杂的交互效果，但我们要秉承“为我所用”、“我会，但没必要”的原则，使用合适恰当的方式来呈现需求。

个人是习惯将弹框这些默认不可见的元素，也放到页面原型的旁边，并在页面中增加相关标记，表明页面元素与这些弹框的关系；此外，也会在页面中增加相关文字说明，以便研发同学了解。

五、发布在线原型

Axure这些原型工具是支持生成html文件的，可以直接通过浏览器打开，查看原型的具体内容。

然而，如果原型需要频繁修改，那么原型文件的同步就成了大问题。往往一个原型文件刚发出去，就发现有一些需要修改变更的地方，又需要赶紧打包一个新的版本。多的时候，一天打包十几个版本都是可能的。

版本众多的原型文件，很容易造成信息不对称，因为产品经理也很难将最新的原型文件及时同步给到所有人。

因此，有一个统一的，在线的，可随时更新的在线原型是非常必要的。

Axure本身支持将产品原型发布到云端，可以直接链接查看产品原型，不过这样做会存在信息泄露的风险。

为了规避这种风险，我们可以将原型的静态文件更新到自己的服务器上。

我之前的项目中，就曾经通过这种方式进行管理，让研发同学帮忙将原型文件发布到内网的服务器中。

只不过这种习惯最终没有保留下来，因为服务器权限还是在研发同学那里，每次发布原型都需要研发同学帮助，后来项目团队发生变化之后，就没有继续沿用这个方法了。

后来发现了腾讯内部的pages工具，可以来发布静态页面，产品经理自己就能适用git工具发布更新原型文件，虽然存在一点门槛，但上手之后却是非常方便。

目前我们团队内部的产品经理都主要使用这种方式来对外发布产品原型，推荐大家学习使用。

六、时常更新，并记录变更内容

在线原型虽然可以实时更新，但也引发了新的问题：产品经理在同步原型文件的时候，一般还会同时同步修改的内容。

但可以方便地实时更新之后，这种修改记录的同步就很难要求了。即使同步了，往往也只是在项目团队内部，而很难同步到项目团队以外。

因此在原型中，最好能够配套一个ChangeLog，这样可以让所有人员，快速了解原型的更新内容。即使每天原型更新十几次，也能够在ChangeLog中说明所有改动的内容。

七、适合的，就是最好的

之前说过，原型是一种沟通工具，既然是一种沟通工具，就需要根据沟通的对象，沟通的场景，以及团队内的流程及习惯进行调整，并没有放诸四海皆准的标准，适合的，就是最好的！

作为产品经理，在产品需求沟通这个环节，应该将团队成员当成用户，将原型当成一个产品来打磨。

团队成员，除了研发，还会有PM、测试，乃至是Leader，不同角色想要从原型中获取的信息各不相同。

同样是研发职能，不同的研发人员的习惯也不尽相同。

作为产品经理，在进行原型设计时，需要考虑不同职能，不同人员的需要，不断地打磨原型内容的呈现，尽可能地提高团队内部的沟通效率。

最后也说一句，我们不能忽略忽略产品原型在项目中的作用，也不能过度拔高原型的作用，不能因为有了清晰准确的产品原型，就省略掉必要的沟通。

作者：klayhuang，腾讯产品运营；公众号：腾讯大讲堂

本文由 @腾讯大讲堂 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。