一份高效的产品原型设计“规范”

我们在做产品经理的工作，用原型来表达产品设计是一个绕不过去的工作版块，很多产品经理的工作时间超过一半以上都在绘制原型。

1.原型规范为什么这么重要？

形成一个团队或自己的原型规范，可以帮助减少自己原型工作时间，还能避免了需求不严谨、甚至是出错的问题。

因为原型实际上等于我们上线产品的具体页面，原型要做的产品设计也就是把App\网页等系统功能所牵涉的页面一个一个绘制出来。

随着工作时间的经验积累，产品经理接触的业务案例越来越多，绘制的页面越来越复杂，我们会找到满足功能设计的核心节点，再进一步沉淀总结就可以拥有自己的一套原型设计规范了，形成规范后的原型设计与开发、设计、测试等沟通效率都逐步提高。

而多余的时间，产品经理就可以聚焦在需求调研、业务拓展、甚至是市场和商务的板块。

2.我个人喜欢的一份高效原型规范

有没有一种原型规范，可以覆盖产品经理所涉及到的产品？包含C端产品、后台产品经理、以及数据产品经理等工作呢？还能够支持包括App、PC、小程序等市面上可以看到的软件形态呢？

今天分享一份我在工作中总结出的一份原型规范，如果投入到团队使用，用这个规范完成1个版本以上的开发后，团队的效率就会越来越高。

这种原型规范方便开发阅读，同样也是设计师、测试等人员容易理解的形式。

原型设计的母板规范

母版在不同原型软件工具下名字叫法不一样，有的叫做模版，有的叫做母版。但顾名思义就是可以在本次原型文件里通用的原型组件。

▲  axure的母版

我建议原型母版应该包含产品的页面导航栏、页面菜单、页面通知、账户信息等全局的功能，这类功能组件有一个特点，即产品的每个页面或者某一个功能下的每一个页面都会有这样的按钮、文案甚至是交互，所以把这类功能合集变成母版将大大降低原型绘制的时间。

▲  功能菜单下的母版

原型的交互说明

交互设计师和产品经理的区别是：

• 交互设计关注在人机交互过程的最好路径，而不是在意是什么功能。

• 产品经理关注的是为用户提供的功能是什么，而不是操作路径。

随着科技进步，不同的终端设备配套的软件不一样、产品形态不一样，其所需要的交互也是不同的，比如网站交互是依靠鼠标键盘，手机的交互依靠手指、VR设备则依靠眼睛。

大多数产品经理的工作是负责某一个单一的产品形态产品设计。只有少部分高级产品经理会负责业务线。一个业务线可能包含多个产品，比如曾经我在喜马拉雅负责线下业务，就负责门店的营收系统，其产品形态（PC端、和APP、小程序）都有。

但我们在做原型的时候，不管是负责业务线、还是产品线，往往一个原型文件会只针对一个产品形态，并且匹配一套交互说明。

下面介绍高效原型规范下的PC和移动端规范

PC的交互说明

1.输入框的交互说明

包含输入框的内容校验、操作提示、和文案提示

2.页面按钮或功能区的交互说明

使用者会点击、悬浮、或双击等操作，能够给出对应的交互提示

3.操作弹窗交互

弹窗的文案说明、弹窗配对的功能选项（单选、多选、还是是否确认），并给出操作结果的提示

4.内容上传交说明

包括默认图片、上传图片预览、以及上传失败的提示，如果对封面有要求，还可以提供裁剪功能，方便信息流效果展示

5.按钮操作交互说明

按钮的选中、取消和默认选择状态的展示，往往会根据前置条件来做对应的反馈。

6.选项框的交互说明

选项分为多选和单选，给出默认选项、选择数量、和数量限制提示，对于选项可以进行编辑、添加的操作

7.账户密码交互说明

因为账户密码不限于PC网站，每个产品都有账户，所以其交互是通用的，包含密码校验错误的各个场景的梳理，给出默认提示、错误提示、和内容为空的交互展示。

App的交互说明（小程序/H5通用）

1.页面导航栏交互说明

App的功能每个页面导航栏跳转方式是固定的，甚至很多时候一个App就是一套一样的。分清功能区、标签导航、页面标题之间的层级关系。

2.页面内弹窗交互说明

弹窗的选项和默认选择，同时给出匹配的按钮文案，方便用户快速选择和确认。

弹窗选择出现的前置条件说明，以及异常情况下的弹窗内容提示。

2.toast提示交互说明

提示包含了用户操作反馈和系统状态反馈，比如正在和服务端数据交互、用户前端操作触发某些条件等，需要用toast的交互来表达，并且匹配文字。

3.操作区域交互说明

App的操作是随着手机面积有变化的，需要说明那些区域可以点击、那些不可以，往往这个是和前端开发息息相关，我们只需要关注UI图按照原型设计表达即可。

4.输入框交互说明

和PC网站交互说明一样，输入框包含了默认文字、输入提示、和输异常提示。

原型的逻辑说明

原型不仅是一个页面，我们在做产品设计的时候，往往会换位思考为用户角度，模拟同样场景下用户在原型里的操作，实际是存在页面顺序的，功能与功能之间也有前后条件的，所以就构成了原型的逻辑。

仅仅是靠一个原型设计的页面是没办法搞清楚需求的全貌，让参与的开发、设计师知道整个需求的来龙去脉。

我接触许多产品新人在做原型的时候最容易欠缺的就是原型背后的功能逻辑，比如你看到的原型工具实际上都可以完成脑图、流程图等功能模块的撰写，原型工具不只是用来画产品页面的，在某些角度来说它就是一个画图软件。

▲  原型的逻辑图

换句话说：原型工具在产品经理的手里其实是一个万能的工具。

实际上产品经理在讲解需求的时候，每次需求评审会一开始，就会开始讲解原型的某个页面，也是坏习惯。让团队知道本次的工作达到的目的，以及要解决的问题，实际上原型的逻辑说明是非常重要的。

原型的文档说明

高效的原型规范一定是要配备文字说明，否则就难以增加原型的理解度。有了文字说明，对复杂的原型效果我们可以省略设计时间，直接用一句文字来代替。

比如如果按照不同账户去绘制下面的权限操作，需要重复绘制下面报表，有多少个角色就要绘制多少个报表。

但我们可以用一句话来替代：“根据用户账户权限，不同权限可以看到的自段内容为XX....“就可以快速完成。

还有原型需要的动画加载效果、原型权限说明、功能的交互动效，都可以用文字来说明。

原型的功能架构

在高效的原型规范里，我们不只是聚焦在一个页面的设计，还要关注在原型背后的产品框架、功能架构，所以我们利用原型提前布置好原型的架构图，可以帮我们全局查看需求的复杂性。

比如上图，给出了内容管理后台下的框架结构，给出了新建素材所涉及到的功能模块必选操作，同时给出了功能模块的逻辑顺序。通过这个结构图可以发现这需求设计冗余复杂，应该可以再进行优先级划分，变为更小的需求。

以上就是本文的分享。

---

推荐作者的公众号：