做事之前，先学会如何休息more

事业是长期的，其间肯定会遇到各种挫折、困难，人也会变得烦闷、低落。这时，一些平常小意思的问题，都会变成拦路虎。要解决这些问题，自己并不是缺乏能力，而只是没了那份心力。你要做的，不是拉钱找人、增加资源，而是休息、放松，重新充电。

设置休息节点，可能比设置目标节点更重要。

不然，结果可能是事业的半成品+疲惫、失败的你

PS：坚持每周游泳、散步，每双周去个新的地方、认识新的人

别做太多准备，除非它不影响你马上行动more

周四想到去租车，周五略做准备后提车，周六出去兜风并还车。对我来说，这样的效率算高的。

其实，租车还是有些麻烦的，真的要做足功课的话，会有很多事要做。像是要选哪家租车公司、什么车型、怎么验车、了解其中的潜规则、等等。而且，在了解这些信息的时候，看到了很多关于租车的负面消息，什么被坑钱之类的，差点因此而放弃。

最好，我还是决定勇敢得当个小白鼠，最多是花钱买教训。结果，并没有遇到网上说的负面情况，玩得还不错。如果当初做准备的时候，因为看到部分负面消息而放弃的话，那我就不能过手瘾、不能享受开车的乐趣了。

没有准备好的战争，大多时候我们都是匆匆上阵。既要有审时度势的能力，更要有当机立断的魄力，就算做错了又怎样？何况又不一定错。

并不是说深思熟虑不对，而是并不适用于所有情况，尤其是生活中实实发生的小事、不大的事。在这些事情上费思量，还不如直接做，做错的代价甚至可能比思量的代价要低。而且，准备时考虑的因素可能实际并不存在，想得太多可能会使原本好的计划胎死腹中。

写下这些文字，提醒自己要果敢

more点击图片查看超大图片：

文字版：

1. 第2章 我们实际上是如何使用Web的

在设计网页时，我们通常认为用户会仔细阅读网页的布局和内容；事实上，他们通常只会匆匆的扫描网页，找到他们感兴趣的、或者差不多合适的；或者后退。

2.1 事实一：我们不是阅读，而是扫描

2.1.1 我们总是处于忙碌之中

2.1.2 我们知道自己不必阅读所有内容

2.1.2.1 只要扫描出感兴趣、相关的内容即可

2.1.3 我们善于扫描

2.1.3.1 例如生活中扫描报纸、杂志、书籍等

2.2 事实二：我们不作最佳选择，而是满意即可

大多数时间里我们不佳选择最佳选项，而是选择第一个合理的选项，这就是满意策略（Satisfice）。

2.2.1 我们总是处于忙碌之中

2.2.2 如果猜错了，也不会产生什么严重的后果

2.2.3 对选择进行权衡，并不会改善我们的机会

2.2.3.1 权衡，还不如错了后退来得快

2.2.4 猜测更有意思

2.3 事实三：我们不必懂为什么，差不多能用就行

在很大程度上人们一起在使用某些东西，但并不理解它们的运作原理，甚至对它们的工作原理有完全错误的理解。

无论对哪项技术，我们通常不愿意花时间去深究。相反，我们贸然前进、勉强应付，编造出我们自己的、模棱两可的故事，来解释我们的所作所为、以及为什么这样能行得通。

很多人完全不是以设计师设想的方式使用网络和软件，但他们用得很好；例如，人们会在Yahoo的搜索框里输入整个URL地址，进而打开这个网页。

2.3.1 原理对我们来说并不重要

2.3.2 如果发现某个事物能用，我们会一直用它

1. 第3章 广告牌设计101法则

像高速公路上扫描广告牌一样扫描网页，让网页在扫描的情况下也清晰易懂

3.1 建立清晰的视觉层次

3.1.1 越重要的部分越突出

3.1.1.1 字体更大、更粗

3.1.1.2 颜色更特别

3.1.1.3 旁边有更多空白

3.1.1.4 更接近页面顶部

3.1.2 逻辑上相关的东西，视觉上也相关

3.1.2.1 相近的内容分成一组

3.1.2.2 放在同一个标题之下

3.1.2.3 采用类似的显示样式

3.1.2.4 放在一个定义明确的区域之内

3.1.3 逻辑上包含的部分，视觉上也嵌套

3.1.3.1 如一个分类的标题之下（或者所在区域内）?

都应该是这个标题所包含的内容

3.2 尽量利用习惯用法

3.2.1 让用户熟悉、快速上手，并且自信

3.3 把页面划分成明确定义的区域

3.3.1 如导航区、内容区、友情链接区、等等

3.4 明显标识可以点击的地方

3.5 最大限度的降低干扰

3.5.1 避免让人眼花缭乱

3.5.2 降低背景噪声

3.5.2.1 如将密密菜单中黑色的分隔线，变成灰色、或者虚线

1. 第6章 街头指示牌和面包屑

6.1 如果在网站上找不到方向，人们就不会使用你的网站

6.2 对比商场购物?

和浏览网站

6.2.1 商场

6.2.1.1 导航系统

See Also:导航系统

6.2.1.2 服务员

See Also:搜索

6.2.2 网站

6.2.2.1 导航系统

See Also:导航系统

6.2.2.2 搜索

See Also:服务员

6.3 网站浏览的特性

6.3.1 感觉不到大小

6.3.1.1 网页的多少

6.3.2 感觉不到方向

6.3.3 感觉不到位置

6.3.S1 因此，网站导航比?

现实生活中的导航更重要

(感觉不到大小 , 感觉不到方向 , 感觉不到位置 )

6.4 导航的用途

6.4.1 给我们固定的感觉

6.4.2 告诉我们当前的位置

6.4.3 告诉我们如何使用网站

6.4.4 给了我们对网站的信心

清楚的导航会给用户留下良好的印象。因此，建站的每时每刻，我们在头脑中都要有这个意识：用户知道他们在干什么吗？

6.5 Web导航习惯用法

6.5.1 就像物理空间的导航系统，也都有自己的习惯用法

6.5.2 网站ID/Logo

6.5.2.1 通常在左上角

6.5.2.2 出现在页面可视层次的首要位置

6.5.2.2.1 本面最显示的内容

6.5.2.2.2 或涵盖页面所有元素

6.5.2.3 看起来像Logo

6.5.3 持久导航

6.5.3.1 不同页面的相同位置

6.5.3.2 不同页面显示相似内容

6.5.3.3 最重要功能之一：回到首页

6.5.3.4 例外

6.5.3.4.1 首页

6.5.3.4.2 表单

6.5.4 栏目

6.5.4.1 主导航条

6.5.4.2 大部分情况下，也包含二级栏目

6.5.5 实用工具

6.5.5.1 不属于内容层次的重要元素

6.5.5.2 不用那么显眼

6.5.5.3 不同类型的网站，实用工具也不同

6.5.5.4 常用的“实用工具”清单

关于我们、下载、目录、结账、论坛、如何购买、招聘、我的__、注册、搜索、购物车、公司信息、联系我们、客户服务、讨论板、常见问题(FAQ)、帮助、主页、投资者关系（Investor Relation）、新闻、订单跟踪、新闻稿（Press Release）、隐私声明、登陆、站点地图、你的账户

6.5.6 页面名称

6.5.6.1 每个页面都需要一个名称

6.5.6.2 出现在合适的位置

6.5.6.3 名称要引人注目

6.5.6.4 和之前点击进入的链接名称一致

6.5.7 页面导航

6.5.7.1 再多层次的页面导航，也要在页面中显示出来?

避免深层次的导航中，没有到当前层次的导航

6.5.7.2 因此，开始设计时，就要考虑所有潜在级别的导航

6.5.8 你在这里

6.5.8.1 告诉用户所在站点层级结构的前后关系

6.5.9 面包屑

6.5.9.1 如：Home > Level 1 > Level 2> You’re here

6.5.9.2 告诉用户从主页到当前页面的路径

6.5.9.3 最佳实践

6.5.9.3.1 放在最顶端

6.5.9.3.2 使用“>”对层级进行分隔

6.5.9.3.3 使用小字体

6.5.9.3.4 使用文字“你在这里”

6.5.9.3.5 将最后一个元素加粗

6.5.9.3.6 不额外用作页面名称

6.5.10 标签导航

6.5.10.1 如典型的Amazon的顶部标签导航

6.5.10.2 优势

6.5.10.2.1 不言而喻

6.5.10.2.2 很难错过

6.5.10.2.3 很灵活

6.5.10.2.4 暗示了一个物理空间

6.5.10.3 最佳实践

6.5.10.3.1 突出当前标签

6.5.10.3.2 不同栏目使用不同的颜色

6.5.10.3.3 进入网站时，有一个标签已经选中

6.5.11 小字体版的底端导航

6.5.12 搜索

6.5.12.1 几乎每个页面都要提供搜索框

6.5.12.2 惯用法

6.5.12.2.1 一个输入框

6.5.12.2.2 一个按钮

6.5.12.2.3 “搜索”两个字

6.5.12.3 避免

6.5.12.3.1 花哨的用户

6.5.12.3.2 额外的提示说明

6.5.12.3.3 额外的选项

6.5.12.3.3.1 如果要提供选项来调整搜索范围，在有用时提供

6.5.12.3.3.2 例如：到达搜索界面，发现结果太多时，需要缩小搜索范围

6.6 后备箱测试

6.6.1 什么是？

6.6.1.1 想像你被蒙上双眼，锁在车子的后备箱里。?

车子开始一会以后，把你放在网站的某个页面上?

视线模糊一点，回答几个问题

6.6.2 怎么做？

6.6.2.1 在网站上任意选择一个页面，打印出来

6.6.2.2 拿到一手开外，或者倾斜一个角度，让你不能仔细观察

6.6.2.3 尽快找到清单中的项目并画上圆圆（不见得都找得到）

6.6.2.3.1 网站ID

这是什么网站？

6.6.2.3.2 页面名称

我在哪个网页上？

6.6.2.3.3 栏目和二级栏目

6.6.2.3.4 页面导航

在这个层次上我有哪些选择？

6.6.2.3.5 “你在这里”指示器

我在导航系统的什么位置？

6.6.2.3.6 搜索

6.A1 如果找不到东西?

用户就会离开

1. 第7章 首先要承认，主页不由你控制

7.1 主页要完成的任务

P71有完整的图示

7.1.1 站点的标识和使命

7.1.1.1 网站是做什么的？

7.1.1.2 和类似的网站有何不同？

7.1.2 站点层次

7.1.2.1 服务内容

7.1.2.2 服务如何组织(持久导航)

7.1.3 搜索

7.1.4 导读

7.1.4.1 内容推介：最新、最好、最流行的内容片断

7.1.4.2 功能推介：新功能、个性化功能、等等

7.1.5 内容更新

7.1.5.1 让用户觉得这不是一潭死水

7.1.6 友情链接

7.1.6.1 预留空间

7.1.7 快捷方式

7.1.7.1 如软件升级链接

7.1.8 注册/登陆

7.1.9 隐性功能

7.1.9.1 告诉用户从哪里开始

7.1.9.2 建立信任感、留下好印象

7.2 困难

7.2.1 每个人都想占一席之地

7.2.2 想要参与、决策的人太多

7.2.3 一个页面要适应所有用户

7.3 如何做？

7.3.1 注意：传达整体形象

7.3.2 进入一个新网站?

扫描后能明白几个问题

7.3.2.1 这是什么网站？

7.3.2.2 网站上有什么？

7.3.2.3 我能在这里做什么？

7.3.2.4 为什么我应该上这个网站、而不是别的？

7.3.2.5 从哪里开始？

7.3.2.5.1 如果要搜索，从哪里开始？

7.3.2.5.2 如果要扫描，从哪里开始？

7.3.2.5.3 如果要看最精彩的内容，从哪里开始？

7.3.3 如何传达

7.3.3.1 所有元素都在起作用

7.3.3.2 两个重要的元素

7.3.3.2.1 口号

7.3.3.2.1.1 位置：靠近网站ID

7.3.3.2.1.2 内容：一条精练的短句，刻画了整个企业 ?

总结它是做什么的，什么让它如此卓越

7.3.3.2.1.3 注意

7.3.3.2.1.3.1 口号要清楚、言之有物

7.3.3.2.1.3.2 不要含混不清、笼统

7.3.3.2.1.3.3 长度适中

7.3.3.2.1.3.4 表述网站的特点和显而易见的好处

7.3.3.2.1.3.5 有个性、生动、甚至俏皮

7.3.3.2.2 欢迎广告

7.3.3.2.2.1 网站的简要描述

7.3.3.3 指导原则

7.3.3.3.1 需要多大空间就使用多大空间，别吝啬

7.3.3.3.2 但也不要使用过多空间，描述就简短

7.3.3.3.3 不要把使命陈述当欢迎广告

7.3.3.3.3.1 如，不要使用“XX公司在XX领域提供世界一流的解决方案”

7.3.3.3.4 最重要的是进行测试

7.3.3.3.4.1 将主页给公司外的人看

7.3.3.4 主页导航可以和其他页面不一样?

当然，更重要的是要基本一致

7.3.3.4.1 用于标识的空间更多

7.3.3.4.1.1 因为主页的网站ID可能比其他页面大?

也就带来更多的空间给导航部件

7.3.3.4.2 主页可以增加栏目介绍

7.3.3.4.3 方向可以不同

7.3.3.5 谨慎使用下拉框

7.3.3.5.1 不是很突出、不容易被立马找到

7.3.3.5.2 不容易扫描

7.3.3.5.3 不容易使用，尤其是条目多的时候

7.3.4 书中示例；几个网站好的、差的地方，作者的改进版本

1. 第8章 农场主和牧牛人应该是朋友

8.1 问题来源

8.1.1 Web开发团队在可用性问题的决策方面，通常并不成功

8.1.2 以不同成员对于是否使用“下拉框”的讨论为例

8.2 问题表现

8.2.1 信仰大战

8.2.1.1 通常为了某些问题的最佳方案

8.2.1.2 无休止

8.2.1.3 讨论者有各自的观点（信仰）

8.2.1.4 很少能因为讨论而改变别人的观点

8.2.1.5 很少能得出有效的结论

8.3 危害

8.3.1 浪费时间

8.3.2 气氛紧张、影响团队合作

8.4 原因

8.4.1 个人喜好

8.4.1.1 对网站我们都有自己喜欢的、不喜欢的

8.4.1.2 讨论时通常会夹杂着自己的喜好

8.4.1.3 经常认为整体Web用户和我们一样

8.4.2 职位情绪

8.4.2.1 项目经理

8.4.2.1.1 通常喜欢：快点得出结论

8.4.2.2 设计师

8.4.2.2.1 通常喜欢：视觉上看起来有趣的网站

8.4.2.3 工程师

8.4.2.3.1 通常喜欢：功能又多又酷的网站

8.4.2.4 业务人员

8.4.2.4.1 通常喜欢：方便推销的网站

8.4.3 文化冲突

8.4.3.1 市场文化

8.4.3.1.1 来自：上层管理、市场、业务拓展

8.4.3.1.2 关注：有助于吸引风投、用户、战略合作伙伴、赢利

8.4.3.2 工程师文化

8.4.3.2.1 关注：技术实现

8.4.4 普通用户的神话

8.4.4.1 神话：存在普通用户/典型用户

8.4.4.1.1 非黑即白

8.4.4.1.2 简单的使用普通用户的“正确答案”

8.4.4.2 实际上

8.4.4.2.1 所有的Web用户都是独一无二的

8.4.4.2.2 每个Web用户都有其特有的使用习惯

8.5 解药

8.5.1 不要问

8.5.1.1 大部分人喜欢下拉框吗？

8.5.2 要问

8.5.2.1 在这个页面，在这样的上下文中，这个下拉框可以为大部分用户提供良好的体验吗？

8.5.3 如何回答

8.5.3.1 测试

8.5.3.1.1 先利用团队的集体技巧、经验、创造力、判断力创建多个版本

8.5.3.1.2 观察用户对其看法和使用的方法

1. 第9章 一天10美分的可用性测试

9.1 可用性测试的现状

9.1.1 太少了

9.1.2 太迟了

9.1.3 为了错误的理由

9.1.3.1 比如，通常为了确定某个问题的方案而测试?

结果可能发现这个功能根本就不重要

9.2 焦点小组不是可用性测试?

Focus Group is not Usability Testing

9.2.1 焦点小组

9.2.1.1 如何做

9.2.1.1.1 一小组人（通常是5~8人）围坐在桌子旁边，对展示给他们的想法和设计作出反应

9.2.1.1.2 这是一个小组过程，主要价值来自参与人员彼此的反应

9.2.1.2 用途

9.2.1.2.1 快速得到用户的意见和感觉

9.2.1.2.2 抽像地确定你的目标受众想要什么、需要什么、喜欢什么

9.2.1.2.3 测试出网站的理念是否有意义、价值主张是否吸引人

9.2.1.2.4 发现用户对竞争对手的看法

9.2.1.2.5 测试网站功能命名

9.2.1.3 注意

9.2.1.3.1 应该在设计网站之前进行

9.2.2 可用性测试

9.2.2.1 如何做

9.2.2.1.1 一次给一位用户展示一些内容?

（不管之处是网站，还是网站原型，或是一些单个页面的蓝图）?

并且要求用户说出：1，这是什么；2，试着用它来完成一项典型的任务

9.2.2.2 用途

9.2.2.2.1 了解网站的运行状况

9.2.2.2.2 确定如何改进

9.3 可用性测试?

需要知道的

9.3.1 如果要建立优秀的网站，一定要测试

9.3.1.1 自己做的时间长了，会失去判断力

9.3.1.2 不同的人有不同的视角，帮助发现问题

9.3.2 测试一个用户，比不做测试好一倍

9.3.2.1 测试总会有效果

9.3.2.2 测试用户的建议，可能会对产品带来意想不到的好处

9.3.3 早点测试一个用户，好过最后测试50位用户

9.3.3.1 让测试简单，也就更容易推行

9.3.3.2 后期修改的成本很高

9.3.4 人们对招募用户代表的重要性估计过高

9.3.4.1 实际上更重要的是：迟早和经常进行测试

9.3.5 测试并不能直接告诉你答案，而是帮助你判断

9.3.6 是一个迭代的过程

9.3.7 没有什么比现场用户的反应更重要

9.4 简易的可用性测试

9.4.1 复杂的测试模式导致测试被忽略

9.4.1.1 错误辩解

9.4.1.1.1 没有时间

9.4.1.1.2 没有钱

9.4.1.1.3 没有专业知识

9.4.1.1.4 没有可用性实验室

9.4.1.1.5 不知道如何处理测试结果

9.4.2 如何简单测试

9.4.2.1 应该测试多少用户

9.4.2.1.1 每轮测试理想用户数量是三个，最多四个

9.4.2.1.2 第一轮测试，用户发现问题，修改后再进行第二轮；依此类推

9.4.2.2 是否应该产生测试报告

9.4.2.2.1 对开发团队，他们发现、理解问题的能力很强?

但往往没有足够的资源来修正，因此要节约时间关注最严重的问题

9.4.2.2.2 用轻量级方式去和开发团队沟通，例如电话而不是长长的文档?

这样，开发团队既能理解，又节约时间

9.4.2.3 宽松招募，曲线上升

9.4.2.3.1 测试对象并不重要！

9.4.2.3.1.1 不一定必须是准确的目标群体

9.4.2.3.1.2 懂得上网的基本知识就可以了

9.4.2.3.2 利用你能找到的任何人，然后曲线上升

9.4.2.3.3 理由

9.4.2.3.3.1 实际上，我们老师初学者

9.4.2.3.3.2 网站只能被设定的目标群体使用，通常并不是好主意

9.4.2.3.3.3 每个人都喜欢简单、清楚的页面；专家也不例外

9.4.2.3.4 例外

9.4.2.3.4.1 如果网站几乎只由某一类用户使用，那么就招这类用户

9.4.2.3.4.1.1 例如，纯女性网站就可以不招男性用户

9.4.2.3.4.2 如果用户群体有几个明显的阵营，那么每个阵营都要招

9.4.2.3.4.2.1 例如，大学的网站，对老师、学生都要测试

9.4.2.3.4.3 网站面向需要专业知识的用户

9.4.2.3.5 注意

9.4.2.3.5.1 提供合理的激励

9.4.2.3.5.2 邀请要简单

9.4.2.3.5.2.1 例如，“我们需要一些人来看看我们的网站，并给我们一些反馈。?

这很容易，大约花费45分钟到一个小时，而且你将得到XX美元的报酬。”

9.4.2.3.5.3 避免对要测试的网站进行预告的介绍

9.4.2.3.5.4 别不好意思请身边的朋友帮助

9.4.2.4 在哪里测试

9.4.2.4.1 随便一间会议室就可以

9.4.2.4.2 可以考虑屏幕录像、录像等方式

9.4.2.5 谁应该在旁边引导

9.4.2.5.1 几乎所有人

9.4.2.5.2 有耐心、冷静、有同理心、关于、天性公正的人

9.4.2.6 谁应该观察

9.4.2.6.1 鼓励任何人

9.4.2.6.2 说服领导支持测试的好方式：让他参与一次观察

9.4.2.7 什么时候进行测试

9.4.2.7.1 越早越好

9.4.2.7.1.1 概念蓝图都可以

9.4.2.7.2 甚至，开始之前可以先测试同类网站

9.4.2.7.2.1 了解好的、不好的设计

9.4.2.8 测试什么

9.4.2.8.1 理解测试

9.4.2.8.1.1 用户看到网站，能否理解网站的目标、价值主张、组织方式、运行方式

9.4.2.8.2 关键任务测试

9.4.2.8.2.1 让用户完成一些任务，观察他们是如何做的

9.4.2.8.2.2 更好的是：让用户做些有自己选择的任务

9.4.2.8.2.2.1 如，找到你最近想买的一本书，?

或者找到一本20元以下的烹饪书

9.4.2.9 书中有一个测试实例，不错！

9.4.2.10 立即回顾测试结果

9.4.2.10.1 给问题分类，确定哪些要修改

9.4.2.10.2 找出解决的方案，确定下一步

9.4.2.11 常见问题

9.4.2.11.1 用户不清楚概念

9.4.2.11.2 他们找不到自己要找的字眼

9.4.2.11.2.1 可能：组织内容的分类不符合用户习惯

9.4.2.11.2.2 可能：符合习惯，但字眼不是他们的期望

9.4.2.11.3 内容太多了

9.4.2.12 注意

9.4.2.12.1 忽略Kayak（皮划艇）问题

9.4.2.12.1.1 用户偏离主题时能马上发现这一点

9.4.2.12.1.2 能在不需要帮助的情况下回到原来的位置

9.4.2.12.1.3 下次操作能正确进行

9.4.2.12.2 抵制添加的冲动

9.4.2.12.3 不要太看重用户对新功能的要求

9.4.2.12.4 主要寻找重要而、或不费力的收获

9.4.2.12.4.1 从来没想过、却很重要、严重的东西

9.4.2.12.4.2 很容易修改的问题

9.4.2.12.5 改Bug和原有功能的平衡

9.4.2.12.5.1 如果修改某个Bug会带来更严重的Bug，谨慎！

9.4.2.12.5.2 别在泼洗脚小的时候、把小孩也泼出去了

9.4.3 每个月一个上午，就这么多

1. 第10章 可用性是基本礼貌

10.1 基本要求

10.1.1 我的网站清楚吗？

10.2 高级要求

10.2.1 我的网站值得尊敬吗？

10.2.1.1 做正确的事——为用户考虑周到

10.3 示例

10.3.1 作者希望在航空公司网站上了解到罢工的最新消息?

结果找不到任何相关消息，非常失望

10.4 好感储存器

10.4.1 用户对网站有个好感的初值?

然后根据使用体验增加、或减少

10.4.2 容量特点

10.4.2.1 因人而异

10.4.2.1.1 有人天生猜疑、挑剔

10.4.2.1.2 有人天生有耐心

10.4.2.1.3 关键是：不要对初值期望太高

10.4.2.2 视情况而定

10.4.2.2.1 例如，用户在状态很差的时候来访问网站?

好感初值自然很低

10.4.2.3 可以重新被填满

10.4.2.3.1 差的设计让用户减分?

好的设计对把分数补回来

10.4.2.4 有时候一个错误就能清空它

10.4.2.4.1 例如，一个有大量字段的注册表单

10.4.3 降低好感的几种方式

10.4.3.1 隐藏我想要的信息

10.4.3.1.1 例如，客服电话，因为要收费、有成本

10.4.3.2 没有按照你们的方式行事就惩罚我

10.4.3.2.1 例如，不在银行卡号中加入空格

10.4.3.3 向我询问不必要的信息

10.4.3.3.1 例如，随便哪个网站都要你的身份证号

10.4.3.4 敷衍我，欺骗我

10.4.3.4.1 例如，在客服电话打不通的时候，电话提示音是：你的电话对我们来说非常重要

10.4.3.5 给我设置障碍

10.4.3.5.1 例如，长长的Flash介绍、无聊的产品介绍广告

10.4.3.6 看上去不专业

10.4.4 提高好感的几种方式

10.4.4.1 知道用户在网站上想做什么，并让操作简易

10.4.4.2 尽量减少步骤

10.4.4.3 花点心思做好

10.4.4.3.1 例如，惠普的售后网页

10.4.4.3.1.1 提供的信息准确有用

10.4.4.3.1.2 表达清楚

10.4.4.3.1.3 组织良好

10.4.4.4 告诉用户想知道的

10.4.4.5 知道用户有哪些疑问，并予以解答

10.4.4.5.1 FAQ

10.4.4.5.1.1 是真正的常见问题，而非广告式问题

10.4.4.5.1.2 保持更新

10.4.4.5.1.3 保持坦诚

10.4.4.6 为用户提供协助

10.4.4.6.1 例如，提供友好的打印页面

10.4.4.7 容易从错误中恢复

10.4.4.8 如果不确定，记得道歉

1. 第11章 可访问性、级联样式表和你

11.1 Accessibility & 508

11.2 可访问性差的原因

11.2.1 网站实际建造者：设计师和开发人员

11.2.1.1 假设所有人都是健全人?

并不理解很多人有访问障碍

11.2.1.2 怀疑增加可访问性能让?

包括正常人在内的所有人受益

11.2.1.3 害怕更大的工作量

11.2.1.4 担心增加可访问性的设计和普通设计很难折衷

11.3 如何做？

11.3.1 经常测试

11.3.2 改正让所有人感到混淆的可用性问题

11.3.2.1 例如，出错时模糊不清的提示

11.3.3 读一篇文章

11.3.3.1 观察16位盲人用户如何使用屏幕门口在不同网站完成许多任务

11.3.3.2 Guidelines for Accessible and Usable Web Sites: ?

Observing Users Who Work With Screen Readers

11.3.3.3 http://www.redish.net/content/papers/interactions.html

11.3.3.4 重要的结果

11.3.3.4.1 例如：用耳朵扫描：语速很快、仅听一部分就决定是否继续下一个

11.3.4 看一本书

11.3.4.1 Joe Clark

11.3.4.1.1 Building Accessible Websites

11.3.4.2 Jim Thatcher

11.3.4.2.1 Constructing Accessible Websites

11.3.4.3 John Slatin

11.3.4.3.1 Maximum Accessibility: Making Your Web Site More Usable for Everyone

11.3.5 使用级联样式表?

Cascading Style Sheets

11.3.5.1 对格式的控制没有限制

11.3.5.2 灵活性

11.3.5.2.1 一个简单的改动就可以改变整个页面

11.3.5.2.2 例如：允许重新定义文字大小

11.3.5.3 浏览器表现一样

11.3.5.4 序列化内容

11.3.5.4.1 将内容按预设的顺序呈现给有阅读障碍的用户

11.3.6 去摘够得着的果子

11.3.6.1 为每张图片增加alt文本

11.3.6.2 让你的表单配合屏幕阅读器

11.3.6.2.1 使用html的label元素把表单字段和提示文本联系起来

11.3.6.3 每个面最前面增加”跳转到主要内容“的链接

11.3.6.4 让所有人通过键盘就能访问

11.3.6.5 注意：自适应技术对JavaScript支持不是很好

11.4 好的例子

11.4.1 公告板上为纸质文字，其上蒙了一层有机玻璃，玻璃上印着盲文

1. 第12章 救命！老板想要我……

12.1 两封邮件

12.1.1 要求太多个人数据的危险

12.1.2 过份强调网站花哨的危险

12.2 注意：老板坚持糟糕设计想法的背后，可能是良好的意图?

尝试着理解这一意图，可能更好的解决问题

1. 推荐读物

13.1 作者认为好的书，应该不都是广告

13.2 Information Architecture for the World Wide Web

13.2.1 透彻的讲解了导航、标签和搜索，极具实用性

13.3 Why We Bug: The Science Shopping

13.3.1 解决这样的问题：创造复杂且引人入胜的环境，让人们寻找所需商品，而且能找到它们

13.4 Sources of Power: How People make Decisions

13.4.1 “我们认为我们是怎么做的”和“我们实际上是怎么做的”之间的区别

13.5 The Practice of Creativity: A Manual for Dynamic Group Problem Solving

13.6 www.useit.com

13.6.1 积极的可用性倡导者

13.7 Homepage Usability: 50 Websites Deconstructed

13.8 Web Application Design Handbook: Best Practices for Web-Based Software

13.8.1 新手的入门指南：大量最佳实践、秘诀、有趣秘诀

13.9 Defensive Design for the Web

13.9.1 如何改进错误消息、帮助、表单和其他危急时刻，充满最佳实践，如何防止用户出错、从错误中恢复

13.10 The Design of Everyday Things

13.10.1 看完，你再也不会用以前的方式看待门把手了

13.11 A Practical Guide to Usability Testing

13.11.1 用户测试指导书籍

13.12 Usability News

13.12.1 http://psychology.wichita.edu/surl/

13.12.2 http://webword.com/

13.12.3 http://usabilityviews.com/

13.12.4 http://usability.gov/guidelines/

关于软件文档的争论从来就没有停止过；最新的状态是：不断有新的争论加入。more

*软件文档有哪些？

本文的范畴包括：UX交互、需求规格说明、原型…

软件文档有用吗？

• 从PM的角度，这是递交必须的形式

• 从开发人员的角度，项目开始的时候，架构师或者开发人员总是需要需求说明、原型等资料，进行架构、编制代码

• 从双方的角度，软件文档可以作为沟通工具。包括PM与开发人员的沟通、老员工与新员工的沟通，总是需要有些媒介、平台，这时软件文档可充当双方可共同理解的沟通桥梁

• 从客户的角度，客户总是喜欢厚厚的文档，尽管他们可能根本就不看

软件文档为什么会有痛？

• 过时、不一

这应该是文档最被人诟病的地方。过时、不一致的文档是无效的，因为也就没人看

现状是

• 往往项目开始的时候，用文档进行沟通、设计；开发到后期，各种文档就被荒废了

• 或者反过来，设计、开发的时候根本就没有文档，而是在快结束的时候，根据客户的要求、或者项目组发现需要一个架构图来进行知识传递，从已有代码反过来提取生成文档

未完待续…

什么是土憋PM？用很土的方法、慢慢憋大的PMmore

获取知识有哪些途径？极端的说，有两种：一种是学院派的系统性教育，如学业有成的海龟；另一种是草根派的自学成才，如八卦新闻中乐见的“农民自造潜水艇”。殊途同归，做到极致，都能做好。

现实的说，极端的情况比较少，大部分是“混合型人才”。我们多多少少都受过系统的教育，又总是自己摸索着，慢慢的也就形成了自己的认知、知识体系。

系统性教育与自学成才，选择哪种更合适呢？这得看情况了。譬如，刚学完计算机网络基础知识，自己制作些泛黑客的网络小工具，就更能体会其中的内涵。再比如，在学一个新概念时，在网络上东找西查了半天，脑子里有零碎的概念，却不能很好的串联起来。这时，找些书籍、系列教程之类的内容，系统性的学习，会更有收获。

经常听到这样的抱怨（包括我自己）：要是有高手能指点一二，自己就能更快的成长，也不会走弯路，也不用这么茫然、疲惫

怎么说呢，真正的高手，可遇不可求；能了解自己的情况、给出指导性建议的高手，就更是凤毛麟角了。现实的说，自己能做的就是广开言路，多多的倾听别人对自己的反馈，从中筛选出有用的，然后自己摸索着改进。

回到标题，自己现在对于PM刚刚入门，这时系统性教育简直就是雪中送炭。不过，限于国内PM体系并不突出，相关的培训教育也不多，这条路就很难走通了。反过来，只能土憋。

最佳实践：

• 看书；书籍的系统性强，能提醒自己遗漏的地

• 网络；网络的时效性强，如订阅牛人的博客、看相关领域的新

• 积累；看到好的设计、创意，不客气的收藏起来，酝酿

• 实践；PM最终的落脚点，就是设计出好的产品；从设计搓的产品开始，慢慢实践