UML软件工程组织

 

 

UEer的团队协作
 
2008-02-27 作者:千鸟 来源: UCDChina.com
 

熟读理论的同学们都比较清楚用户体验(以下简称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号