熟读理论的同学们都比较清楚用户体验(以下简称UE)的概念，不管是基础的架构设计，还是推进后的过程设计，UE都应该渗透到每一个环节中，有没有做是一回事，做没做好是另外一回事。

理想化的情况：

1. UCD是做产品的核心理念，适合团队内任何成员和职位，而不是UEer专有的。
2. UEer的主要工作，是从用户心理所反应出来的行为角度去分析产品。
3. UEer不仅要能提出问题，更重要的是给出切实可行的解决方案。

工作中的常见问题：

1. 需求讨论会上，因为功能的UE问题而发生方向性争执，常见于PM和UEer之间。

多半都是沟通不够充分造成的，只要双方都有足够的信任感和责任心，事情哪有做不好的。曾经有一次，我们相持到把技术总监召唤过来做裁判的地步，最后还是把应有的权力给争取了过来 :)

理想的设计师和项目经理

2. 流程有断层，很多UE方面的工作都已经被束缚到了条条框框内，设计师们不能放手去做。

也就是说上下游的关系没有处理好，每个层级内都是自己在做事情，没有照顾到整个大团队。这样的结局很可能就是互相鄙视，然后反复磨合沟通修改，直至消耗完整个项目周期。

UE设计师要在项目之初就参与进去

3. UEer要做的工作貌似很多，一篇评测可以包括视觉、代码、结构，甚至涉及架构。

凡事都有一个发展的阶段，但UEer肯定不是帮忙解决视觉(visual)、代码(code)问题的打手，这些都是视觉设计师和代码工程师的职责所在。

视觉设计师扛起UE大旗？

4. 对陈旧产品评测时，UEer把问题找出来了，方案也提出来了，结果发现执行不下去，比如当年数据库的结构问题、产品的架构问题……

这类问题经常暴露在进行产品整合时，有可能是规范不统一，也有可能是之前没有考虑周全。实在不便解决，那就只能等到更新版本了，这其实也是很多网站频繁改版的重要原因。

把UE设计放到底层逻辑架构设计的前面去做

除了以上推荐的一些文章，最近网络相关话题的讨论还有很多，我根据自己的理解，把UE定位在处理抽象逻辑的环节，也就是在给自己定位中所提的B层级。重新思考了一些观点，顺便造了个新词(UEer)，也算是对前段时间工作的总结。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号