用户体验来源于深入实践

作为软件开发者来说，通常只会满足于功能的实现。而作为项目负责人，则还要关心做出来的系统用户使用时的体验如何？除了满足功能上的需求之外，操作起来是否简便，是否符合日常的操作习惯呢。

但在项目实施的过程中，软件开发人员通常并不与最终用户接触，当项目负责人分配完任务后，一般会根据以往的工作经验以及自己的理解，开始搭建心目中那个理想的软件房子。而所谓UI设计或美工，就好比是一名室内设计师，也只能按照现有的房屋结构实现优化，有些结构性设计自己并没有话语权，最多是反馈至项目负责人。项目负责人虽然总领整个项目，但架构的设计和代码的编写常常还得仰仗软件开发人员，因为他可能并不完全了解某种开发语言的细节，通常也只能根据自身的经验描述用户的需求和自己梦想中的样子。

最终的结果是，当我们把精心烹饪的软件大餐端到用户面前，满怀期待地准备迎接用户的赞不绝口时，没曾想收到的却是一份电子邮件，12345，罗列了一大堆需要改进或不符合要求的问题。这时，所有项目组成员的信心都会受到极大的打击，于是开始噩梦般的程序改造。

人们都喜欢一气呵成的感觉，就像几千前王羲之曲水流斛挥笔留下的兰亭集序。

然而现代工业不是艺术。

那么，我们怎么才能知道用户想要的到底是啥样的呢。

其实，很多时候用户自己也说不清楚想要什么，他们通常也是根据自己以往的使用经验提出自己的要求。比如，用户天天使用Excel，他就会要求报表做出像Excel一样的效果，Web程序员听到这里就傻掉了。

我觉得，想了解用户到底要什么，就要深入到用户的实践中去，把自己换位成会计、仓管员、开票员，亲身体会实际工作中的痛点，这时，不需要用户描述，用户不了解你的编程技术，不知道用啥技术能实现想要的结果，而程序员是最清楚的。不需要太长时间，可能一个小时就够了，安排软件开发者亲身体验一下用户的工作，有时会比开一天的会效果更好。

另外，这个过程最好安排在软件测试阶段。

为什么不放在需求分析时或者需求分析后呢？我认为，就像美食家一样，需要厨师把菜炒出来，才能给出评价和改进意见。当用户拿到测试版本，对软件操作是否达成自己的要求有个具体的认识，才能提出更真实的意见，开发者也能更方便的换位思考。有人会觉得，软件架构已成形，这个时候会不会晚了，万一发生变动成本太高。实践中确实有这种痛的领悟，但没有办法，软件开发是一件很特殊的工作，有时候只能自己推翻自己。微软、谷歌都无法避免，何况你我。

可能会受些舟车劳顿之苦，可能要在烈日下暴晒，但仅仅需要花费你一天或半天的时间，暂时离开空调房，效果一定是事半功倍的。

********

2015年6月6日