返回首页
当前位置: 首页 > 解决方案

手把手教你写交互设计文档

时间:2018-09-30 16:25:07来源:本站 作者: 点击:
  

  离开交互圈已经有段时间了。但由于博客还在,还是能够偶尔收到一些邮件,上周有位同学问我:我在求职,我看到很多招聘说明上需要交互设计师编写

  这让我想起来2009年自己在项目里也大力推行过交互说明文档(在下文中,简称为DRD),格式倒没什么限制,交互设计师自己写到界面上也行,单独文档成文也行,总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来,降低项目里的沟通成本和风险。今天整理电脑,翻出以前的PPT,分享之。这将涉及到几个问题:

  所谓DRD即是用来承载交互说明,并交付给前端、测试以及开发工程师参考的文档。

  在项目中,交互设计师的主要产出物可能依次是:site map,page flow,wireframes。有的大型项目前期,交互设计师有可能还会产出用户需求分析文档(与PD产出的市场需求文档不一样的是,URD更多侧重于对目标用户的需求分析)。

  DRD则很少有人专门撰写。如果需要对交互设计进行说明,聪明的交互设计师往往会直接标注在线框图里,或者在项目中不断和前端工程师和开发工程师口口相传,反复验收,不断迭代修改来确保所有的交互设计意图最终得以呈现。

  DRD非项目必需环节,一般情况下也不会为交互设计师专门留出相应的时间预估。没有这份文档,项目也会继续,但是可能项目会为此承担不必要的沟通成本和时间成本。严重的话,项目的质量也会受到影响。所以写与不写,交互设计师需要做把握,时间被统一包含在“线框图”环节内——如果你要写,请在评估时预留1-2天的时间。

  敏捷开发意味着很多不同角色的流程需要并行操作。如果等到产品经理的FRD已经全部敲定,交互设计师再开始去画线框图,固然会减少沟通成本和返工风险,但是同时意味着交互设计师的很多想法不被采纳。如果产品经理再强一些,他甚至会在FRD里连原始的DEMO也一并绘制出来了,功能性的需求和界面交互的需求有时无法区分太清楚——比如他会在FRD里直接要求每页条目40条,超过40条即分页。而交互设计师可能会认为像蘑菇街那样不断装载出足够长的页面会更亲和……所以,我们希望是和产品经理同时开始工作,在术业有专攻的时候相互补充。

  同样,开发工程师也希望及早介入需求,在FRD并未确认的时候就了解需求,进而将商业需求和功能需求转化为开发工程师看得明白的开发需求清单(这个清单,大部分叫做UC,即USE CASE),当这份清单由工程师需求分析师——在过去,这个角色被叫简称为RA,但是目前已经取消此专门的职位,而是由开发工程师代表担纲此环节工作,为了便于描述,在此文里,我仍然将做这件事情的人称为RA——交付给具体的执行工程师后,执行工程师基本上可以当作一条条的checklist开始高效工作,而不必再思考商业逻辑和需求。同样,测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试,这也是基于UC和FRD去撰写的。

  所以,开发需求分析是个很重要的环节。那RA是如何来完成需求分析工作的呢?

  对于做这件事情的人来说,足够详尽的FRD是非常重要的。所以一份FRD虽然是PD产出,但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递,却存在很多问题。除了线框图,没有“详尽的说明性的文档”告诉他们。比如:

  一方面,交互设计师对产品经理说:这块由我们来考虑,你的文档不必包含设计上的说明,这随时会调整的。

  另一方面,线框图的评审有时会让RA参与,有时却没有叫他们。即使叫上了他们,他们也会发现交互设计的需求变化要比FRD变化快。另外,他们会认为UC不必写太多关于交互设计的需求。

  在某个大型项目结束后,作为交互设计师,我进行了一些调研,听听这相关人员是怎么表述问题的:

  每次变动都很痛苦,设计变了之后,我就要跟着改UC,改截图,有时候UED改了还忘了通知我们,导致UC有问题……

  希望UED能够在提交HTML DEMO给RA时,能同时给出一份页面元素描述文档,需要介绍html demo中的文案、链接以及相关的图片尺寸或显示字符个数。现在RA在这方面花费的时间比较多,经常要和UED去确认这些内容。

  前期RA和PD沟通过程中,有很多交互点点不能够明确,比如“默认显示多少属性值”,“标题显示多少字符”等。在以往的需求和项目中,对待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PD为了可控性的需求,往往会“越俎代庖”,直接在FRD注明这种需求(对于交互设计师来讲,却又导致没有发挥余地)

  走访了一些交互设计师后,他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑:

  交互认为很平常的设计需求,如果不表达出来,还是容易被前端和开发忽略掉。我经历的一个项目,前端从头到尾更换了三个人,每次我都要重复去讲解下设计需求,讲得口干舌燥。而且做好后,还需要去验收。

  这些说明与功能实现没有太大关系,主要是为前端做HTML的时候参考的。一般视觉设计师会在PSD里标注清楚。如图:

  如下图所示,作为DRD,你有必要传达清楚Browse by category区域的设计:链接的可点击性,链接的指向,字符与条目的数量限制等,但是具体二级类目排列是按产品数目排还是按字母排,还是人工运营,是FRD要解决的任务。

  提高空间利用率,有时网页上的动态文字需要从数据库里提取部分然后截断处理。比如下图中的标题和描述。你的DRD需要传达清楚:1,是否要做限制?2,如果做限制的话,多少字出现截断?截断后是显示为省略号还是不显示?这个汉语设计相对简单,如果英文单词的话,因为是按字符,每个字符的宽度不一致,需要预估,另外还需要注明是整词截断还是词间截断。

  很多网站都有对搜索结果的筛选设计(refine search),比如aliexpress搜索结果页左侧。这块区域的交互事件是非常复杂的。

  要确保这些你设想中的复杂的交互逻辑能够被理解被呈现,除了一页页的线框图,你有必要再三让前端工程师和开发工程师了解并达成认知一致。所以你需要将页面上的关键链接事件标识清楚。它们有的指向无需刷新页面的交互,有的指向你安排的并非PD安排的某个中间页面(page flow是交互设计师的职责)

  相信我,我很不愿意写这些东西。我喜欢在会议室向各位涉众演示我的线框图,我会研究用axure制作各种动态效果,达到它足够逼真呈现各种联动——比如当你选择了下拉菜单中的某项时,页面上其他区域也发生相应的变化。可是,Axure不是全能的。即使能够表达出来,线框图交付出去,也不能确保其他人都能够一一进行点击尝试。所以只能在会议室反复讲解,在事后再三检查并敦促修改。

  但是当我尝试用下图对这块小小且复杂的区域进行详细说明后,事情变得简单多了。所以我用节省的时间去写了这份PPT.

  又如,你可以在这里说明任何你想要的效果。你的受众也只需要用10分钟时间阅读完毕,标注出与他工作相关的重点,存档并在遇到问题,找不到你人时随时参考。

  这也是一项不怎么有创意的事情,但是你若不事先想清楚,在项目过程中有点麻烦。写文档看似枯燥乏味,反过来想也是让你自己再好好思量审核设计本身的关键步骤。我曾经自以为完善的交互设计方案就是在写DRD的时候发现存在重大的纰漏,然后及时优化的。

  你们的产品兼容所有浏览器简直是梦想,但是有时出于效率的要求,我们必须战略性放弃某些浏览器,比如IE6.:D 。 这个决定谁来做?是前端工程师还是产品经理?还是你——交互设计师?我认为决定权在交互设计师这里,但是他必须和产品经理达成一致,并与前端确认。你要求兼容的浏览器越多,标准越高,前端的工作量就会越大,测试的工作量甚至也会翻倍。

  Heidi的建议:尽可能与你的线框图同时交付,如果你先交付出线框图,在撰写DRD的时候,极大可能会发现问题或产生优化的想法。但是往往写DRD至少需要1-2天的时间,你不可能让所有下游等着你的工作。所以:

  我的经验是这个工具最好能够提供清晰的目录导航结构,而且易标注。word确实是个写文档的好工具,不管你信不信,反正我是信了。

  准备写DRD的朋友,请认识清楚此文档真正要解决的问题是什么?如果是解决沟通偏差、需求遗漏、沟通成本高的问题,你在项目里没有出现过这种问题,各合作方也反馈良好,那么这个文档就无需写。如果是解决对设计需求进行存档,便于后续人员改版时查看的问题,则又是另外一回事(经验证明,过去的DRD确实能够在改版时起到一定的帮助,在我离开原项目很久后,新的设计师还找我要过相应项目的文档,了解过去的设计逻辑)。

  有很多需求,交互设计师只要求实现即可,但是他可能并不在乎是前端实现还是后端实现。前端工程师对DRD进行把关和修订,能够将设计语言转化为工程师能够看懂的语言,且能够划定与开发的实现边界。

  但是有个问题是,虽然DRD的目标受众有开发和测试,但是让开发工程师同时参考那么多文档是不现实的,所以仍然是开发工程师的接口人,也就是事实上的RA需求分析作为需求整合传递的角色,将商业需求和设计需求,传达给具体的执行开发工程师与测试工程师:

  对于坚持撰写DRD的我来说,DRD的好处自己当然是明白的——在撰写过程中重新梳理设计逻辑,优化设计;降低沟通成本等等。

  解决问题有多种方案,DRD只是其中一个。不过,当你因为设计需求传递过程中发生了问题,或者你的需求被理解偏差,或者你的需求被遗漏,或者你接手的项目改版,因为要梳理过去的设计逻辑焦头烂额时,你可以试试用DRD。如果使用过程中还是存在问题,那么就想想是否还存在别的解决方案吧~

  谢谢曹大师的分享,能发一份DRD参考模板给我么?产品新人一枚,希望能学习更多的产品知识

  从我的感觉来说,这么写比较奶妈,其实,可能将某一些交互形为组件化,不用每次都说,还且一些通用的页面模型,可以直接和通用的说明跳转即可,程序其实很讨论很多文字的。

  最后,为什么这些说明不是放在交互稿里面的的,为什么还要独立文档,这不是折腾么。

  在公司,交互出原型,我在原型的上面写业务需求,并补充异常场景,如数据为空的时候怎么展示(不包后端的处理模块,跟你目样的一样。)

  程序一般性看交互稿就有全部的需求带入感了,反而减弱了prd的存在感。prd更多的是业务流程类的讲解,偏后端。

  每个公司的要求和组织架构不一样,比如在大公司,有专门的部门,每个部门都需要输出专业文档。当然,绝大部分中小型公司,都没有这个职位,所以产品经理把这个事情也干了,一个PRD就好了。

  首先谢谢大神的分享,受益颇丰,老师可否发一份原作DRD文档给我们参考一下?邮箱

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、招聘、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上海广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里分享知识、招聘人才,与你一起成长。

来顶一下
近回首页
返回首页
------分隔线----------------------------
发表评论 共有条评论
栏目最新
热点内容
相关内容
    无相关信息