东莞广之旅莞城营业部:让UCD成为职业习惯

众所周知，UCD（ISO 13407）是一种用来提升产品可用性的有力方法，其以用户为中心的价值观念和增量反复的行为方式有效地拉近了设计者同用户之间的距离，强调了对用户的尊重，极大地支持了设计目标和商业价值的实现。

然而，UCD的作用还可以更大。恰当地使用UCD来规划工作，可以有效提高工作效率，改善人际关系。

最近正在阶段性工作总结，以下算是一点点心得体会。

常见的现象

1）执行不力

我们常说，方式反映目的。如果工作在执行过程中困难重重，感觉与一线执行人员的沟通存在障碍，甚至工作遭到抵触，那么多半是因为工作的方式存在问题。为什么那么有价值的工作会得不到理解和执行呢？请思考以下几个问题：

• 你的目标是什么，和执行人员的目标有何不同？
• 你选择执行的方式，例如沟通方式，推动方式等，是否有利于协作方双赢或者多嬴？
• 你的方式是否让对方感到了尊重（情感、时间、工作方式……）？
• 你的方式是否有利于构筑持续稳定的互信（工作不止一次，合作还要继续）？

如果我们不了解执行人员的目标，未发掘对方的潜在期望，就不可能选择出恰当的沟通、执行方式；反过来说，不恰当的方式将妨碍正常的沟通交流，妨碍信任的建立，进而阻碍工作的正常开展。

2）信任危机

如果合作双方的信任出了问题，很少会有人当面为你指出，你只会感觉到不断受阻，甚至举步为艰。

信任不仅仅来自良好的执行结果，更多地来自你职业的思维、行为方式。如果设计中含有明显的错误或者缺陷，设计多次变更带来工作上的反复，设计的表达方式影响沟通和理解，……那么不可避免地，我们的工作能力即将遭到置疑。信任危机的存在将成为合作过程的暗伤，时刻影响工作推动，而且暗伤一旦产生，要治愈会相当困难。

因此，大家最好避免所制定的guideline中存在矛盾、模糊不清、重复定义的地方，最好让你的设计有继承性而不总是重复劳动。

3）结果难以预测

当过程不可控的时候，结果就变得难以预测。之所以难以预测，是因为我们并不知道哪里会出什么问题，更不用说如何避免了。因此，我一直相信好的过程能产生好的结果。

问题症结

思考过上文的几个问题，结合UCD的观念，便可以大概知道问题的症结所在。或许出乎你意料之外，以UCD为基本设计思路的我们，竟然也多多少少会犯违背“以用户为本”的原则——一定程度上，我们自觉不自觉地选择了简单粗暴的工作方式、沟通交流方式。

显然，作为可用性工作者，并且处在整个工作流程前端的我们有时忘记了我们的工作不是发号施令，是协作。

尝试在工作中运用UCD

请允许我套用UCD的讲法，将与我们协作的人称作“用户”——原本他们就是我们所输出的信息、文本、设计的用户。

1）替“用户”着想：和用户研究一样，我们必须了解与我们协作的人/部门的基本情况，然后才谈得上制定策略使我们输出的信息能被顺利而高效地接收。这些基本情况包括职责范围、开发工作量、工作方式、沟通方式等，显然，如果你有多个协作的部门，那么你就有了多个典型用户。只有在了解这些情况的前提下，你才不会想要给不同部门制定同样一份长达几十页的规范细则，才不会重复向不同的人解释同一个问题。或许，你觉得这样做不如“一刀切”来得简单，那最好你准备好了足够多的耐心去倾听抱怨！：）

2）挖掘用户期待：交互设计中，如果你满足了用户潜在的期待，用户的满意度将得到极大的提升，工作当中一样如此。如果你讨厌为界面上大量的冗余信息付出时间和精力，那么你就应该把不适用的规范条目从规范中删除，以尊重和节省程序员的时间。同时，这是你职业素质的体现，不是吗？

3）让方式利于目标实现：我的经验表明，很多阻力来源于不恰当的处理方式。例如，原本你是打算说服程序员做某项修改的，结果由于用词不当或者语气不妥，让对方感觉到了不舒服，那结果可想而知；原本你期望需求人员能够详细了财务部分的设计，但是却采用了糟糕的表达方式，反而造成了解偏差，有时对方不得不动用“猜测”；原本你期望程序员A阅读财务部分的设计，但你却把设计隐藏在众多设计中却没有提供方便的检索方式……采用积极的沟通态度，适当地倾听，清晰地表达等都利于提高效率和目标实现。此外，你一定体验过良好的工作方式所带来的激情和团队凝聚力！

4）同“用户”确认：就象UCD中的用户测试一样，你必须了解你输出的作品是完整的，是对方想要的。这件事我们必须首先去做，否则“用户”是不会主动找你的。你自己可以制定一条衡量工作成果的标准：“用户”的认知是唯一的评估标准。也许这多少也需要点反复，但不会象用户测试那样频繁吧。

5）（等待你的补充……）

UCD从目标确立到方式方法的选择无不体现出对用户的尊重和对过程的控制，对于这些思想和方法的实践将有助于我们做好其它设计之外的工作。

很多同行可能并不为工作方式而头疼，那可能是因为所在的公司拥有完善的岗位定义、工作流程和规范的工作文档，而这些做法很大程度上考虑了本文所说的问题。如果你的公司还没有完备的流程，如果你正在尝试类似XP（极限编程）的方法，不妨尝试一下在协作过程中使用UCD的思想和本文所述的方法。