谈谈原型设计中配备的原型交互规格说明书DRDWord文件下载.docx

谈谈原型设计中配备的原型交互规格说明书DRDWord文件下载.docx

《谈谈原型设计中配备的原型交互规格说明书DRDWord文件下载.docx》由会员分享，可在线阅读，更多相关《谈谈原型设计中配备的原型交互规格说明书DRDWord文件下载.docx（20页珍藏版）》请在冰豆网上搜索。

它是把抽象的产品需求转化为具象的线框图呈现的过程，在交互设计日常工作输出的最终产物，用来告诉别人「页面设计细节」的一个说明文档。

在项目中，产品经理或者交互设计师的主要产出物可能依次是：

站点地图（sitemaps）、页面流（flowcharts）、线框图（wireframes）、视觉样式（screendesigns）。

如果需要对交互设计进行说明，有些产品经理或者交互设计师往往会直接标注在线框图里，或者在项目中不断和前端工程师和开发工程师口口相传，反复验收，不断迭代修改来确保所有的交互设计意图最终得以呈现。

然而这样做可能会浪费很多时间，甚至意图传达不够清楚，以及标注在线框图里的说明也不够清晰（再加上能够被标注的空间和条件非常有限，所以只能对一些主要或者特殊的功能和数据进行备注，无法做到面面俱到）。

在这样的情况影响之下，那么就需要将这些做法给规范一下。

这就需要一份交互稿子，产品经理或者交互设计师的工作虽不只是画交互稿子，但是好的交互稿不仅能够完美阐释产品内容和产品经理或者设计师的设计思路，还能够在项目各方协调工作中起到重要作用。

保证完整的呈现产品需求和设计思路的交互稿，能够让各方工作人员有一致的工作目标，而有良好体验的交互稿，还能够便于各方理解，从而提高后期开发对设计的还原度，提高各方工作效率。

全局页面说明主要包括Z轴内容层级、X轴和Y轴适配方案、整体跳转逻辑等，这些均需要在产品研发前期通知前端、视觉等协作同事的。

准确传达自己的整体产品设计思路，便于他们进行框架搭建或者视觉定义。

另外，还可以指导后期复杂需求的交互设计。

全局交互则是为了组件化设计，不仅保证产品设计的一致性，也能够提高视觉和开发工作效率。

单页面文档设计

由于每一个页面的内容比较丰富且交互逻辑复杂，所以逐渐形成了每一个文档页面只做一个页面的设计规则，保证设计文档中的页面与真实产品中的页面一一对应，便于交互文档按照产品业务组织和减少协作方查找内容时间。

单页面设计其实与一个页面只讲一件事情的设计方法相通，在表述本页面内的设计内容时要说明清楚每一个与其他页面关联的用户接触点从哪里来到哪里去，保证开发、QA们阅读交互说明的时候能够理解当前页面内容与其他内容的关系。

统一页面内容布局

作为交互文档，它的目标用户比较明显的主要是与我们协作的前后端开发、QA们、视觉小伙伴，其实我们可以很简单地就了解到他们几乎90%都在使用公司配置的显示器，公司配置的显示器基本尺寸为1920*1080，所以便可以根据显示器的尺寸定义Web页面大小、交互说明显示区域等，这样便可以尽量保证在首屏内显示相关内容。

另外，根据对开发的了解，他们较为习惯Y轴方向浏览信息（其实感觉大部分人都喜欢Y轴方向浏览信息），因此文档页面和交互说明布局以纵向为主，在他们单方向浏览时，保证所有交互点都能看到。

主页面

比如，运营平台中有需要在表格中横向显示十几项信息内容。

1.尽量使用灰阶色

不少产品经理或者交互设计师做交互稿的时候是非常认真的，会尽量做高保真的设计，有蓝色或绿色按钮、橙色的警告图标等，有时候还会直接用视觉设计定义的视觉色彩规范去做交互稿，呈现出完美的交互稿。

说实话真的是很漂亮的交互稿，几乎不需要视觉设计师做什么修改。

这样完美的交互稿却在无形中对视觉设计师、开发、QA们造成了困扰。

对于视觉设计师来说，在交互稿中出现的那些彩色其实会对他们做视觉设计造成一定的干扰，表示不同明度的灰色调，其实他们是能够理解到交互设计师所要表达的意思的。

另外，交互稿中彩色内容还会成为视觉焦点，跟开发和QA们有沟通过，他们表示这会无形中干扰对交互逻辑和细节的关注。

2.统一字号和字体

比如统一使用微软雅黑，选择这个字体纯属因为它是无衬线字体，看着简单，而且微软雅黑是各浏览器适配系统字体时的常用默认字体。

字体中有一个正常页面文稿唯一可以使用的彩色，即警告色#ff6666（彩色也尽量使用饱和度较低的彩色）。

除了主要定义了自定义灰度色系、字号，还有4px间距、头像尺寸、品牌色。

3.不同类型的需求应有不同的方法呈现设计

产品需求大致可以分为两大类：

任务型和信息型需求，针对不同类型的需求要能够通过一些基本的设计方法去呈现我们的设计。

比如，对于任务型需求，我们可以提供必要的流程图去帮助开发和QA们更好地理解用户在完成任务的过程中可能会走到哪里，有助于他们进行研发设计和测试设计。

那么对于信息型需求，则提供信息结构图和业务架构图，让他们在宏观上能够更好地理解需求。

4.交互说明应便于阅读和查找

交互说明中尽量字体稍微大一些，交互说明的字体大小我们使用的是16px，比一般字体会大2px，这一方面可以区分交互说明文案内容和页面内容，另一方面也便于开发和QA们阅读。

面上内容与交互说明的组织方式可以有很多种，比如，画上连接线、编号标记等。

我们组目前做的业务需求还是都比较复杂的，考虑到不想让页面变成编织网一样的东西，便采取了实用编号标记的方式去组织交互说明。

如果交互说明中出现不同内容的点需要再次写交互说明的时候，编号采用N-N的形式，交互点中每一条交互内容以中划线开头，交互内容中如果再有分级，便可使用无序编号等等，依次类推下去。

如果交互说明中出现与其他页面的关联，着重标出来，这样便于开发和QA们在阅读的时候能够很快定位跳转或回跳页面，明确本页面与产品其他部分的关系。

5.交互说明应具有逻辑性

逻辑性或许是每一个设计师的必备属性，我们使用MECE也好，使用逻辑树分析法也好，都是让我们能够遍历或穷举我们想要写的交互点的各种情况的。

这里我主要想说的是要真正的具有逻辑性，我接触的一些设计师，虽然也能对一些用户接触点做出详尽而无遗漏的说明和解释，却经常会出现说此言彼的情况，使得交互说明冗杂而不易阅读。

而真正的具有逻辑性，是能够清楚自己在每一个用户接触点上想要说明的场景和处理方式，尽量减少各个用户接触点的交叉说明，保证交互说明思路清晰而内容详尽。

6.交互流程应具有封装性

封装性的概念其实来源于研发中代码封装的概念，说的是如果一个方法被封装好了，当使用到这个方法时，只需要传入不同的参数便可以得到想要的结果。

这里我引用到流程的封装上，一个全局性的需求流程可能是不一样的，定义好变量参数，便可以在不同的模块调用这块逻辑。

这是比较符合开发们设计代码的主要思路的，所以和研发们解释起来是非常顺畅的，而且能够减少重复设计。

二、原型交互规格说明书（DRD）的结构分析

那么，一份好的DRD文档应包含哪些内容呢？

以下是我整理的DRD输出思路，仅供交流或参考。

内容源自工作经验的总结，源自同事的沟通及反馈，源自过往阅读过的相关文章的总结。

当然，这个交互设计文档模版不是一成不变的，产品经理或者设计师要根据自己产品的需求以及内部设计团队的实际情况来灵活运用，不要被模版限制了想象力，其实变来变去，就这么多内容。

∙文档封面：

团队/项目信息+版本信息+时间等。

∙更新日志：

文档中更新的部分及对应的更新人员，方便他人查看。

∙文档图例：

文档中所用图例的说明及其意义。

∙设计背景/思路（设计过程/文档说明）：

需求分析表结构、产品结构/信息结构、业务流程/功能流程图、需求列表。

∙业务流程：

产品的核心业务流程（也可以在交互原型稿中随页面流程一同展示，根据实际需要制定）。

∙全局通用说明（全局说明）：

包括常用的交互控件、全局可复用的界面、单位的规范、时间规范、缺省页汇总、动效说明、语音说明、安卓说明、打点说明等。

∙非功能需求说明：

为了满足用户，业务需求开发要做的事情、如安全、性能等。

∙页面交互：

文档的主体（包括信息架构图、操作流程图、页面交互流转、交互说明等），并根据页面的层级优先级，实际情况进行编号命名。

∙回收站：

存档一些暂时不需要的内容，方便后期调用；

被称为是交互文档的“后悔药”。

在改了很多稿的交互稿中你永远不知道哪一稿才是最终稿，所以，请把你遗弃的稿子放在这里！

万一老大很喜欢第一稿呢？

谁也说不准！

1.设计背景/思路的简述

下面对原型交互说明书的一些主要的部分进行讲解一下，至于文档封面、更新日志、文档图例在这里就不一一叙述了。

1）需求分析表结构

①产品名称：

平台/系统名称。

②项目背景：

首先，要明确问题是什么。

产品或者这块相关的数据出现了什么问题，或者在核心业务目标上出现了什么问题，这些都是问题的定义（为什么要做这个功能）。

其次，明确要解决什么问题。

这里通过项目背景推导出业务诉求，也就是业务/产品目标。

最后，产品目标是产品能得到什么样的结果，对产品来说可以获得什么样的好处。

所以在交互文档的设计中要重点体现出产品目标。

通过明确产品目标，可以清晰地指导我们做的交互方案。

③用户对象：

通过对现有产品的用户画像得出我们的用户群体，明确为谁而设计。

④场景分析：

依据使用情景分析（即用户故事的方式）交互情景。

⑤用户目标：

用户想要的是什么？

用户通过这个功能想要达到什么样的好处和目的，可以通过用户画像等研究方法，大的项目可能需要更多维度的分析才能够明确用户目标。

⑥设计目标/设计思路：

根据业务目标和用户目标，推导出设计的目标，提高用户活跃度，基于业务升级的视觉体验（产品架构升级、提升阅读转化、促进用户活跃、视觉品牌升级）。

⑦核心数据：

提到的业务目标、用户目标、那么跟这几个目标相关的那些数据能在项目上线后证明目标是不是达到了，他们就是核心数据，在这里都要明确出来。

⑧项目风险：

优化了某些功能很有可能会给其它模块带来一些负面的影响，这里要明确出有可能会出现的风险，然后评估一下风险的大小。

若风险可以忽略，那项目就能够执行下去，若风险的负面影响大于整个项目的收益，那就要另做考虑了。

2）产品结构/信息结构

在设计初期要画好的，它们是从不同的维度来梳理产品的。

产品结构图作用是梳理产品功能点，梳理产品有多少个功能模块。

罗列出来各个功能模块下的各个页面，但不需要罗列页面中的内容。

信息结构图（也就是思维导图）的作用是梳理具体页面显示信息。

罗列产品各个数据元素罗列出来，只需要罗列活的数据，固定在页面里的信息数据不需要罗列。

3）业务流程/功能流程图

业务流程图，用于说明整个业务逻辑流向。

功能流程图，用于确定产品功能设计逻辑。

4）需求列表

用来整理本次需要做的需求进行相关描述，是做哪个端口的哪个页面及做完之后可能存在的相关