数据的规范化储存概念软件的毕业设计.doc

西安交通大学本科生毕业设计（论文）数据的规范化储存概念软件的毕业设计目 录前 言11.1课题来源与背景介绍11.1.1课题来源11.1.2UX Office软件简介11.2课题针对问题11.3主要工作内容2第1章调查的结构框架31.1专家访谈31.2效度分析31.2.1结构效度31.2.2内容效度41.2.3交流效度71.2.4分析效度81.3信度分析81.3.1通过试调查信度分析来修改问卷91.3.2验证正式问卷内部一致性12第2章数据分析与结果152.1样本比例152.2聚类分析162.3数据对比分析182.3.1中国企业与外国企业的用户体验部门对比192.3.2行内人员与行外人员看法对比222.4分析结果与讨论24第3章用户模型25第4章软件功能架构设计274.1原理274.2软件模块274.3各模块包含的数据参量284.4基本功能304.4.1数据查看304.4.2数据转化314.4.3数据导入和导出334.4.4数据计算364.4.5筛选374.4.6搜索374.5数据展示模式374.5.1查看模式374.5.2编辑模式37第5章结 论39致 谢40参考文献41附 录42附录一：调查问卷42附表二：UX Office测试记录表格44附表三：专家访谈提纲46附表四：四个企业用户体验部门的资料收集49附录五：英文文献翻译53英文原文53翻译译文63附录六：实习鉴定70II前 言1.1 课题来源与背景介绍1.1.1 课题来源本文作者从2008年3月1日到5月26日在北京伊飒尔界面设计有限公司实习，毕业设计项目来自用户体验解决方案部门的UX Office软件项目。UX Office项目由现任职于西门子用户界面设计中心的德国博士Helmut Degen于2006年提出的未成熟的新概念。北京伊飒尔界面设计有限公司对该软件进行实际探索性开发工作。该软件尚未发布。本论文作者于2007年底在产品设计课程设计中独立提出同样的产品新观念，本毕业设计项目是按照本文作者的独立思考进行的，其中有些设计思想超过了Helmut Degen，并没有从他处借用任何概念和设计思想。1.1.2 UX Office软件简介用户体验（user experience），通常被缩写为UX，它用来描述用户在使用某产品或系统时的用户需求（user need）。根据用户需求可以建立用户模型，从而指导产品的设计。UX Office，用户体验办公室，实际上只是可用性测试的软件平台。UX Office用它自身设计的一套工作流程来规范和帮助用户体验工作人员进行项目管理和可用性测试。1.2 课题针对问题目前国内企业的用户体验部门缺乏一套标准化工序，缺乏对可用性研究资料的规范化保存。以往项目中建立的访谈提纲、问卷、用户模型和可用性测试标准等文档，在新的同类项目中没能有效利用，而是需要员工在Word、Excel等软件里重新建立各种文档，并且这些文档没有统一的格式规范，实际上也不方便再次利用。这增加了员工重复性的手工劳动，也导致部门内缺乏规范化的数据资料积累，不利于部门水准的提高和新员工的培训。针对以上问题，本文提出一款应用软件概念，目的是帮助企业用户体验部门建立一个有关用户调查和可用性研究资料的规范化数据库，实现访谈数据、问卷数据、用户模型数据、可用性测试数据的量化、规范化、标准化，从而提高工作人员的工作效率和质量。1.3 主要工作内容本文工作内容有以下几方面。1）自主研究提出软件概念。2）第一章和第二章通过用户调查，得出影响企业设计过程的五个因素，并对比了国内外企业在这五个因素方面的差距。3）第三章建立了用户模型，描述了设计调查过程中哪些环节需要数据积累。4）第四章进行了软件功能架构，设计了软件的原理、基本功能模块、数据库和数据展示模式。第1章 调查的结构框架本调查的目的是了解国内企业的用户体验部门在设计调查过程中存在的问题，进而讨论本软件如何解决这些问题。1.1 专家访谈专家访谈的目的是为了建立全面真实的调查框架结构。调查专家级用户可以深入了解他们在设计调查中的工作流程和存在问题。本次访谈涉及产品经理1人、用户研究员4人。选择访谈这些人，是因为他们分别具备了以下几点特征。1）产品经理：是北京伊飒尔公司的用户体验解决方案部门经理，从2006年开始负责进行探索性开发UX Office项目，历时两年。了解软件概念、功能、开发过程和现阶段功能缺陷。有项目管理经验。掌握两年内的所有UX Office的开发文档。2）用户研究员：在企业（腾讯、百度、西门子、联想）有3年以上做用户研究、可用性测试项目的经验。他们所在的企业，正是本软件未来可能推广的对象。访谈提纲和结论见附录三、附录四。1.2 效度分析效度指两个方面含义。第一，调查是否真实，它的真实程度。第二，调查是否全面，它反映全面情况的程度1。效度分析阐述了本文如何考虑调查的全面性、真实性。1.2.1 结构效度结构效度（Construct validity），它是指采用的理论模型的框架结构能够真实全面描述调查对象的程度1。本文在设计因素框架时从以下两个方面考虑了结构效度。1）全面性。本软件是一个新概念产品，主要目的建立用户研究资料以及各种应用软件的可用性研究资料的规范化数据库。在设计软件功能架构时，作者需要了解企业在设计调查过程中还存在哪些问题？这些问题中还有哪些是可以通过本软件解决的？本文通过专家访谈以及作者实习时的见闻经验来保证因素的全面。2）真实性。请专家验证因素框架中的问题是不是当前企业在设计调查和可用性测试过程中切实存在的。2）通过聚类和信度分析改善因素框架。先进行试调查，小样本发放试调查问卷30份，对回收的数据进行聚类分析，观察与开始制定的因素框架有何区别，通过计算Cronbach 值、增减问题和来修改框架。本文最终确立的因素框架如表 11所示：表 11 因素框架一级因素二级因素因素说明理论发展理论依据采用的理论依据是否正确？自主研究部门内是否进行方法和理论的自主研究？数据资料访谈提纲和问卷是否建立了问卷库？问卷调查结果是否有统一格式保存？用户模型是否会建立用户模型？可用性测试数据是否有统一格式？用户录音录像是否需要保存录音录像？招募用户是否存在用户库？执行水准访谈和设计问卷的水平水平是否不均衡，项目质量是否因人而异？执行认真程度是否认真的完成工作？执行效率是否高效的完成工作？部门协作新员工培训成本是否和程序员和美工很好配合？交接任务能否保证项目质量？资源管理项目计划与管理是否能制定合理项目计划？工作流程是否存在统一的工作流程？1.2.2 内容效度在确定结构因素后，要把各个因素转化为具体调查内容和调查问题。内容效度（Content validity）关心的是，是否一个因素的内容都在测量中呈现出来10。本文主要从以下几个方面来考虑和保证内容效度。1）这些因素可转换为哪些调查内容？每个因素对应的问题如表 12所示：表 12 每个因素对应的具体问题一级因素二级因素对应问题理论发展理论依据认为可用性测试用ISO9241-11标准足够了。自主研究没有系统的归纳过一套可操作的理论方法用于用户研究或可用性测试。部门或公司内部很少进行行业内的理论研究。新的研究方法都是从别人那儿学来的。数据资料访谈提纲和问卷我认为自己访谈和问卷问题设计得好。有时我觉得自己在做市场调查而不是用户需求调查。问卷调查结果部门内有标准统一的模版。用户模型部门内有标准统一的模版。可用性测试数据部门内有标准统一的模版。用户录音录像我们长期保存用户的录音录像。招募用户部门内没有详细的用户库。只有对长期调查我们才建立用户库。很多时候我们做调查，因为资源限制，不严格按抽样配比用户。项目数据同类产品的研究会归类放置。文档保存杂乱。数据积累很有限。执行水准访谈和设计问卷的水平用户研究常常和产品设计挂不上钩，设计还是得靠设计师的灵感。访谈水平我当访谈和测试的主持人没问题。执行效率提高做项目的效率是我的迫切要求。部门协作新员工培训成本如果能减少对新员工的培训就好了。交接任务员工跳槽、换人会让这个进行中的项目一塌糊涂。与其他部门协作做项目的时候，总要跟上级部门（或客户）反复进行交涉。他们外行人根本不懂用户体验。我不知道程序员开发软件时需要我提供什么东西。我提交给其他部门的文档总是需要额外的解释。资源管理项目计划与管理部门内有项目计划与时刻表。工作流程部门内有自己的一套工作流程。做成项目就好，至于什么流程不重要。2）这些问题是否对被调查者产生诱导？在问题的陈述中，尽量避免直白的问：“你们部门是否存在着不注重数据积累的问题？”这类带有倾向性的问题，而是尽量使用陈述句，让被调查者根据所在部门的实际情况给与评测，看看是不是与实际情况符合。问题的问法修改如表 13所示：表 13 修改前后问题对比修改前的问题修改后的问题认为可用性测试用ISO9241-11标准足够了。公司做可用性测试时，基本一直使用“有效、效率、满意度”这三条测试标准。没有系统的归纳过一套可操作的理论方法用于用户研究或可用性测试。部门内很少组织进行用户研究和可用性测试的理论方法研究。部门或公司内部很少进行行业内的理论研究。删去。和上一个问题重复。新的研究方法都是从别人那儿学来的。大家经常把外国出的新理论套用在实际项目上。内心认为做出的东西没有表面上看起来那么有用。有时我也不太清楚一份用户研究报告怎么具体指导产品设计。喜欢卖弄新名词。多用一些名词术语能让别人觉得我更专业。在做用户研究时，有时靠感觉，缺乏论据和数据支持。我注重去“感觉”用户需求是什么，并不一定需要数据和论据。别的部门的人很多不认可我们的工作。有些产品经理和程序员不是很认可我们部门的工作。报告里的数据实际上有水分。在调查之前我们可能已经想好了结果。我认为很难避免这种主观倾向的干扰。调查结果其实并不可信。有时候客户会找好几家公司同时帮他们做同一个项目的用户研究，每份调查报告都只作为参考。用户研究常常和产品设计挂不上钩，设计还是得靠设计师的灵感。UI设计师觉得他们的设计方案实际并不取决于用户研究的结果。做项目的时候，总要跟上级部门（或客户）反复进行交涉。删去。进行讨论和讨价还价是一定存在的，不必问此项。他们根本不懂用户体验。上级或者客户不懂用户体验，但是喜欢乱提要求，我们常觉得很为难。我不知道程序员开发软件时需要我提供什么东西。从事用户研究和可用性测试的人不必和程序员有交涉。我提交给其他部门的文档总是需要额外的解释。我在为用户争取利益的时候总需要对其他部门进行很多解释。部门内有项目管理混乱。项目管理好坏对我的工作影响很大。部门内有自己的一套工作流程。部门内部有一套固定的工作流程。做成项目就好，至于什么流程不重要。我觉得工作流程是怎样的不重要，只要做好了项目既可。我认为自己访谈和问卷问题设计得好。我认为调查中设计的访谈提纲和问卷的品质很高。有时我觉得自己在做市场调查而不是用户需求调查。我做用户调查时，很多时候在套用市场调查的办法。部门内没有详细的用户库。部门内有一个详尽庞大的用户信息库。只有对长期调查我们才建立用户库。我们只储存那些长期调查的、重要的用户信息。很多时候我们做调查，因为资源限制，不严格按抽样配比用户。我们有时招募用户会忽略先前制定的比例。我应付访谈和测试主持人没问题。我主持访谈和挖掘用户需求的能力很棒。大多数是定性分析。对于数据分析，我们经常做定性分析。很少做定量分析。我们很少做定量数据分析。有些结论分析缺乏数据支持。我们有力的证据支持是：用户说而不是数据统计分析。报告撰写部门内有标准统一的模版。删去这个问题，统一模版是必然的。加一个问题，平时报告中的结论分析占篇幅一半左右。同类产品的研究会归类放置。以前做过的同类项目的数据，在另外一个项目中，我会查询翻看。文档保存杂乱。删去。对设计没有指导意义。数据积累很有限。部门内很注重数据的积累保存。提高做项目的效率是我的迫切要求。我认为现阶段应该先提高研究质量，而不是先考虑效率。有时项目做坏是因为执行的人的水准问题。项目执行人的水准对项目影响很大。如果能减少对新员工的培训就好了。新员工在上岗前需要经过一周以上的培训。和其他部门的配合是默契的。时常能听到部门内员工对客户或其他部门人员的抱怨。员工跳槽、换人会让这个进行中的项目一塌糊涂。项目人员应该从头到尾坚持做完项目，其中换人会严重影响项目质量。1.2.3 交流效度交流效度（Communication validity），是指你在调查过程中与被调查人之间的沟通程度1。问卷问题是不是被人所理解？他们理解的意思是不是问题要问的？本调查中，交流效度是依靠试调查来保证的。通过试调查，进行了如下交流效度的考虑。1）本问卷需要被调查人如实反映所在公司、部门中的实际情况，这点如果不说清楚，被调查人会误解为表达他自己的期望或认识。例如，在试调查中，当问到“可用性测试是否在用ISO9241-11的三条标准”时，有人选择了十分不同意。当问到他所在部门是否还使用这三条标准做测试时，回答却是肯定的。这是由于没有向被调查人讲明要调查哪些内容。解决的办法是这样两点。第一，在问卷前加上说明。比如：请您根据您所在公司或部门的情况来打分。这句话还应该用粗体标注出来。第二，把问卷量表中的“同意、不同意”改成“与实际情况符合、不符合”。2）被调查人是不是觉得问卷问题晦涩难懂？在试调查之后，可以询问被调查人的感想，比如，是否不理解题项的意思？题目是否太长？有没有歧义？有没有不好回答的题项？通过试调查，对以下题目做出了语言上的修改，如表 14所示：表 14 问题问法修改前后对比修改前修改后修改原因公司做可用性测试中，基本一直使用“有效、效率、满意度”这三条测试标准。可用性测试使用“有效、效率、满意度”这三条测试标准。原问题太长，增加被调查人的负担。部门内很少组织进行用户研究和可用性测试的理论方法研究。部门内很少组织可用性的理论方法研究。原问题太长，增加被调查人的负担。有时候客户会找几家公司同时做一个项目的用户研究，每份调查报告都只作为参考。有时候客户会找好几家公司同时帮他们做同一个项目的用户研究。原问题实际问了两个问题。以前做过的同类项目的数据，在另外一个项目中，我会查询翻看。以前做过的同类项目数据，在另外一个项目中会查询翻看。原问题拗口、不通顺。从事用户研究和可用性测试的人不必和程序员有交涉。从事用户研究和可用性测试的人很少和程序员有交涉。原问题有个人态度倾向性。在调查之前我们可能已经想好了结果。我认为很难避免这种主观倾向的干扰。在调查之前可能已经想好了结果。原问题实际问了两个问题。我认为调查中我设计的访谈提纲和问卷的品质很高。访谈提纲和问卷问题的品质很高。原问题有个人态度倾向性。这里希望了解整体水准。上级或者客户不懂用户体验，但是喜欢乱提要求。上级或者客户不懂用户体验，但是喜欢乱提要求，我们常觉得很为难。原问题实际问了两个问题。最后变成了主观描述。我们有力的证据支持是：用户说而不是数据分析。我们有力的证据支持是：用户说原问题实际问了两个问题。1.2.4 分析效度分析效度（Analysis validity）包含认知效度和分类效度。认知效度指对调查方法和试验方法的认识程度，你对调查数据的理解程度和分析概括程度。分类效度指从调查数据进行分类的有效程度1。本文就从这两个方面来分析调查的分析效度。首先，对认知效度的分析。对本次调查方法的分析有哪些？本调查的分析方法是对比分析，对比了中国企业与外国企业在用户调查与可用性测试过程中的差距。其次，对于分类效度，为了更客观的衡量用户体验部门的部门协作力，还把被调查者分为了行内人员与行外人员。1.3 信度分析信度（reliability）是指使用相同研究技术重复测量同一个对象时得到相同研究结果的可能性10。内部一致性（internal consistency），与一个量表中的题项的同质性有关。内部一致通常等价于克若恩巴齐（Cronbach,1951）的阿尔法系数，（Scale Development）。在试调查和调查过程中，本文在以下几个步骤中进行了信度分析：1.3.1 通过试调查信度分析来修改问卷对于30份试调查问卷数据，先进行聚类分析，剔除掉和所有问项相关度都很低的问题，然后进行内部一致性检验，用Cronbach 系数检验重新聚类后的各类的内部一致性。再逐条删减问题，发现假若删减一道问题，Cronbach 系数升高，则应从类里剔除这个问题。如果这道问题放在别的类里会升高Cronbach 系数的值，则可以考虑将它归到别的类里。聚类结果发现，聚成8类时，第四类和第七类都只包含一个问题，并且这个问题放在哪个类里都会降低其Cronbach 系数值，说明它和所有问项相关度都很低。应该予以删除。本次聚类使用SPSS16.0中Analyze菜单下的Heirarchical cluster功能，选用华生法（wards method），聚类树状图如所示：图 11 聚类树状图通过计算Cronbach 系数删减问题的结果如表 15所示，删减或转移问题的原因如表 16所示：表 15 内部一致性检验过程类和值序号问题处理之后值第一类0.749Q1公司做可用性测试时，基本一直使用“有效、效率、满意度”这三条测试标准。保留0.830Q9有时候客户会找好几家公司同时帮他们做同一个项目的用户研究，每份调查报告都只作为参考。保留Q12从事用户研究和可用性测试的人不必和程序员有交涉。删除Q16我觉得工作流程是怎样的不重要，只要做好了项目既可。保留Q18我做用户调查时，很多时候在套用市场调查的办法。保留Q20我们只储存那些长期调查的、重要的用户信息。删除Q24我们很少做定量数据分析。删除Q2部门内很少组织进行用户研究和可用性测试的理论方法研究。添加第二类0.784Q2部门内很少组织进行用户研究和可用性测试的理论方法研究。删除0.802Q8在调查之前我们可能已经想好了结果。我认为很难避免这种主观倾向的干扰。保留Q21我们有时招募用户会忽略先前制定的比例。保留Q25我们有力的证据支持是：用户说而不是数据统计分析。保留Q32时常能听到部门内员工对客户或其他部门人员的抱怨。保留第三类0.795Q4有时我也不太清楚一份用户研究报告怎么具体指导产品设计。保留0.828Q7有些产品经理和程序员不是很认可我们部门的工作。保留Q10UI设计师觉得他们的设计方案实际并不取决于用户研究的结果。保留Q11上级或者客户不懂用户体验，但是喜欢乱提要求，我们常觉得很为难。保留Q23对于数据分析，我们经常做定性分析。删除Q12从事用户研究和可用性测试的人不必和程序员有交涉。增加第四类Q29我认为现阶段应该先提高研究质量，而不是先考虑效率。删除第五类0.682Q3大家经常把外国出的新理论套用在实际项目上。保留0.687Q17我认为调查中设计的访谈提纲和问卷的品质很高。保留Q19部门内有一个详尽庞大的用户信息库。保留Q22我主持访谈和挖掘用户需求的能力很棒。保留Q20我们只储存那些长期调查的、重要的用户信息。添加第六类0.543Q5多用一些名词术语能让别人觉得我更专业。保留0.647Q6我注重去“感觉”用户需求是什么，并不一定需要数据和论据。保留Q26平时报告中的结论分析占篇幅一半左右。保留Q28部门内很注重数据的积累保存。保留第七类Q13我在为用户争取利益的时候总需要对其他部门进行很多解释。删除第八类0.647Q31新员工在上岗前需要经过一周以上的培训。保留0.624Q30项目执行人的水准对项目影响很大。保留Q27以前做过的同类项目的数据，在另外一个项目中，我会查询翻看。保留Q15部门内部有一套固定的工作流程。保留Q14项目管理好坏对我的工作影响很大。保留表 16 删减问题的原因序号问题处理原因Q12从事用户研究和可用性测试的人不必和程序员有交涉。和第一类不属于一类问题。放置在第三类中会使信度升高。观察后发现和第三类问题都属于协作方面。Q20我们只储存那些长期调查的、重要的用户信息。和第二类不属于一类问题。放置在第五类中会使信度升高。观察后发现和第五类都属于数据库问题。Q24我们很少做定量数据分析。无法从中得到设计信息。Q23对于数据分析，我们经常做定性分析。无法从中得到设计信息。Q29我认为现阶段应该先提高研究质量，而不是先考虑效率。单独聚为一类，和其他问项相关度都低。两重问题。也无法得出设计信息。Q13我在为用户争取利益的时候总需要对其他部门进行很多解释。单独聚为一类，和其他问项相关度都低。无法得出设计信息。问题模糊，没说清楚要解释什么。1.3.2 验证正式问卷内部一致性正式问卷共发放86份，回收有效数据72份。数据使用SPSS 16.0软件进行聚类。聚类后发现，第一、二、三类分别包含的题目数量只有1、2、1个，去掉这四个题之后，整体Cronbach 系数值由0.796升高为0.805，差值仅为0.009，说明这四个题和其它问题相关度都不高。聚类树状图如图 12所示：图 12 正式问卷数据聚类树状图剩下三个类包含的问题和每一类的内部一致性如表 17所示：表 17 验证正式问卷的内部一致性因素序号问题内部一致性检验部门协作Q5我做用户调查时，很多时候在套用市场调查的办法。Q6在调查之前我们可能已经想好了结果。我认为很难避免这种主观倾向的干扰。Q7我们有时招募用户会忽略先前制定的比例。Q8我们有力的证据支持是：用户说而不是数据统计分析。Q9时常能听到部门内员工对客户或其他部门人员的抱怨。Q10有时我也不太清楚一份用户研究报告怎么具体指导产品设计。Q11有些产品经理和程序员不是很认可我们部门的工作。Q12UI设计师觉得他们的设计方案实际并不取决于用户研究的结果。Q13上级或者客户不懂用户体验，但是喜欢乱提要求，我们常觉得很为难。Q14从事用户研究和可用性测试的人不必和程序员有交涉。数据积累Q15大家经常把外国出的新理论套用在实际项目上。Q16我认为调查中设计的访谈提纲和问卷的品质很高。Q17部门内有一个详尽庞大的用户信息库。Q18我主持访谈和挖掘用户需求的能力很棒。Q19我们只储存那些长期调查的、重要的用户信息。Q20多用一些名词术语能让别人觉得我更专业。Q21平时报告中的结论分析占篇幅一半左右。Q22部门内很注重数据的积累保存。资源管理Q23项目执行人的水准对项目影响很大。Q24以前做过的同类项目的数据，在另外一个项目中，我会查询翻看。Q25部门内部有一套固定的工作流程。Q26项目管理好坏对我的工作影响很大。如表所示，假若删去前三类，即1-4题。进行内部一致性检测后，Cronbach 系数分别为0.775、0.737、0.801。第2章 数据分析与结果本章通过对调查数据的聚类分析和对比分析，得出两个结论。第一，什么因素影响企业设计调查过程。第二，外国企业和中国企业的用户体验部门的差距何在。2.1 样本比例本次调查共发放两套问卷。第一套是发给用户体验行业工作人员的，第二套是发给程序员、美工、产品经理的。第一套问卷共发放86份，回收有效数据71份；第二套问卷共发放73份，回收有效数据57份。针对第一套问卷的调查样本比例，如表 21、表 22、表 23、表 24所示：表 21所属单位类型单位类型外企国企民营其他未填写人数2193650百分比29.6%12.7%50.7%7%0%表 22从事的项目类型项目类型手机互联网行业软件操作系统游戏软件其他未填写人数242191457百分比38.8%29.6%12.7%1.4%5.6%7.0%9.9%表 23职业状况职位类型用户研究交互设计可用性测试产品经理其他未填写人数231322841百分比32.4%18.3%31.0%11.3%5.6%1.4%表 24 工作年限工作时间1年以下1-3年4-5年5年以上未填写人数1550411百分比21.1%70.4%5.6%1.4%1.4%针对第二套问卷的调查样本比例，如表 25、表 26、表 27、表 28所示：表 25所属单位类型单位类型外企国企民营其他未填写人数12142470百分比21.1%24.6%42.112.3%0%表 26从事的项目类型项目类型手机互联网行业软件操作系统游戏软件其他未填写人数98247522百分比15.8%14.0542.1%12.358.8%3.5%3.5%表 27职业状况职位类型视觉设计产品经理程序员市场营销战略策划其他未填写人数515177256百分比8.8%26.3%29.8%12.3%3.5%8.8%10.5%表 28工作年限工作时间1年以下1-3年4-5年5年以上未填写人数2329320百分比40.4%50.9%5.3%3.5%0%2.2 聚类分析本文提出一项结论，即从五个方面可以评价一个用户体验部门或用户体验咨询公司的好坏，它们分别是理论发展、执行水准、部门协作、数据积累、资源管理。这个结论是通过聚类分析得到的。聚类分析是根据研究对象的相关程度，把相关程度比较强的对象归为一类1。本文所采用的聚类方法，是层级聚类（hierarchical clustering）方法。通过试调查，回收了31份有效数据。对这些数据进行聚类和信度分析，删减了一些降低Cronbach 系数值的问题，按聚类结果重新排布了题项顺序。将修改过后的问卷正式发放，回收72份有效数据。再进行聚类，聚类后对应的类和题项如所表 29示：表 29 聚类后的问题对应因素序号题项第一类Q1可用性测试使用“有效、效率、满意度”这三条测试标准。第二类Q2部门内很少组织可用性的理论方法研究。Q4工作流程不重要，只要做好了项目既可。第三类Q3有时候客户会找好几家公司同时帮他们做同一个项目的用户研究。第四类Q5我做用户调查时，很多时候在套用市场调查的办法。Q6在调查之前我们可能已经想好了结果。我认为很难避免这种主观倾向的干扰。Q7我们有时招募用户会忽略先前制定的比例。Q8我们有力的证据支持是：用户说而不是数据统计分析。Q9时常能听到部门内员工对客户或其他部门人员的抱怨。Q10有时我也不太清楚一份用户研究报告怎么具体指导产品设计。Q11有些产品经理和程序员不是很认可我们部门的工作。Q12UI设计师觉得他们的设计方案实际并不取决于用户研究的结果。Q13上级或者客户不懂用户体验，但是喜欢乱提要求，我们常觉得很为难。Q14从事用户研究和可用性测试的人不必和程序员有交涉。第五类Q15大家经常把外国出的新理论套用在实际项目上。Q16我认为调查中设计的访谈提纲和问卷的品质很高。Q17部门内有一个详尽庞大的用户信息库。Q18我主持访谈和挖掘用户需求的能力很棒。Q19我们只储存那些长期调查的、重要的用户信息。Q20多用一些名词术语能让别人觉得我更专业。Q21平时报告中的结论分析占篇幅一半左右。Q22部门内很注重数据的积累保存。第六类Q23项目执行人的水准对项目影响很大。Q24以前做过的同类项目的数据，在另外一个项目中，我会查询翻看。Q25部门内部有一套固定的工作流程。Q26项目管理好坏对我的工作影响很大。观察第四类，发现它包含的题项都是在描述用户体验工作人员如何执行项目以及如何与其他部门的人打交道。再对第四类进行一次聚类。这时发现，第6、8、11、12、13题是一类，它们描述的是部门间协作，第9、10、5、7、14题是一类，它们描述的是项目的执行过程。聚类结果如图 21所示：图 21 对第四类问题的再次聚类观察表 29 聚类后的问题对应中的第五类，它包含的题项都是在描述一个部门的各种数据积累，这些资料中，有的是用户库、问卷库，有的是结果数据。第六类描述了人力资源和项目管理对项目质量的影响。从上表可以看出，第一、二、三类总共只包含4个题项，第1、2、3题都是为了获取一个信息，那就是部门内是否存在着理论发展。但是为什么这3个题没有被聚为一类？因为他们的问法不得当。以上分析得出五个因素。这与调查开始制定的因素框架是基本相符合的，如图 22所示：图 22五因素数据积累资源管理部门协作理论发展执行水准 影响部门水准的六个因素2.3 数据对比分析本文从以下两个方面进行了数据对比分析。第一，中国企业和外国企业用户体验部门的差异。涉及到的中国企业包括伊飒尔（Isar）、唐硕（Tang）、百度（Baidu）、腾讯（Tencent）、联想（Lenovo）、用友（Ufida）、金蝶（Kingdee）、中国移动（CMCC）、中兴（ZTE）、亚太鸿远（HYT）等公司。涉及到的外国企业包括西门子（Siemens）、谷歌（Google）、微软（Microsoft）、思特沃克（Thoughtworks）、欧特克（Autodesk）、SAP、惠普（HP）、奥美（Ogilvy）。第二，对比用户体验行内人员和其他部门人员就同一问题的评价。用户体验的行内人员包括用户研究员（有的公司叫商业分析员）、可用性测试员、交互设计师、产品经理等。与用户体验行业有接触、合作的行外人员包括程序员、市场营销员、战略规划者、产品经理、视觉设计师等。2.3.1 中国企业与外国企业的用户体验部门对比1）中外企业是否都建立了详尽的用户信息库？52.4%的外企员工认为他们所在部门有比较详尽的用户信息库，而国内企业中只有28.9%的员工认为自己部门有详尽的用户信息库。这说明，做项目时，在用户招募的速度和质量方面，外国企业会胜过中国企业。笔者在北京伊飒尔公司实习之时，曾亲眼目睹公司不按用户配比，随意找熟人完成用户访谈的事实，访谈完成后，也并不将这些人的资料和联系方式进行长久保存。写在用户个人资料上的东西完全成了形式。这个事实反映了此公司用户库资源的匮乏及匮乏原因。直方图和数据如图 23所示：外国企业FrequencyPercentValid PercentCumulative PercentValid114.84.84.8229.59.514.33733.333.347.64838.138.185.75314.314.3100.0Total21100.0100.0中国企业FrequencyPercentValid PercentCumulative PercentValid11226.726.726.721124.424.451.13920.020.071.141022.222.293.3536.76.7100.0Total45100.0100.0图 23 直方图和数据2）中外企业在数据保存问题上是否有很大差异？有90.5%的外企员工认为部门内很注重数据的积累保存，相比中国企业只有60%的员工认为部门内很注重数据的积累保存，还有33.3%的中国企业员工认为部门不注重数据积累。数据积累保存在外国企业几乎形成了人人都有的观念，而中国企业不是。这一部分的直方图和数据如图 24所示：外国企业FrequencyPercentValid PercentCumulative PercentValid329.59.59.54838.138.147.651152.452.4100.0Total21100.0100.0中国企业FrequencyPercentValid PercentCumulative PercentValid1613.313.313.32920.020.033.3336.76.740.041431.131.171.151328.928.9100.0Total45100.0100.0图 24直方图和数据3）中外企业员工设计访谈提纲和问卷问题的能力是否有差异？47.6%的外企员工认为提纲和问卷的质量很高，对应国内企业员工只有24.4%的认为提纲和问卷问题的品质很高。外企员工有14.3%认为品质不高，国企员工有35.6%的认为品质不高。国内企业的用户体验部门有3/4的员工不敢说自己设计的提纲和问卷品质高，那就是说，大量的用户调查项目是不合格的。为什么品质不高？因为没有数据积累。上一次做的调查的过程、问题和结果没有规范化的保存下来，下一次做同类项目无法有效利用。这一部分的直方图和数据图如图 25所示：外国企业FrequencyPercentValid PercentCumulative PercentValid129.59.59.5214.84.814.33838.138.152.44838.138.190.552.59.5100.0Total21100.0100.0中国企业FrequencyPercentValid PercentCumulative PercentValid148.98.98.921226.726.735.631840.040.075.641022.222.297.8512.22.2100.0Total45100.0100.0图 25 直方图和数据4）中外企业员工主持访谈和挖掘用户需求的能力是否有很大差异？57.1%的外企员工认为自己主持访谈和挖掘用户需求的能力很强， 48.9%的中国企业员工认为自己主持访谈和挖掘用户需求的能力很强。这与上述的数据积累与理论研究两方面相比，外国企业和中国企业的员工差别不大。直方图和数据如图 26所示：外国企业FrequencyPercentValid PercentCuulative PercentValid229.59.59.53733.333.342.94523.823.866.75733.333.3100.0Total21100.0100.0中国企业FrequencyPercentValid PercentCumulative PercentValid148.98.98.92715.615.624.431226.726.751141840.040.091.1548.98.9100.0Total45100.0100.0图 26 直方图和数据5）中外企业是否都很注重项目管理？90.5%的外企员工认为部门的项目管理好坏对工作影响很大。中国企业员工有93.3%也具有同样看法。双方在此问题上不存在大的差异。直方图和数据如图 27所示：外国企业FrequencyPercentValid PercentCumulative PercentValid214.84.84.8314.84.89.54942.942.952.451047.647.6100.0Total21100.0100.0中国企业FrequencyPercentValid PercentCumulative PercentValid124.44.44.4312.22.26.741533.333.340.052760.060.0100.0Total45100.0100.0图 27 直方图和数据2.3.2 行内人员与行外人员看法对比这个对比是为了说明部门协作的问题，特别是外国企业和中国企业在部门间协作方面有无差异。1）产品经理和程序员是否认可用户体验部门的工作？从平均值看，中国企业用户体验部门的员工在其它部门是否认同自己这个问题上保持中立态度，但是中国企业行外人员给出的平均分却只有2.5，偏向于不认同。相比外国企业中，其它部门的员工是认同用户体验部门的工作的。这说明，在和程序员、视觉设计师等协作的过程中，中国企业的员工对自己乐观估计了。平均分如表 210所示：表 211行内外人员看法对比表问项内容：用户体验部门的工作是否被认可？外行：Q5我们不是很认可用户体验部门的工作。内行：Q11有些产品经理和程序员不是很认可我们的工作。外国企业中国企业行外行内行外行内2.08333.52382.50003.21742）设计方案是否并不来源于用户研究？在中国企业，用户体验部门自己持中立态度，而其它部门给出3.5分，稍高于用户体验部门自己的评分。平均分如表 212所示：表 212 行内外人员看法对比表问项内容：与交互、视觉设计师的合作外行：Q6具体软件的设计方案实际并不取决于用户研究的结果。内行：Q12UI设计师觉得设计方案实际并不取决于用户研究的结果。外国企业中国企业行外行内行外行内2.08332.85713.50003.08703）是否和程序员能很好合作？中国企业行内人员的评价为3.4分，但是中国企业其它部门人员给分只有2.6，认为他们不能跟程序员很好的合作。平均分如表 213所示：表 213 行内外人员看法对比表问项内容：与程序员的合作外行：Q7他们跟程序员能非常好的合作。内行：Q14从事用户研究和可用性测试的人经常与程序员合作。外国企业中国企业行外行内行外行内3.75003.33332.68423.45652.4 分析结果与讨论通过以上数据分析，本文得出了以下三个结论。1）通过聚类分析，验证了本调查的因素框架：数据积累、部门协作、资源管理、理论发展、执行水准。本文认为这些因素可以用来衡量一个用户体验部门的水准。2）通过数据对比分析，得出外国企业用户体验部门和中国企业用户体验部门的重要差距，那就是外国企业重视数据积累和部门协作。而在执行水准和资源管理方面，外国企业与中国企业没有明显差别。本软件需要帮助中国企业的用户体验部门建立一个关于用户调查和可用性研究资料的标准化数据库。3）通过数据对比分析，发现中国企业的用户体验部门协作力不佳，尤其是跟程序员合作不佳。可以建立一个规范化表格，