《Don't make me think》读书笔记

一,不要让我思考(第一原则)


不要让用户去思考,网站不是一本书籍,没有人会细细阅读,大家都是扫描读过整个网站。

每一个可能让用户停下来思考的模块或点,都应该避免,例如:

我在什么位置? 我该从哪里开始?

他们把xxx放在什么地方去了?

这个页面上最重要的是什么?

为什么他们给他取这个名字?

二,用户实际上是如何使用web的


  1. 用户仅仅是视觉扫描网站,而不会仔细阅读网站

用户在扫描过程中,会关注的地方:

所有样式明显突出显示的文字,与用户手头任务相关的内容,我们当前或接下来的兴趣,以及人类脑袋里根深蒂固的兴趣触发词:“免费”“大减价”“美女”还有我们的名字。

  1. 用户不做最佳选择,而是选择第一个合理的选项

一旦用户发现一个连接(按钮),看起来似乎是能跳转到我们想去的地方,那用户就有很大概率会点击。

  1. 用户使用网站达到某一任务目标时,不一定是最优解。

用户通常是勉强应付的,如果发现某个事物能这么用,那么用户会一直那么用它,虽然效率可能极其低下。

所以我们需要去观察他们的“可用性测试 ”,很有可能用户的操作方式根本不是我们设计的使用方式,如果出现这种情况,可能需要对操作流程进行优化和调整。

当用户掌握了高效正确的使用方式后,对于留存客户更有帮助。

三,广告牌设计101法则:为扫描设计,不为阅读设计

  1. 建立清楚的视觉层次: 突出重要的部分, 逻辑上相关的部分视觉上也相关,逻辑上包含的部分在视觉上进行嵌套
  2. 习惯用法: 不仅是web里通俗的习惯用法(常识),也要相关 用户本身的使用习惯和工作习惯。
  3. 把页面划分成明确定义的区域
  4. 明显标识出可以点击的地方(按钮,链接)
  5. 降低视觉噪声:弹出框的模糊暗色背景,去除无用的数据显示,只保留有用的信息,降低噪声。

四,无须思考的选择

“三次无须思考,明确无误的点击 相当于 一次需要思考的点击。 ”---尽量删减需要思考的点击


五, 省略不必要的文字

尽量减少欢迎词

尽量减少指示说明: 每个模块的说明尽量简短明确,FAQ收缩起来,用户想看时候再点击。

六, 街头指示牌(持久导航) 和面包屑

Web与真正的大卖场的区别在于:

感觉不到大小;感觉不到方向;感觉不到位置。

所以web需要持久导航,一个在任何页面都会存在的指路牌。

持久导航的基本五元素:

站点ID(LOGO),

栏目,

回主页的方式,

搜索的方式,

实用工具(帮助,关于我们,联系我们)

*搜索的作用:有些用户的习惯是优先浏览自己找答案,有些用户是优先询问(搜索),通过询问找答案*

点击某一栏目后,要有被点击的效果,让用户知道已经处于这个界面中。

  • 页面名称(相当于大路牌):

明确的写明用户所在的页面位置,大字体,明显的位置

页面名称 要与 点击的链接一致。

  • 面包屑:

 针对多级菜单使用,明确告知用户你所在的层级

  • tab的布局:

作者最推崇的导航元素。注意点击后的tab效果就好。

对一个网站的最基本的导航测试:

 打开一个网站主页,请迅速找到以下六个元素:

1.站点ID, 2.页面名称 3.栏目和它的下一级栏目(如果存在的话)

4.页内导航 5.“你在这里”指示器 6.搜索

如果这六个元素缺少一些,需要我们补充设计,或者有明确的理由可以忽略这个缺失。


七, 首先要承认,主页不由你控制

主页总是会有很多内容要放:导读,内容更新,友情链接等等,内容太多就会产生混乱的状态。

在混乱之中有一件事不能忘记:传达整体形象,。

 进入一个主页,主页应该非常轻松地回答我的四个问题:

  1. 这是什么网站?
  2. 我能在这里做什么?
  3. 网站上有些什么?
  4. 为什么我应该在这里,而不是在别的地方?


  为了达到上面的四个目标,我们需要一个明确的口号 和 欢迎页面(已经存在)

  网站口号:

  • 口号要清楚,言之有物。
  • 不好的口号含混不清,听起来太笼统
  • 好的口号长度适中,6-8个英文单词足以表达思想

第五个问题:从哪里开始?

当用户进入网站,快速扫描主页后,应该能明确无误地知道:

  • 如果我想搜索,可以从哪里开始
  • 如果我想扫描,可以从这里开始
  • 如果我想扫描该网站最精彩的内容,从这里开始

在哪些针对一系列步骤的过程所建立的网站中(如同咱们的初始化流程),整个过程的起点应该很显眼。

所以最好的办法就是,让 每个起点 看起来像起点:搜索款像搜索框,栏目列表像栏目列表,并加上清楚的文字描述。

下拉框的问题

作者是不太推崇下拉菜单的,虽然它可以节省空间,但是:

你必须把它们找出来;它们不好扫描; 它们不好控制。

 如果下拉菜单的内容的排序是可以预料的,下拉菜单还是有意义的,比如 月份选择。

 但是如果内容是不可以预测的,比如 行业选择词典,下拉菜单的设计就变得糟糕了


八, 农场主和牧牛人应该是朋友

本章很短,主旨大意就是,web设计团队和市场人员和高管不应该为 网站可用性争论不休,因为任何一方的观点可能都不是 使用者的真实想法

九,一天10美分的可用性测试

 可用性测试,即真正探究实际使用者的真实想法的测试。

这个测试会在我们把产品推到种子用户之前完成。

 可用性测试的要点:

  • 可用性测试一定要做,如果想做一个好的网站的话。

使用者的真实体验和想法,与设计者永远存在偏差,一定要从测试结果中优化。

  • 一次测试9个人,不如分成3轮各3个人好

因为每次测试时测试者很可能都卡在同一类问题中,只有修复了这一类问题,使用者才能找到新的毛病。

  • 测试是一个迭代的过程:测试,微调(修复),测试,再微调
  • 每轮3-4个用户最优
  • 不要在意测试者的标准(比如:必须是写字楼租赁部人员)

一个好的系统不是给专家使用的,而是行业小白或者非本行业人也应该是可以使用的。

测试者的选择可以采用这样的标准: 先以满足最低要求为主(可以使用电脑和上网的人),再逐步提升,最后一两轮提升到专业人士。

一次可用性测试的流程:

  1. 找到一个安静的地方,一台电脑,一个屏幕录制软件
  2. 开始录制测试过程,先进行的是“理解”测试: 让测试用户看到网站,然后看他们能否理解这个网站,网站的目标是,价值主张,组织方法,运行方式等。
  3. 然后进行的是“关键任务”测试: 让用户尝试去完成一些我们设定好的任务(如找到一个你感兴趣的在租客户)

当我们设定“关键任务”时,尽量设定一些 用户有自己权利参与选择的任务,这样会有更好的结果。

比如“找到一本你想买的书,或者一本最近买过的书”比“找一本14美元以下的烹饪书”有更好的效果,当人们执行呆板的任务时,不会进行感情投入,也不会尽可能运用个人知识。

*越早把设计思想展示给用户越好,用户更愿意去评论一些看起来还没有完成的东西,因为他们觉得你还有机会去修改。*

*超简易可用性测试:小隔间测试。 只要你建立了一种新页面(特别是表格),就把它打印出来,拿给你旁边隔间的人,看他们能否弄清楚页面的意思,这种测试效率很高,也能减少很多潜在问题。

可用性测试的回顾:

  1. 给问题分类: 把大家看到的问题,进行分类,决定哪些问题需要修正。
  2. 解决问题: 找出修正这些问题的方法。

可用性测试的常见问题:


  1. 用户不清楚概念:

他们就是不理解,他们看着网站或页面,要么不知道它们说的是什么,要么他们以为自己知道,但是实际理解有误。

  1. 他们找不到自己要找的字眼:

这通常意味着,1.你用来组织内容的分类不符合用户的使用习惯 2.分类符合他们的习惯,但是没有使用他们期望的名字

  1. 内容太多了:

他们要找的内容就在页面上,但是他们就是看不到。

这通常意味着,1.你需要减少页面上的整体干扰 2.把他们想看的内容设置的更加醒目

问题改进的基本原则:

  1. 忽略掉“kayak”(皮划艇)问题

在任何测试中,你都可能会遇到这样的情况,用户暂时出现错误,然后又在不需要任何帮助的情况下又回到原来的轨道。这就像划皮划艇翻船一样,只要皮划艇及时恢复正常,就只是一种乐趣而已。

只要1) 出现问题的人马上发现自己偏离了原来的主题 2) 他们尽量回到原来的方向而不需要帮助 3) 这种情况看起来并没有扰乱他们的活动,你就可以忽略这些。

总得来说,如果 用户关于在哪里找到他们需要的内容的第二次猜测总是对的,就已经可以了。

如果这种同一情况(同一场景)在多个用户的测试中发生,咱们可以尝试讨论一些简单的修正方法,但是也有可能是无法修复的,因为没准有两种类似信息就同时存在,还不能重点强调其中一个。

  1. 抵制添加的冲动

当测试结果表明,人们没有理解某些内容时,大部分人第一反应是添加内容:注释或解释说明。

不要试图添加,而是去除某一个(或一些)让人混淆的内容,而不是增加新的干扰。

     

  1. 不要太看重人们对新功能的要求

人们总有新功能的需求。就像李冉说的,你列出的功能他肯定都要。

  1. 抓住够得着的果子

在每轮测试中,你的主要目标是寻找重要而不费力的收获,一般有以下两个类别:

 恍然大悟型:

这是那些在测试中出现的,当大家看到第一个用户试着勉强应付的时候,问题和解决方案都很明显的那种惊喜。 应该马上修正这样的问题。

 便宜型:

也要尽力实现以下变更 1)几乎毫不费力的 2) 需要费一点力气,但效果非常明显的。

  1. 别把孩子也泼出去了!(非常重要)

和任何好的设计一样,成功的网页往往要进行巧妙的平衡。任何微小的变化都会带来不小的影响。

不要让你新做的改变 破坏 已经正常工作的部分。

所以不要盲目地进行大改,一切都需要平衡,在突出表现某一内容时,要考虑其他内容的重要性是不是降低了。

十,可用性是基本礼貌

一个客户进入一个网站,都会自带一个“好感存储器”,好感存储器里的好感度增或减 会依个人特质和不同情况而定。

我们要做的就是保证客户在使用系统的时候有足够高的好感度,而不是消耗掉他的好感度,客户被气走。

  • 降低好感度的几种方式:

1) 隐藏我想要的信息: 客户服务电话号码,运费 和 价格

 2) 因为没有按照你们的方式行事而惩罚我:

我应该永远不要想到对数据设定格式:是否要在我的社保号码中间加破折号,信用卡号码中间是否要加入空格等等。

不要因为不想多写一点代码就让我在错误数据输入框停留太久。


 3)向我询问不必要的信息

 大多数用户都很介意个人信息,如果网站要求的信息超出当前任务时,会让用户觉得很厌烦。

 要求填写内容太多时,填写内容的虚假概率就越高。

 4)敷衍我,欺骗我

用户讨厌 虚伪的真诚,也讨厌假意的关心。

 5)给我设置障碍

不得不等待的长长的flash介绍,或者浏览多个页面的图片介绍(用户都很忙的)

 6)你的网站看上去不专业

组织不好,不专业,布局上没有下功夫,用户也会失去好感。

 


  • 提高好感度的几种方式:


1)知道人们在你网站上想做什么,并让它们明白简易

把用户最想做的三件事儿摆在最明显的地方

 2) 告诉我我想知道的:

把运费,各种费用,暂停服务以及其他你不愿意放在前面的内容放在前面。

如果你的运费比我期望的高,可能会让我降低好感,但因为你的坦诚和让我更方便可以弥补降低的好感值。


 3)尽量减少步骤:

 操作流程中步骤越少越好。

 4)花点心思:

解决我的问题所需要的信息;保证它准确有用;用清楚的方式来表达;组织良好,可以轻松找到。

5)知道我可能有哪些疑问,并且给予解答:

  • 他们是真正的常见问题列表,而不是 “我们希望人们会问的问题”
  • 保持更新。客户服务和技术支持部门很容易就能为你提供本周问的最多的五个问题。作者通常会把这份清单放在任何网站的服务支持页面的顶部
  • 保持坦率。 人们常常在FAQ上寻找一些你不希望他们问到的问题的答案,在这些问题上保持坦率,能在很大程度上提高用户的好感。

 6)为我提供协助,例如打印友好页面。

打印界面时自动去掉广告和无用的横幅信息,保留重要的文字,插图和图表。

7)容易从错误中恢复

就是说要给用户提供一个快速的恢复或绕过错误的办法。

8)如有不确定,记得道歉

有时候你会因为暂时没有能力或资源做到用户想要的,如果你做不到,至少让他们明白你知道你在给他们造成不便。

十一,可访问性,级联样式表和你

讲的是针对残障人士的可访问性优化,咱们暂时先不用这部分。

再后面就没有有用的了。全书结束。

《Don't make me think》读书笔记

时间: 2025-01-02 03:10:32

《Don't make me think》读书笔记的相关文章

CI框架源码阅读笔记3 全局函数Common.php

从本篇开始,将深入CI框架的内部,一步步去探索这个框架的实现.结构和设计. Common.php文件定义了一系列的全局函数(一般来说,全局函数具有最高的加载优先权,因此大多数的框架中BootStrap引导文件都会最先引入全局函数,以便于之后的处理工作). 打开Common.php中,第一行代码就非常诡异: if ( ! defined('BASEPATH')) exit('No direct script access allowed'); 上一篇(CI框架源码阅读笔记2 一切的入口 index

IOS测试框架之:athrun的InstrumentDriver源码阅读笔记

athrun的InstrumentDriver源码阅读笔记 作者:唯一 athrun是淘宝的开源测试项目,InstrumentDriver是ios端的实现,之前在公司项目中用过这个框架,没有深入了解,现在回来记录下. 官方介绍:http://code.taobao.org/p/athrun/wiki/instrumentDriver/ 优点:这个框架是对UIAutomation的java实现,在代码提示.用例维护方面比UIAutomation强多了,借junit4的光,我们可以通过junit4的

Yii源码阅读笔记 - 日志组件

?使用 Yii框架为开发者提供两个静态方法进行日志记录: Yii::log($message, $level, $category);Yii::trace($message, $category); 两者的区别在于后者依赖于应用开启调试模式,即定义常量YII_DEBUG: defined('YII_DEBUG') or define('YII_DEBUG', true); Yii::log方法的调用需要指定message的level和category.category是格式为“xxx.yyy.z

源码阅读笔记 - 1 MSVC2015中的std::sort

大约寒假开始的时候我就已经把std::sort的源码阅读完毕并理解其中的做法了,到了寒假结尾,姑且把它写出来 这是我的第一篇源码阅读笔记,以后会发更多的,包括算法和库实现,源码会按照我自己的代码风格格式化,去掉或者展开用于条件编译或者debug检查的宏,依重要程度重新排序函数,但是不会改变命名方式(虽然MSVC的STL命名实在是我不能接受的那种),对于代码块的解释会在代码块前(上面)用注释标明. template<class _RanIt, class _Diff, class _Pr> in

CI框架源码阅读笔记5 基准测试 BenchMark.php

上一篇博客(CI框架源码阅读笔记4 引导文件CodeIgniter.php)中,我们已经看到:CI中核心流程的核心功能都是由不同的组件来完成的.这些组件类似于一个一个单独的模块,不同的模块完成不同的功能,各模块之间可以相互调用,共同构成了CI的核心骨架. 从本篇开始,将进一步去分析各组件的实现细节,深入CI核心的黑盒内部(研究之后,其实就应该是白盒了,仅仅对于应用来说,它应该算是黑盒),从而更好的去认识.把握这个框架. 按照惯例,在开始之前,我们贴上CI中不完全的核心组件图: 由于BenchMa

CI框架源码阅读笔记2 一切的入口 index.php

上一节(CI框架源码阅读笔记1 - 环境准备.基本术语和框架流程)中,我们提到了CI框架的基本流程,这里这次贴出流程图,以备参考: 作为CI框架的入口文件,源码阅读,自然由此开始.在源码阅读的过程中,我们并不会逐行进行解释,而只解释核心的功能和实现. 1.       设置应用程序环境 define('ENVIRONMENT', 'development'); 这里的development可以是任何你喜欢的环境名称(比如dev,再如test),相对应的,你要在下面的switch case代码块中

Apache Storm源码阅读笔记

欢迎转载,转载请注明出处. 楔子 自从建了Spark交流的QQ群之后,热情加入的同学不少,大家不仅对Spark很热衷对于Storm也是充满好奇.大家都提到一个问题就是有关storm内部实现机理的资料比较少,理解起来非常费劲. 尽管自己也陆续对storm的源码走读发表了一些博文,当时写的时候比较匆忙,有时候衔接的不是太好,此番做了一些整理,主要是针对TridentTopology部分,修改过的内容采用pdf格式发布,方便打印. 文章中有些内容的理解得益于徐明明和fxjwind两位的指点,非常感谢.

CI框架源码阅读笔记4 引导文件CodeIgniter.php

到了这里,终于进入CI框架的核心了.既然是"引导"文件,那么就是对用户的请求.参数等做相应的导向,让用户请求和数据流按照正确的线路各就各位.例如,用户的请求url: http://you.host.com/usr/reg 经过引导文件,实际上会交给Application中的UsrController控制器的reg方法去处理. 这之中,CodeIgniter.php做了哪些工作?我们一步步来看. 1.    导入预定义常量.框架环境初始化 之前的一篇博客(CI框架源码阅读笔记2 一切的入

jdk源码阅读笔记之java集合框架(二)(ArrayList)

关于ArrayList的分析,会从且仅从其添加(add)与删除(remove)方法入手. ArrayList类定义: p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Monaco } span.s1 { color: #931a68 } public class ArrayList<E> extends AbstractList<E> implements List<E> ArrayList基本属性: /** *

dubbo源码阅读笔记--服务调用时序

上接dubbo源码阅读笔记--暴露服务时序,继续梳理服务调用时序,下图右面红线流程. 整理了调用时序图 分为3步,connect,decode,invoke. 连接 AllChannelHandler.connected(Channel) line: 38 HeartbeatHandler.connected(Channel) line: 47 MultiMessageHandler(AbstractChannelHandlerDelegate).connected(Channel) line: