如何写一份交互说明文档
浏览:2274次 出处信息
![](http://1802.img.pp.sohu.com.cn/images/blog/2012/3/11/15/26/u82672385_136c115e15cg213.png)
离开交互圈已经有段时间了。但由于博客还在,还是能够偶尔收到一些邮件,上周有位同学问我:我在求职,我看到很多招聘说明上需要交互设计师编写界面交互设计文档,请问界面交互设计文档是什么文档?怎么编写呢
这让我想起来2009年自己在项目里也大力推行过交互说明文档(在下文中,简称为DRD),格式倒没什么限制,交互设计师自己写到界面上也行,单独文档成文也行,总之就是让交互设计师能够将界面承载不了的信息通过文档沉淀下来,降低项目里的沟通成本和风险。今天整理电脑,翻出以前的PPT,分享之。
这将涉及到几个问题:
![](http://1871.img.pp.sohu.com.cn/images/blog/2012/3/11/15/27/u82672385_136c116bdabg213.png)
1. 什么是交互说明文档(DRD)?
所谓DRD即是用来承载交互说明,并交付给前端、测试以及开发工程师参考的文档。
在项目中,交互设计师的主要产出物可能依次是:site map,page flow,wireframes。有的大型项目前期,交互设计师有可能还会产出用户需求分析文档(与PD产出的市场需求文档不一样的是,URD更多侧重于对目标用户的需求分析)。
DRD则很少有人专门撰写。如果需要对交互设计进行说明,聪明的交互设计师往往会直接标注在线框图里,或者在项目中不断和前端工程师和开发工程师口口相传,反复验收,不断迭代修改来确保所有的交互设计意图最终得以呈现。
2. 为什么要写?
DRD非项目必需环节,一般情况下也不会为交互设计师专门留出相应的时间预估。没有这份文档,项目也会继续,但是可能项目会为此承担不必要的沟通成本和时间成本。严重的话,项目的质量也会受到影响。所以写与不写,交互设计师需要做把握,时间被统一包含在“线框图”环节内——如果你要写,请在评估时预留1-2天的时间。
那么,结合我过去的经历,谈一下此文档的必要性。
下图是一个产品开发项目基本的流程。
![](http://1862.img.pp.sohu.com.cn/images/blog/2012/3/11/15/28/u82672385_136c117c9a6g214.png)
敏捷开发意味着很多不同角色的流程需要并行操作。如果等到产品经理的FRD已经全部敲定,交互设计师再开始去画线框图,固然会减少沟通成本和返工风险,但是同时意味着交互设计师的很多想法不被采纳。如果产品经理再强一些,他甚至会在FRD里连原始的DEMO也一并绘制出来了,功能性的需求和界面交互的需求有时无法区分太清楚——比如他会在FRD里直接要求每页条目40条,超过40条即分页。而交互设计师可能会认为像蘑菇街那样不断装载出足够长的页面会更亲和……所以,我们希望是和产品经理同时开始工作,在术业有专攻的时候相互补充。
同样,开发工程师也希望及早介入需求,在FRD并未确认的时候就了解需求,进而将商业需求和功能需求转化为开发工程师看得明白的开发需求清单(这个清单,大部分叫做UC,即USE CASE),当这份清单由工程师需求分析师——在过去,这个角色被叫简称为RA,但是目前已经取消此专门的职位,而是由开发工程师代表担纲此环节工作,为了便于描述,在此文里,我仍然将做这件事情的人称为RA——交付给具体的执行工程师后,执行工程师基本上可以当作一条条的checklist开始高效工作,而不必再思考商业逻辑和需求。同样,测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试,这也是基于UC和FRD去撰写的。
所以,开发需求分析是个很重要的环节。那RA是如何来完成需求分析工作的呢?
对于做这件事情的人来说,足够详尽的FRD是非常重要的。所以一份FRD虽然是PD产出,但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递,却存在很多问题。除了线框图,没有“详尽的说明性的文档”告诉他们。比如:
![](http://1802.img.pp.sohu.com.cn/images/blog/2012/3/11/16/0/u82672385_136c119fad3g215.png)
一方面,交互设计师对产品经理说:这块由我们来考虑,你的文档不必包含设计上的说明,这随时会调整的。
另一方面,线框图的评审有时会让RA参与,有时却没有叫他们。即使叫上了他们,他们也会发现交互设计的需求变化要比FRD变化快。另外,他们会认为UC不必写太多关于交互设计的需求。
在某个大型项目结束后,作为交互设计师,我进行了一些调研,听听这相关人员是怎么表述问题的:
开发部门的需求分析师:
产品经理:
走访了一些交互设计师后,他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑:
交互认为很平常的设计需求,如果不表达出来,还是容易被前端和开发忽略掉。我经历的一个项目,前端从头到尾更换了三个人,每次我都要重复去讲解下设计需求,讲得口干舌燥。而且做好后,还需要去验收。
可是以下问题都可以通过一份DRD来解决吗?
![](http://1821.img.pp.sohu.com.cn/images/blog/2012/3/11/16/3/u82672385_136c11ce507g214.png)
3. 写什么不写什么?
![](http://1821.img.pp.sohu.com.cn/images/blog/2012/3/11/16/6/u82672385_136c11f38e0g214.png)
要明确文档的定位,从写什么与不写什么开始,划清DRD以及FRD的边界。
1. 不写视觉规范规格标注
这些说明与功能实现没有太大关系,主要是为前端做HTML的时候参考的。一般视觉设计师会在PSD里标注清楚。如图:
![](http://1811.img.pp.sohu.com.cn/images/blog/2012/3/11/16/10/u82672385_136c1227a04g213.png)
如下图所示,作为DRD,你有必要传达清楚Browse by category区域的设计:链接的可点击性,链接的指向,字符与条目的数量限制等,但是具体二级类目排列是按产品数目排还是按字母排,还是人工运营,是FRD要解决的任务。
![](http://1802.img.pp.sohu.com.cn/images/blog/2012/3/11/16/10/u82672385_136c122da5dg213.png)
那么文档写什么呢?
![](http://1821.img.pp.sohu.com.cn/images/blog/2012/3/11/16/3/u82672385_136c11c5659g215.png)
举例子说明下:
1. 字符限制
提高空间利用率,有时网页上的动态文字需要从数据库里提取部分然后截断处理。比如下图中的标题和描述。你的DRD需要传达清楚:1,是否要做限制?2,如果做限制的话,多少字出现截断?截断后是显示为省略号还是不显示?这个汉语设计相对简单,如果英文单词的话,因为是按字符,每个字符的宽度不一致,需要预估,另外还需要注明是整词截断还是词间截断。
![](http://1862.img.pp.sohu.com.cn/images/blog/2012/3/11/16/17/u82672385_136c129472dg215.png)
2. 链接具体化
很多网站都有对搜索结果的筛选设计(refine search),比如aliexpress搜索结果页左侧。这块区域的交互事件是非常复杂的。
![](http://1811.img.pp.sohu.com.cn/images/blog/2012/3/11/16/25/u82672385_136c130f619g214.png)
要确保这些你设想中的复杂的交互逻辑能够被理解被呈现,除了一页页的线框图,你有必要再三让前端工程师和开发工程师了解并达成认知一致。所以你需要将页面上的关键链接事件标识清楚。它们有的指向无需刷新页面的交互,有的指向你安排的并非PD安排的某个中间页面(page flow是交互设计师的职责)
![](http://1871.img.pp.sohu.com.cn/images/blog/2012/3/11/16/22/u82672385_136c12d9b70g214.png)
3. 交互细节说明
相信我,我很不愿意写这些东西。我喜欢在会议室向各位涉众演示我的线框图,我会研究用axure制作各种动态效果,达到它足够逼真呈现各种联动——比如当你选择了下拉菜单中的某项时,页面上其他区域也发生相应的变化。可是,Axure不是全能的。即使能够表达出来,线框图交付出去,也不能确保其他人都能够一一进行点击尝试。所以只能在会议室反复讲解,在事后再三检查并敦促修改。
但是当我尝试用下图对这块小小且复杂的区域进行详细说明后,事情变得简单多了。所以我用节省的时间去写了这份PPT.
![](http://1862.img.pp.sohu.com.cn/images/blog/2012/3/11/16/5/u82672385_136c139f523g215.png)
又如,你可以在这里说明任何你想要的效果。你的受众也只需要用10分钟时间阅读完毕,标注出与他工作相关的重点,存档并在遇到问题,找不到你人时随时参考。
![](http://1821.img.pp.sohu.com.cn/images/blog/2012/3/11/16/10/u82672385_136c13eb0d1g215.png)
5. 表单的校验
这也是一项不怎么有创意的事情,但是你若不事先想清楚,在项目过程中有点麻烦。写文档看似枯燥乏味,反过来想也是
![](http://1802.img.pp.sohu.com.cn/images/blog/2012/3/11/16/12/u82672385_136c14091deg214.png)
建议继续学习:
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
扫一扫订阅我的微信号:IT技术博客大学习
后一篇:为细节设计 >>
文章信息
- 作者:Heidi格物志 来源: Heidi格物志
- 标签: 文档
- 发布时间:2012-03-11 22:10:29
建议继续学习
近3天十大热文
-
[185] WEB系统需要关注的一些点
-
[12] 我的git笔记
-
[12] 深入剖析 redis replication
-
[12] 一次神奇的MySQL优化
-
[12] Spark性能优化——和shuffle搏斗
-
[12] InnoDB insert性能拐点测试
-
[11] 浏览器的工作原理:新式网络浏览器幕后揭秘
-
[11] Python 代码规范小结
-
[10] Linux系统管理技术手册第十三章系统实践
-
[10] Android设计中的.9.png