交互说明文档-规范

1、交互说明文档教学一.什么是交互说明文档（DRD?所谓DRD即是用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。在项目中，交互设计师的主要产出物可能依次是：sitemap,pageflow,wireframes。有的大型项目前期，交互设计师有可能还会产出用户需求分析文档（与PD产出的市场需求文档不一样的是，URD更多侧重于对目标用户的需求分析）。DRD则很少有人专门撰写。如果需要对交互设计进行说明，聪明的交互设计师往往会直接标注在线框图里，或者在项目中不断和前端工程师和开发工程师口口相传，反复验收，不断迭代修改来确保所有的交互设计意图最终得以呈现。二.为什么要写？DRD非项目必需环

2、节，一般情况下也不会为交互设计师专门留出相应的时间预估。没有这份文档，项目也会继续，但是可能项目会为此承担不必要的沟通成本和时间成本。严重的话，项目的质量也会受到影响。所以写与不写，交互设计师需要做把握，时间被统一包含在“线框图”环节内一一如果你要写，请在评估时预留1-2天的时间。那么，结合我过去的经历，谈一下此文档的必要性。下图是一个产品开发项目基本的流程。MRDPRD或者叫8RD或者FRD蒜；靛IWireframe's视觉即PQDHTML开发需求分析开发商业需求卜MAD功能需求Lf设计需求.RA需求分析敏捷开发意味着很多不同角色的流程需要并行操作。如果等到产品经理的FRD已经全部敲

3、定，交互设计师再开始去画线框图，固然会减少沟通成本和返工风险，但是同时意味着交互设计师的很多想法不被采纳。如果产品经理再强一些，他甚至会在FRD里连原始的DEMO也一并绘制出来了，功能性的需求和界面交互的需求有时无法区分太清楚一比如他会在FRD里直接要求每页条目40条，超过40条即分页。而交互设计师可能会认为像蘑菇街那样不断装载出足够长的页面会更亲和所以，我们希望是和产品经理同时开始工作，在术业有专攻的时候相互补充。同样，开发工程师也希望及早介入需求，在FRD并未确认的时候就了解需求，进而将商业需求和功能需求转化为开发工程师看得明白的开发需求清单（这个清单，大部分叫做UC,即USECASE）,

4、当这份清单由工程师需求分析师一一在过去，这个角色被叫简称为RA,但是目前已经取消此专门的职位，而是由开发工程师代表担纲此环节工作，为了便于描述，在此文里，我仍然将做这件事情的人称为RA交付给具体的执行工程师后，执行工程师基本上可以当作一条条的checklist开始高效工作，而不必再思考商业逻辑和需求。同样，测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试，这也是基于UC和FRD去撰写的。所以，开发需求分析是个很重要的环节。那RA是如何来完成需求分析工作的呢？ 前期介入，对PD进行开发需求评估支持； 参与每次的FRD评审会； 详细审阅FRD文档并不断与PD确认。对于做这件事情的人

5、来说，足够详尽的FRD是非常重要的。所以一份FRD虽然是PD产出，但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递，却存在很多问题。除了线框图,没有“详尽的说明性的文档”告诉他们。比如：刷箱不刷新页面的tabRadQbutton有无紧认选择一一输入衽有无初始值？校险如何做？一方面，交互设计师对产品经理说：这块由我们来考虑，你的文档不必包含设计上的说明，这随时会调整的。另一方面，线框图的评审有时会让RA参与，有时却没有叫他们。即使叫上了他们，他们也会发现交互设计的需求变化要比FRD变化快。另外，他们会认为UC不必写太多关于交互设计的需求。在某个大型项目结束后，作为交互设

6、计师，我进行了一些调研，听听这相关人员是怎么表述问题的：开发部门的需求分析师：每次变动都很痛苦，设计变了之后，我就要跟着改UC,改截图，有时候UE我了还忘了通知我们，导致UCW问题,，页面交互的需求容易漏掉，因为UC里面不可能写太多交互方面的东西。希望UEDI也够在提交HTMLDEMORA时，能同时给出一份页面元素描述文档，需要介绍htmldemo中的文案、链接以及相关的图片尺寸或显示字符个数。现在RA在这方面花费的时间比较多，经常要和UEDi确认这些内容。产品经理：前期RAWPD沟通过程中，有很多交互点点不能够明确，比如“默认显示多少属性值”，”标题显示多少字符”等。在以往的需求和项目中，对

7、待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PD为了可控性的需求，往往会“越俎代庖”，直接在FRDft明这种需求（对于交互设计师来讲，却又导致没有发挥余地）走访了一些交互设计师后，他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑： 交互认为很平常的设计需求，如果不表达出来，还是容易被前端和开发忽略掉。我经历的一个项目，前端从头到尾更换了三个人，每次我都要重复去讲解下设计需求，讲得口干舌燥。而且做好后，还需要去验收。 DRD做为参考手册，一定程度上避免不吻合的问题发生。 即使有问题发生，也可以作为界面验收时的Checklisto将“我对

8、A说，我对B说，A对B说"，转变为“A和B共同参考同一份文档”，减少沟通成本及信息不对称。全程影响用户体验（一直到测试，都需要参照设计文档）。可是以下问题都可以通过一份DRD来解决吗？日三。，上夕J包牵制重复劳动则偏差r沟通成本大重要信息遗漏三.写什么不写什么？文档不要写什么？视觉规范规格Marc商业逻辑（比如为什么要有这详细的功能实现机制功能逻辑详细的文案要明确文档的定位，从写什么与不写什么开始，划清DRD以及FRD的边界。1 .不写视觉规范规格标注这些说明与功能实现没有太大关系，主要是为前端做HTML的时候参考的。一般视觉设计师会在PSD里标注清楚。如图:2 .不写功能实现逻辑。

9、如下图所示，作为DRD,你有必要传达清楚Browsebycategory区域的设计：链接的可点击性，链接的指向，字符与条目的数量限制等，但是具体二级类目排列是按产品数目排还是按字母排，还是人工运营，是FRD要解决的任务。iSorry,nomatchesvwelewdinProdiKtIfmy宜interestedmEaegeo«erflems.tryarchirigBvowmbyC4itigoiy”Aqilculmi*，二E®PnochMts.F3fm&Equipfn事嘀Plartl&Mm前OifvFruih;Ftrtmr;Trattort;B«M

10、t;Rice.,FifthGram.AnmtlFMdA|>(i-iv«lAutumnAppar«i4.Soortwe，.DftseJackets;5。和一VoiWffVH&Workw#iQ睥才科S；Shirty类目推荐区，一级大类暂时不可点击，二线类目可点击到categoryli小二级兴目无金量限需入类目提取规则以及排列所人工运营U那么文档写什么呢?文档写什么?字符限制链接指向交互细节说明II校验浏览器兼容性测试说明举例子说明下：1 .字符限制提高空间利用率，有时网页上的动态文字需要从数据库里提取部分然后截断处理。比如下图中的标题和描述。你的DRD需要传达清楚

11、：1,是否要做限制？2,如果做限制的话，多少字出现截断？截断后是显示为省略号还是不显示？这个汉语设计相对简单，如果英文单词的话，因为是按字符，每个字符的宽度不一致，需要预估，另外还需要注明是整词截断还是词间截断。"23.00-3218，回；-rtreAHProductsAiRe9tvif'UP、t>L*E.Eu6NwywfUS®而第就MBff12»en0»lW4OBe<igM*Mhinwftwvfi«。的+s)Mt4b*co*i2 .链接具体化很多网站都有对搜索结果的筛选设计(refinesearch)，比如aliexpre

12、ss搜索结果页左侧。这块区域的交互事件是非常复杂的 类目和属性的不同如何处理 属性以及每条属性显示的属性值的条目是否有显示上的限制？ 选中后，被选中的属性值是停留在原地，方便用户记忆，还是放到统一的位置，方便用户统一查看？其他未被选中的属性值是否消失?1.electiicscooterRfeLlJIel&ctncscooter9scootermniirtCh-naf0KID4Waiu4eE工200'WCit'drP”1'内电iu时Rt"WheelSite12r-FoMdiMeYes-CenificamnCEPJax要确保这些你设想中的复杂的交互逻辑能够

13、被理解被呈现，除了一页页的线框图，你有必要再三让前端工程师和开发工程师了解并达成认知一致。所以你需要将页面上的关键链接事件标识清楚。它们有的指向无需刷新页面的交互，有的指向你安排的并非PD安排的某个中间页面（pageflow是交互设计师的职责）A.复杂交互的凌程图;I.triHaHMik4.B.端接和button的指向：mm62n-60I*I鼻._h一|BK*J"v-1Buynowbutton，指向下订单页面&不一定是具体的URL,但是需要给出线框图或由m。的港接3 .交互细节说明相信我，我很不愿意写这些东西。我喜欢在会议室向各位涉众演示我的线框图，我会研究用axure制作各

14、种动态效果，达到它足够逼真呈现各种联动一一比如当你选择了下拉菜单中的某项时，页面上其他区域也发生相应的变化。可是，Axure不是全能的。即使能够表达出来，线框图交付出去，也不能确保其他人都能够一一进行点击尝试。所以只能在会议室反复讲解，在事后再三检查并敦促修改。但是当我尝试用下图对这块小小且复杂的区域进行详细说明后，事情变得简单多了idijd丽的&US$53山0产品规格工.打乂然示葬一赶珞.?篝后.e,&o.e区域均发生取动一9.的格及龄格注小起仃*工*叶牯氤刍前露隹耳宰怯后强上最考;”:最要价区簿.C的格注#.小题iifiL*%第注诉f每包比件.每年多J?技工在疗包盒节左下匕

15、，Wnord何取说目寰上当配况站F小匕订量.，d恰日衰二，H号京阶通僮息将襄甘阍.痛要端出区城壶哥打砧。或M*更下由*L来疑】歌汰E亍敬手:二翼桥送髭烙下的最不超EM.«用户一应入符分黑范的数字后再切换产M规格周厘留闲户簿人.又如，你可以在这里说明任何你想要的效果。你的受众也只需要用10分钟时间阅读完毕，标注出与他工作相关的重点，存档并在遇到问题，找不到你人时随时参考。点击镣析叠的属性2"里现动效果的拉开点击线穆图看t乳节里，FK新页圜一F.IfliMhirlliiliAaIWi/9H.Aimwiw44rAAllMl*PM曲>#1叫 ijliPim心力Awihwin&

16、quot;图w (看然掌VNC，Wf告/4*4nAwibvltM©Fffi*flrr M»j.1-&11al口i_._*+IaVfl-f、一iA»lbHl«1*tnLz二 忙£5中.营/唾产，：，i Gwwi(it) FM口啾 1i Jib-g匚才/tMr,B UVft*；K44* dR«»4iN,(1|Ml«-!Bl-.nwu.*IraQqnVP-F4.，»E，B0$IlR«Mh%.35jNiUTilMM，国1:析春届性的黑轩1 .氏手给花戈里开的拄名.其他E。量性值主色显示，不珥有1

17、。十的裁量霞祝L*2 .宜电在开状态下的性名+接乜直皆收工回到原治状毒.*3 .每次占*也起蜉不司肝灵亘工刑一也濡取K*4 .M行依校区址；接个货苴事.Amibut*M4 .表单的校验这也是一项不怎么有创意的事情，但是你若不事先想清楚，在项目过程中有点麻烦。写文档看似枯燥乏味，反过来想也是让你自己再好好思量审核设计本身的关键步骤。我曾经自以为完善的交互设计方案就是在写DRD的时候发现存在重大的维漏，然后及时优化的。QuantityPncePerUnitUS$G,|A&.C输入据都不填登清空订点击GO一由口n可用.页面不响应.J0r4B.C三个知九门中任何一个填与不月言蝶芭的字弓时即时它

18、动濡除春蝴戴康巧字符国险数恰格区间W字及小tfc点外所树字符，不事比嵬示.爵看海宝价格直域网割！'-*汪，；只清除非规范博百字符.得融符合要求的字行就字和卜款点）举例a用户粘砧加7龛B玄（就入梅.目动清是甲间的蛇+JH3*在B和（:帕入相臬入葡大唇小数字,点击GO.传送散携调整为正常（前小后大3页而明新，也入椎自动调壁为前小后大.C.«5,。博修正常发字如100,工圈空点击GC页面刷新，结果数为大于或等于W0的结果CM6r8留空.C城与正常数字，?fl100.点击GO贯加朝后，珏果效力小于或等于100的踞星*.非螭范安号情况由Oean员.责捶供*.5九6和£两个痂入

19、一样的疑字（如183相当干箱入。至118.到取小于或等于谭较字的铝里.5 .浏览器的兼容性要求你们的产品兼容所有浏览器简直是梦想，但是有时出于效率的要求，我们必须战略性放弃某些浏览器，比如IE6.:D。这个决定谁来做？是前端工程师还是产品经理？还是你一一交互设计师？我认为决定权在交互设计师这里，但是他必须和产品经理达成一致，并与前端确认。你要求兼容的浏览器越多，标准越高，前端的工作量就会越大，测试的工作量甚至也会翻倍。比如:优先圣随求浏览器A所有功能可用;虫面元素与PSDDem无偏差，如字体大小、样式、行距、元素位署等今IE6.0IE7.0Firefox2.0Firefox340B所有功能可用

20、JIE8.0页面无错位；不影响阅读；C主功能可用具体的要求受高业项目要求、浏览器使用比例变化影0吼但是需要设计师范实并注明到设计文档中。四.什么时间交付呢？Heidi的建议：尽可能与你的线框图同时交付，如果你先交付出线框图，在撰写DRD的时候，极大可能会发现问题或产生优化的想法。但是往往写DRD至少需要1-2天的时间，你不可能让所有下游等着你的工作。所以：你可以交付出线框图供视觉先开始。视觉设计往往会先做风格定位设计，这和交互细节关系不大。先交付出已经确定的线框图给前端，然后在1-2天DRD后，若有改动，与前端当面一一确认并一起交付。五.如何写DRD?1.选择最有效率的工具。我的经验是这个工具

21、最好能够提供清晰的目录导航结构，而且易标注word确实是个写文档的好工具，不管你信不信，反正我是信了。PPT?Word?Visio?PDF?线框图软件直接标注？一一工具和格式不是问覆L易读2.易标注详细？简洁？目录结构？一一说明问题即可，有清毗的目录结构有大量需要用到标注的内容，需要采用最有效率的工具.3.易共享不用额夕滦软件.方便上传confluence2.建立固定的目录结构下图仅供参考。大项目的交互说明文档参考目录结构：修改纪要一一标明更改内容及年月日，相关人员相关交付物说明一一线框图地址、FBRD、UC地址等，方便查看*内容范围界定涵盖的项目范围、主要模块等.EJ使用说明（可选）一一你的

22、目录结构，是如何组织的具体模块目录（链接具体化、字符、交互说明、校验等）浏览器兼容性测试六.重要的原则准备写DRD的朋友，请认识清楚此文档真正要解决的问题是什么？如果是解决沟通偏差、需求遗漏、沟通成本高的问题，你在项目里没有出现过这种问题，各合作方也反馈良好，那么这个文档就无需写。如果是解决对设计需求进行存档，便于后续人员改版时查看的问题，则又是另外一回事（经验证明，过去的DRD确实能够在改版时起到一定的帮助，在我离开原项目很久后，新的设计师还找我要过相应项目的文档，了解过去的设计逻辑）。 不是为了写文档而写文档（而是为了解决问题） 适合于项目、合作方（大项目有大文档，小需求有灵巧的解决方案） 工具不是问题（易传播，易标注，成目录即可） 模版不是问题，大家看明白就可完美的文档无法取代面对面的沟通（评审会和讨论不会因为文档而减少）需要在实践中不断改进七.谁来写?两个邑色合作,