可能拥有一个外部资源的UX顾问对团队来说是个看起来很美好的事
不管你称UX为什么，UID或者UCD，它的初衷都是极为理想的——用“最好的”用户体验最大化“正确的”软件的使用价值。明显，“最好的”用户体验首先基于“正确的”软件，即一个被需要使用（体验）的软件才会被评判是不是拥有“最好的”体验。而我所观察到的UX的普遍问题就在于，在没有足够深度的分析这个软件是不是一个“需要的（Required）”之前就开始考虑它如何变得”可用的（Usable）“、“好用的（Useful）”、甚至“依赖的（Engaged）”。
问题的结症在于，体验设计师往往倾向于一种对解决方案偏执的一个团体，它们的设计思维已经演变成一种很自然地对各种交互模式的组装过程。当得到一个客户的需求，他们会不加思索的把这个需求翻译成一种用户体验的各种体验元素，然后根据这些元素寻找与之匹配的交互模式（Interaction Patterns）进行生硬的组装。
例如有这样一个需求：我希望能维护一个偌大的客户资料库，我可以建立不同级别客户的组织树，每个树上的节点都是一个客户，我希望我能编辑或查询每个节点上的各种信息。
经过经典的业务场景分析或者用户角色分析（Persona Analysis），诚然，我不认为这样的活动本质上能够左右后面的设计（大部分情况只是一种自证的过程），这样的需求语言很容易就被UX转化成各种体验元素：
- 树状结构；
- 节点可以搜索，快速定位；
- 节点可以增删改查；
- 节点信息可以增删改查；
- 节点信息少就用一个表单增改查，节点信息多就分多个表单到不同tab；
接下来这些体验元素就马上变成各种交互模式。如果UX稍微具有一点学习能力的化，他应该知道这个世界上有UI Pattern这种汇聚最新最眩交互模式范例的网站，在上面可以找到这些体验元素所对应的，被推荐的交互模式。这些交互模式的汇总就变成了Lo-fi或者Hi-fi的原型呈现在客户的眼前。而往往，其中的交互模式便揉杂了大量的设计师个人情感，而这样的私人偏好对于开放团队来说很多时候都是极为恐怖的风险。
经典的例子就是被TW内部津津乐道的"Marc's Heritage"。在一个我们以往的项目中，我们的UX在一个Windows应用程序中大胆的使用了圆角这一个在若干年前极为流行的，并被大量用户体验设计师喜爱的概念。如果是Web程序还好，可是当圆角碰上一个纯Windows程序时，在当年的技术环境下，这个概念被彻头彻尾地成为一场灾难——不论是性能还是各种分辨率的显示上，我们的开发团队耗费了大量的时间和精力，而客户一再强调这是必须有的特性，因为我们的用户体验设计师告诉我们这将极大地提高员工的视觉感受从而提高工作效率。
巧妙的伎俩就是和客户绑定。客户极为容易绑定，我也在咨询项目中见到客户公司的UCD部门类似“能不能实现不是我关心的事情，我要对客户负责，我要充分考虑客户真正使用时的感受进行设计”的豪言壮语。
能不能实现不是我关心的事情，我要对客户负责，我要充分考虑客户真正使用时的感受进行设计
听到这样的话，客户拒绝的可能性基本为0，因为客户只可能拒绝少给他或者不给他，对于多给的，一般客户没有任何理由拒绝。于是这个事情就变成，客户永远都不会拒绝UX某种喜好所转化的某个功能，而UX极易于和客户达成一种“爱的联盟”，UX富于煽情的表白足以让客户冲昏头脑认为，UX所做的一切都是为了自己能有个“好用的”工具，那么如果UX已经不站在开发团队这边，这样的联盟就使得开发团队几乎失去任何说不的机会。
发生这一切的原因只可能是UX不和团队在一起，UX不需要对交付负责。作为一个项目正式启动就的UX，极有可能把这个项目当成他个人喜好的验证场，加之极易和客户形成绑定，所有的开发风险留给了开发团队。
“把业务人员和开发人员弄到一起！”这样的怒吼其实也适应于UX，不跟开发团队在一起的UX自然不需要为交付负责。我在客户现场发现的案例是，因为UCD是独立的内部咨询部门，UX本身是独立于项目管理本身的，于是就出现了之前提到的言辞。而令人费解的是，UX本人实际上一直都会和团队在一起，但却不对交付负责，这样奇怪的组织结构导致我们的UX只在为客户说话。
从从业务角度出发，所谓的解决方案其实其实并不能称之为高质量，很多情况下我都认为这样的方案只是让客户因为过多关注了那些“好用（Useful）”的设计而忽略了大部分还没有达到“可用（Usable）”的缺陷——其实这样是很多UX使用的策略，或者根本不能称之为一种策略，而是一种无心的过失——企图用一种闪烁着，“看起来很美好”的东西使那些不足够挑剔的客户放弃深究那些他们应该更加关注的地方。而风险在于。这些“看起来很美好”的东西最终都会转化成开发风险转嫁于交付团队，而因为不为交付团队负责，又极易于与客户产生绑定关系，这种风险又被上升到一种不可规避或极难弱化的程度。
回到UX的初衷——用“最好的”用户体验最大化“正确的”软件的使用价值。在敏捷“适可而止”的语境里，这个初衷也许应该被重新审视为“用'适可而止'的用户体验最大化‘正确的’软件”。先保证所有设计达到“可用的”的质量级别，再通过对“正确的”软件持续不断的反馈和改进，根绝实际选择制造业务价值最大的功能将“可用的”升级为“好用的”。事实上很多“可用的”功能最后也会成为低频操作，那么对其进行“好用的”用户体验提升在某种情况下被认为是一种价值浪费。
UX在敏捷当中也应该符合敏捷的节奏，永远不做最美的事情，只保持一种较为平均的体验质量要求，专注于把“适可而止”的交互体验附加在“适可而止”的功能（符合业务需要的）上。当然，这一切都有一个关键的前提，UX，请为交付负责。