Warlial2012-06-20 14:501条评论
正在上传…重新上传取消
本文由【编者按】@heidixie发布于其个人博客—Heidi格物志。从交互设计师的角度讲解制作交互说明文档的好处和方法。
与一般教程不同，作为一名互动设计师，作者在互动描述文档和互动设计过程中可能出现的问题方面经验丰富。因此，他详细分析了每一个细节，让读者知道为什么。
所谓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如何完成需求分析？
- 前期介入，对PD评估和支持开发需求；
- 参与每次的FRD评审会；
- 详细审阅FRD不断与文档相关PD确认。
对于做这件事的人来说，足够详细FRD很重要。所以一份FRD虽然是PD输出，但许多实施细节是由开发工程师不断沟通、评估和确认的。然而，设计需求的传递存在许多问题。除了线框图，没有详细的解释档告诉他们。
正在上传…重新上传取消
一方面，交互设计师对产品经理说：我们将考虑这一点。您的文档不需要包含设计说明，这将随时调整。
另一方面，对线框图的评估有时会RA参与，有时不给他们打电话。即使他们打电话给他们，他们也会发现交互设计的需求变化比FRD变化很快。此外，他们会认为，UC不要写太多关于交互设计的需求。
在一个大项目结束后，作为一名交互设计师，我做了一些研究，听听相关人员如何表达问题：
：
每次变化都很痛苦。设计改变后，我会跟着改变UC，有时改截图UED改了也忘了通知我们，结果UC有问题……
页面交互的需求很容易被遗漏，因为UC不可能在互动中写太多。
希望UED能够在提交HTML DEMO给RA可以同时给出页面元素描述文档，需要介绍html demo文案、链接、相关图片尺寸或显示字符数量。RA在这方面花费更多的时间，往往需要和谐UED确认这些内容。
前期RA和PD在沟通过程中，有许多交互点无法清楚，如默认显示多少属性值、标题显示多少字符等。在过去的需求和项目中，我们都想到弥补这些问题FRD去文档或邮件。它不仅增加了沟通成本，而且有遗漏细节的风险。PD对于可控性的需求，往往会超越FRD注明这种需求(对于交互设计师来说，却没有发挥的余地)
走访了一些交互设计师后，他们也有如何清晰无遗漏地传达交互设计需求的困惑:
- 互动认为，非常常见的设计需求，如果不表达，仍然很容易被前端和开发所忽视。在我经历的一个项目中，前端从头到尾更换了三个人。每次我都要反复解释设计需求，口干。完成后，您还需要进行验收。
- DRD作为参考手册，在一定程度上避免了不一致的问题。
- 即使有问题，也可以作为界面验收Checklist。我对A说，我对B说，A对B说A与B共同参考同一文件，降低沟通成本和信息不对称。
整个过程影响用户体验(直到测试，都需要参考设计文档)。
但是，以下问题可以通过一个问题来解决DRD来解决吗？
正在上传…重新上传取消
正在上传…重新上传取消
要明确文档的定位，从写什么和不写什么开始，划清楚DRD以及FRD的边界。
这些描述与功能实现无关，主要是为了前端HTML参考。一般视觉设计师会参考。PSD里标注楚。如图：
正在上传…重新上传取消
如下图所示，作为DRD，你有必要传达清楚Browse by category区域的设计：链接的可点击性，链接的指向，字符与条目的数量限制等，但是具体二级类目排列是按产品数目排还是按字母排，还是人工运营，是FRD要解决的任务。
正在上传…重新上传取消
那么文档写什么呢？
正在上传…重新上传取消
举例子说明下：
提高空间利用率，有时网页上的动态文字需要从数据库里提取部分然后截断处理。比如下图中的标题和描述。你的DRD需要传达清楚：1，是否要做限制？2，如果做限制的话，多少字出现截断？截断后是显示为省略号还是不显示？这个汉语设计相对简单，如果英文单词的话，因为是按字符，每个字符的宽度不一致，需要预估，另外还需要注明是整词截断还是词间截断。
正在上传…重新上传取消
很多网站都有对搜索结果的筛选设计（refine search），比如aliexpress搜索结果页左侧。这块区域的交互事件是非常复杂的。
- 类目和属性的不同如何处理
- 属性以及每条属性显示的属性值的条目是否有显示上的限制？
- 选中后，被选中的属性值是停留在原地，方便用户记忆，还是放到统一的位置，方便用户统一查看？其他未被选中的属性值是否消失？
正在上传…重新上传取消
要确保这些你设想中的复杂的交互逻辑能够被理解被呈现，除了一页页的线框图，你有必要再三让前端工程师和开发工程师了解并达成认知一致。所以你需要将页面上的关键链接事件标识清楚。它们有的指向无需刷新页面的交互，有的指向你安排的并非PD安排的某个中间页面（page flow是交互设计师的职责）
正在上传…重新上传取消
相信我，我很不愿意写这些东西。我喜欢在会议室向各位涉众演示我的线框图，我会研究用axure制作各种动态效果，达到它足够逼真呈现各种联动——比如当你选择了下拉菜单中的某项时，页面上其他区域也发生相应的变化。可是，Axure不是全能的。即使能够表达出来，线框图交付出去，也不能确保其他人都能够一一进行点击尝试。所以只能在会议室反复讲解，在事后再三检查并敦促修改。
但是当我尝试用下图对这块小小且复杂的区域进行详细说明后，事情变得简单多了。
正在上传…重新上传取消
又如，你可以在这里说明任何你想要的效果。你的受众也只需要用10分钟时间阅读完毕，标注出与他工作相关的重点，存档并在遇到问题，找不到你人时随时参考。
正在上传…重新上传取消
这也是一项不怎么有创意的事情，但是你若不事先想清楚，在项目过程中有点麻烦。写文档看似枯燥乏味，反过来想也是让你自己再好好思量审核设计本身的关键步骤。我曾经自以为完善的交互设计方案就是在写DRD的时候发现存在重大的纰漏，然后及时优化的。
正在上传…重新上传取消
你们的产品兼容所有浏览器简直是梦想，但是有时出于效率的要求，我们必须战略性放弃某些浏览器，比如IE6.:D 。 这个决定谁来做？是前端工程师还是产品经理？还是你——交互设计师？我认为决定权在交互设计师这里，但是他必须和产品经理达成一致，并与前端确认。你要求兼容的浏览器越多，标准越高，前端的工作量就会越大，测试的工作量甚至也会翻倍。
正在上传…重新上传取消
Heidi的建议：尽可能与你的线框图同时交付，如果你先交付出线框图，在撰写DRD的时候，极大可能会发现问题或产生优化的想法。但是往往写DRD至少需要1-2天的时间，你不可能让所有下游等着你的工作。所以：
- 你可以交付出线框图供视觉先开始。视觉设计往往会先做风格定位设计，这和交互细节关系不大。
- 先交付出已经确定的线框图给前端，然后在1-2天DRD后，若有改动，与前端当面一一确认并一起交付。
我的经验是这个工具最好能够提供清晰的目录导航结构，而且易标注。word确实是个写文档的好工具，不管你信不信，反正我是信了。
正在上传…重新上传取消
下图仅供参考。
正在上传…重新上传取消
准备写DRD的朋友，请认识清楚此文档真正要解决的问题是什么？如果是解决沟通偏差、需求遗漏、沟通成本高的问题，你在项目里没有出现过这种问题，各合作方也反馈良好，那么这个文档就无需写。如果是解决对设计需求进行存档，便于后续人员改版时查看的问题，则又是另外一回事（经验证明，过去的DRD确实能够在改版时起到一定的帮助，在我离开原项目很久后，新的设计师还找我要过相应项目的文档，了解过去的设计逻辑）。
- 不是为了写文档而写文档（而是为了解决问题）
- 适合于项目、合作方（大项目有大文档，小需求有灵巧的解决方案）
- 工具不是问题（易传播，易标注，成目录即可）
- 模版不是问题，大家看明白就可
- 完美的文档无法取代面对面的沟通（评审会和讨论不会因为文档而减少）
- 需要在实践中不断改进
正在上传…重新上传取消
我建议由交互设计师发起，但是由前端工程师进行修订，再传递给开发工程师。
有很多需求，交互设计师只要求实现即可，但是他可能并不在乎是前端实现还是后端实现。前端工程师对DRD进行把关和修订，能够将设计语言转化为工程师能够看懂的语言，且能够划定与开发的实现边界。
项目中交付物对应不同的使用角色，如下图所示：
正在上传…重新上传取消
但是有个问题是，虽然DRD的目标受众有开发和测试，但是让开发工程师同时参考那么多文档是不现实的，所以仍然是开发工程师的接口人，也就是事实上的RA需求分析作为需求整合传递的角色，将商业需求和设计需求，传达给具体的执行开发工程师与测试工程师：
正在上传…重新上传取消
【总结】
对于坚持撰写DRD的我来说，DRD的好处自己当然是明白的——在撰写过程中重新梳理设计逻辑，优化设计；降低沟通成本等等。
但是并非所有人都喜欢写文档或者都喜欢看文档。
解决问题有多种方案，DRD只是其中一个。不过，当你因为设计需求传递过程中发生了问题，或者你的需求被理解偏差，或者你的需求被遗漏，或者你接手的项目改版，因为要梳理过去的设计逻辑焦头烂额时，你可以试试用DRD。如果使用过程中还是存在问题，那么就想想是否还存在别的解决方案吧。