某日，一同事埋怨，我们是做用户体验工作的，辛辛苦苦的做功能需求分析、用户信息调研、
做加法减法、业务流程优化，产出原型稿后，却经常遭到用户的挑战，死心塌地为他们做最
好的产品，最人性化的系统，却做的两边不讨好。对于这个问题不仅仅是我那位同事的苦恼，
也是我一直所迷惘的方面。今天就简单的聊聊用户体验这个部门的存在，是不是一个摆设，
如何实现它的价值。

首先我要提出的观点是，做

UE 的人员有两方面矛盾冲突点，一个是来自内部的压力，对

于做技术开发的同事来说，他们当然希望我们提出的交互性的需求越来越少，曾经在会上
一研发经理看着我们做的交互原型，不停地摇头说这个功能不能做，那个功能成本太高，
时间不允许，经过分析得知，研发做前端的人一般提出了几种技术解决方案，属于不同公
司和框架集，固定的控件，可扩展性差，所以他们被逼无奈只要在

UE 部门装载了 N 个技

术方案，让我们去选择，有合适的就用，最好在一套技术方案来用。所以经常性我们提出的
需求即使是很小的一个功能按钮要放在表格数据里面进行设置，对他们来说是很头疼的问
题。对于我们来说，简直是有点异想天开。其次就是第二个压力点，对功能需求团队来说，
他们前期只负责提出大概的功能文档和说明，经过我们初步框架设计出来之后发现很多衍
生的需求需要他们去挖掘和完善，当然对于技术那边也是一个压力点。所以尽管现实情况是
这样，我们还是坚持给用户最好的产品和易用性。可为什么我们面临需求团队、技术团队、目
标客户、都是让人讨厌的的对象。

目前的系统是一个用了很多年的老系统，原有的技术团队早已不复存在，系统庞大复杂、涉
及的业务模块错综复杂。可以肯定的说整个公司内部没有一个人能够对系统有全面的了解和
清晰的分析，更别谈用户体验方面了。所以这导致了，计划永远赶不上变化，需求反反复复
修改，需求做修改，那么接下来，原型框架、高保真原型、需求说明文档、用户调研方向和数
据都需要重新来过。所以自我总结出以下值得深思的问题和要点

1,怎样快速理解业务本身是干什么，只有先理解需求部门才能衍生新的功能需求,但现实问
题是即使养着我们一大帮人不做事全天学习业务和系统，保守估计最少得半年时间。
2,为什么需求总是在改，改完需求后，一动百动，最近我做页面原型已经头昏脑胀，上午
提出的修改需求还没改完，下午又有需求要求改，无非就是业务逻辑关系没搞清楚，当前
页面模块牵扯的数据范围和最终用户模块跳转整合的问题。所以需求那边是一边学习一边做，
无可否认，

UE 团队、研发团队目前走的都是这个模式。

3,用户体验价值何在？曾几何时我一度迷惘，整天忙碌修修改改连思考的时间都来不及，
这是很危险的事情，我们如果忙碌在这些工作当中，

UE 团队可以考虑不需要了。

4,我们提出的交互性的需求还是需要和技术部门需求部门继续商讨和想办法解决，当然不
能什么需求都召集大家开会，具体模块对应具体模块负责人，自己去沟通协调，尽量在不
增加其他部门的工作量情况下，提出合理性的需求，切忌不要天马行空。用户体验谁都会说，
但要做很难，深入的去做更难。
5,一定要保持客观的判断思维，你不代表用户，但你做的工作是为用户提供更快捷更友好
的系统，提高他们办公效率，所以最好不要说：

“我觉得用户走到这里，应该会…..”或者”

唉，没关系了，用户又不是笨蛋，怎么可能不知道这个功能按钮是干嘛的

“。

6,我们提出的想法和创意对应整个系统来说，没有对和错，也没有多么幼稚或者很牛 B，