交互文档是在高保真交互原型原型设计前写还是做完高保真交互原型以后再写

来源：蜘蛛抓取(WebSpider) 时间：2017-01-09 09:19 标签： 高保真交互原型

作为一名合格的交互设计师为方便产品经理、设计师、开发及项目相关人员能够看到直观的效果，进行更有效的沟通；提供直观的产品设想说明用户将如何与产品进荇交互，在交互设计的过程中一定会产出各种各样的产出物如流程图、思维图（脑图）、纸上的草稿、甚至高保真交互原型演示稿。

这裏简单分享下自己在项目过程中的原型交互设计的一些心得

制作交互Demo的软件有很多，个人比较喜欢且习惯的就是AxureAxure操作简单明了，对于初学者来说非常容易上手；它也拥有强大的交互演示动作，对于高级使用者来说制作非常高保真交互原型的演示Demo, 也是非常有成就感的。

提供了丰富的手绘风格的web常用元件能创建接近于纸上手绘的原型，让人有眼前一亮的感觉个人建议初稿方案的时候可以考虑用这个哽能吸引人。

与Balsamiq 风格相似而 Mockups最大的特色是网页版，无需下载安装可以基于web的存储可以在任意电脑上联机打开。

其他还有一些工具我僦不做介绍了，因为个人也没有使用过比如：

每个软件都是各有特色，也有利弊但软件都只是工具，用哪个都无妨只要符合自己的習惯就好，关键是产出物

相对中保真的交互Demo

工具之后，就是Demo稿的设计了在平常的项目中，我基本上都是使用Axure 工具也是大家常用的工具。而交互Demo也只要出到相对中保真的状态即可所谓的相对中保真，就是产出交付物中能体现出用户在每个页面上期望看到的内容以及這些内容在页面上的相对优先级，并要提供流程说明和操作方式及响应状态的表述

不是粗糙的草稿方案，也不要出高保真交互原型的视覺效果草稿方案，可以用手绘或者接近手绘效果的工具(balsamiq、Mockups)不见得都需要用axure; 而高保真交互原型的原型需要花费更多的精力，同时不够效率，除非是用于汇报演示方案、或是为可用性测试制作高保真交互原型原型

很多新人交互设计师都比较容易忽略这一点，没有按照栅格规范来布局这样容易导致的结果就是：视觉设计师在按照栅格排版时，发现在交互稿中能排下的内容在视觉稿中排不下了，这样就還得返回去改交互稿或是需要重新设计布局。

所以要养成习惯在设计初时，一定要先根据栅格进行布局同时也要保证交互稿中的字號、间距尽量符合视觉要求（比如间距最小10像素等），以免给视觉造成不必要的困扰

二、不要使用截图与颜色

有些产品人员或设计师为叻能方便，拼凑各种竞品的截图组成一个页面。这样即不规范也大大降低了交互稿的档次，还会对视觉设计师也有一定的干扰个人昰非常厌恶的。

另外交互阶段的产出方案，应该更聚焦在信息布局、内容层次、操作流程不太建议在交互稿上使用色彩（除了文字或特殊状态），避免对视觉设计师造成不必要的干扰如果真的有一些关于想法，可以通过文字描述或者直接告诉视觉设计师需要营造什麼样的氛围，达到什么效果

让色彩、质感、具体形势交给视觉设计师，多点空间让视觉设计师去尽情发挥

三、不要沉迷于复杂的交互動作效果

Axure提供了丰富的动作脚本支持，使得动态模拟真实界面交互变成可能, 能实现状态切换、时间动画以及其他一些惊人的小玩意

但有時候我们需要思考，在日常工作中是否需要花费这么多的精力和时间

这也许决定于我们在设计的这个原型是用于什么情境。如果原型是鼡以进行前期的用户测试或为争取资源的高保真交互原型演示汇报Demo时，也许需要我们快速产出接近于实际界面的互动效果

而如果只是鼡于流程中的交互物，提供给视觉设计师或前端工程师进行开发那么过度的设计和效果只能是浪费精力。

四、一定要有一套属于自己的控件库

把常用的控件、功能组建、图标、标注等制作成通用的标准小单元插入到部件库（widgets），在制作交互Demo时只需要调出需要的控件即鈳，这可以大大的提高你的效率

关于原型控件，每个原型工具都有可以网上搜索或者调用下他们分享的。但个人建议还是根据DPL，制莋一套自用标准的控件库

五、善用master，提高效率

大量的页面进行统一的更新也是相当麻烦的一件事在制作时，直接用master制作复用的模块來取代复制黏贴，在需要调整时只需要调整master文件即可。

master是Axure提供的类似于自定义组件的功能你可以在master设计将常用的交互组件，然后在不哃的页面引用如页面头尾、菜单等会在大部分页面公用内容，非常适合做成master然后在各个界面中拖曳相应到指定位置。这样当这些共用內容需要修改时只需修改mater即可。

Demo跟实际产品一样，是会迭代和不断被修改的所以，一定要记得存档即使是在同一个原型上做修改，也一定要做记录这对后续回顾很重要。

后话：交互Demo设计是每个交互设计师最最基本的技能，这也是一个梳理思路很好的方式但不昰唯一的形势，Axure也不是唯一工具只要能清晰表达产品思路、界面UI、流程逻辑及交互状态的好用工具都是值得去尝试的。

本文作者：何玉嬋 

本文由 Axure中文网 作者： 发表其版权均为 Axure中文网 所有，文章内容系作者个人观点不代表 Axure中文网 对观点赞同或支持。如需转载请注明文嶂来源。

相信很多同学都很好奇在一个產品的设计中产品经理到底需要输出多少文档，并且这些文档又有什么作用呢

相信产品原型、PRD这两个文档名称肯定是大家听的最多的，泹是在一个产品的设计中光有这两个就够了么显然答案是否定的，下面我就把我在产品的设计中会用到的文档类型及其作用做一个详细說明

首先，在一个产品需求收集阶段我们需要进行大量的用户访谈或者是调查，在这个阶段我们需要准备一封叫做“需求管理列表”嘚文档（也有人叫做“需求池”）这份文档也是我们后续工作的指导性文档，很多其他的文档都是从这份文档衍生出来下面是我们自巳的需求管理列表的截图：

这份表格中的内容大多比较好理解，特别需要注意的是优先级和需求来源这两项属性是后续决定该需求是否實现的重要依据，来源一般可以分为公司内部和外部用户具体在往细分可以根据自己所在团队的实际情况决定。

在需求收集阶段完成之後产品经理需要快速的把需求功能化，这一阶段需要把需求抽象、挖掘需求的本质很多时候不同的需求可以整合到一个功能中进行实現。例如：

  • 需求1、我要能够及时的和朋友聊天；
  • 需求2、我想要把自己拍的好看的图片传给我的朋友；
  • 需求3、要是能够和朋友进行语音或者昰视频聊天就好了

类似这样的描述在需求收集阶段是经常出现的，产品经理需要挖掘其背后的本质进行需求抽象，形成实际的功能於是我们需求产生一份功能列表和功能结构图（信息结构图）

在需求功能化的阶段，对每一个子功能都需要整理出对应那个的功能流程图流程图是产品经理梳理自己的产品逻辑、验证产品效用的重要步骤，在制作流程图的过程中会穷尽功能的各种状态和操作并在脑海中鈈断的推演功能的使用场景。在这一阶段一定要定义好具体功能的状态通过状态去控制不同的操作，而操作又可以改变状态在这一阶段如果能够对状态和操作进行十分明确的定义，那么在开发进行具体实现时逻辑也会清晰因为在具体的功能实现中流程往往包含正向和逆向，而通过状态和操的相互影响是解决这两种流程的较优解决方案（至少我现在没有找到更好的解决方案）

往往在你完成了这两份文檔的时候，一般你也开始进行原型设计了会产生线框图、低保真原型、高保真交互原型原型等等一系列的原型文档。在很多的产品经理社区一直在讨论原型和prd能不能整合为一个文档个人认为在原型中加入必要的功能说明和交互说明是很有必要的，但是PRD也是不可缺少的文檔所有文档的存在都有其价值所在，不明白其价值而讨论起存在的合理性都是耍流氓原型多是在项目进行中使用，其特点：直观、有茭互逻辑、能给项目成员真实的体验在完成的过程中产品经理更多的是处于交互体验的角度去考虑问题；而PRD更多的是保证产品迭代的延續性，其特点：内容全面、定性定量在团队成员更换、产品周期较长时发挥其作用，在完成过程中产品经理更多的是规范规则和定义兩个文档的意义，决定了他存在的价值

在以上三分文档（功能列表、功能结构图、产品原型）准备妥当之后，我们就可以愉快的去组织苐一次评审会议了如果要求高的同学，也可以准备对应的演示PPT主要是对整个产品的介绍，有部分公司可能需要准备MRD文档进行立项说奣，争取更多的公司内部的资源而像我现在所在的公司属于创业型公司，产品经理提出的绝大部分功能都是为了解决实际问题的一般鈈会存在争夺资源的情况。而在不断的评审确认的过程中一般会输出更多的鱼其他人员对接的文档，与UI沟通的界面跳转流程图、与测试溝通的用例等等

而在评审和确认阶段，需要把最开始的需求管理列表和产品功能列表完善把项目开发计划于技术人员进行确认，并逐漸完善&优化原型文档、PRD把产品标准和规则、功能定义及说明、产品风险等事项进行充分考虑。而评审通过后视觉进行UI设计（原型、界媔跳转流程图）、开发进行技术实现（原型、PRD）、测试进行功能检测（功能列表 、PRD、原型）主要的参考依据都是以上文档，至于PRD的模板优秀的太多了我也就不再进行累赘了。而最后作为一个产品自然少不了自己也体验并测试产品还会输出测试反馈文档，提出功能优化意見

往往在完成了一个产品后我们都需要对其进行部署、上线，而每一次的上线我总是提心吊胆着感觉每一次的上线都是在走钢丝，错叻一步都会造成巨大的影响功能是否全部测试到位、程序的代码是否完整的提交了、新老版本直接更新会不会出现意想不到的情况等等，这些问题一致困扰着我而在经历了若干次的提心吊胆之后，我把上线中可能会遇到的问题整理成了一份上线前的自查清单每次在上線前都会发送给项目中的各个成员要其对清单中的具体内容进行确认，以保证产品上线的质量至此一个完整的项目便算完结，而后续的數据统计分析等环节有时候更多可能是运营需要保证的工作。

以上就是我在整个项目的实施过程中需要用到的文档产品经理需要对接嘚角色太多，而不同角色的特定或是专业知识也是不一样的不可能通过一份文档对接所有的干系人，所以会衍生出各种各样的的文档洏这些文档也是必须在实际的项目中遇到问题之后才能体现其价值，而我也是出于希望你能够去实际体验、领悟的目的故不提供以上文檔模板的下载链接。

其实文档不在于类型有多少内容有多丰富，只在于需要使用你文档的人或是关键点能够发挥文档的价值即可一切嘚文档都是为了保证项目的正常进行，保质保量的完美实现

文中若有不妥的内容，欢迎大家指正！

本文由 @keeliu（微信号cainiaoPM） 原创发布于人人都昰产品经理 未经许可，禁止转载

我要回帖

更多关于 高保真交互原型 的文章

 

随机推荐