交互设计硬知识-交互文档篇

  • 经验类型经验/观点
  • 经验属性原创文章
  • 经验版权署名-非商业性使用-禁止演绎
3719 6 36 2020-09-12

交互设计师在工作中存在两种沟通方式,一种是口头交流,一个是书面沟通。对大多数公司来说,产研在一起办公,在需求下放时,交互设计师可以尽快的拟好原型,同时拉上产品研发一起初略探讨方案的可行性及实现成本,但不论是传达需求还是讨论方案,只要涉及到表达和交流时,均会延伸出各种麻烦,往往细节如果没有传达到位,就有大多数锅等待着你背,因此落在书面上的文字和图形,除了确认方案避免甩锅,也能在你构思的时候完善你的逻辑。

交互文档,简称DRD,是交互设计师最为重要的产出物之一,占日常工作交付内容的70%以上,它是用来梳理交互事件,页面流程逻辑的原型图+注释的描述文档。主要目的是将交互设计思路清晰的展现给视觉设计人员、前后端研发团队、测试团队等,便于团队人员快速理解产品定义,实现产品功能与交互方式等。

这里需要说明的是,从原型工具里导出的交互文档往往缺乏可读性,干枯的思维导图加冷冰的原型,然后凌乱的附上几句说明,你的阅读对象大多数会处于懵逼状态。同时交互文档通常也不是一步到位,在评审后,或则开发中,甚至测试阶段都可能暴露你的设计缺陷,因此修补,更正,添加设计内容和方案是常有的事。我们通常会先梳理核心功能流程,与产研预评审;然后对照PRD完善所有需求的细节内容,包括原型及交互注释,在正式评审环后补缺补漏便可直接交付给前端和视觉;最后是用例测试阶段,各种极限值或则遗漏逻辑逐渐暴露,如果你没有能提前预测到的话,那就继续完善方案,只不过此时可能得背锅了。

以上算是抛砖引玉,下面我们将系统的来讲述一下,怎么写好交付文档。

 

一:封面

封面通常只需要写明文档的项目名称、最近更新日期、对应版本号、以及对接人对应的职位、名称、联系方式。

其中对接人通常为产品经理、交互设计师、视觉设计师、前端工程师、后端工程师(如果有)、测试同学等。


二:目录

就像我们写PPT或则看书一样,每个章节都需要归类,合理分级,分清主次,可便于团队成员迅速定位需要设计开发或则修订的内容。


三:更新日志

前面提到,从正式评审到最终上线的每一个环节均可能暴露你的设计缺陷,或则是因为其他原因调整设计方案,这是一个很频繁的操作,我们必须事无巨细的将修订内容整理记录下来,以便团队成员对照修改,同时责任落实到人。修订记录包含以下几部分:序号、修订内容(详细描述修订的位置,以及对应调整的大致内容)、日期:修订的具体日期、修订人、备注(如果有需要的话)


四:全局说明

我们通常会将那些需要重复说明的内容整理到全局说明当中。例如:原型说明、操作说明、手势说明、表单说明、颜色含义说明、跳转图例、常用控件、缺省图例、文档标识图例、页面标题及原型图命名规范等等。在团队成员阅读文档前提前制定阅读规则,可以省去许多重复的文字描述。


五:文案规范

一个合格的产品,是需要对其文案内容进行规范和制约的,其中包含有:统一单位格式,确定文案表达,设定字符限制。这样,除了在前端能保持表达的一致性外,亦可在后台编辑时防止因为字数超过限制而导致前端页面不兼容的情况。


六:信息架构&功能列表

通常产品经理会在PRD里详细描述其需求的执行策略及需求详情,但并不意味着交互设计师可以直接套用,每一个流程下来我们都必须拆解其诉求,特别是针对其核心流程,以及其附加任务流,然后合理组装成详细的实现方案。这个时候可能你需要Xmind来绘制思维导图,理清信息架构,梳理分配功能实现点,组合、转移、隐藏甚至删除其某些功能点,最终落地为详细的内容模块,以及每个模块所包含的页面。当然,如果仅仅是功能迭代的小需求我一般会省略过这一部分,但如果你是入门的小白,或者是需求够大不足以让你立马就在脑海里组织实现方案,我建议大家还是尽可能的完善这一部分工作,除了可以明了逻辑结构,交互状态外,详细的功能列表可以帮助下游开发及视觉设计师,合理分工及预估工时等。


七:交互说明

交互说明是交互文档的主体部分,它将所有的原型页面、内容布局、跳转关系、流程逻辑、操作方式、交互规则、状态反馈、异常流、动效说明等,按信息模块进行划分并针对性进行注解说明。

A. 关于绘制原型页面:

1.保真度:低保真可以迅速布局,但缺乏细节,高保真则耗时耗力,不便于修改,建议使用中保真程度,位于线框图和UI效果图之间即可。

2.尺寸:通常交互原型和视觉设计是对齐的,我们会同在sketch上作业,移动端为375*667pt,PC端宽度为1280px。当然你们可以根据实际情况协商解决,确保统一可以便于协作及沟通。

3.颜色:原型设计通常使用黑白灰三种颜色,通过深浅不同来标识层次和重点,颜色越深则越突出。如果遇到需要警告、提示、强调的时候,也可以适当用其余色彩来表示,以作区分。

4.字体:一般需要和视觉设计师商量,跟着其视觉规范走即可。需要注意的是最小字号、通用字号、标题字号等,以及加粗时机等。

5.热区:即页面中的内容板块触控或元素链接区域。在做交互说明时,我会绘制一层半透明的色块盖在原型图之上,然后注明尺寸、间距。

B. 关于文档编写:

1.注释说明:主要是针对页面及交互逻辑进行说明。同时我在写注释说明时,会将设计师、运营人员、前后端工程师等需要特别注意的地方用不同颜色标记出来,以便其快速定点识别。

2.页面命名:我们需要注意每个功能模块及页面的命名及编号,这样除了可以让阅读者迅速其迅速识别页面外,也便于你们沟通和交流,最最重要要的是当你跨文档页面描述其跳转关系时,有序的编号及命名可以直接在注释说明里描述其位置,帮助下游同学快速锚定页面,而不用画一条非常之长的箭头指示线条(通常你的文档页面也不允许)。

3.交互控件:如果你们已经编写了一套通用组件规范,或则打算采用网络上开源的组件库,那样你就无需多费口舌来描述某一组件的交互方式,直接在备注里标明控件路径即可,例如:Ant Design / 数据录入 / Cascader级联选择 / 选择即改变

4.连接线:单条连接线需要标明起点和终点,多条连接线之间避免重叠,建议可以错开绘制,以免造成误解。

5.异常处理:复杂的需求里常伴有各种异常流,建议咨询或者配合测试同学一起梳理,并在文档的当前模块标明出来,千万别只着眼正常流程的编写而忽略异常流。

6.回收站:废弃页面或板块内容先别着急删除,当方案在不断的调整优化过程中,你可能随时需要吃下这颗后悔药。

C. 关于动效说明:

静态的注释说明如果说的不够清楚,可以将动作分帧拆解,并逐一标注说明,或者用原型动画工具直接输出mov格式,添加到交互文档附件上,以帮助理解。此时交互设计师需要尽可能描述动效的实现时间、运动曲线、运动方式、触发方式等。


八:交互走查

交互设计师会根据一定的设计标准,自我校验设计方案,发现问题,然后修订完善。大致可分为业务逻辑走查,产品功能走查两部分。

业务逻辑走查:需要你检验设计方案是否满足了业务需求,最终达成其业务目标,这需要你足够熟悉产品的业务逻辑。

产品功能走查:需要注意区分设计终端,App和web的差异性导致了其页面布局、交互方式、实现逻辑的不一致,因此走查点也不一样。

走查时需要注意以下几个规则:

1.先走查核心流程,再走查次要流程

2.先走查正常流程,再走查异常流程

3.先可用性、再易用性、再情感化

文章下方我会附上一份我自己整理的交互走查表以供下载,便于你理解和参考。需要注意的是我们需要结合自身的产品特性,来迭代和完善专属自己产品的交互走查表,而不是简单的依葫芦画瓢。


九:修订DRD

1.边做边沟通:没有多少需求是你可以一眼望穿的,团队成员也难以一次性花时间通篇评审你的交互文档,所以在沟通和协调中进一步调整,更切实际。

2.交互走查:自我校验方案设计,查缺补漏,不断完善交互设计方案。

3.需求评审:在正式评审环节,考虑到实现成本、更优方案、PRD调整、或者是你逻辑遗漏等,都需要你在会后重新修订内容。这时候别忘了记录到更新日志里哦。

4.用例测试:测试同学会针对某些极限值、突发状况等问题来测试你设计的完整度,如果事先未能考虑到,也需要及时修订,或则放在下一版本继续优化。

5.灰度发布:邀请某些用户对新版本进行试用,然后收集工单反馈,听取用户实际使用的感受,以此检验设计方案,如有不足则立即优化改进,最后确保用户体验。


十:后记

世上的交互文档其实各种各样,我并不认为存在某种特定格式或者标准流程,讲明白一件事,衔接好上下游,推动产品成功上线,并解决实际问题,最终得到用户的认可,这才是交互文档存在的最实际意义。如果纠结在到底是用axure还是sketch、PPT来呈现你的文档,毫无意义。我们需要着眼于结构、内容本身,而不是呈现方式,法无定法然后知非法法也。但编写的时候仍需要注意以下几点:

1.逻辑严谨,注释清晰

交互文档要求内容结构和页面布局逻辑严谨,思路清晰,符合产品架构的层级关系,以完成既定的设计目标。注释页面时注意文本简明扼要,做到不重复、不遗漏,以达成交互思路和方案更好的可视化、明了化。

2.利于协作,便于沟通

为保障交互文档便于下游童鞋查看或编辑,输出时需要考虑格式,如果是sketch制作的话导出PDF,如果是Axure设计的话则生成一份HTML文件,这样对方无需安装你的设计软件,也可以顺利打开查阅。

3.保证形式,美即适用

交互文档除确保方案的可用性和易用性外,也需要审视呈现上的美感,通篇的排版布局如果干净明了、科学易读,不仅利于你的方案阐述,会增加下游童鞋在设计开发过程中的愉悦感,同时体现你设计的专业性。

4.归纳整理,便于迭代

业务会根据市场动向要求实时变更设计方案,而产品本身通盘的逻辑也是牵一发而动全身,所以你随时会面临设计重构和调整,况且日常迭代也需要你翻出过往的文件,在此基础上延伸设计。所以归纳并整理好交互文档,保证文档命名有序,可便于后期查找调阅。我文档命名方式通常为产品名/项目名+版本号+设计时间,例如:蜂鸟跑腿5.3.0版20200325。

Powered by Froala Editor

全部评论:6

更多作品

发表评论

取消

点击右上角
分享给朋友吧

分享到

取消

每人每天仅限5票,快给你心仪的作品鼓励的一票。

投票