你是一位交互设计师吗？
告诉我，你具体做些什么？
我是做网站设计的？听起来不够专业。
我是做网页设计的，听起来……
你们是做界面的……
恩，好吧，我勉强接受，但是还是会很不死心补充一句：其实我们不只做界面，我们还规划使用流程，研究用户为了达到目标所要完成的任务，简化任务……听不懂？好吧，whatever！
交互设计就像他们主要的产出物之一――线框图一样，很多时候沦落到中间产物，处在尴尬的境地。
前面如果有优秀的产品经理，并且精力旺盛，有时就会一并连交互的工作做掉了。
后面如果有优秀的视觉设计师，并且精力旺盛，接到交互设计师交付给他的一堆简陋的线框图，反而不知道怎么下手，而且，他会很抗议自己成为了一个油漆工，不知道在这个线框的基础上“什么是可为，什么是不可为”，我们会经常看到一些“明知不可为而为之”的视觉设计师在交付了视觉稿后，遭遇到交互设计师的诘问：这个结构你不能根据视觉来调整，这个会改变我之前定义的用户引导方式，这个是之前确认过的！
一. 快乐并痛苦着交互设计师
合作伙伴的痛苦：
很多时候，产品经理在放手后觉得很痛苦：唉，他到底理解清楚没有我的商业意图？我不放心，我觉得事情不可控……很多时候，视觉设计师在接手后觉得很痛苦：唉，前期的需求和业务讨论，我压根就没参加，这一堆东西，我看不明白，但是还是得一页页去美化，而且我还得把工作成果交给他验收……更多有关的人觉得很痛苦，流程长，分工细，到了开发的时候，遇到了问题，还得先找交互，通过交互去找前端工程师，解决问题。交互设计师们的痛苦：
花了很多精力做了很多中间产物，一般这些中间产物瞬间就会被替代掉，到了项目发布，那些就已经被遗忘了。
花了很多精力去做协调和沟通，自然而然成为UED三个角色的小PM.
商业BRD写好了，要去和产品经理讨论业务需求并且坚守用户体验防线。线框做好了，要和一群人去讲设计需求，要撰写文档。视觉稿好了，要提防人家不小心改变了线框框架。文案和HTML做好了，又要去验收HTML有无按照设计需求执行，开发完成了，还得去像测试人员一样投入去测试bugs。发布后，还要持续进行效果的跟踪。这些，工作很多时候看起来劳而无功。
但是交互最痛苦的，不是这些。
交互痛苦的事情之一，说服基本靠YY。
这段时间做封闭做项目，从一进到项目室，就有明确的时间点和计划，来不及系统化思考，投入去做。遇到一些引发争议的问题，去和产品经理们谈，发现，我们的讨论慢慢地演变成为故事PK赛。大家举个各种场景的故事去试图说服对方。比如，我说，如果我是用户，我怎么怎么地。他说：我不那么看，如果我是用户，我怎么怎么地。
所谓的PK就成为了谁反应快，能够抓住对方的漏洞，谁的口才好，搞得对方无从辩驳，谁就赢了。
其实，事后反思，我们的persona去哪儿了？怎么都成了讲极端非典型场景非典型需求用户的例子了？
我们的以用户为中心的高尚理论去哪里了？怎么都成为以自己为中心了？
事实就是这样：
我们没有足够的时间去为每一个项目建立一个persona。
以前建立的persona不是适合所有项目。
我们一般没有足够的时间在开始做方案前引入用户研究。
所以，我们在PK的时候，有时不得不靠举例子，讲故事。可能，交互设计师一个很重要的素质就是要“很诚信地讲更加可信的故事”。不靠YY,靠一些观察，数据，案例分析，在讨论的时候，很自然用用户的场景去描述设计，用户来到这里，他带着什么样的需求，在遭遇到这种提示后，他会有什么样的反应……他的这种反应会导致他接下来怎么去做……要尽量像用户灵魂附体一样去讲。我见过一位优秀的设计师，在讲用户的使用场景时，我虽然整个场景是他自己YY出来的，但是他的抓狂的动作、痛苦的表情，让人“感同身受”――到了这份上，想要PK产品经理，想要说服谁，一般都成功了。
当然，作为一名交互设计师，我觉得PK成功，心里不一定有胜利的喜悦。因为，有可能需求方让步不是因为真的被故事打动，而是时间因素，觉得没有必要在这种“细节上”花太多时间。
交互痛苦的事情之二，时刻在反思：我做得对吗？这真的是对的吗
PK赢了，可是扪心自问：我做的方案真的是对的吗？用户真的这样想的吗？他们真的是这样用的吗？
也许我们心里都会有点虚。
事实上，设计以后也需要不断根据用户测试、数据情况不断迭代。
曾经有产品经理当时和我聊天时，就聊到一件往事，他说：当初设计师发动了好几个设计师过来和我讨论那个方案，他们坚持要做成那样，我争论不过，就按照他们的方案做了。结果数据效果不好，被重新换回来了……
二.交互设计师的专业性体现：
既然大家都痛苦，为何还会有交互设计师？为何不干脆去掉这个职位？
其实上，昨天才听老大讲，确实会有这个考虑，以后就没所谓的交互设计师和视觉设计师了，我们都要双栖，变成“产品设计师”。
与此同时，产品经理（产品规划师）还是会继续存在（暂且不讨论这两者之间的关系）。
我理解的产品设计师，是能力更加全面的交互设计师。他的责任更加大，到了产品的层面而不再是一个流程中的中间角色。他的能力要求更高，也许连视觉都一起做掉了，精简了流程。
所以被叫成什么不重要，只要我们做的核心事情不会改变，对我们能力的要求也不会有太大的改变，只会增加，不会减少。借用大名鼎鼎的冰山模型来套一下，我心目中的交互设计师的冰山模型。具体的技能与知识都不在这里细化，在家里自己做了一张思维导图，如果一个个细化，扩展起来非常吓人。
交互设计之父Alan cooper有以下让很多交互设计师扬眉吐气的话：
但是有趣的是，在交互设计领域，国外的专家人物没有这个老头子岁数长，也大部分处在35岁到50多岁之间，而国内目前活跃着的甚至顶着专家头衔的，大部分都是在30岁以下。
这说明即使交互设计被交互设计之父定义为“非常复杂，非常困难”，比写代码更加“需要老练”，但是国内的现实情况是，对交互设计师的门槛并不高。这大概是因为我们大部分人都处在“能做/会做”的阶段。
能做是什么呢？给个任务，能够在规定的时间按照一般性的要求做完。比较简单，懂点基础知识，掌握点基本技能，就可以了。
做好就属于“部分超出期望”，在完成任务的基础上，要更多地体现你背后的设计思路，要系统化地思考。即使没有人要求你，你也需要自己多出不同版本的方案进行筛选……到了卓越的层次，对你的要求更加高，更多的体现在前瞻性的规划和创造力的方案上，你可能不需要做具体的任务，但是你需要去带动别人成长，影响合作伙伴，影响需求方……
我们很多人其实都还停留在第二个阶段，所以我们需要去研究交付物的专业化，研究更高效的工具，这当然是重要的一方面，那是职业的象征。我是比较反对做为一名交互设计师，连自己的交付物交付出去，让合作伙伴必须要打多个电话才能搞清楚如何去使用的。但是这肯定不是核心竞争力，而是基础。
三.交互设计师的核心竞争力
核心竞争力是别人无法模仿，无法快速学到的能力。
核心竞争力是一种综合技能，是别人看不到的能力，但是实际上极大影响你最后的结果。
核心竞争力是这个职位存在的必要性的体现，也是能够保证我们从“能做”到“做好”，到“追求卓越”（卓越很难达到，但是不能不追求）。
1. 感知/挖掘需求的能力
需求为王。谁更加能够感知用户需求，谁就能够讲出更加靠谱的可信的故事，谁就有说服力。谁能够会更加站在商业需求的高度，站在战略的高度，谁就能够更加容易与商业方进行沟通，谁就更加容易赢得他们的信任，让他们更加放心把东西交给你做而不是由于不放心而指指点点。谁能够挖掘到更深更潜在的需求，谁就更加有可能超出期望，做出开拓性的前瞻性的设计。谁能够用用户的需求说话，谁就更加对自己的设计方案有信心，才会更加坚定去推进。如何做呢？（其实我不喜欢写建议，因为很多时候我自己也做不到）
尽可能找机会让自己和用户接触，并且记下他们对你的产品的任何一句反馈和建议，日后一定用得到。有机会参与用户访谈时，尽可能让客户讲自己的故事（而不是急于验证你的产品，这样你才会知道真实的用户是什么样，他们的使用场景是什么）多多利用公司已有的调研材料和结果，尽可能多收集，想办法利用。提高自己的数据分析能力――很多时候我们都以为数据分析就是看什么时候数据上升了什么时候下降了，其实最重要的是从这些现象里挖掘出深层次的原因来。多用自己的产品，模拟用户去用。
2. 给出创造性的解决方案能力
但是你要比他们更加容易把拿到的调研结果，转化为清晰的用户需求，进而是解决方案。
解决方案，产品经理也能出。
视觉设计师也能出。事实上，任何人都能出。
但是做为交互设计师，你的要求是：尽可能有创造力。
尝鲜是设计师的本能。但是很多时候我都要检讨，我已经习惯性就对浮出框点关闭，直到有一天团队新来的一位设计师在我旁边看我直接看都不看点击了关闭后，他说：我觉得你应该去试试，说不定对我们有启发。
设计都是相通的。
之所以暗淡无光，其一可能是因为第一点，业务不熟悉，对网站特定的用户缺乏了解。其二，不知道要找那些关键的人，不知道怎么去讲自己的设计，不知道如何推动。
酒香也怕巷子深，在一个大公司里，噪声太多，干扰不少，大家的精力非常分散，你作为交互设计师，需要在一个短时间里找到合适的人，集中他们的精力，消除他们的矛盾（需求的矛盾），让他们对你的方案达成共识，需要宣讲的能力，需要解决混乱场面的能力，需要会议组织能力。
在项目的推动过程中，你有时还必须要知道什么时候该找什么样的人来帮助你拿到结果。找对你，让你事半功倍。
有次，一位很优秀的产品经理和我分享他的经历，他说在他来公司的前三个月，就学会了一项核心技能：找人。知道遇到什么问题，该找什么人。有时找不对，就要绕很大的圈，还不一定能够解决问题，时间就白白浪费了。