产品设计体会(7024)有关交互设计,读过的6本书

前段时间把交互设计之父Alan Cooper大爷(此牛也是VB之父)的About Face 3.0中译版《软件观念革命:交互设计精髓》翻完了,发现自己对交互设计的“术”兴趣不浓,所以还是留给更专业的交互设计师去研究吧,自己只记了如下一点点笔记:

知识体系的4P,这个总结的很通用,可以映射到很多事情上,赞:

 Ø  Process,过程,整个设计的过程。我的理解,比如一些常用的流程。

 Ø  Pattern,模式,一些解决问题的方法论。比如用户研究。

 Ø  Principles,原则,一些习惯用法的规则。比如“不要让用户思考”。

 Ø  Practices,实践,把上述3个理论具体化,找到所在产品、团队的较优实践,每次都会不一样。此外还有与产品有关的周边团队的影响,不要让非核心的失误坏了大事。

产品的三个模型:

 Ø  现实模型,描述产品是怎样运作的。

 Ø  心理模型,表达用户是怎样理解的。

 Ø  表现模型,即设计者模型,是设计者如何将现实呈现给用户,应该尽量接近用户的心理模型,但是相应的工作量也会增加。

用户访谈和用户观察的注意点:

 Ø  在交互发生的地方进行访谈:能观察到用户使用产品的情景很重要,但很多时候我们是出于成本的考虑,并没有到实地去访谈。

 Ø  避免一组固定的问题:固定的问题会让被访者产生被审问的感觉,我们应该准备好问题清单,但清单只是一个引导作用,并不用照着读。

 Ø  首先关注目标,任务其次:比用户行为更重要的是行为背后的原因,多问问为什么。

 Ø  避免让用户成为设计师:听用户说,但不要照着做,用户的解决方案通常短浅、片面。

 Ø  避免讨论技术:特别是碰到一些略懂技术的用户,不要与其纠缠产品的实现方式。

 Ø  鼓励讲故事:故事是最好的帮助设计师理解用户的方法。

 Ø  避免诱导性的问题:典型的诱导问题:如果有某某功能,你会使用么?一般来说用户会给出毫无意义的肯定答复。

这本书我是去浙图借的,当时居然发现About Face 2.0,当然也是中译版,也在,就一并借来翻翻,一直没看过这本类似行业圣经的书,也着实遗憾,发现2.03.0,由于写作的时间从2003变成了2007,所以加了一些最新的东西,比如很多图片更新了,用于举例的软件版本也升级了,全书也从40+万字变成了50+万字,不过整体依然大同小异。

作为一个准产品经理,我一直说,在公司里被迫的要做一些交互设计的事情,而交互设计又是那么的专业和有深度,所以也意味着被迫的犯很多交互设计的错误,于是只好通过看一些书、文章来尽量少错一点,这两、三年来看过的书还有:

《交互设计之路》Cooper大爷again,个人感觉这看起来比About Face轻松一些,入门可以用这个;

GUI设计禁忌》,更加的实用,“术”一些,可能更适合一线的交互设计师,不过这块的知识发展太快,对于一本2005年就翻译完成的书,看的时候要多加小心;

《可用性工程》,一般般了,比较的理论化,像教材,有些通用原则值得仔细品味;

《一目了然》《点石成金》(即著名的Don’t make me think),这两本是小书,看起来轻松愉快,半天搞定,而且也比较新,推荐翻翻。

发现全是英文书的中译版,所以对于实力型选手,建议读原版,可以领先国内思想23年,自己早年读书没有做笔记的习惯,现在感觉挺可惜的

当然如果你对读书很感兴趣的话,也可以看我的《产品经理值得读的12本书》

百度空间的验证码【人人都是产品经理:9005】

想必同学们都碰到过提交网页的时候验证码过期的问题吧,百度博客的验证码不会在页面刚load完就显示出来(1),而是在你准备输入验证码的时候,点击输入框它才出来(2),避免了过期的问题,但是还有个缺陷,有的用户会奇怪“没看到验证码啊,怎么办?”

另外,点“看不清”刷新验证码的时候,字符并没有变(3)(4),很有意思。

怎么再优化?

产品设计体会(7007)当交互设计遇到敏捷开发

让我们先回到2002115日,交互设计之父Alan Cooper和极限编程创始人Kent Beckpk,话题是“当交互设计遇到敏捷开发。就像小说里两大高手对决一样,双方大战三百回合还是没有分出胜负,终归握手言和(或者小气的赌气分手,呵呵),引用一些对那场战斗的评论:

Ø Cooper大师认为子弹很贵,因此在每次开枪之前一定要精确地瞄准。负责瞄准的人应该是专业的交互设计师。

Ø Beck大师认为有了极限编程,子弹变得很便宜,我不需要瞄太准,打不准就再放一枪,没什么大不了,最终总能打中目标。

Ø Cooper大师很适合做一个狙击手,点射的命中率几乎能够达到100%

Ø Beck大师很适合做一个机枪手,机枪是不可以点射的,一般都是扫一片,用密集的火力消灭敌人。

Ø 两者考虑问题的角度不大一致,其实并不存在非常大的冲突。相反,交互设计与敏捷开发方法能够结合起来,以更小的成本交付令用户满意的产品。Patton在这方面做了成功的尝试。

还是那个道理,方法只有是否合适,没有好坏之分,也许“交互设计”比较适合传统领域、成熟公司、时间资源充裕的时候,使用者在某领域中已经出于领先地位,目的是求稳,不犯错就是胜利;“敏捷开发”适合新兴行业、创业公司、时间紧迫,大家都在赶,谁先出头谁就能占得先机,或者作为挑战者进入某个行业,团队本身灵活,失败了损失也不大,重来的成本低。从这点上看,互联网行业、SAAS模式似乎更偏向于使用敏捷开发的方法,但敏捷绝不是在时间紧迫下的被迫放弃交互,而是主动为之的一种思想,并且要将交互融入其中(敏捷设计?)。

从另一个角度想,“交互设计”适合设计型公司,“敏捷开发”适合技术型公司,各个公司都有其强势的部门,这里就不展开了。

“交互设计”之于“敏捷开发”,有点像那个“大象与猴子”的寓言(一时找不到),最后结合在一起最好,又像楷书与草书,同样是写字,没法评价哪个好哪个差,也许结合一下又出现了很赞的行书