写 人数 5 15 17 7 2 5 6 百分比 8.8% 26.3% 29.8% 12.3% 3.5% 8.8% 10.5%
表 2-8工作年限
工作时间 1年以下 1-3年 4-5年 5年以上 未填写 人数 23 29 3 2 0 百分比 40.4% 50.9% 5.3% 3.5% 0%
2.2 聚类分析
本文提出一项结论,即从五个方面可以评价一个用户体验部门或用户体验咨询公司的好坏,它们分别是理论发展、执行水准、部门协作、数据积累、资源管理。这个结论是通过聚类分析得到的。
聚类分析是根据研究对象的相关程度,把相关程度比较强的对象归为一类[1]。本文所采用的聚类方法,是层级聚类(hierarchical clustering)方法。
通过试调查,回收了31份有效数据。对这些数据进行聚类和信度分析,删减了一些降低Cronbach α系数值的问题,按聚类结果重新排布了题项顺序。将修改过后的问卷正式发放,回收72份有效数据。再进行聚类,聚类后对应的类和题项如所表 2-9示:
表 2-9 聚类后的问题对应
因素 序号 题项 第一类 Q1 可用性测试使用"有效、效率、满意度"这三条测试标准。 第二类 Q2 部门内很少组织可用性的理论方法研究。 Q4 工作流程不重要,只要做好了项目既可。 第三类 Q3 有时候客户会找好几家公司同时帮他们做同一个项目的用户研究。 第四类 Q5 我做用户调查时,很多时候在套用市场调查的办法。 Q6 在调查之前我们可能已经想好了结果。我认为很难避免这种主观倾向的干扰。 Q7 我们有时招募用户会忽略先前制定的比例。 Q8 我们有力的证据支持是:用户说...而不是数据统计分析。 Q9 时常能听到部门内员工对客户或其他部门人员的抱怨。 Q10 有时我也不太清楚一份用户研究报告怎么具体指导产品设计。 Q11 有些产品经理和程序员不是很认可我们部门的工作。 Q12 UI设计师觉得他们的设计方案实际并不取决于用户研究的结果。 Q13 上级或者客户不懂用户体验,但是喜欢乱提要求,我们常觉得很为难。 Q14 从事用户研究和可用性测试的人不必和程序员有交涉。 第五类 Q15 大家经常把外国出的新理论套用在实际项目上。 Q16 我认为调查中设计的访谈提纲和问卷的品质很高。 Q17 部门内有一个详尽庞大的用户信息库。 Q18 我主持访谈和挖掘用户需求的能力很棒。 Q19 我们只储存那些长期调查的、重要的用户信息。 Q20 多用一些名词术语能让别人觉得我更专业。 Q21 平时报告中的结论分析占篇幅一半左右。 Q22 部门内很注重数据的积累保存。 第六类 Q23 项目执行人的水准对项目影响很大。 Q24 以前做过的同类项目的数据,在另外一个项目中,我会查询翻看。 Q25 部门内部有一套固定的工作流程。 Q26 项目管理好坏对我的工作影响很大。
观察第四类,发现它包含的题项都是在描述用户体验工作人员如何执行项目以及如何与其他部门的人打交道。再对第四类进行一次聚类。这时发现,第6、8、11、12、13题是一类,它们描述的是部门间协作,第9、10、5、7、14题是一类,它们描述的是项目的执行过程。聚类结果如图 2-1所示:
图 2-1 对第四类问题的再次聚类
观察表 2-9 聚类后的问题对应中的第五类,它包含的题项都是在描述一个部门的各种数据积累,这些资料中,有的是用户库、问卷库,有的是结果数据。
第六类描述了人力资源和项目管理对项目质量的影响。
从上表可以看出,第一、二、三类总共只包含4个题项,第1、2、3题都是为了获取一个信息,那就是部门内是否存在着理论发展。但是为什么这3个题没有被聚为一类?因为他们的问法不得当。
以上分析得出五个因素。这与调查开始制定的因素框架是基本相符合的,如图 2-2所示:
图 2-2 影响部门水准的六