Tag Archive for 'Giles Colborne'

Designing for delight

Designing for delight (Giles Colborne)

View more presentations from cxpartners.

简单的秘密

Giles Colborne在Usability Professionals’ Association Conference 2009上关于“The secrets of simplicity”的slide。举的例子:遥控器的精简设计,写的非常好。

BBC未来媒体技术创意总监访谈

【译者:耿人杰 原文:Interview with the BBC’s Future Media Technology Creative Director 作者:Giles Colborne

引言:移动设备界面设计是一个非常新颖的话题。在这一领域没有案例,更没有所谓的成功标准。通过了解国外领先媒体在未来媒体领域的发展,我们可以找到些努力的方向。另外,文章也搞所我们移动设备设计和web设计最本质的差别在于,前者有使用的情景,而后者的使用环境相对稳定。

———————————— 全文的分割线 —————————————

Jane Murison是英国广播公司(BBC)的未来媒体技术创意总监。她被任命来负责创建各类新兴终端的用户体验。我们谈到的是:什么让移动设备与众不同?以及它如何影响到需要创建一个新的用户界面设计和研究体系。

Giles Colborne:你在BBC扮演什么角色?

Jane Murison:我负责运营一揽子跨平台的项目,包括互动电视和移动设备。我们就像一个为BBC内部客户服务的代理机构。

GC:怎样才能创建一个好的移动设备界面?

JM:我所见过最好的手机网站是eBay,它提供了所有你认为重要的内容。在Web上你可以在各种地方加上你想要的链接,但在移动设备上这样行不通。

如果你问用户,他们总是说希望在移动设备界面能像大屏幕电脑一样能完成所有任务。但是如果真的将所有的东西都提供给他们,用户将发现它将变得很难使用。所以,你必须将Web上的内容进行浓缩,这很难!

GC:以用户为中心的设计[在设计过程中研究用户的想法]到底应扮演怎么的角色?

JM:如果产品设计的不合适那就是我的责任。我的工作就是确认UCD(以用户为中心的设计)流程工作正常,并确保在正确的时间点得到专家级的意见。如果你喜欢,以老的动态系统开发(DSDM)术语来说我就是主要的“用户提倡者”。

GC:你需要努力工作来使团队明白应该进行可用性研究吗?

JM:我是首席创意官,因此比较容易能说服团队以用户为中心进行设计。在过去的8年中,我每年要花1个月的时间去说服团队这么做。

有时我们不称它为“以用户为中心的设计”,我们会说这是“基于事实的设计”、“找出事实”或者是“用户反馈”。无论我们称它什么,只要我们的客户觉得合适就行。

移动设备界面设计的挑战

GC:移动设备界面设计需要一种新的用户研究方式吗?

JM:是的。BBC的移动设备界面设计经常是基于事件(event-based)的(如,围绕着体育赛事和音乐活动),所以如何在恰当的时间内结束研究,并把成果运用到项目中去,这不太容易办到。

对于移动设备来说,使用情景变得至关重要。将日常情景研究和实验室研究成果紧密结合通常很有效。通过研究日常情景,通常能获得更多关于用户的知识。

我们都知道实验室研究是荒诞的,它并不是自然状态下的结果,但是少你能坐在凳子上打开网站。而移动设备界面设计则完全不是你呆在一个房间中能够得到的。

GC:但你们仍然会做一些实验室研究,如何模拟移动设备使用过程中的那些不可预测环境?

JM:我们做了些特别的事情。在一次实验室测试过程中,我们让测试主持人在参与者用手机完成任务时给他们打电话。他们叫道:“等一下,我有个电话要接”,但等他们意识到正在发生什么时,都表现得相当惊讶。

一些移动设备在处理中断时表现的比较出色。但通常在这种情况下,你无法给用户很多帮助,因为这取决于他们用的是什么类型的移动设备。

GC:你领导着用户体验设计部门(UED),并和技术、产品和内部客户共同工作,如何使合作能够顺利进行?

JM:我认为多人一起对交付物进行决策比较好。最近一个项目中,相比以前围坐在电脑前,我们花费了很多时间在白板前一起筹划产品的设计。所以,在我们的合作中,不会出现一个人画,其余的人看的情况。

我们允许失败、鼓励尝试。在设计过程中,即使失败也可以微笑面对,并从中学到东西。

作为一个团队,经过失败应该变得更紧密,而不是分崩离析。

作为一个经理,你不得不注意你对团队的表达方式:“很好,这非常有效,因为我们已经开始有所收获。现在,让我们按照这个方向开始努力吧。

GC:你对移动设备界面设计有什么展望?

JM:开放标准。当标准统一后,移动设备网络将不必像当前网络那样:“当你访问内容时总是必须从别人的接口中取得。”而在当前,我们能做的是用户提供相对好一点的界面。

触摸游戏进行时

【译者:耿人杰 原文:Touch Screen Gaming 作者:Giles Colborne

同步发文于译言:http://article.yeeyan.org/view/gengrenjie/47191

引言:触摸屏应用如何进行交互设计是当前全球设计界都在关注的问题。提供多种方案可能是一种可以尝试的方式。此文对比了iPhone上吃豆人的两种触屏交互方式,给我们带来了些灵感。

———————————— 全文的分割线 —————————————

我们在今年已经看到太多有关多触摸感应界面的文章了(可能由于技术的越发成熟,也可能Nintendo DS和iPhone太成功了)。

到底什么原因导致触摸感应界面(touch screen interface)如此受欢迎呢?显然,更大的按键和更易点击的界面是原因之一,但完整的原因应包括更多而不仅仅是“玻璃后面的键盘”。

按钮 VS 手势

一个伟大的例子就是iPhone上南梦宫(Namco)出品的吃豆人游戏(Pac-Man)。它提供了两种触摸屏操纵的方式:一种不太好使,另一种接近完美(但有些小瑕疵)。

南梦宫提供的默认操作是经典的方式:你能使用四方向键来改变吃豆人的方向。但它的表现很差,因为触屏不能提供反馈,导致你不得不随时注意你的手指是否准确的按在了按钮上。这影响了游戏性,让你显得手忙脚乱。

Namco's Pacman with button controls

iPhone上的吃豆人:屏幕上的按钮很容易理解,但你不得不总是盯着屏幕来操作它。

这是通常将按键显示在触屏上进行操作的弊端,这种方式显得如此笨重。但Apple公司已经为此开发了一些软件来弥补这一弊端,诸如:预测校正(predictive correction)和随着点击而扩大的按钮。

南梦宫的另外一种可选的操作方式是在屏幕虚拟的遥感(joystick)上挥动你的手指。这种类型的“手势界面”对于在线游戏是一种更好的设计方式。挥动(Swiping)意味着你不必精确地点击那些微小的控制区域,所以你可以将你精力完全注意在游戏中。

Namco's PacMan with joystick control

在一个触摸屏上,通过挥动你的拇指来改变方向是对于此类应用更好的操纵方式

在实践中,南梦宫的执行方案仍然要求你在正确的区域挥动你的手指。有时你会误操作,导致游戏失败。

小变化,大变革

如果南梦宫能让你在屏幕的任何地方都能挥动手指操作吃豆人那游戏的体验将会更佳。当一个小的改变发生在用户界面设计时,经常会导致它的体验从令人沮丧变成完美无缺。

但千万不要认为手势界面总是比其他类型的界面表现的更好。它们只是在此类拟真类(immersive)应用中表现出色。

如果你正在设计一个手势界面,有一个建议总能帮到你,即:使用大而简单的手势,而非小且定向(targeted)的。

如何说服管理层进行可用性研究

【译者:耿人杰 原文:Justifying usability research 作者:Giles Colborne

同步发文于译言:http://article.yeeyan.org/view/gengrenjie/47164

引言:如何说服管理层进行可用性研究是任何一个UED团队都需要面对的问题。你必须以他们听的懂的理由说服他们进行这项投资,这不是件简单的事情。具体应该怎么做呢?这篇文章将给你点启示。

———————————— 全文的分割线 —————————————

客户经常让我给他们的管理层解释为什么我们要进行用户测试,为什么我们要花更多时间测试网站原型而不是已实现的网站。我认为有必要就这个问题分享一下我的观点。

为什么以用户为中心的设计是问题的解决方案

以用户为中心的设计(User centred design)值得投资有两个原因:首先,它能揭示用户使用网站的真实情况。其次,它能更早地抓住问题的核心。

IT项目失败通常是由于开发人员没有听用户的

之所以如此多的IT项目无法达到预期的成功,是因为开发团队没有考虑是否用户能很好的使用他们开发的系统。

项目组的成员有一种倾向,他们总假设他们的设计是易于使用的。这忽略了项目组通常是具有了解产品和行业背景的专家。

而以用户为中心的设计(User centred design)能够确保从一开始,真实的用户就能参与到设计的过程中,这使得传统的设计假设遭到质疑,从而有更好的设计能符合用户需求。

信任用户而不是专家

即使是专家级别的可用性评估的效果也低于真实用户的。可用性权威Jacob Nielsen估计到,一个外部的可用性专家通常只能识别约35%的可用性问题。更糟的是,专家评估的可用性问题通常并不准确。所以花在修改项目的时间可能是被浪费的。

相对的是,一个89人的用户小组通常能识别约95%的可用性问题。

换句话说,真实的用户测试比所谓专家(即使他是来自外部的)的判断效率更高。

更早地抓住问题的核心

随着项目的展开,解决问题的成本将不断升高。在项目开始时,往往是少数人参与具体的项目。到最后,参与人数将有所上升。这意味着通过达成共识来解决问题将变得相当困难,解决问题成本高昂。

Roger Pressman计算到如果在早期(在编写代码前)解决一个问题需要花1美元的话,在编程期间解决该问题需要花6.5美元,这是巨大的提升。如果等到编码在测试时再解决,通常要花15美元。如果等到第二版时再解决费用将变成60100美元。

这是对未能在早期识别问题的惩罚。更普遍的是,错误可能在离产品发布时间很短的某刻被提出。这意味着,一旦产品发布,软件通常表现低于预期,需要花费更高成本来弥补。

所以,在项目开始时花点时间来解决问题是明智的。

更重要的是,你了解的那些用户做和不做的行为将有助于你进行所有的设计决策。

这就是为什么我们推荐在网站进入开发进程前测试原型设计、已有网站,甚至是竞争对手的网站。