1. 概念的特性

1.1. 专一性原则(specificity principle)认为概念与目的应该一一对应

1.1.1. 专一性原则已被证明是概念设计中最有用的原则之一
1.1.2. 一个概念最多只能满足一个目的

1.2. 很少有没有目的的概念

1.2.1. 如果本应隐藏的用户机制被暴露，可能会产生没有目的的概念
1.2.2. 无目的的概念会扰乱界面并迷惑用户
1.2.3. 无目的的概念是奇怪的

1.3. 没有概念来实现目的可能是因为设计者领域之外的限制，有时或许只是因为严重的疏漏

1.3.1. 概念缺失则会导致更为复杂的交互

1.4. 概念冗余，即多个概念服务于同一目的，会导致用户困惑与资源浪费

1.4.1. 概念冗余在两个本应相同的概念之间引入了令人困惑的区别，并迫使用户用不同的方法来做相同的事情
1.4.2. 概念冗余通常是由于在概念设计时只考虑了某些特定情况（可能是由子团队负责开发），而没有对软件的核心概念给予足够关注
1.4.3. 每个目的都应该通过最多一个概念来实现并避免概念冗余
1.4.4. 避免概念冗余当然也是合理的，因为可以节省精力

1.5. 概念过载，即一个概念具有多个目的

1.5.1. 错误聚合，设计者错误地将多个目的当成一个目的
1.5.2. 目的被拒，即设计者有意忽略用户目的
1.5.3. 突发目的，概念随着时间的推移演变出新的（通常是不兼容的）目的
1.5.4. 搭载现象，即设计者试图将新目的挂靠在旧概念上，以便减少设计和实现工作
1.5.5. 概念过载会由于不相关目的的耦合而引入额外的复杂性
1.5.6. 概念过载会导致功能受限，因为第二个目的被强加到原有概念之上

1.6. 导致软件复杂性的增加和清晰度的降低

1.7. 一致性原则有助于确认有多个组成部分的目的究竟算一个目的还是多个目的、是否可能整合为一个单一目的，各部分是否有共同的利益相关者、它们是否为一个共同的使命服务，以及它们之间是否有冲突

1.8. 在软件设计中，概念和目的应该一一对应

1.8.1. 每个概念都应该有一个激发它的目的
1.8.2. 软件的每一个目的也都应该有一个完整的概念

2. 无概念的目的

2.1. 如果对设计进行审视，你可能会发现有些基本目的并没有与之对应的概念来实现

2.2. 所有软件都会随着时间的推移而发展，新的需求总会出现

2.3. 设计之初就明显缺少概念的目的

2.4. 通信人概念

2.4.1. 大多数电子邮件客户端都缺少通信人概念，该概念用于识别邮件的发件人和收件人
2.4.2. Gmail这样的封闭电子邮件系统很容易实现通信人概念，但要想在更广泛的范围内实现这个概念，则需要通用的身份验证作为基础
2.4.3. 有了通信人概念，电子邮件的发件人字段就无法被伪造，垃圾邮件也将更容易受到控制

2.5. 备份中的删除警告

2.5.1. 从计算机中删除的文件会在一段时间（比如30天）之后从备份中被删除
2.5.2. 意图很明确：阻止客户将备份服务当作无限期的云存储
2.5.3. 备份软件可以提供一个概念来跟踪删除操作，并在删除操作发生时给出警告，这样就可以确定用户是否有意删除，以免在他们还没注意到之前就从备份中删除了文件

2.6. 缺少样式概念

2.6.1. 一个概念在某一类软件中经常使用，但在另一类软件中却常常不可用，即使这个概念对于后者而言也非常有用

2.7. 不完整的模板概念

2.7.1. 由于软件的形式有限，导致这个概念的常规目的无法实现
2.7.2. 解耦设计的关键是网站制作者不需要一开始就确定模板，而是可以先试着加入一些内容，然后看看内容在模板里看起来如何

2.8. 随着技术的普及，人们很容易认为软件设计中所有的核心问题都已经解决了

2.8.1. 这些没有概念的目的表明，即使在人们最熟悉的软件中，还有一些最基本的需求没有得到满足，软件设计师仍然有重要的工作要做

3. 概念冗余

3.1. 如果存在另一个用于相同目的的概念，那么当前的概念就是冗余的

3.1.1. 设计师最初看到了两个截然不同的目的，但最终却发现它们只是同一个更通用目的的变体

3.2. Gmail的分类概念

3.2.1. 分类概念遭到否定的根本原因在于它是冗余的

3.3. Zoom广播

3.3.1. 广播概念是一个冗余概念
3.3.2. 聊天概念和广播概念似乎具有相同的目的，但又不尽相同
3.3.2.1. 广播消息在屏幕上闪过，而聊天消息则出现在滚动的消息记录中
3.3.2.2. 广播消息可以跨越会议室，聊天消息则不能
3.3.2.3. 广播消息会很快消失，聊天消息则会保留在消息记录中
3.3.2.4. 在理想情况下，聊天概念应该包含这两个概念的特性

3.4. 消除概念冗余将减少开发人员的工作，并为用户提供更简单、更强大的工具

4. 概念过载

4.1. 最有趣的软件设计原则是一个概念最多只能有一个目的

4.2. 一个概念不能很好地满足两个目的

4.2.1. 目的指导着概念设计的各个方面
4.2.2. 如果软件有两个不同的目的，它们必然会向不同的方向发展，而概念设计也必须在它们之间做出妥协
4.2.3. 更有可能的是，这种设计最终连一个目的也无法完全满足，因为这个目的本来朝着一个方向发展，却被拉向另一个方向

4.3. 错误聚合(False convergence)

4.3.1. 错误聚合是指一个概念针对两个不同的功能，而这两个功能被错误地假设为具有相同的目的
4.3.2. Facebook的好友概念
4.3.2.1. 允许两个用户建立一种关系，在这种关系中他们可以看到彼此的帖子
4.3.2.2. 隐藏了两个截然不同的目的

>  4.3.2.2.1. 过滤：通过展示好友的帖子，Facebook为用户省去了亲自筛选帖子的麻烦

>  4.3.2.2.2. 访问控制：通过选择好友，用户可以选择谁可以看到自己的帖子

4.3.2.3. 2011年增加了关注概念，只用于过滤帖子，而非访问控制

4.4. 被拒目的(Denied purposes)

4.4.1. 被拒目的是指被设计者忽略的目的，尽管用户有相应的需求
4.4.2. 列出候选目的然后将之否定通常是令人钦佩的，这是防止软件设计膨胀的关键策略
4.4.3. 最有效的箴言是“设计最简单的东西”，这既适用于选择要达到的目的，也适用于设计实现这些目的的概念
4.4.4. 以保持用户界面的简单性为名忽视用户需求，进而否定一个目的，这也可能是一种武断的行为
4.4.5. Twitter中的收藏概念

4.5. 突发目的(Emergent purposes)

4.5.1. 突发目的是原有旧概念新产生的目的，通常由用户自己创造
4.5.2. 一个概念在设计时可能只有一个单一的、引人注意的目的，但随着用户发现该概念的新用途，其他目的可能会出现
4.5.3. 电子邮件的主题行概念

4.6. 搭载(Piggybacking)

4.6.1. 搭载现象指现有概念被调整或扩展以适应新目的
4.6.2. 导致概念过载最常见的原因是，设计师看到了使用现有概念来支持新目的的可能，因此没有设计新概念，省去了设计和实现新概念的麻烦
4.6.2.1. 设计师也可能认为用户会欣赏概念更少、内涵却更丰富带来的经济性，但这通常是错误的
4.6.2.2. 相比于数量较少但是复杂和令人困惑的概念，较多但统一、有说服力的概念更好
4.6.3. 富士相机的长宽比
4.6.3.1. 长宽比概念在RAW格式的文件上非常有效
4.6.3.2. 由于长宽比概念通过重载与JPEG格式相关联导致过载，因此不能单独将之用于JPEG格式
4.6.3.3. 即使你只想以RAW格式保存图像，并且自定义长宽比，在设置图像质量时也必须选择同时包含RAW和JPEG格式的文件，然后再删除JPEG文件
4.6.3.4. 补救方法是提供一个与图像大小概念不同的长宽比概念，使自定义长宽比的操作与选择文件类型的操作相互独立

4.7. 补救方法

4.7.1. 尽可能准确地阐明单一目的，并检查概念的不同动机是否真正反映了同一目的，这样可以避免错误聚合
4.7.2. 认真对待用户的意见和经验，特别是那些技术水平较低和较不愿意采用新技术的用户，这样可以避免出现被拒目的
4.7.3. 突发目的是最难避免的，因为没有人能够预测设计将以何种方式影响其使用场景并创造新的用途
4.7.3.1. 只要意识到突发目的的出现，就可以添加新概念来解决这种概念过载
4.7.4. 应该避免将概念用于相互矛盾的目的来优化设计的冲动，应认识到这样节省下来的努力会导致情况更加复杂，最终付出高昂的代价
4.7.4.1. 避免出现搭载现象

5. 目的的颗粒度和一致性原则

5.1. 设计是否冗余或过载取决于目的

5.2. 需要通过一致性测试，揭示多重目的伪装成一个目的的情况

5.3. 在理想情况下，目的的设定不应该随案例不同而变化，也就是说，目的需要保持一致

5.4. 重新设定目的

5.5. 共同的利益相关者

5.6. 共同使命

5.7. 无冲突

6. 分解概念

6.1. 解决概念过载的方法是分解概念，然后为每个目的建立一个新的概念

6.2. 回应概念，其目的是传递对帖子的情绪反应

6.3. 推荐概念，其目的是管理推送内容

6.4. 特征分析(profiling)，其目的是定向投放广告

6.5. 极端情况是，这三个概念可能构成一个几乎完全不同步的自由组合

6.6. 另一个极端情况是，三个概念完全同步，回应按键也作用于推荐和特征分析

6.6.1. 过载问题已经转化为过度同步问题
6.6.2. 至少在概念分离的情况下，设计中有更清楚的迹象表明这些概念已经耦合在一起，并且即使试图在相互冲突的不同目的之间寻求平衡，概念本身被破坏的风险也比较小

6.7. 概念分解之所以很有价值，在很大程度上是因为它允许将一个特殊的概念（比如Facebook的点赞概念）分解成更一致、更通用的概念，从而为用户提供更简明的体验，并为记录和保存设计知识提供更好的结构