列提纲时还要顺便解答一个关键的设计问题：这些条目会不会是同一件事物呢？设计的相当大一部分工作就是找出产品到底要做成什么样子，它的每个组件如何组装到一起？两个需求能否通过一个功能满足？某个功能是否做的事太多，若分解成多个功能，会不会更顺畅些？作为设计人员，你的个人风格很大程度上就是你在合并、拆分应用软件的组件时的力度，所以要准备花大量的时间来考虑这个问题。

例如，在SnackLog设计中，你正考虑是否要包含标记和多用户支持。在组织提纲时，你发现它们似乎均可以放到“分类化”下面。这是个信号，表明它们也许可以被合并。要考虑是什么（如果有）造成了这种区别。它们都要求设置、应用购买标签。在浏览购买记录时，它们也需要过滤或搜索。看上去是如此相似。

你可以列出好几条多用户支持的功能，因为它们不太像iOS的功能。例如，对其他用户隐藏某个用户的购买记录。iOS设备通常是一个人用的。如果有多个人在一台设备上存放记录，他们也很可能是一个家庭的，因此不会介意共享信息。最后，在iOS应用软件里支持多用户并不合理。但如果人们真想共用SnackLog，可以为每个人创建个标记，就可以得到多用户支持的绝大多数功能。所以这两个功能可以合并。

所以基于两点原因，你就可以放下支持多用户的想法。一是在iOS上似乎没有必要；二是你可以采用标记的办法实现多用户的多数功能。事实上，你还不算真正地抛弃这个功能，而是将其合并到一起。在iOS上充满了此类功能的合并问题。

还要知道，有些时候看似一个功能，实际却要拆分为一个或多个更专一的功能。以删除为例，乍一看，删除所有条目只是删除单一条目的变种操作。所以无论你构思到哪种操作，都要每一条目逐个表现出来可删除的功能（在实际交互过程中，可以想象有个垃圾桶图标，你点击它时会提供“单个删除”和“全部删除”按钮）。这么做有点可怕。人们经常会删除单个条目，但很少想把整个购买记录都干掉。虽然都是删除操作，但你需要用迥然不同的方式来设计它们。在修订自己的提纲时，你可以把“全部删除”从浏览功能移至设置区域。你也许不再将它称为“删除”，而改称为“复位”，以示区别。构思符合你的有关功能思路的词汇，将有助于你设计实现它们。