在2011年10月，我曾经相继写了两篇关于交互设计的文章，到现在已经有两年了。而在期间，有不少新的想法在伴随着我的工作、交流涌现了出来，再加上几周前，我在新的团队又进行了一次分享，因此颇有点心得，于是在此再分享一些经验。
不过这是个人经验，眼界还是有限，欢迎大家拍砖。
一. 再谈术语
当有人在关注技术和功能的时候——我想应该还会记得满屏在bling bling闪烁的各种网页吗?网页设计师是比较畅销和通用，但是在后来，当焦点需要外观的时候，就涌现出了大量的“美工”。在这时，没有UCD的指导思想，而更多的是TCD(以技术为中心)，或者是BCD(猜是什么?哈哈，就是以老板为中心)。
当在UI年代引入User概念，同时也催生了大量的UI设计师和各种UI论坛，而此时的指导思想正在从BCD转向UCD。最后产生UCD指导思想，于是也诞生了UCD指导思想下的一系列组织、工作方法、工具。
让我们感谢促成这一切的国外先驱们和国内先驱们吧。
二. 交互设计师的重要交付物
在过去的经验里，有三个交付物最为常用。
1. 行为路径——有时叫做页面流程图(Page Flow)，关注任务流和页面流设计，让用户流转顺利，提升任务完成效率。
2. 信息架构——有时叫做站点地图(Site Map)，关注内容结构、导航系统设计，让用户方便找到所需信息。一般来讲，内容为主的网站比较重视信息架构设计。
3. 单页面交互设计——一般用线框图、原型图来称呼这部分交付物，但有时也不局限于什么形式，关注单页面信息布局、内容优先级及交互细节。
三. 核心竞争力?
以前写过一篇《交互设计师的核心竞争力》，回头去看确实有些不够精练了。
有人又问我，Heidi你觉得做好交互需要哪些素质和技能?我想了一下，似乎可以用四个关键词来表达。
表现在外，你可能会一些工具和方法，如AXURE，如卡片分类，如可用性测试，如角色模型建设……或者精通各种理论。但是在这些之下，我们需要在四个方面有意识提升自己。
1. 同理心：以用户为中心，站在用户立场上思考，喊起来很容易但是做起来很难，有时候我们不得不就站在自己的立场上。同理心是比较强大的武器，让你任何时侯够能够设身处地去考虑用户的感受、习惯和可能会犯的错误。要训练同理心，从你发出的每一封邮件开始，写作之时发送之前，模拟一下你的读者是怎么阅读这封邮件的?你打算让他们先看哪里?注意到哪里?做什么动作?给你什么回应，然后模拟下他们看到邮件后会不会如你所愿。代替用户去思考是很难的，我们自然无法做到完全像他们一样，但是至少我们得有这个意识。
不得不说，这点上，女人们占据点优势。
2. 好奇心：喜欢尝鲜吗?喜欢第一时间升级吗?喜欢探索新鲜好玩的交互吗?无疑的，交互是提供各种需求的解决方案，你面对的需求可能很变态，但是大部分需求或许都是已有成熟的解决方案的。你很多时候做的就是迅速想起来一些模版，然后在此基础上做更多优化。而不是任何时候都重新设计轮子。脑子里存储尽可能多的模版，是需要长期积累但是终会见效的工作。这不是不让你创新，而是更高效率的创新。
不得不说，这点上，男人们占据点优势。
3. 系统化：很多职业和工种都需要系统化思考。交互尤其需要。交互的工作训练我几年，以至于带着交互的背景去做别的任何工种，会让我感觉更加得心应手。@夏目V说得好，一般看交互设计师看两点，一个是解决复杂问题的能力，能够在各种限制条件下给出优雅的解决方案，一个是上下协作沟通能力。这两点确实很重要。在2008年刚入职阿里时，我也写过一篇文章《交互设计师如何拿到结果?》文中提到，设计的任务是在种种限制下，寻求解决问题、满足期望或需求，并且技术上可行，投入产出比又较高的最佳解决方案。绝对不能够单纯从某个很炫的交互效果，极佳的用户体验单维度进行思考。《设计心理学3》主要的话题是设计要会管理复杂，设计面对着复杂，输入复杂，但是要输出简单易用的东西，这之间需要强大的转换器。
系统化是什么？
整体而非局部，相关而非孤立——能够看到需求的相关性需求，有可能把需求分析没——不需要做，也有可能把需求分析得很大——发现了很多相关性的需求，从而一起解决，而不是头疼医头。还是那句话：every thing is connected。
本质而非表面——看到需求背后的需求，多问几个为什么，为要这个?没有的话你们怎么做?有了之后呢?拿他去做什么?
交互设计师在进入设计和细节之前，一定要给自己留点时间去想想这个事情，“让我想一下”，想一下商业需求的背后，想一下竞争对手做了啥，多想几个解决方案……
4. 说服力：
很悲剧的就是，很多时候无法用数据去量化交互价值。数字虽然会骗人，但是我们需要它。它客观，毋庸置疑，看似公正。很难想出别的材料去取代数字。但是交互的价值就是这样，你有时真的是会找不到一个不受其他因素干扰的数据指标去证明你做对了(但是，如果别人想找一个指标证明你做错了往往又很容易……唉)。同一个指标会受到大量其他因素干扰，同期发布的功能，市场的促销活动，客服的工作……等等。
曾经我改了很难改动的首页一角，观测转化率数据，发现上升了几个百分点，喜报邮件还没有来得及发，第二天却又发现下跌了……然后几天后又上升了……是好是坏?不知道。如果要定性调研，问几个人，都反馈好的。但是要定量数据?那要看我选取的是上升的时间段还是下降的时间段了。
但是交互设计师必须要有说服力，你必须要让PD或者其他资源投入方认可你的方案，尤其是改善型的需求，或者是需要投入很多资源的需求。
图形化、专业交付物、讲故事都似乎是经过验证的有效手段。
我有时会很早就让需求方、其他人一起参与，看似最后的方案是大家一起得到的，反正达到目的就可以了。
四. 瓶颈?
恩，前不久和一些朋友们聊天，觉得开发、PD和交互是一个很有趣的怪圈。通常而言(不代表绝对哦)：
开发看不起PD：因为PD除了有想法，写点文档，看起来啥都不会，而通常开发们自己就很有想法……
PD看不起UED：因为他们通常会觉得UED太事儿妈，事儿太多，考虑得太细，他们根本就不明白这个东西对公司到底有多么重要……
UED和开发惺惺相惜，他们相互崇拜，对于开发来讲，UED做的东西很帅，而他们攻城师就缺会把东西做好看的人。UED很崇拜技术，他们做的任何效果，都需要开发攻城师神奇般地实现。
UED通常自怨自艾，UED通常也看不起PD……因为有时他们会觉得PD过于商业化，没有信仰，有时他们觉得PD们都在做执行工作，规划不都是老板们拍出来的吗?
PD有时认为自己完全不能理解UED和开发攻城师的脑子结构是怎么长的。
当然，大部份配对都是很和谐的……
不管如何，PD看不起UED的原因，我们是要认同的。
除了商业意识没有跟得上外，交互也会面临其他的瓶颈，如价值量化和说服力问题、技术发展及眼界问题(像我，一段时间不在交互圈里混，一旦失去警惕，就会发现技术已经日新月异，目前移动客户端的交互、响应式设计已经把我抛到后面了)，如果作为交互不持续学习及更新，很快你会发现你能够想出来的解决方案，技术GG们早就知道了，他们甚至比你更能够提供更好的解决方案。
要从会做到做好，进而要做卓越，继续追逐专业路线的话，必须要克服这几个瓶颈。
当然，还有其他路线可以选择，比如走管理路线。。
另外一条路，则是带着交互的技能去做别的。
交互不是岗位而是技能，这是我的观点。如上图，PD分成功能型PD和业务PD，业务PD要对业务负责，要规划具体的业务，业务有可能是做运营活动，也有可能需要市场活动，或者新建团队，或者规划一个具体的系统，涵盖的任务会更为宽广。 而功能型PD则为功能、产品负责，范围相对业务PD狭义很多。通常我们说的PD是属于功能型的?假设如此，PD往前再走一步，可以做业务PD，再多走一步，则完全做业务方。
难怪有人说，PD是为了培养成为业务Leader的。
而PD往后走则可以做产品设计，前提是若对交互有兴趣并且能够承接进来。
而同样的，交互若往前走，也可以做产品设计师(既做PD也做设计)，也可以做PD(只做PD，不做设计)。
我的经验证明，一边写PRD，一边画原型，绝对效率比写好PRD交给别人去做原型或者一边和别人讨论PK一边等一边写PRD效率要高太多。
走的过程自然有磨合，有不适应，也有更多要学习的东西，但是也绝对有新的体验和上升空间。