白鸦，以用户为中心的设计

回忆一下我之前经历过的两次自上而下推动过程,
希望不要对号入座，这些回忆只是我自己的经历 不代表什么观点.

03年和05年我分别经历了两次难忘的很有对比性和代表性极具教育性和参考性可以作为我正反面教材的UE人员在企业之中的“起义”过程（断句练习），他们一次是我在学习一次是我在操作、一次是成功的一次是失败的、一次是得到了领导层足够认可和支持一次是“自以为得到了领导层认可自以为他们会很支持”、…
　
　
那次“我在学习的成功的得到了领导层足够认可和支持的”：

据说03年在我们当时的那拨人之前，我所在的那个公司内部曾经有人做过UCD的工作，是在测试部门之下成立了一个产品可用性研究的小组。但后来有很多原因导致了那个部门的解散，听说是其中最主要的是高层领导把这个小组定义为了一个“研究小组”，他们认为“没有必要也暂时没有力量对这样的部门和这样的工作给予专门的精力投入”。他们的具体原因很多，比如：“这些人太学术了”或者觉得“这些细节的东西根本没有什么大的影响”、“现在产品的主要任务应该绝大部分在于功能的实现和架构的设计”等等…

03年初的时候由于产品在实际应用中的几个恶劣后果很明显的暴漏（特别是因为某次应该界面语言表达的不当，导致操作人员的一次勿操作，而让公司损失巨大），于是我当时的LEADER们得到机会再次把可用性作为一个话题很正式的提了出来，并把这样的错误很夸张的完全归结为产品可用性的问题，且不断的给领导层去解释和灌输。
于是可用性再次被提上日程。但在实施中还是苦难重重。后来他们给回忆说，刚开始他们经过了很多引导和说服，但依然没有能够得到同事们的充分支持，高层领导们也对这个事情没有太多的心思关注，因为他们实在还没有看到更多的好处和必要性，高层更不会浪费在办公室打高尔夫的时间去枯燥的听我的LEADER们给讲“可用性的重要和必要”..
起义的浪潮再次出现了停止…..

03年五月我所在那个公司的几个LEADER们通过和国外同行的接触和不断努力，借一次高层去国外公司访问考察的机会，让他们在考察的日程表中加入了一项对别人公司可用性相关成果的参观，并现场听取了别人可用性部门的介绍。
他们又在在回来后及时给高层们递交了成立UCD部门的想法，这个时候还算顺利的得到了高层们的安抚式答复：“既然别人这么做了，我们也应该可以去学习学习”
于是我和几个设计的同事开始得到了真正受顺和培养的机会，那样的一个小组再次成立。
在接下来的一个系统升级项目中（给现有系统添加两个新模块）我们是非常辛苦的，甚至有很多时候要在没人配合的情况下自己动手弄程序去修改和调整一些问题（我们我们几个都会写程序）。就算这样，在UE的角度来说我们最后看到的产品效果 依然连我们预期的70%都没能达到。。

很快系统升级完成，让我们有成就感的效果出现了：很多操作人员反馈“新添加的两个模块用起来很方便，工作效率提高了很多..”
每一次得到这样的反馈我们都在MSN上互相庆祝…
庆祝的同时我们并没有忘记把他们反馈的好处一一记录，然后再每次的产品理会上去不停的演示和讲述这些改进..

于此同时高层领导也发现：1、通过几个UCD人员的折腾 产品质量确实提高了，特别是操作员的效率提高了 ；2、这些人的成本还是蛮低的，工资也并不高也需要不了几个人；3、他们做起来也没有想象中那么麻烦和古板

抓住这样的机会我的LEADER们再次申请了请国外专家来公司培训的机会，
同时也得到了高层的支持，他们下达了四道命令：1、以后每个项目都尽量要有UE人员的参与；2、以后每个项目周期最好都要有专门的加入UCD的时间；3、开发人员和产品人员需要给予UCD人员充分的支持；4、可以适当扩展这个小组，甚至可以尝试成立一个这样的部门。
于是，真正的部门组建开始了，

有了馒头可吃，接下来我们的路虽然充满了曲折但并没有继续挨饿了…
当然这次自上而下的推动过程我在其中只是个学习者，在不久的05年我还经历过一次失败的推动过程…

　
　
　
　
那次“我在操作的失败的‘自以为得到了领导层认可自以为他们会很支持’的”：

当时我去那个公司可以说算是在该公司管理人员的“盛邀”之下过去的，因为有了他们的热情 我就默认了“这个公司的管理层还是很重视UCD的”..

于是在去那个公司之后我并没有过多的和领导层进行UCD概念的交流和灌输，也没有把“让他们重视UCD”提高到很深的高度。
我迫不及待的让自己进入了工作状态，给“界面设计”和“产品”的人员进行了不少基础的讲演，并不辞辛苦的给这些负责实际执行同事们不停的灌输这些概念。　（也就是在那个时候我认识了我的最铁支持者 臭鱼，）

事实上我的这个努力效果后来并没有白费，在接下来的工作中和我直接配合的设计部门人员都非常的支持我组建的"UE小组"工作,还有人主动要求要参与进来锻炼和学习。 甚至在后来出现问题时 产品人员也主动表示“支持我们的结果”。

但我当时万万没有预料到，最后出现了一些不好的效果时恰恰是因为上级部门的原因，在他们无法权衡的时候他们选择了“放弃一个自己还不是很了解的领域选择一个不会出太大问题的答案”。
那个时候我才真正明白“原来他们邀请每个人过去都是很盛情地，他的盛情邀请只是因为他觉得你的领域可能比较重要，但他并没有真正把你的重要性提升到一定的高度”。

通过那次经历我给自己这样的总结：
1、领导层的施压很重要，
2、执行部门的支持只是执行阶段的需要的工作，但领导层的支持可能是决定你是否出成绩的地方
3、我“如何做事”的能力还是非常不够，脑子太直很不好

　
　
UE在越来越多的产品中作用越来越明显（特别是互联网产品），UE成为产品核心竞争力一个组成部分的趋势越来越开始凸现，我相信以后要影响高层自上而下的推动这个行业并不会像以前那么艰难…　

回忆一下过去，不要对号入座,也只是回忆我自己的过去不代表什么观点…

———————————————————————————————–
　“UE在企业中”这个话题计划一共包括：“让同事支持你的工作”“自上而下的推动”、“先动起来”、“让别人看到你的成绩”、“如何（是否）外包你产品的UE”、“理想化发展路线”、“回头看看”…

分类：UCD ,06/05/27 11:33 下午 | 18,358 次浏览 |