Getting Real 第十一章
第十一章 言语
第一节 功能规格书没有任何的功能
不要撰写功能规格文档
这类蓝图性质的文档通常对最终成品毫无帮助，原因如下：
功能规格都是幻想
他们不反映实际情况。一个应用，在开发、设计、使用前都是不真实的。功能规格只是一些纸上的文字而已。
功能规格都是关于妥协的
它只是为了让人有参与感并感觉快乐，措辞温和，用处不大。对于艰难抉择，暴露公开等关键问题，它也从不涉及。
功能规格只能产生达成一致的幻觉
一群人对某段文字达成一致并不是真正的共识。每个人阅读相同的文字有可能产生不同的理解。之后不可避免地会产生如下言论：“等等，这不是我当初所设想的。”“额，我们当时不是这么描述它的。”“我们当时已经达成一致了，你都签字了。”你一定很熟悉这些套路。
功能规格逼迫你在信息量最少的时候做出一些最重要的决策
在你开始一个项目之前，你对其知之甚少。你做的越多，用的越多，你就了解地越深。这才是你应该做出决策的时刻——当你获得足够的信息时。
功能规格会导致功能过载
在规格书上增加点什么是没有成本的。你可以为了取悦某人就随意增加功能。最终你是为这些项目列表而设计，不是为用户设计。结果是，你的网站严重过载，因为屏幕的顶部有 30 个导航标签.
功能规格无法让你进化、改变
一个功能被终止。即使在开发过程中，你发现这是个错误的决定，你也必须坚持下去。一旦开始创建，任何事情都会改变，而规格书无法应对这个现实。
那么该用什么来替代规格书呢？用一页纸描述你的 App 要做什么。用简明的语言，快速执行。如果一页无法完整描述，那么就太复杂了。这个过程的耗时不应超过一天。
之后开始搭建界面——用界面来代替功能规格。快速画出一些简单的草图。然后将其转变为 HTML 。文字会导致不同的理解，界面能够成为每个人达成一致的基础。
当每个人都使用同一界面时，困惑就消除了。在你开始关心后端代码前，搭建一个人人都可以观看、点击、感受的界面。
忘记死板的规格书。他们让你过早地作出重要决策。绕开规格书，你就能保持灵活。
无用的规格书
一份规格书几乎是无用的。我从未见过一份规格书能在全面和精确上取得平衡。
而我见过很多基于规格书创建出来的糟糕产品。这是最糟糕的一种编写软件的方法，因为这意味这软件是基于理论编写，而不是事实。
—— Linus Torvalds, Linux 创建者 （from Linux: Linus 关于规格书的看法）
与阻碍做斗争
有些人坚持在开始设计之前就确认大量的需求文档，我认为这些人是真正的阻碍，他们会拖慢过程的进展（这些人往往对设计和创新思考没有任何贡献）。
我们最好的成果都是基于脑子里的几个概念，他们是关于网站改进，快速原型，或对设计做出些许改变，之后用真实的数据搭建一个原型。在对原型进行一番探讨后，我们通常能获得一个良好运转的项目，也通常都有个好结果。
—— Mark Gallagher, 公司内网开发者, (from Signal vs. Noise)
第二节 不要制造死文档###
抛弃无用的文书
避免功能规格书是一个好的开始，但别就此停住。应该在任何地方都避免过量的文书。除非一个文档能变成实体，否则不要生成它。
搭建，而不是书写。如果需要解释什么，尝试做出原型，而不是一堆冗长的文档。一个真正的界面或原型能够逐步成为真正的产品，而一页纸，最终只会进入垃圾箱。
这里有一个例子：如果一个线框图注定无法成为实际的设计，那就不要做它了，除非这个线框图最终要转变为真正的设计。
脱离于产品的文档是没有价值的。你所做的一切都应该能够最终转化为实物。如果一个文档在实现之前就停止了，它就死了。
没人会读它
我数不清在开发团队周围有多少无聊的、未读的，盖满灰尘的产品规格书和商业需求文档。我们只是写代码，讨论问题，进行用户测试。我曾经和这样的开发者共事过，他们花费数小时的时间撰写冗长、详细的邮件，或者编码标准文档，而这些最终都无人阅读。
网络应用的前进不依赖大量的文档。软件开发是一个持续改进、迭代的过程，包括了交互，快速决策，以及前进路上的那些无法预测的问题。所有这些都不能，也不应该被纸张所捕获。
不要浪费时间撰写这些美好的幻象，没人会看的。如果你给产品足够的成长空间，它将变成一个与设想完全不同的产品，你要接受这个事实。
—— Gina Trapani, 网络开发者/ Lifehacker (生产力和软件指南) 编辑
第三节 告诉我一个简洁的故事
描绘故事，而非细节
如果你发现需要用语言描述一个功能或概念，尝试写一个简短的故事。不要陷入设计或技术的细节，只需一个简洁的故事。用正常的人类语言来描述，就像一个普通的对话。
它不必是一篇论文。只要描述事件发生的流程。如果能通过你正在开发的用户界面来描述这个故事，那就更好。
重要的是体验，不是细节。考虑战略，不是战术。战术会在你开始搭建具体的组件时落实。现在你只需要一个能开始对话的故事，引导你走上正确的路径。
第四节 使用真实的语言
插入真正的文字，而不是 lorem ipsum
Lorem ipsum dolor 是设计师的好朋友。无意义的文字能够帮助人们理解设计。但无意义的文字同样有危险。
它将基于文本的内容简化为一个视觉设计元素，而不是文字应该呈现的：一段需要阅读或进入的有价值的信息。你不知道放入一段可阅读的内容后会发生什么变化，这意味着你不知道你的网站填充内容后的样子。它在你和现实之间蒙上了一层纱。
你需要一段真实的拷贝来知晓这个字段应该有多长
你需要一段真实的拷贝来知晓表格会如何拉伸或收缩
你需要一段真实的拷贝来知晓你的 App 看起来是什么样的
尽可能使用真实的相关的文字。如果你的网站或应用需要数据输入，输入真实的数据。尽量进行真实的输入，而不是从别处粘贴一段文字。如果是名字，输入一个真实的名字。如果是一个城市，输入一个真实的城市。如果是密码，需要输入两次，那么就输入两次。
当然，随机输入一些无意义的文字要方便许多。但这是不真实的。这不是你的用户会做的事。用户在使用的时候不会有捷径。当你复制粘贴的时候，你不会知道真实的输入感觉是什么。
做用户会做的事，这样你能更好地理解他们，也就能搭建出更好的界面。
假文垃圾
没有了想象出实际内容的想象力，一个设计依据就消失了。意义被模糊了，因为他只是一段文本。可理解性遭到了妥协，因为没人意识到这段文字实际上是用来阅读的。机会也丢失了，因为你用来代替真实内容的假文垃圾无法提供这种机会。文本会变得很小，因为它不是用来阅读的，我们或许创建许多可爱的空格。
—— Tom Smith, 设计师/开发者 (from 我讨厌假文和假文使用者)
第五节 将产品人格化
你的产品人格类型是什么
把你的产品想象成一个人。你希望他成为什么样的人？礼貌？坚定？宽容？严格？风趣？冷酷？严肃？放松？你想成为一个偏执狂还是值得信赖的人？一个百事通？还是一个谦虚可爱的人？
一旦做出决定，在产品的搭建过程中，始终记住这些人格特征。利用他们来指导文案写作，用户界面，功能设置。每当你做出改变，问问自己，这个改变是否符合 App 的人格特征。
你的产品是有发言权的，它每天 24 小时都在与你的客户交谈。
