避免服务评估时的常见错误

本文摘自《Service Design: From Insight to Implementation》,作者Andrew Polaine, Lavrans Løvlie和Ben Reason,由江南大学设计学院研究生刘兆峰翻译。

测量体验持续时间

设计小组在评估服务体验时通常会犯的第一个错误就是只与客户或用户交流一次。然而,对他们的服务历程中的不同阶段进行评估用户体验是至关重要的。当用户接触到与曾经习惯使用一段时间的旧有服务相比全新的服务时,他们的理解和预期将非常不同的。

例如,当人们第一次被医院诊断出癌症住院时,他们缺乏能力去理解医生接二连三的治疗建议。(此时)患者仅能能够处理眼前的处境,他们问的最多的都是类似“我有生存机会有多少?”这样的问题。然而,经过三个月的化疗,患者可能有足够的能力来判断护士的注射剂量是否合适,能够充分理解医学术语,阅读同等学力的医学期刊文章。

评估内容是指服务在不同的阶段是否满足人们的期望。如果用户在初次使用时获得了极好的体验,那么它会在用户接下来的日常使用体验中辜负用户的预期吗?当用户具备使用一项易于上手的服务的能力的时候,使用过程能否给予用户更深入的体验?人们在什么时候考虑换掉他们原有的服务供应商?对他们来说抛弃这项服务到底有多困难?

要弄清楚这一点,你可以观察某一个人用户,去评估在在一段时期内的体验如何,也可以参与进几个用户的不同的体检阶段当中,以了解他们有哪些期望,过程中实现了哪些变化。大多数公司都希望能够同时获取和留住大量用户。评估服务流程中的各个阶段可以让他们在这两点上做的更好。收入的增加和利润提升则应遵循自然规律。

评估接触点

设计小组第二个易犯的常见错误是只了解使用单一服务渠道的用户。如果你需要了解某一个单一接触点的质量好坏的话,这种做法是没问题的(“你觉得我们的网站如何?”),但它不会给你的服务体验整体质量的提升提供任何有价值的数据。 继续阅读避免服务评估时的常见错误

服务体验原型

fengmian

本文摘自《Service Design: From Insight to Implementation》,作者:Andrew Polaine,Lavrans Løvlie,和Ben Reason,由江南大学设计学院研究生杨秋翻译,刘兆峰校正。

体验原型的四个层次

随着时间变迁,体验原型出现从临时应急到制作精细的阶段性变化。我们通常把这些不同的级别划分为四种类型的原型:低成本、半结构式的讨论,参与者的走查,更精细的模拟,以及全面的试点(图1)。通常,我们会将四种类型的元素进行混合来创建一个高水平的原型测试。当然,预算随着每个层次的细节增加而增加,所以你会发现每一个阶段的原型都需要满足客户可以停止进行下一个步骤的内容。

1

图1 体验原型的四个层次类型 

讨论

讨论原型非常类似于用户的洞察访谈,并且通常来说这是最实惠的选择。你可以在一个小时的访谈中带入一系列的接触点模型,并根据你所计划的用户旅程与他们展开讨论。 你所访谈的对象所扮演的角色就是他们自己、对接触点作出反应并提供反馈,就像真实的互动一样。

讨论的效果是解决服务定位中最显著的问题或难题,避免出现重大错误。一个典型的讨论原型包涵5至10位用户以及他们发表的见解,这将帮助改进你的设计。当在你试图找出服务的定位应该是什么的时候,它会是非常有帮助的。例如,你可以模拟不同的网站页面或创建各种营销材料,观察他们对不同的服务定位有何反应。他们也许会对价格、特定的服务单元或对定位不理解而作出反应。在理念建设的过程中,所有的这些投入都是有用的。 继续阅读服务体验原型

创建游戏场景

0

本文摘自《Game Design Essentials》第二章《游戏设计核心概念》中的一个章节,作者:Briar Lee Mitchell,由江南大学设计学院研究生刘兆峰翻译。

创建游戏场景

你已经写好了脚本,设计出了了不起的人物角色和道具,现在是需要建立舞台的时候了。游戏场景可以定义游戏本身视觉体验和感官效果,刺激玩家情绪,激励竞争,带来令人惊奇的体验。随着每一款游戏的诞生,设计师们也了解到,玩家希望得到更大更好的东西。换句话说,如果玩家在一款游戏中经历了一次美妙的体验,那么他们在下一次的游戏过程中就会希望体验得更多。游戏在很大程度上依赖于让玩家经历一次比一次更加写实的目标体验。

如果你试图为一个特定的用户市场设计一款游戏,那你应该多看看市场上已取得成功的游戏,学习他们的场景设计。

当设计二维游戏场景时,你要考虑将布局分成不同的前景、中景和背景元素是很有用的。这三个区域能够为你的场景带来一种纵深感。

继续阅读创建游戏场景

制定可用性测试计划(2)

本文摘自《Handbook of Usability Testing》,作者:Jeffrey Rubin和Dana Chisnell,由天翼阅读用户研究员张晓雯翻译。

列出任务清单

任务清单包含被试在测试中要完成的所有任务。清单包括在使用产品、文档等过程中进行的常规任务。

任务设计经历两个阶段。早期阶段,任务清单是为项目团队成员,而不是真实用户设计的。你只需要提供尽可能详实的细节,以便测试计划的审阅者可以评估是否任务是正确且可执行的。

然后,才是将任务扩展为丰富的任务场景脚本,供被试使用。场景脚本应该有现实细节和情境,帮助被试无需主持人的介入就能进行。

测试计划的任务组成部分

测试计划中的任务包括以下四个组成部分:

任务的简短介绍

此时不需要提供太多细节,用一行文字叙述,将任务与项目团队沟通清楚就好。

任务执行中需要的材料和设备

可用性测试中场景至关重要。如果产品处于早期设计阶段,你作为测试主持人,需要提供这些场景材料或是模拟器的当前状态。例如,你想测试一个还没有编码或制作高保真原型的网站,那你至少需要提供页面的线框图。又或者,电脑中的网页可单独操作,只是还没有被组合为完整的工作原型,你(或者是被试)需要按照恰当的时间顺序打开并浏览页面文件。

继续阅读制定可用性测试计划(2)

制定可用性测试计划(1)

usability

本文摘自《Handbook of Usability Testing》,作者:Jeffrey Rubin和Dana Chisnell,由天翼阅读用户研究员张晓雯翻译。

测试计划是整个可用性测试的基石。计划应当阐明如何测试,何时、何地,由谁来推动测试,为何测试以及测试内容。不过,有时在项目期限临近的巨大压力下,你可能不打算写一份详尽的测试计划。毕竟,你认为自己对即将进行的测试已了然于心,不必再花时间把它写下来。但是,这样不规范的做法显然是错的,最终不可避免地将带来麻烦。

为什么要制定测试计划?

合理的做法是:当你知道将要进行测试的那一刻起,就该着手准备测试计划了。之后随着项目推进,不断完善计划,收集反馈,如此往复。当然,灵活也是有限度的,你在测试前必须设定某个时间节点,确保在此之后,计划不会变动。同时,测试的产品在这个时间节点后,也不允许再有任何改动,直到测试结束。你可能已经发现测试计划是产品开发周期中唯一具有明确时间点的文档,因此格外重要。

当期限临近时,你要竭尽所能不要去变动将要进行测试的设计产品。额外改动会令之前制定的测试方案变得不再可靠,譬如需要研究的问题甚至是数据收集方法的信度都会受到影响。如果在计划的时间点之后被迫更改测试,那要确保每个人都了解此举带来的风险:测试可能是无效的,并且临近测试前改动的产品有可能无法正常使用。

下文列出了为何需要制定详实计划的原因,以及在开发团队中测试计划作为沟通工具的使用方法。

继续阅读制定可用性测试计划(1)