Table of Contents generated with DocToc
- 别让我思考
- 我们实际上是如何使用web的
- 为扫描设计，而不是为阅读设计
- 建立清楚的视觉层次
- 利用习惯用法
- 用户喜欢无需思考的选择
- 省略不必要的文字
- 设计导航
- 设计主页
- 开发团队关于可用性的讨论
- 可用性测试
- 尊重用户，并获得用户尊重
- 可访问性
- 减少可能让用户迷茫的东西，文案的明了性至关重要
- 必要部位的强识别性
页面要做到不言而喻。如果不能，那至少要做到自我解释
扫描/满意即可/勉强应付
- 用户不会阅读，而是扫描
- 用户不会斟酌后仔细选择，猜测与随机占多数
- 用户很少会按照我们所设计的去使用产品，但依旧能够使用
网站可用性测试
帮助用户正确使用网站，引导他成为“专家”，把握全局，那样用户有更多的可能会留在这个网站成为老用户
- 在每个页面上建立清楚的视觉层次
- 尽量利用习惯用法
- 把页面划分成明确定义的区域
- 明显标识可以点击的地方
- 最大限度降低干扰
- 越重要的部分越突出
- 逻辑上相关的部分在视觉上也相关
- 逻辑上包含的部分在视觉上进行嵌套
好的视觉层次通过预先处理页面，用一种我们能够理解的方式对页面的内容进行组织并区分优先级
如果要创新，那么：
- 新东西必须和习惯用法一样清楚、一样不言而喻，没有学习曲线
- 能够给用户带来很大价值，值得他花时间学习
“达到任何地方的点击次数”：
真正的问题不是到达目标之前要点击的次数，而是每次点击有多艰难--需要多少思考，还有多大的不确定性来判断自己是否做了正确选择
对于欢迎文字和说明文字要精炼精炼再精炼
- 网站ID标识（名称/logo）
- 网站导航
- 用户可以比较方便的回退到上一步操作
最重要信息争取在首屏展现
网站标识
- 我们很可能会将个人喜好带入到产品调研和讨论中，并误认为自己喜好的也是用户所喜欢的
- 不同职位会带来不同的偏见
- 所有web用户都是独一无二的，没有什么所谓的普通用户。他们对网页的个人反应和那么多不同的变量有关系
- 试图用一些简单的喜好来形容用户既琐碎又没有什么关系
- 好的设计会把这种复杂性考虑进去
- 对于大部分web设计而言，没有简单的“正确”答案。良好的、一体化的设计能满足需要，也就是说，经过仔细考虑、实现和测试的设计就是好的
- 测试。通过测试观测用户的动机、理解和反应的不同
一小组人（5~8）参加，对展现给他们的想法和设计做出反应。 主要价值来自参与人员彼此的反应。可以快速得到用户意见和感觉
可以抽象的获知用户想要什么、需要什么、喜欢什么，测试网站的概念是否有意义，价值主张是否吸引人,但不太适合用来了解网站的运行情况和如何改善网站
一次一个用户的展示内容，并要求用户：
- 说出这是什么
“理解”性测试 让测试用户看到产品，看他们是否理解产品，如何理解产品，理解产品的目标、价值主张、组织方式、运行方式
- 试着用它来完成一项典型的任务
观察用户是如何完成任务的，过程中会遇到哪些问题
测试是一个不断迭代的过程，应该穿插在设计开发之中
在可用性测试结束之后：
- 给问题分类
- 用户不清楚概念
- 用户找不到自己想要的东西
- 内容太多了
- 解决问题
- 忽略“皮划艇问题” “皮划艇问题”指初次使用产品时因小困惑而产生的错误，这些错误往往会在之后被自主修正，不是什么问题
- 抵制添加的冲动 在测试的时候看见用户没有清楚理解一些功能的作用的时候，大部分人的第一反应是为功能添加说明。而正确的解决方案往往是去除一些让人混淆的内容，而不是额外再加入其他干扰
- 不要太看重人们对新功能的要求
- 抓住够得到的果子
- 恍然大悟型
- 便宜型
- 知道人们在你网站上想做些什么，并让它明白简易
- 告诉用户他想知道的
- 尽量减少步骤
- 保证信息准确而有用，并用清楚的方式表达
- 为用户提供协助
- 容易从错误中恢复
可访问性不仅仅针对正常用户，也是对于残疾用户而言的