本书主要讲述人机交互学(Human-Computer Interaction，简称HCI)这一学科在Web界面设计领域中的应用。
正如你所看到的，这是一本文字轻松，而且有很多好玩插图的……技术理论书籍。
没错，技术理论。它将和你讨论关于软件(或网站)的界面与用户之间的关系——界面是你做的，而使用它的是用户——所以，别自信满满地说自己做得很牛，让我们听听用户的意见。这本书能告诉你这一套顺序大概是怎样的，你应该注意些什么，*终水到渠成的是一个能经得起考验的产品。
这本书可以说是一本针对广泛大众，以及那些没有接受过人机交互和可用性专业培训的用户界面设计人员的辅导和帮助手册。你不必背诵那些拗口的专业词汇，你只需知道“我该如何去做”从而解决问题。这本身也是人机交互学科的一个重要原则——“易于学习，从而便于使用”。
你明白了。这不是本情节跌宕起伏的小说，也不是行文优美如诗的散文。但我仍然希望它能给人带来快乐——学习不是一件枯燥的事，但很多人把它变得枯燥了。绝大多数技术理论书籍的作者们都正襟危坐就好像板着面孔的老师，不可否认，对待学术问题应当态度严谨，但是严谨不代表枯燥，能在专业知识课堂上把

第二章 了解用户，了解需求
交互设计是要优化人们与计算机产品的交互。
怎么优化？这个问题暂时先放在一边。让我们先想想优化给谁。
没错，我们当然是优化给用户。但是如果你不知道用户是谁，也不知道他们想达到什么目的，那你怎么知道该优化什么，又该如何优化呢？
所以，一切的出发点应该是：找出谁才是你需要了解的人，然后弄清楚他们想要什么。
前面说过，“理解用户的需要，从而建立明确的需求”是交互设计的基本活动。我们就是要将用户时时刻刻摆在所有过程的首位。这就是“以用户为**”的方法。
2.1 谁是用户？
找出用户似乎是一件很容易的事情。但首先我们需要弄清楚“用户（user）”和“客户（customer）”的概念。没错，产品的销售对象是“客户”，只有客户才是愿意掏腰包购买产品的人，考虑他们的感受是非常重要的。但是客户并不就一定会亲自使用我们设计的产品。
换句话说，客户不一定就是用户。
举个简单的例子，某个网站制作公司的老板不一定必须得是网页设计师。他确实需要购买一些软件产品用于开发网站，比如Dreamweaver、Visual Studi0，甚至包括Flash和Photoshop。他购买了这些软件，他便是Adobe或者微软的客户。但老板并不一定要去使用这些软件，甚至可能根本就不懂如何操作。也就是说，他没有与这些产品发生直接的交互，自然不是软件的用户。软件是否容易使用，界面是否友好，有没有良好的通用性，这些跟他没有多大关系。
但是，他手下的那些网页设计师每天都面对着这些软件，他们就是软件的用户。而交互设计的目标正是为了支持这些人（他们很辛苦）的需要，满足这些人的期望，让他们在工作中能够更方便、更舒心和更有效。
……

前 言
序章 关于这本书
0.1 谁该看这本书？
0.2 这是本什么样的书？
0.3 怎么用这本书？
0.4 感谢这些伙计
**章 你首先要知道的一些事情
1.1 我听说过这些词不过它们到底是什么？
1.1.1 什么是UI设计
1.1.2 什么是交互设计
1.1.3 什么是好的用户界面设计
视觉表达不清
非常繁琐
提示混乱
难以使用
强迫用户
1.1.4 那么该怎么做？
什么人会使用产品？用在什么地方？
用户会有些什么样的行为？
1.2 我干嘛得学这些玩意还要买本书？！
1.2.1 用户界面不是次要的工作
1.2.2 用户界面设计不是界面程序设计，也不是界面图形设计
对于软件设计师来说
对于美术设计师来说
真正的用户界面设计人员
1.2.3 交互设计是一门跨学科领域
1.2.4 不用成为专家，理解方式即可
1.3 OK，那我该怎么做？
1.3.1 交互设计的4个内容
理解用户需要，建立用户需求
开发一些候选设计方案
制作设计方案的原型
用户测试和评估
1.3.2 交互设计的3个特征
以用户为**
建立明确具体的可用性标准
反复迭代
1.3.3 交互设计的2个目标
可用性目标
用户体验目标
1.3.4 摩西的十诫
让用户随时了解系统的状态
系统应与真实世界相符合
给予用户控制权和自主权
提倡一致性和标准化
帮助用户识别、诊断和修复错误
预防错误
依赖识别而不是记忆
强调使用的灵活性及有效性
*小化设计
提供帮助及文档
1.3.5 如何粗略地评估可用性
第二章 了解用户，了解需求
2.1 谁是用户？
2.1.1 普遍而又特殊的用户
用户的普遍性
用户的特殊性
两者兼顾
2.1.2 用户可不是越多越好
2.1.3 “阿童木”的诞生
2.2 什么是需求？
2.2.1 “需要”产生需求
2.2.2 点了牛扒，端上来的却是意大利面
2.2.3 各种类型的需求
功能需求
用户需求
数据需求
环境需求
可用性需求
2.3 如何确定需求
2.3.1 介绍一些数据搜集的方法
问卷调查
用户访谈
观察和提问
集体讨论
2.3.2 筷子、刀叉和勺，哪种餐具*好？
2.3.3 一些要注意的地方
一切的**都是为了搞清楚用户需要什么
要考虑所有的用户类别
每个用户类别只派一位代表参与是不充分的
打“组合拳”，不要单一套路
在可能的情况下，先小规模试验
如果得到的需求信息太多
记录数据同样很重要
2.3.4 解释与分析数据——一道填空题
2.4 归根结底，我们要了解任务
2.4.1 用讲故事来描述任务
2.4.2 用流程图描述任务
2.4.3 理想和现实的差距
守旧的用户
过分的用户
妥协还是抗争？
2.5 环境？什么是环境？
2.6 做个小结
第三章 设计方案和制作原型
3.1 为什么，以及怎么做
3.2 初级原型和**原型
3.2.1 初级原型很重要
草图，或者说涂鸦
连环画
制作卡片
模拟界面
3.2.2 **原型同样重要
3.2.3 嗯，不过原型仅仅只是原型
3.3 概念设计，或者说初步设计
3.3.1 伙计们，让我们先考虑功能
3.3.2 概念模型是个什么玩意？
开放思路，同时考虑用户和应用环境
保持简单，但也不要过于简单
使用初级原型来快速获取反馈
反复迭代进行设计
3.3.3 开发概念模型的几个问题
采用什么样的交互方式？
是更“智能”还是更“服帖”？
是否存在合适的熟悉概念进行映射比拟？
3.3.4 在概念设计中使用原型
3.4 物理设计，或者说具体设计
3.4.1 一些具体的设计指南
力求一致性
允许频繁使用系统的用户使用快捷键
提供明确的反馈
设计对话，告诉用户任务已完成
提供错误预防和简单的纠错功能
应该方便用户取消某个操作
用户应掌握控制权
减轻用户的记忆负担
3.4.2 界面元素和界面风格
3.4.3 菜单（或者导航栏）的设计
3.4.4 图标的设计
不要“辞不达意”
小而简单
3.4.5 屏幕布局的设计
大的方针
同时也要考虑细节
还要很多地方需要注意
3.4.6 别理那些复杂的工具，我们做的是Web
第四章 以用户为**的开发
4.1 为什么要让用户掺和进来？
告诉他们别太天真
另一方面他们才是真正的主人
4.2 支持用户，而不是限制他们
排**位的永远是用户，不是技术
给他们*习惯的环境
要支持用户，就得考虑周全
经常向他们咨询意见
4.3 如何让用户参与？
4.3.1 用户参与的不同形式
**之一：让用户作为设计组成员
**之二：用户远距离参与设计
4.3.2 用户参与的是与非
4.4 别用望远镜，要现场研究
4.4.1 关于现场研究
4.4.2 你是师傅，我是徒弟
不是在会客室
建立正确的关系
该问就大胆问
不要跑题太远
4.4.3 这不是你的地盘，别太不拘小节
4.4.4 我们能得到什么？
第五章 文化的差异
5.1 什么是文化的差异？
5.2 对于Web和Web-based产品来说
5.2.1 一次要做几件事？
5.2.2 高度认知和低度认知
5.2.3 功能还是关系？
5.2.4 网页和界面的视觉反映
5.2.5谁的错？
5.3 国际化和本土化
注意适配分辨率的大小
尽量多用被广泛接受的图标
绘制图标时注意地域性
翻译时使用用户习惯的表达方式
注意不同地区使用的单位和格式
注意文字的输入
避免出现对某些地区不适用的信息
其它方面
第六章 网页的可用性
6.1 人们是如何使用网页的？
6.1.1 他们很会节省时间
6.1.2 他们也不会仔细考虑
6.2 好感度计量器
6.2.1 我经历过好几次这种情况
6.2.2 这些都会降低好感度！
让我感到郁闷
总是误导我
总是让我猜
总是要我找
总是说我错
耽误我的时间
甚至还让我抓狂
6.3 因此，为扫描而设计
6.3.1 更清楚的布局和视觉层次
越重要的内容越醒目
相关的内容看上去也得相关
包含的内容要显示从属关系
别显示太多无关的信息
6.3.2 清晰地划分页面区域
6.3.3 适应用户的习惯
6.3.4 提供目光的“落脚点”
6.4 同时，减少用户的思考
6.4.1 减少不确定因素
6.4.2 保证网页的一致性
一致的网站标志和导航栏
一致的页面布局
一致平衡的信息结构
一致的重复性元素
一致和谐的字体和色彩
一致，但不一样
6.4.3 明显标识可以点击的地方
有时候下划线可有可无
有时候*好有下划线
超链接和按钮
6.4.4 清晰、简单的网页内容
使用用户的语言，而不是技术语言
使用通俗的语言，而不是故作高深
减去不必要的词句，让页面更简短
不要夸夸其谈，或者让人摸不着头脑
6.5 告诉用户他们在哪里
6.5.1 导航栏存在的意义
6.5.2 导航栏所需要的元素
网站logo标识
网站的栏目
“回到首页”
附加功能
搜索工具
6.5.3 导航指示、页面标题和“面包屑”
导航指示
页面标题
“面包屑”
第七章 Web-based产品
7.1 Web或者不是Web？
有一些比较偏向于软件
有一些则更偏向于网页
有些产品比较单纯
有些产品的用户群比较广大
*后它们还是网页
7.2 我为什么说要考虑用户的感受
7.3 首先看看菜单和对话框
7.3.1 我需要菜单，但必须是好菜单
时隐时现的菜单项
探头探脑的菜单项
7.3.2 让我陷入困境的对话框
让我没有选择
让我不知道该怎么选择
没有第三种选择
7.4 你真明白那些控件的作用吗？
7.4.1 单选按钮和复选框
把复选框当作单选按钮
把单选按钮当作复选框
是必须要我选，还是不需要我选？
7.4.2 标签虽好，问题多多
标签只能用来导航，不能选择数据
到处都是的标签
太小和太大的标签
7.4.3 简单而又不简单的文本框
在不该用的地方使用文本框
该用文本框的地方却又很随意
7.5 每一个元素都要有合适的位置
7.5.1 控件的摆放位置
胡乱放置的按钮
距离产生美？
7.5.2 你无法逃避的对齐方式
是左对齐还是右对齐
不要只注意一边
如果有时候左右都不能对齐
上下也要对齐
第八章 测试可用性
8.1 为什么要测试？
8.1.1 美国到底民主还是不民主？
我喜欢的，别人也应该喜欢
角色的不同导致看法不同
8.1.2 这不是简单的是非题
8.2 几个要注意的事实
8.2.1 一些需要记住的事实
可用性测试不是软件测试
哪怕只测试一个用户，也比不做测试要好
早点测试一个用户，好过*后测试100个用户
“迭代”的测试和频繁的测试
测试后马上回顾测试结果
8.2.2 一些需要避免的认识
不要认为可用性测试很难
不要认为可用性测试总是非常昂贵
不要认为可用性测试是表层问题
不要认为测试是要去“证明”什么
不要仅仅测试，却不纠正发现的问题
8.3 测试的前期准备
8.3.1 测试的地点和设备
*正式和*精良的装备
你也可以优化和精简
8.3.2 测**户的招募
测**户的选择
究竟每次应该测试多少用户？
如何招募用户？
8.3.3 主持人和观众
谁适合当测试的引导人？
谁适合当测试的观察者？
8.3.4 道德问题
8.4 测试的过程
8.4.1 设计好考题
8.4.2 介绍阶段
8.4.3 正式测试
观察用户
让用户进行有声思考
提出问题
尊重测**户
一个实例你就能明白
8.4.4 马上回顾和总结
8.5 让专家来评估（别忘了，你也是专家）
8.5.1 现成的原则——启发式评估
8.5.2 你也可以看看这些具体的评估角度
关于一致性的评估
关于界面简洁性的评估
关于信息反馈的评估
关于用户动作性的评估
关于产品特色的评估
8.6 测试需要修正
有些问题可以忽略
有些要求也可以忽略
别顾此失彼！
第九章 了解满意度
9.1 询问用户：问卷调查
9.2 询问用户：访谈
终章 回到开始：什么是好的用户界面设计

本书从*日常的的界面使用体验出发，用通俗易懂的语言，结合实际工作案例进行讲解，是一本难得的国内交互设计的入门读物。本书由浅入深的介绍了UCD的相关知识，如UI设计帮助你从交互设计的角度重新认识Web设计。其内容易于理解，对于想更多的人传播UCD思想很有意义。
这是一本极其幽默的电脑书，一本能够带给你快乐的书。 本书的作者是个多才多艺的家伙，既是UI设计师和漫画家，也是布鲁斯口琴和摇滚乐队的吉它手，同时，业余时间还好写魔幻小说和计算机书。
本书不仅能够带给你快乐，还饱含思想，大把大把的思想，**都是货真价实的东西，就像那种大皮沙发一样，里面塞满了实实在在的材料，都是可以用到你的Web开发中的。