［总结］：在用户的视角来看，我们也希望他看到的都是最简单最愉悦的一面。作为客户培训师，你不需要知道产品数据在我们后台是存储在什么服务器的。用户搜索产品时，也更加不需要了解一个检索词是经过了多少词解析判断计算，跑了几台服务器，最终把结果呈现给他的。但是作为工作人员，我们得了解需要怎么做，才能够把最简单最愉悦的结果呈现出来。（Heidi注：如图5所示）

图5：简明网站产品建设流程图

这个图呈现的流程，依赖于多个部门的通力合作。从战略层高瞻远瞩的判断、从产品经理对于市场的分析以及功能、内容的规划、描述，到用户体验团队，开发和测试团队的全力配合，而网站产生后，还要依赖于SEO、市场营销、销售和客服的工作。

成功的网站，一定是多个部门一起围绕相同目标运作的结果，但是其中一个环节失败，则可能会造成全盘皆输。

本文虽然篇幅已经很长，但是涉及到具体的流程、方法，都只能简单带过，希望大家要记住这是对话的场景，不要以偏概全哦。
你对他提出的问题，想如何回答呢？如果你有问题，质疑，鼓励……欢迎交流。

离开交互圈已经有段时间了。但由于博客还在，还是能够偶尔收到一些邮件，上周有位同学问我：我在求职，我看到很多招聘说明上需要交互设计师编写界面交互设计文档 ，请问界面交互设计文档是什么文档？怎么编写呢

 

所谓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去撰写的。

 

“这个不符合用户的心理”，“这个功能打破了我们产品整体的平衡性，放在这里在我看来是不太合理的”…

作为互联网行业里万千鼠标民工中的一员，诸如以上的对话，每天都在我们的生活中不断演绎着。合理性慢慢的成为了检验我们专业技能以及设计水平最重要的一种指标；诚然，足够的合理性能够为我们所设计的产品保驾护航，能够给其带来可预见性的回报和收获，但长此以往，却很难再出现令我们叫“WOW！！”的产品了。让我们来看颗栗子~ 

iPhone5自9月13日发布以来，就受到了前所未有的神吐槽，在这一次，大家都能很明显的感受到没有了乔帮主以后，苹果不再是创新界的翘楚了。

2012年里，我(英文原文作者)在TH_NK 里大约花费了50个小时用于可用性测试，其余的时间则主要用来进行实际的设计工作，或是与客户、开发者、分析人员等进行沟通。在这些可用性测试当中，经过对被测者行为的观察以及与他们面对面的交流，我对一些一直以来虽有所了解、但在实际工作中却时常会忽视掉的设计原则有了更加贴近实践的认知，另外也发现了一些从前没有想到过的问题。时值岁末，我将这些经过实践验证的设计要点作以小结并分享给各位，希望能够为大伙来年的工作带来一定参考和借鉴的价值。

1.你不是你的用户

扪心自问，我们真的很容易忘记一件重要的事情：用户并不会按照我们设想的方式去行事。作为产品和设计方面的从业者，我们对自己的产品和服务太了如指掌了，对产品的功能逻辑及设计方案太心知肚明了；即使是作为第三方咨询顾问一类的角色，你也很容易把事情考虑的过于理所当然，认为“外界”的人能非常清楚的理解你所要表达的东西。

而事实上，多数用户在实际上手使用之前，并没有和产品产生长久的关联；对于我们来说很显而易见的东西在用户看来很可能需要一定的辅助才能理解并正确操作。交互模式是否符合直觉，是否能够保持足够的一致性以符合用户逐渐建立起来的心智模型，用户界面是否会在必要的环节提供足够有效的辅助引导，这些都是我们在为核心功能打造设计方案的同时必须考虑到的问题。

2.导航至首页

在很多场可用性测试当中，我们都观察到，其实会通过点击页头logo回到首页的被测者很少；多数人都试图通过点击浏览器上的后退按钮来实现这个目标。虽然对于设计师来说，将logo链接至网站首页的做法是一种早已被普遍接受的规范，但事实上普通用户对这一点的认知似乎并不是那么的根深蒂固。

3.通过下拉列表选择国家

我们曾经对一个面向全球的在线零售网站的支付环节进行过可用性测试，从中我们发现，在选择国家的时候，很少有用户懂得通过首字母快捷键来快速定位国家选项在下拉列表当中的位置，然后通过上下箭头按键进行调整并敲击回车或空格键来完成选择。绝大多数的用户仍然是使用鼠标将列表点开，上下寻找并点击选取。

其实下拉列表易用性的问题(特别是那些所包含的选项超过了7个的列表)早就引发过广泛的争论，使用快捷键进行操作的方案也是为了解决这方面的问题而孕育而生的，但在现实当中我们仍然发现有那么多的用户实际上并不了解这种重要的导航操作。

Christian Holst在重新设计国家列表 一文中介绍过一种蛮有意思的解决方案，虽然我们还没有对这种方案进行过量化的测试，不过至少它看上去确实比传统的下拉列表方式要好用。

Flickr为用户准备了很多有意思的登录欢迎语，这其实是一个容易被忽略的细节，但Flickr的整体设计风格与产品气质也正是由许许多多这样的细节构成的。也许，只有当这些细节从产品中消失的时候，我们才会发现并开始怀念它们。

我(英文原文作者)会特别在意这些细节，因为它们可以触发用户的情感响应。如果运用方式得当，这些细节当中的小魔鬼可以帮助我们打造出更具人格的产品，并使用户在与之进行互动的过程中产生积极的情感响应；而这种积极的态度会有效的促使用户主动传播和拥护你的产品。这种在人格层面与用户建立关联的设计思路也被称作“情感化设计”。

一点小理论

“情感化设计(Emotional Design)”一词由Donald Norman在其同名著作 当中提出。而在Designing for Emotion 一书中，作者Aarron Walter将情感化设计与马斯洛的人类需求层次理论联系了起来。正如人类的生理、安全、爱与归属、自尊和自我实现这五个层次的需求，产品特质也可以被划分为功能性、可依赖性、可用性和愉悦性这四个从低到高的层面，而情感化设计则处于其中最上层的“愉悦性”层面当中。

一个有效的情感化设计策略通常包括两个方面：

1. 你创造出了独特并且优秀的风格理念，令用户产生了积极响应。
2. 你持续的使用该理念打造出一整套具有人格层面的设计方案。

接下来，我们将一起了解一下情感化设计的组成要素及相关策略，看一看有哪些产品在这些方面做的比较有代表性；另外，我们还会通过几个案例分析来感受一下从整体角度持续使用情感化设计理念所带给产品的“人格魅力”。

亲密是爱情关系中的温暖体验，是一种朋友般的亲近。由于真正喜欢和对方在一起，渴望同对方一道建立更有凝聚力的和谐关系，希望把自己的生活以坦诚、不设防的方式与对方分享。伴侣间会发展出属于两个人的沟通风格，熟悉彼此不完美的个性。亲密令恋人互相关心，善待对方，满足彼此的需要和欲望。亲密没有激情强 烈，但能促进恋人相互亲近，让人感受到人际温暖。

根据DailyTech的统计，到2015年，移动互联网的用户数量将会超过桌面用户。除了智能手机之外，使用平板电脑甚至是电视机进行上网的用户也在持续增加。在这种形势下，怎样让我们的网站尽量兼容各种类型的设备，并确保优良的用户体验，这将是越来越重要的问题。

通过响应式的设计开发方式，我们可以使网站页面随浏览设备的不同而自行响应，动态的调整布局结构、元素规格样式，将相同的内容以不同的格式呈现给不同设备的用户。

如果你对响应式Web设计还不大了解，可以先参考阅读我们之前的关于响应式设计的概念、组成要素及基本实现思路 方面的文章，全方位预热一下。

什么情况下适宜采用响应式Web设计的方式

当客户提出产品功能移动化的需求时，有一些解决方案可供我们选择，包括原生客户端应用、Web应用等；究竟怎样的方式更合适，还是取决于具体的需求情况。另外也要考虑网站本身是否需要实施移动化。虽然响应式站点并不能算是一种纯粹的移动化解决方案，但是，在某些情况下，这种方式是非常值得考虑的。

你心里没谱

设计开发一个全新的移动版本站点或是客户端应用，整个过程是有很大挑战性的。除非产品正式上线，否则你无法真正了解它是否会成功。与其单纯的为了移动化而花费资源打造移动版本站点或是开发客户端应用，不如先花些心思将原本的网站打造的更具弹性，使其在各种主流移动设备中都拥有尽量优秀的用户体验。

你想节约成本

要打造响应式站点，自然离不开有经验的交互、视觉设计及前端开发人员。所需的资源，尤其是时间方面，比起普通网站来说大约增加20%到30%的样子；但比起单独打造移动版本的网站，或是设计开发客户端应用的成本来说，却要低很多。从维护的角度来说，也会轻松很多。

你希望网站可以兼容未来的新设备

所谓的移动版本站点，通常是针对某类具体规格的设备进行单独打造的，弹性比较差。新的移动设备层出不穷，传统的移动版本站点需要不断的进行更新维护，才能尽量保证在新设备中工作良好。响应式设计可以根据设备浏览环境的具体规格进行判断，使用不同的呈现方式来展示内容，无需针对某种特定的规格进行维护，适应性更好。