产品文档-界面交互设计规范及案例

产品设计文档界面交互设计规范及案例

离开交互圈已经有段时间了。但由于博客还在，还是能够偶尔收到一些邮件，上周有位同学问我：我在求职，我看到很多招聘说明上需要交互设计师编写界面交互设计文档，请问界面交互设计文档是什么文档？怎么编写呢这让我想起来2009年自己在项目里也大力推行过交互说明文档（在下文中，简称为DRD）,格式倒没什么限制，交互设计师自己写到界面上也行，单独文档成文也行，总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来，降低项目里的沟通成本和风险。今天整理电脑，翻出以前的PPT，分享之。这将涉及到几个问题:一.什么是交互说明文档（DRD）？为什么要有这险。今天整理电脑，翻出以前的PPT，分享之。这将涉及到几个问题:一.什么是交互说明文档（DRD）？为什么要有这份文档？写什么？什么时间交付？怎么写？谁来写？谁来管理？可能的问题?所谓DRD即是用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。在项目中，交互设计师的主要产出物可能依次是：sitemap,pageflow,wireframes。有的大型项目前期，交互设计师有可能还会产出用户需求分析文档（与PD产出的市场需求文档不一样的是，URD更多侧重于对目标用户的需求分析）。DRD则很少有人专门撰写。如果需要对交互设计进行说明，聪明的交互设计师往往会直接标注在线框图里,或者在项目中不断和前端工程师和开发工程师口口相传,反复验收,不断迭代修改来确保所有的交互设计意图最终得以呈现。二.为什么要写？DRD非项目必需环节，一般情况下也不会为交互设计师专门留出相应的时间预估。没有这份文档,项目也会继续,但是可能项目会为此承担不必要的沟通成本和时间成本。严重的话,项目的质量也会受到影响。所以写与不写,交互设计师需要做把握,时间被统一包含在“线框图”环节内——如果你要写,请在评估时预留1-2天的时间。那么,结合我过去的经历,谈一下此文档的必要性。下图是一个产品开发项目基本的流程。

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

是目前已经取消此专门的职位，而是由开发工程师代表担纲此环节工作，为了便于描述，在此文里，我仍然将做这件事情的人称为RA——交付给具体的执行工程师后，执行工程师基本上可以当作一条条的checklist开始高效工作，而不必再思考商业逻辑和需求。同样，测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试，这也是基于UC和FRD去撰写的。所以，开发需求分析是个很重要的环节。那RA是如何来完成需求分析工作的呢？前期介入，对PD进行开发需求评估支持；如何写一份交互说明文档参与每次的FRD评审会；详细审阅FRD文档并不断与PD确认。对于做这件事情的人来说，足够详尽的FRD是非常重要的。所以一份FRD虽然是PD产出，但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递，却存在很多问题。除了线框图，没有“详尽的说明性的文档”告诉他们。比如：刷新不刷新页面的tabSbtjinneinlFVMundSbtjinneinlFVMundRmdicibuttDARmdicibuttDA有无数认选择怦是者源I卜事,©imiRSrQ甘淤溪目输入框有无初始值？校验如何做？Qwthi!I ZuMLM：叫I»I |SMh—=11和 冲|岫*i WJ 加hr一方面，交互设计师对产品经理说：这块由我们来考虑，你的文档不必包含设计上的说明，这随时会调整的。另一方面，线框图的评审有时会让RA参与，有时却没有叫他们。即使叫上了他们，他们也会发现交互设计的需求变化要比FRD变化快。另外，他们会认为UC不必写太多关于交互设计的需求。在某个大型项目结束后，作为交互设计师，我进行了一些调研，听听这相关人员是怎么表述问题的：开发部门的需求分析师：每次变动都很痛苦，设计变了之后，我就要跟着改UC,改截图，有时候UED改了还忘了通知我们，导致UC有问题……页面交互的需求容易漏掉，因为UC里面不可能写太多交互方面的东西。希望UED能够在提交HTMLDEMO给RA时，能同时给出一份页面元素描述文档，需要介绍htmldemo中的文案、链接以及相关的图片尺寸或显示字符个数。现在RA在这方面花费的时间比较多，经常要和UED去确认这些内容。产品经理：前期RA和PD沟通过程中，有很多交互点点不能够明确，比如“默认显示多少属性值”，“标题显示多少字符”等。在以往的需求和项目中，对待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PD为了可控性的需求，往往会“越俎代庖”，直接在FRD注明这种需求（对于交互设计师来讲，却又导致没有发挥余地）走访了一些交互设计师后，他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑：交互认为很平常的设计需求，如果不表达出来，还是容易被前端和开发忽略掉。我经历的一个项目，前端从头到尾更换了三个人，每次我都要重复去讲解下设计需求，讲得口干舌燥。而且做好后，还需要去验收。DRD做为参考手册，一定程度上避免不吻合的问题发生。即使有问题发生，也可以作为界面验收时的Checklist。将“我对A说，我对B说，A对B说"，转变为“A和B共同参考同一份文档”，减少沟通成本及信息不对称。全程影响用户体验（一直到测试，都需要参照设计文档）。可是以下问题都可以通过一份DRD来解决吗？A这么多问题？牵制重复劳动偏差，沟通成本大重要信息遗漏三.写什么不写什么？

1=1文档不的什么？1=1文档不的什么？视觉规范规格［Margin、间距、容器宽度等）商业逻辑〔匕嚏口为什么要有这个功能）详细的功能实现机制（UC和FRD的任务）□功能逻辑（点击离线状态的ATM后判断等）详细的文案（另夕睚交动态文案表）要明确文档的定位，从写什么与不写什么开始，划清DRD以及FRD的边界。不写视觉规范规格标注这些说明与功能实现没有太大关系，主要是为前端做HTML的时候参考的。一般视觉设计师会在PSD里标注清楚。如图：不写功能实现逻辑。如下图所示，作为DRD，你有必要传达清楚Browsebycategory区域的设计：链接的可点击性，链接的指向，字符与条目的数量限制等，但是具体二级类目排列是按产品数目排还是按字母排，还是人工运营，是FRD要解决的任务。

£1Sony.£1Sony.nomattlwsv«retoundinProducttfwTeinterestedin展用白sorikH整mg恻弓晶srthino类目推荐区;AqilcinlliireGrfjsnicp-fodud^FfirmMeiy&Equipm@nl;Pl自力AqilcinlliireGrfjsnicp-fodud^FfirmMeiy&Equipm@nl;Pl自力1&』ninii0l F*ii%Ferticei；T,c：修修;日日即1曾pi修；Fr$shveqeia肚Grain;ah冏勃IF时d人工运营」Apywl故归近即।时「就&时Mue由：中髓气名：曲山电屿;Unge呻;Unrfiorms&WorlM@在甘《前忙写T「ShiiU；E那么文档写什么呢？文档写什么7字符限制链接指向目交互细节说明E1校验浏览器兼容性测试说明举例子说明下：字符限制提高空间利用率，有时网页上的动态文字需要从数据库里提取部分然后截断处理。比如下图中的标题和描述。你的DRD需要传达清楚:1，是否要做限制？2，如果做限制的话，多少字出现截断？截断后是

显示为省略号还是不显示？这个汉语设计相对简单，如果英文单词的话，因为是按字符，每个字符的宽度不一致，需要预估，另外还需要注明是整词截断还是词间截断。鹏NOVlOigEMIF3Piaw匚WimFe 鹏NOVlOigEMIF3Piaw匚WimFe 订否砧xRwamr27dsysLEil23.0O-32lJ00/Lrt1OpnK«3fL=BVI11J39.Hn3^04FmcrtieCMiwwi-Fih1 （心durim$]|UP3ai碗rjYiu&世训卸画U£0伯4fBi卜明i词师2轿呷即小耿。叩丽◎汕g1nm冲i*ip叶e链接具体化很多网站都有对搜索结果的筛选设计(refinesearch),比如aliexpress搜索结果页左侧。这块区域的交互事件是非常复杂的。•类目和属性的不同如何处理•属性以及每条属性显示的属性值的条目是否有显示上的限制？•选中后，被选中的属性值是停留在原地，方便用户记忆，还是放到统一的位置，方便用户统一查看？其他未被选中的属性值是否消失？AllProductsRennesearcnWRegionsShiptoResutsturelectricscooterSntrrtRfrLsllOnlyNumberofOrdarv.1MlhllELECTRIC5cgTEHWheelSize!■l-=wjitys:AllProductsRennesearcnWRegionsShiptoResutsturelectricscooterSntrrtRfrLsllOnlyNumberofOrdarv.1MlhllELECTRIC5cgTEHWheelSize!■l-=wjitys:keceriiricatioii要确保这些你设想中的复杂的交互逻辑能够被理解被呈现，除了一页页的线框图，你有必要再三让前端工程师和开发工程师了解并达成认知一致。所以你需要将页面上的关键链接事件标识清楚。它们有的指向无需刷新页面的交互，有的指向你安排的并非PD安排的某个中间页面（pageflow是交互设计师的职责）2.・凶・厄・超5.B.SS接和button的指向2.・凶・厄・超5.B.SS接和button的指向：Buy口。卅butEn，指向下订箪页面。不一定是具体的URL,但是需要给出线框图或dem□的捱接。A.复杂交互的流程国;L・・口・电■■■■4.述看■性耳困班融口B32.5Dl«iDAmridg2Em-*0DDiFl3.3.交互细节说明相信我，我很不愿意写这些东西。我喜欢在会议室向各位涉众演示我的线框图，我会研究用axure制作各种动态效果，达到它足够逼真呈现各种联动——比如当你选择了下拉菜单中的某项时，页面上其他区域也发生相应的变化。可是，Axure不是全能的。即使能够表达出来，线框图交付出去，也不能确保其他人都能够一一进行点击尝试。所以只能在会议室反复讲解，在事后再三检查并敦促修改。但是当我尝试用下图对这块小小且复杂的区域进行详细说明后，事情变得简单多了。所以我用节省的时间去写了这份PPT.

UES53.0CI▼58.90：LotridLajtr.t?-n.jjj-ftwHE.米独星,W13D0QLS447.M9价格JI饰崭注料'雇小眼订量，料将注得।等包几件,好件行少微UES53.0CI▼58.90：LotridLajtr.t?-n.jjj-ftwHE.米独星,W13D0QLS447.M9价格JI饰崭注料'雇小眼订量，仇的目表上如常取冲修信息苜目若向r苴要过型区城点西的riding.仇的目表上如常取冲修信息苜目若向r苴要过型区城点西的riding.见下阻.川卷年4一旦箫入芍合以百3荔早后，耳切李之百石塔可用10分钟时间阅读完毕，标注出与他工作相关的重点，存档并在遇到问题，找不到你人时随时参考。,点击被圻拄的履性时，星现郎画熟果的拉开t点击统框图看大墓敕果3不刷据页面.FibMmi向MkU*FibMmi向MkU*MilliirH•7lillillmrltM皿1if^«rreBmHhF・仲Fu4icli*n1/LMlJbvIfl酶FMRkdai：3i4^：ill5BF0fl(23iJi人口Rip»iHie«kBD那VVmc#i?HE方.时为亡f 皑1s<MnmFiayDirrmE-如地口川小问隼ur»rt「*i，旭**3日峥USaPflrtGM力!”BRWH的gdd3中代兄如由出*CFFlc-Mlenl&5|-卜询胃四》£BooleMHMiW好的：：斩赵藏性的盛丹L因孕幼生宽昼卉的展拽考-其也的哦性理鼻蒸昱示［不虞有10个的葭M曜卷，，ir点击展若优态〒打耳投名r号片信友崭收苴n回利鹿蛤就有，*.每次卓喜欣起药不胤蒙页区〔占旎♦次填取J.-.取标号发区域；曜个横向条・平Amibiile06 --5.表单的校验这也是一项不怎么有创意的事情，但是你若不事先想清楚，在项目过程中有点麻烦。写文档看似枯燥乏味，反过来想也是让你自己再好好思量审核设计本身的关键步骤。我曾经自以为完善的交互设计方案就是在写DRD的时候发现存在重大的纰漏，然后及时优化的。Prit*PtrUriit!~▼rwr^~\Cnelr4自K航人植都不填或清空时点击GO——OuHfin可用.我面不响应--亡2・3%&用三个幡入蚱中任何一个城写不料合堤藉的字符时——即时自动清除非胤篇顼耳字栉《即修教价蝴阍 至i字及小数点外断而字符上不弹出提币.善考询宝位援区图限和： ^ '- 、注意，只湎除非翱范承写字符「保逑符宫要求削字符（:迎平和小戏点L.•举例，同户粘砧有7到日职E特入推.自动清楚中间的姓，Ah箝在日利士柏人柜里输入的大后小教字.庶击（56传递颤据调整为正常小后天3簧面剧痂，输入捱自动调整力前小后犬.一Ci«5sB械耳正常鼓手如100,t潴空，点击GO一页面朝新.括肆铁的大于鸡等于1MJ的晶来.一C»>«：康留空।。费与正常数字'如100，点击店O—贾面别甘，舟果数为小于或等于100地纳扁.一张规延填写情况由加an负责提供*,■才・7MB和c两个独人一弊的数字£知1003相当于物色。到1页到取小于或辱于诬毁事的^里..■6.浏览器的兼容性要求你们的产品兼容所有浏览器简直是梦想，但是有时出于效率的要求，我们必须战略性放弃某些浏览器，比如IE6.:D。这个决定谁来做？是前端工程师还是产品经理？还是你——交互设计师？我认为决定权在交互设计师这里，但是他必须和产品经理达成一致，并与前端确认。你要求兼容的浏览器越多，标准越高，前端的工作量就会越大，测试的工作量甚至也会翻倍。比如「优先缎描述浏览器A所有◎能可用三而面兀素与咫口口已巾口无偏差，如子体大小,样式、行距、元素位置等。IE6.0IE7.0Firefox2.0Firefox3.0IB 所有功能可用5 IE8.0页面无错位J ……不影响阅读，C 主功能可用.…具体的要求受商业和项目要求、浏口使用比例变化影响。但霞要设讨1谓实并注明到设it文档中。四.什么时间交付呢？Heidi的建议：尽可能与你的线框图同时交付，如果你先交付出线框图，在撰写DRD的时候，极大可能会发现问题或产生优化的想法。但是往往写DRD至少需要1-2天的时间，你不可能让所有下游等着你的工作。所以：•你可以交付出线框图供视觉先开始。视觉设计往往会先做风格定位设计，这和交互细节关系不大。・先交付出已经确定的线框图给前端，然后在1-2天DRD后，若有改动，与前端当面一一确认并一起交付。五.如何写DRD?选择最有效率的工具。我的经验是这个工具最好能够提供清晰的目录导航结构，而且易标注。word确实是个写文档的好工具，不管你信不信，反正我是信了。

PPI?Word?Visio?PDF?线框图软件直接标注？——工具和格式不是问题详犯？简洁？目录结装I?——说明问题即可，有清毗的目录结构有大量需要用到标注的内容,需要L易读 采用最有效率的工具“.易标注//.易共享 不用额夕麋软件，方便上传confluence建立固定的目录结构下图仅供参考。［项目的交互说明文档参考目录结构：修改纪要一一标明更改内容及年月日，相关人员相关交付物说明一一线框图地址、FBRD、LJC地址等，方便查看。内容范围界定一一涵盖的项目范围.主要模块等口EJ使用说明（可选）――你的目录结构，是如何组织的具体模块目录.…（销接具体化、字符、交互说明、校验等）浏览器兼容性测试具体里面的细节，就不一一罗嗦了。重要的原则准备写DRD的朋友，请认识清楚此文档真正要解决的问题是什么？如果是解决沟通偏差、需求遗漏、沟通成本高的问题，你在项目里没有出现过这种问题，各合作方也反馈良好，那么这个文档就无需写。如果是解决对设计需求进行存档，便于后续人员改版时查看的问题，则又是另外一回事（经验证明，过去的DRD确实能够在改版时起到一定的帮助，在我离开原项目很久后，新的设计师还找我要过相应

项目的文档，了解过去的设计逻辑）。•不是为了写文档而写文档（而是为了解决问题）•适合于项目、合作方（大项目有大文档，小需求有