阅读本身相关
- 据我所知挺多人（举例说中文的人）看花体字或全大写的字很困难，比如菜单，新闻标题。但字母国家的人似乎没有这个困扰，之前和国际友人聊天得到的影响是，中国人是看字的整体样子，而他们是从左往右看，类似按顺序拼出来，于是减缓了变成大写或者花体字就很不一样的问题。
- 但这本书中关于阅读的介绍（基于英语）却说初级阅读者才会读出来，相当于语义驱动，需要读出来根据上下文来理解（os：说明需要根据上下文来理解就是因为学的不好啊...）。而训练过的熟练的阅读者是特征驱动，即大脑无意识的就处理了内容。这样想的话，一目十行的人肯定也不会在心里“默读”，毕竟默读的速度太慢了。而这一点和语言本身没有关系。
我赶时间，所以我走了远路
- 如果两者非要选一个，不动脑子胜过按键，只要每一次按键操作都是明确简单的。
- 另一种说法是经可能的减少用户的操作，肯能会想方设法的合并内容使功能“显得”简单。不能说完全不对，但也要适当，如果实在合并不了，宁愿多一步，保证清晰优先
忘了收尾工作
- 因此在收尾处提醒很重要。比如车灯不关会提示音报错并且不能锁车门。
从经验中学习是很容易的
- 比如开车，习得之后可以不再需要不间断的主动意识，可以并行，比如同时听歌聊天。
只要一点功夫就能解决，也不愿意做
- 比如一个后台有demo，但一报错最先想到的是找技术，而不是对比自己的操作和demo有什么差别，错误提示是怎么样的。（人之常情，怎么办呢？当然是原谅他啊）
关注用户目标
- 用户主动打开一个软件，是带着自己的目标的，而不是我们想要让他做的事，用户在乎的只是我们的东西是否能让他达到他的目标。
想要的工具和得到的工具之间的差距，执行的鸿沟
对象，用户需要看到的东西
- 对于后台来说，或者是我们需要单独管理的东西，比如用户数据
对象操作矩阵
- 很多操作是通用的，矩阵的形式很方便表达
- 矩阵如果特别乱，也说明后台设计可能有问题，至少会很难学习操作
复杂源于不同而又相似的概念
高响应的需求
- 0.1s之内要有反馈，至少显示btn已被按下，否则要显示在忙碌。比如发音，需要单独取音，如果不能立刻播放，至少要让用户感觉已经按到了正在准备播放，否则会一直按。
- 10s量级的任务就为重量级操作了。比如搜索。
- 避免不了的延迟放在任务单位之间
- 先显示重要信息，比如低像素的图片，文档的第一页。
- 高响应是设计问题：随着计算机的进步，负荷也会增重，依旧会有计算难度，给用户高响应的体验是设计问题。
