1 前言
一直想一个吸引眼球的副标题,最后还是觉得书名上的这个副标题,最能体现这本书的核心。
这是一本入门书籍,所以非常适合我这种交互的初学者。这本书给我的最大启发,就是发现测试的重要性,之前重点一直关注上设计的理论和技巧上,而验证设计这个重要的过程没怎么关注。这可能也跟我所在的公司环境有,公司从制造行业发展而来,在软件开发过程中能引入UI/UX设计,在领导看来已经算难能可贵了吧(现状是几个项目共用一个UI,UI兼任UE)。
虽然公司一直喊着以客户为中心,但UE设计人员短缺,更别提对设计的可用性测试,通常对发出的设计稿就是小组内部评审下。如果按照书中的分类应该属于用户可用性成熟度模型(作者根据经验设定的一种类似于CMM的模型)中的摇篮期
设计流程大致分成三部分调研、设计和测试。
3 调研(用户访谈的技巧)
用户访谈的技巧2.1 传统访谈方式的局限
反馈意见。反馈意见经常用户的建议和行为并不一致,比如用户说“我觉得习惯了的话还是很好用的”,但事实上要真的习惯这个产品,用户可能要话费很大精力。
假如用户真的可以想出很实用的点子,并且愿意无偿提供给企业的话,那么专业的设计团队还有存在的必要吗?
小组访谈(焦点小组)参与人数比较多,每个人发言时间有限,收集来的多是意见、体验比较少;发言时容易被别人的观点影响;因为是在众人面前发言者,发言者难免会对发言内容进行加工和润色。
一对一访谈。无论是计划好的问题,还是开放的问题。用户的一般的回答也是归纳过的,缺乏细节。
2.2 师徒式访谈
师徒式访谈(contextual inquiry),也译作背景调查法,现场调查法。它的基本基本步骤是:请教 -> 刨根问底 -> 核实
请教。访谈暖场后,慢慢将话题移到需要的主题,进而引出深入的交谈。
刨根问底。跟传统访谈的目的是获取信息不同, 师徒式访谈更重视完全理解用户所讲的内容。
核实。大致理解后,把理解的内容复述给用户进行核对。
访谈结束后将记录内容整理成情景剧本。访谈的记录无论是语音还是文字,缺乏使用背景,对于用户发言,分析时可能会有不同的理解。而是用情景剧本将用户发言内容用故事的方式来记录,则会更严谨,便于理解。一般地,情景剧本包括:
- 用户的个人信息
- 使用产品的背景
- 使用场景
3 原型(原型制作的要点)
原型制作的要点3.1不要忘记做的假页面。
在制作界面时确保错有的菜单都能点击,让用户在测试的时候更加自然、流畅。一个简单的方法是,无需测试的功能就统一跳转到一个界面,显示“目前该页面不可用,请返回上一页”。
3.2 元素的保真度区分对待。
原型中的内容,如网站中的新闻、产品列表;操作中的提示框等。而另一些元素如果跟实际开发的相差很远,用户使用原型时将无法得到设计人员想要的结论。这些元素包括:
- 界面顺序、数量
- 界面元素的位置
- 链接和按钮上的文字
- 界面上的提示性文字
- 输入项和格式
- 操作相关的图标
3.3 制作原型所需的技能
绝大部分的原型不需要高深的艺术素养或专业的程序开发技能,更需要的是深入理解用户需求,分析测试所需的逻辑能力,不局限于已有概念的发散思维能力。
不需要区分岗位,或是需要一个人同时具备这些技能。开发团队可以一起讨论好细节,然后由界面设计人员或是开发人员制作具体的原型。
4 测试(用户测试的方法)
用户测试4.1 用户测试
用户测试是一种典型的实验型产品可用性评价,它是一系列用户参与评估的方法的总称,这些方法包括:
4.1.1 用户测试
发声思考法(Talk Alound Method)。用户一边说出心里想的内容一边操作,有助于弄清楚为什么会导致用户操作出现问题的原因。在用户发言和操作的同时,注意一下三点:
- 用户能否独立完成任务(有效性)
- 用户在使用过程汇总,是否做了无效操作或是不知所措的情况(效率)
- 用户是否有不满的情绪(满意度)
4.1.2 回顾法
回顾法(Retrospective Method)。用户操作后回答问题,补充想要了解的用户信息,这样可以避免打断用户的操作。但回顾法缺点比较明显,如复杂的操作很难回顾;用户一般在回顾时会自行总结,遗漏很多细节;比较耗时等。正因如此,一般较少使用回顾法。
4.1.3 性能测试
发声思考法和回顾法都属于定性分析,如果需要定量分析,则可以进行性能测试(Performance Measurement)。
前两种方法一般是一对一,但性能测试参与人数较多,一般采用集体测试的方式。测试场所用隔板简单划分后,每次510人进行测试,每12人配一个监督者(可以让兼职大学生担任),参与测试者需要20以上。
测试主要对产品三要素(有效性、效率、满意度),定量体现在:
- 有效性可以用任务完成率来表示
- 效率可以用任务完成时间来表示
-
满意度可以用主观评价来表示,一般用调查表的形式
性能测试缺点很明显,一是时间、金钱成本太高;二是设计团队无法从测试结果中,找到用户不能完成任务的原因。
4.2 DIY用户测试
随着敏捷开发的迅速普及,正规用户测试的时间、金钱的成本难以承受。但绝不能因此而放弃测试,在保证测试环节下,进行简化的DIY测试也能达到预期的效果。
正规用户测试 | DIY用户测试 | |
---|---|---|
选择的主体 | 专业的顾问 | 你和同事 |
参与者 | 调查公司的注册会员 | 朋友的朋友的朋友 …… |
活动地点 | 带有单向可视玻璃的专业实验室 | 会议室或者其他可利用的空间 |
成果 | 内容丰富的报告(带动画) | 像笔记一样的报告和对话 |
其他 | 参与调查会提供高档工作餐 | 咖啡畅饮 |
网友评论