在确定结构因素后,要把各个因素转化为具体调查内容和调查问题。内容效度(Content validity)关心的是,是否一个因素的内容都在测量中呈现出来[10]。本文主要从以下几个方面来考虑和保证内容效度。
1)这些因素可转换为哪些调查内容?每个因素对应的问题如表 1-2所示:
表 1-2 每个因素对应的具体问题
一级因素 二级因素 对应问题 理论发展 理论依据 认为可用性测试用ISO9241-11标准足够了。 自主研究 没有系统的归纳过一套可操作的理论方法用于用户研究或可用性测试。 部门或公司内部很少进行行业内的理论研究。 新的研究方法都是从别人那儿学来的。 数据资料 访谈提纲和问卷 我认为自己访谈和问卷问题设计得好。 有时我觉得自己在做市场调查而不是用户需求调查。 问卷调查结果 部门内有标准统一的模版。 用户模型 部门内有标准统一的模版。 可用性测试数据 部门内有标准统一的模版。 用户录音录像 我们长期保存用户的录音录像。 招募用户 部门内没有详细的用户库。 只有对长期调查我们才建立用户库。 很多时候我们做调查,因为资源限制,不严格按抽样配比用户。 项目数据 同类产品的研究会归类放置。 文档保存杂乱。 数据积累很有限。 执行水准 访谈和设计问卷的水平 用户研究常常和产品设计挂不上钩,设计还是得靠设计师的灵感。 访谈水平 我当访谈和测试的主持人没问题。 执行效率 提高做项目的效率是我的迫切要求。 部门协作 新员工培训成本 如果能减少对新员工的培训就好了。 交接任务 员工跳槽、换人会让这个进行中的项目一塌糊涂。 与其他部门协作 做项目的时候,总要跟上级部门(或客户)反复进行交涉。 他们外行人根本不懂用户体验。 我不知道程序员开发软件时需要我提供什么东西。 我提交给其他部门的文档总是需要额外的解释。 资源管理 项目计划与管理 部门内有项目计划与时刻表。 工作流程 部门内有自己的一套工作流程。 做成项目就好,至于什么流程不重要。
2)这些问题是否对被调查者产生诱导?在问题的陈述中,尽量避免直白的问:"你们部门是否存在着不注重数据积累的问题?"这类带有倾向性的问题,而是尽量使用陈述句,让被调查者根据所在部门的实际情况给与评测,看看是不是与实际情况符合。问题的问法修改如表 1-3所示:
表 1-3 修改前后问题对比
修改前的问题 修改后的问题 认为可用性测试用ISO9241-11标准足够了。 公司做可用性测试时,基本一直使用"有效、效率、满意度"这三条测试标准。 没有系统的归纳过一套可操作的理论方法用于用户研究或可用性测试。 部门内很少组织进行用户研究和可用性测试的理论方法研究。 部门或公司内部很少进行行业内的理论研究。 删去。和上一个问题重复。 新的研究方法都是从别人那儿学来的。 大家经常把外国出的新理论套用在实际项目上。 内心认为做出的东西没有表面上看起来那么有用。 有时我也不太清楚一份用户研究
报告怎么具体指导产品设计。 喜欢卖弄新名词。 多用一些名词术语能让别人觉得我更专业。 在做用户研究时,有时靠感觉,缺乏论据和数据支持。 我注重去"感觉"用户需求是什么,并不一定需要数据和论据。 别的部门的人很多不认可我们的工作。 有些产品经理和程序员不是很认可我们部门的工作。 报告里的数据实际上有水分。 在调查之前我们可能已经想好了结果。我认为很难避免这种主观倾向的干扰。 调查结果其实并不可信。 有时候客户会找好几家公司同时帮他们做同一个项目的用户研究,每份调查报告都只作为参考。 用户研究常常和产品设计挂不上钩,设计还是得靠设计师的灵感。 UI设计师觉得他们的设计方案实际并不取决于用户研究