的结果。 做项目的时候,总要跟上级部门(或客户)反复进行交涉。 删去。进行讨论和讨价还价是一定存在的,不必问此项。 他们根本不懂用户体验。 上级或者客户不懂用户体验,但是喜欢乱提要求,我们常觉得很为难。 我不知道程序员开发软件时需要我提供什么东西。 从事用户研究和可用性测试的人不必和程序员有交涉。 我提交给其他部门的文档总是需要额外的解释。 我在为用户争取利益的时候总需要对其他部门进行很多解释。 部门内有项目管理混乱。 项目管理好坏对我的工作影响很大。 部门内有自己的一套工作流程。 部门内部有一套固定的工作流程。 做成项目就好,至于什么流程不重要。 我觉得工作流程是怎样的不重要,只要做好了项目既可。 我认为自己访谈和问卷问题设计得好。 我认为调查中设计的访谈提纲和问卷的品质很高。 有时我觉得自己在做市场调查而不是用户需求调查。 我做用户调查时,很多时候在套用市场调查的办法。 部门内没有详细的用户库。 部门内有一个详尽庞大的用户信息库。 只有对长期调查我们才建立用户库。 我们只储存那些长期调查的、重要的用户信息。 很多时候我们做调查,因为资源限制,不严格按抽样配比用户。 我们有时招募用户会忽略先前制定的比例。 我应付访谈和测试主持人没问题。 我主持访谈和挖掘用户需求的能力很棒。 大多数是定性分析。 对于数据分析,我们经常做定性分析。 很少做定量分析。 我们很少做定量数据分析。 有些结论分析缺乏数据支持。 我们有力的证据支持是:用户说...而不是数据统计分析。 报告撰写部门内有标准统一的模版。 删去这个问题,统一模版是必然的。加一个问题,平时报告中的结论分析占篇幅一半左右。 同类产品的研究会归类放置。 以前做过的同类项目的数据,在另外一个项目中,我会
查询翻看。 文档保存杂乱。 删去。对设计没有指导意义。 数据积累很有限。 部门内很注重数据的积累保存。 提高做项目的效率是我的迫切要求。 我认为现阶段应该先提高研究质量,而不是先考虑效率。 有时项目做坏是因为执行的人的水准问题。 项目执行人的水准对项目影响很大。 如果能减少对新员工的培训就好了。 新员工在上岗前需要经过一周以上的培训。 和其他部门的配合是默契的。 时常能听到部门内员工对客户或其他部门人员的抱怨。 员工跳槽、换人会让这个进行中的项目一塌糊涂。 项目人员应该从头到尾坚持做完项目,其中换人会严重影响项目质量。
1.2.3 交流效度
交流效度(Communication validity),是指你在调查过程中与被调查人之间的沟通程度[1]。问卷问题是不是被人所理解?他们理解的意思是不是问题要问的?本调查中,交流效度是依靠试调查来保证的。通过试调查,进行了如下交流效度的考虑。
1)本问卷需要被调查人如实反映所在公司、部门中的实际情况,这点如果不说清楚,被调查人会误解为表达他自己的期望或认识。例如,在试调查中,当问到"可用性测试是否在用ISO9241-11的三条标准"时,有人选择了十分不同意。当问到他所在部门是否还使用这三条标准做测试时,回答却是肯定的。这是由于没有向被调查人讲明要调查哪些内容。解决的办法是这样两点。第一,在问卷前加上说明。比如:请您根据您所在公司或部门的情况来打分。这句话还应该用粗体标注出来。第二,把问卷量表中的"同意、不同意"改成"与实际情况符合、不符合"。
2)被调查人是不是觉得问卷问题晦涩难懂?在试调查之后,可以询问被调查人的感想,比如,是否不理解题项的意思?题目是否太长?有没有歧义?有没有不好回答的题项?通过试调查,对以下题目做出了语言上的修改,如表 1-4所示