本节书摘来自华章出版社《iOS应用软件设计之道》一 书中的第1章，第1.4节，作者：（美）William Van Hecke ，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.4　列出提纲时的更多输入

除了厘清头绪外，要列出提纲还有许多输入源。你可以通过开会来推敲出某项功能的细节。提纲是个随你所想，跟踪所有话题、子话题、问题和决策的极好方式。
如果你能直接与现有用户沟通（因为你正工作于已有产品上），或者与目标受众中的成员沟通，就可以获取海量的深层次信息。毕竟，你不能一个人想到所有东西，与用户沟通（来自支持邮件、评价等）能够让你关注自己的不足，而不是对其需求表现出全面、均衡的表达。
可供你收集那些应用软件的用户的看法的办法很多，下面是最常用的一些。
会面：这既可以是正规的，你邀请目标受众中的成员参加有组织的对话，在此你记录数据，随后分析；也可以不是正规的，你事先准备几个关键问题，在会议或行业展览上遇到某个用户，就问问他。如果你擅长从人们那里得到诚实的答案（只要他们真诚待你，这很容易），与某个热心用户交谈15分钟，其效果比在单位内部开一星期的会效果还要好。
情景探究：倘若你在寻求帮助人们做某件特定的工作，这会是个深入探究你要处理问题的极佳办法。在情境探究中，你在用户工作时拜访他们，观察他们的工作过程，尽可能地获取他们的说明。如果你对这种做法感兴趣，可以看看Hugh Beyer和Karen Holtzblatt合著的《情景式设计》（Contextual Design），此书是这种做法的鼻祖。
竞争分析：如果你想做个东西，挤进业已存在的产品市场，就一定要做些工作，找出现存产品没有做到的地方。你的应用软件做的哪些事情其他应用软件也做到了？依你看，这些开发者为何选择这样的功能集，做出这样的设计决定？什么是他们知道的，而你却不知道？更重要的是，你的应用软件有什么优势，让人们愿意买你的软件而不是别人的？系统地考虑这些问题，能够让你更深入地了解如何把你的产品差异化，做出真正有价值的东西。
Ideo方法卡（在前言中做过说明）有好几种做法，可供你搞清楚用户真正希望和想要的东西。
一旦你做出来产品，供这个世界使用，提纲和缺陷数据库就是个记录用户反馈和研究用户的结果的好办法。倘若没有数据库，即使你阅读了有关应用软件的全部邮件和推特信息，只是偶尔做一下用户测试，你也很难让用户告诉你有关应用软件的喜爱与讨厌之处。
在保存记录时，你可以实际查看人们是否爱抱怨如何使用某些功能，或者测试参加者与设备交互时是否存在麻烦，而不是依赖令人讨厌的选择性记忆。但是，一定要记住，你得到的用户反馈并不精确代表用户对你的应用软件的所思所想！它代表的是人们体验的一部分，人们的体验会被乐意写信反映问题的少数用户曲解。在第10章中，我们会详细讲解开发人员与用户的关系。
如果你开发过软件，就可能熟悉版本控制系统（如Subversion或Git），它维持一个团队所有源代码变动的中心仓库。版本控制不仅对代码有用，还可以放入所有设计资源。能够访问你的设计思路历程是无价的，不至于让你回想已经丢失的草图，而需要再画一张图。
版本控制系统不必是必需的；如果你用的不是命令行方式，可以使用诸如Black Pixel的图形客户端Versions（其可视化比较工具Kaleidoscope用来查看不同版本的设计文档，效果非常好）。另一个杰出的工具是Layer Vault，是专门为设计人员创作的基于网页的版本控制系统。