penddy对《交互设计之路》的笔记(10)

交互设计之路
  • 书名: 交互设计之路
  • 作者: 库帕
  • 副标题: 让高科技产品回归人性(第二版)
  • 页数: 230
  • 出版社: 电子工业出版社
  • 出版年: 2006-3
  • 第22页
    我相信在因特网上可以销售任何东西并获利和成功。实现的秘笈就是在线商店必须比传统商店提供更令购物者满意的可衡量的服务,价格只是满意内容的很小一部分
    2011-02-10 16:05:18 2人喜欢 回应
  • 第88页
    据我个人的观察,我总结出4条程序员与普通人不同的基本思维和行为方式:程序员牺牲简单而获得控制权;程序员牺牲成功换取理解;程序员只关注可能性,不管概率;程序员行为就像体育生。
    2011-07-04 15:16:24 4人喜欢 2回应
  • 第118页
    让人们喜爱你的产品,即使只是少部分人,这就是成功之道。
    目标用户越多,偏移目标的可能性就越大。如果想得到50%的产品满意度,你就不能让一大批人中的50%对产品满意来达到这个目标,只能通过分离出这50%的人,让他们100%满意来做到。可以再进一步,瞄准10%的市场,让他们成为产品的狂热追随者,你能获得更大的成功。这似乎有悖常理,但是只为一个人设计是让大众满意的最有效方法。
    2011-02-12 10:36:12 回应
  • 第122页
    作为设计工具,让角色精确比让角色正确更为重要。就是说,详尽而具体地定义角色比让角色非常正确更为重要
    在定义角色时我们追求精确,但是我们要排除平均状况。平均用户从来不会真正“平均”。
    平均角色会损害精确角色所具有的优点:具体。角色的巨大力量在于它们的精确程度和具体性。用集合的方式来处理会损害角色的有效作用。
    2011-02-12 10:47:42 回应
  • 第128页
    每份角色表至少有一个首要人物角色。首要人物角色是设计为之服务的中心人物,这个角色的目标必须得到满足,但是不能通过为其他角色设计的界面来满足。首要角色应该有专门为他设计的操作界面。
    如果发现首要人物角色超过三个,就意味着我们的问题过于庞大,我们在试图一下子完成太多的事情。创建角色可以限制我们实际为他们进行设计的用户类别。如果角色过多,我们引入角色的意义也就失去了。
    2011-02-12 11:14:08 回应
  • 第140页
    进一步地说,最重要的目标是具体个人拥有的个人目标。是真实的人而不是抽象的企业与你的产品打交道,因而必须将人们的个人目标置于企业目标之上。人们会尽全力达到商业目标,但是这仅是在达到他们的个人目标之后。最重要的个人目标是维护个人尊严:不觉得自己愚蠢。
    良好交互设计的本质是,设计的交互能让使用者在不影响个人目标的情况下,达到他们的实际目标。
    目标不是任务。目标是终结条件,而任务是达到目标所需要的中间过程。区别任务和目标非常重要,人们很容易将它们相互混淆。
    有一种简单的方法可以区别任务和目标。任务随着技术的变化而变化,而目标具有让人高兴的稳定属性。例如,从圣路易斯到旧金山旅行,我的目标是快速、舒适、安全。如果是在1850年前往加州的金矿,我很可能乘坐一辆新的大篷马车,为了安全起见,我会随身携带一支温彻斯特来复枪。而在1999年从圣路易斯前往加州硅谷,我会乘坐一架波音777客机,而也是为了安全起见,我会把枪留在家里。我的目标没有变化,但是由于技术的变化,我的任务却发生了截然相反的变化。
    2011-02-12 11:30:21 回应
  • 第171页
    场景是从初期调研阶段收集的信息中建立起来的。通常,在与用户访谈和直接观察中,我们会得到很多有关任务的信息。目标比较稳定持久,但是任务是流动的,可改变的,很多任务在电脑系统中并没有必要。在编写场景时,我们需要找出那些因历史原因而存在的任务,并将它们剔除。 比起深度,有效的场景需要在广度方面更加完整。换句话说,将场景从头至尾进行描述,比将每一步骤详尽地描述更重要。 我们应当将重点放在那些能深化设计工作的场景,而避免陷入边缘状况。我们只编写两类场景:日常场景和必要场景。
    日常场景最为有用,也最为重要。它们是使用者需要执行的主要任务,这些任务还会需要经常执行。例如,在一个缺陷跟踪系统中,查找缺陷和填写新缺陷报告单就是日常场景。任何技术支持人员都会在一天内多次地执行这两项任务。 通常,大多数使用者只有有限的日常场景。一般不过是-个或两个,超过三个的情况很少。
    必要场景是所有那些不常用,但是必须具备的场景。清空数据库和发出异常请求就属于必要场景。必要场景也要求有灵活的操作指南。但是,使用者不会追求熟练使用这些场景。因为不常用,使用者会愿意迎合程序的做事方式,不会考虑去定制操作。因而,程序员们也不必在必要场景上花费与日常场景相当的精力和资源。这种区别就像一部新车的豪华内饰和发动机舱内的简陋修饰一样。 虽然多数产品必要场景也不是很多,但是它们一般都多于日常场景的数量。
    当然,有第三种场景:边缘场景。程序员自然会很重视边缘场景,但是我们可以在产品设计过程中忽视边缘场景。这可不是说相应的功能可以在程序中省略,而是说我们可以很粗略地设计交互,将它们放到操作界面的背后。处理边缘场景的能力,决定了程序的成功和失败,而处理日常场景和必要场景的能力,决定了产品的成功和失败。 如果使用者频繁执行某一任务,这个任务的交互就应精心雕琢。同样,如果一个任务是必需的,但是不常执行,它的交互也需要细心设计,虽然目的不同。对于为处理边缘状况而产生的不常用的任务,不需要精心设计。时间和金钱永远不会充裕,边缘状况是我们可以安全地节省资源的地方,并把它们集中起来发挥最大用处。我们必须支持所有场景,但只需要为那些重要和常用的场景进行设计。
    2011-02-12 14:31:39 3人喜欢 1回应
  • 第206页
    永远应该优先满足的是用户的需求。毕竟,虽然其他人站在那里要求行动,但客户是惟一手里拿着支票的人。每个商业人员没法不受他的影响!
    2011-02-12 15:57:16 回应
  • 第209页
    如果我们将Maister的方法运用到产品行业的话,我们就会发现,所有客户的要求都是"灰发"工作,"头脑"工作是所有因内部驱动而安排的工作。换句话说,保持技术领先,避免客户驱动死亡螺旋是产品经理的职责。你必须像刚起步时那样,在内部寻找答案。 这意味着有远见,有责任心,付出时间,进行控制。
    2011-02-12 16:05:13 回应
  • 第230页
    尽管交互设计师占据主导地位,他们绝不可能比程序员更了解程序的内部。他不可能从程序员的角度看得更清楚,为了获得成功,他必须从另一个角度看待问题。 交互设计师能够与程序员平起平坐的基础是,提交精确而完整的交互设计文挡。设计师只有提交让人信服的解决办法,程序员才会逐渐信任和依靠他们。
    2011-02-12 17:34:18 回应