【转载】同事对项目UI问题案例分析培训的总结

今早刚参加完部门特意给我们.net培训员工安排的《项目UI问题案例分析》，趁热打铁，写写自己这次交流会的总结。

首先非常感谢部门的这次交流会安排，也特别感谢Guang哥百忙之中抽空给我们准备案例并主持这次交流会！

案例分析交流会主要内容：

1. 表述UI设计所要遵循的原则
2. 具有UI问题的项目案例(UI失败案例) 演示
3. 讨论、分析、交流案例的UI问题所在
4. 强调UI设计所要遵循的原则
5. 修改UI问题后的项目案例演示

从UI问题案例中认识到的部分UI问题，具体从Guang哥演示的失败案例中，存在以下的问题：

1. 布局问题。很多同一页面的各个板块的衔接并不自然，有些是留有不必要的空袭，有些是留白太多！有些原本应该是边界底对齐的板块弄得参差不齐，UI感觉凌乱。
2. 显示问题。有些是必要的标注信息没有，其中的一个典型就是一个表格内容没有列标题，会让用户二仗和尚摸不着头脑。有些是必要的信息没显示全，再一个例子就是创建时间显示，只显示月日，找不到哪年。
3. 用户操作的体验性问题。虽然页面上该有的功能按钮都有了，但是摆放的位置不符合用户操作习惯，可能需要用户“寻寻觅觅”之后才能找到。操作按钮的位置随内容的改变而变化的问题也会让用户不知所措。
4. 挑战人们的常识性问题。明明就是一个列表的表项图标，并不具有其他任何功能，却把它设成一个“展开目录”样式的图标，按常识性认识来说，大家都会去点击尝试展开那项的内容，但实际上它啥功能都不具备！

对于上面总结的UI问题（其实还没总结完），我们可以看到，有些看上去都是很低级的问题，那为什么会出现呢？我觉得那是开发人员的习惯问题和态度问题。就如Guang哥所说，有些问题可能是开发人员开发的时候只注重功能的实现而忽略了UI上信息的完整性，而有些我觉得应该是开发人员的态度问题，缺少严谨，不对用户负责的态度！而有些纯粹是项目整体所存在的弊端。单元测试没有发现那些问题，可以说是程序员的问题，但在系统整合、测试上却没有发现问题，等到了客户那问题才呈现，那不得不说项目组的工作存在问题了。

所以我觉得，在我们以后的开发中，除了实现功能外，我们还应该关注我们呈现出来的UI的合理性、感官和客户的操作性。在我们自个做单元测试时，要把我们放在客户的角色上去使用自己开发的模块，从客户角度出发，查找自己的不足。当然有些UI问题是在系统整合之后才出现的，所以在整合后的系统测试时，也要应该关注UI的合理性、感官和客户的操作性。

 

对于UI失败案例项目，我交流会后就有了疑问，在系统整合后，是否进行过系统测试？Guang哥在会上说过这么一句话：对自己要严格！自己找自己麻烦，总比客户来找你麻烦好得多！那个项目在拿到客户那演示之前，有没自己亲自去使用过，尝试找过自己的麻烦？是不是项目组在开发产品的时候要对客户负责？

 

对Guang哥的话的感想：

1. “把意识转变为习惯”

当然，Guang哥说的意识指的是好意识！把意识转变成习惯，会让自身的工作效率得到一定程度的提高。在不知不觉中就已经考虑了UI问题，站在了客户的角度上去组织设计UI，那样也会在不知不觉中向客户交了一份满意的答卷！

2. “起始速度固然重要，但之后怎么去保持一个稳定的加速度更重要”

这个算是交流会上Guang哥的一句“题外”话，并不是完整准确版，但大体意思就是那样。这是他跟我们培训员工交流工作思想时做的比喻。这很大程度上很符合我个人的人生观，但比喻比较经典！一下子就记住了！人不管是在学习中，还是工作中，都要保持一个上进的心，充实自己，提升自己，让自己“保持一个稳定的加速度”不断超越自己！

 

听者有心——对C经理的一个纠正的感想。

交流会上，Guang哥在给我们阐述UI设计原则时，称我们为“学生”，C经理当时也在，他即刻纠正“是同事”。说者有心，听者也有心。

听者心之一：

我觉得C经理的这个纠正，对于我们这些应届培训生，是在强调着：我们已经是社会工作者，已经不是校园里的学生了！不管是我们自己，还是公司的其他员工，都要帮我们把以前所熟悉的校园环境通通刷掉，换成现在的工作环境！因为我们就在工作中。

听者心之二:

现在是以交流会的形式在学习，是跟同事一同探讨一同分析一同交流的方式学习，已经不是以前学校里的老师撒米，我们来嘬的方式了！所以我们应该主动，主动去阐述我们的观点，主动提出我们的疑问！

哈，就听出两个心！

以上就是我的一些总结。说是总结，不如说是随笔比较好点。