文字 第11章
功能定义一点用都没有
不要写功能定义文档
这些蓝图文档通常和成品几乎毫无关系。理由如下：
功能定义文档是虚幻的
功能定义文档不反映真实情况。一个应用只有在被构造时、被设计时，和被使用时才是真实的。功能定义文档只是纸上谈兵
功能定义文档是无关痛痒的
功能定义文档可以用来让人感受到参与的乐趣，措辞温和但是并不是那么有用。它们不关心艰难的抉择，不关心成本——而这些正是建立一个成功的应用所必须考虑的。
功能定义文档只能达成虚幻的共识
看文字并不能让人们达成共识。大家可以读到同样的文字内容，但每个人的想法却可能不同。以后将不可避免地发生这种情况：“等下，我不是那样想的。”“啊？我们可不是这么说的。”“是的，就是这样的，我们大家都同意了——你还签过字呢。”我相信，你知道该怎么做。
功能定义文档逼迫你在拥有最少资讯时作出最重要的决定
当你刚开始构建时，你知道的是最少的。而做得越多，用得越多，你才能了解得越多。这才是你应该做出决定的时候——即当你有足够多信息，而非信息少的时候。
功能定义导致功能泛滥
功能定义阶段对整个过程没有什么推动。 写点东西加个标注，看上去并不需要什么代价。你可以加上他们欣赏的功能，让那些令人头疼的人高兴。然后你按照那些写下来的文字标注设计，而不是为人设计。 最终你得到的将是一个拥有30个栏目的臃肿站点
功能定义让你无法变通、变化和重新评估
一个功能一旦得到认同，即使在开发阶段你就意识到它是个坏主意，你也不得不照做。一旦你开始做某事，一切都在变化，而定义却不会去处理这些实际情况。
那么，你应该做什么去替代功能定义呢？ 去写一个简明的替代文档，以此引导你去做那些真正的事。 写一页的说明去描述这个应用要做什么。 使用平实的语言并且要简短。 如果要阐述的内容超过了一页纸，就太复杂了。 这个过程不应该超过一天。
接下来开始建立界面—-界面将成为功能文档的替代物。 在纸上简单快速地画些草图。 然后把它写成html代码。 界面设计是每个人都会认同的共同基础，这不同于，大段的文字可以有不同的理解。
人人都使用同样的屏幕界面时， 混乱不见了。在你开始担心后台代码之前，要建立一个人人都可以看得见的，使用的，点击访问的，并且可以“感受到的” 界面。 一定要尽量把自己置于客户体验之前。
忘记那些锁定的功能定义。 它们迫使你做大，在太早的时候逼你作关键决策。 略过功能定义阶段，你将可以便于改变并且保持灵活性。
没用的功能定义
“功能定义”几近无用。 我还从来没有见过一个足够全面和足够准确的功能定义文档。
而且，我见过大量的基于功能定义（文档）的无用功。 这真是写软件的唯一最坏途径，这从它的定义就可以看出： 为了教条而写软件，而不是现实。
—Linus Torvalds, Linux之父 (摘自: Linux: Linus 谈规格书))
和阻碍作斗争
我发现人们常常坚持在任何设计工作开始之前，要先准备大量的需求文档， 这真是一些“阻碍”，使整个过程变慢。（这些人通常对设计没有任何的贡献和创新思维）
我们所有的最佳工作都是这样做出来的， 我们把头脑中的一些关于站点改进的想法， 先作一个（静态）的快速原型， 再改动一点设计，然后使用真实数据建立一个活的原型。 在把原型上的一些累赘剔除以后，我们通常都会得到一个健康运转的项目，并且取得很好的成果。
—Mark Gallagher, 公司内部网研发人员 (摘自 Signal vs. Noise)
别写死文档
根除不必要的文书工作
避免写功能规格定义是一个好的开始,但不要仅只于此；要处处避免过分的写文档工作。除非有个文件确实要演变成现实, 否则别写它。
建造出来,别写出来。如果你需要解释什么,先建造一个原型而不是写一份冗长的文档。实际的界面或原型是你正在构建一个真正的产品的很好说明。另一方面,一纸文档,只能说明它们终将被丢入垃圾桶。
这里有一个例子:如果一个线框文件是注定要停止,并且永远也不会直接变为实际设计,不要为此烦恼。而如果线框开始作为一个线框造型并且演变为实际设计,那就用它。
脱离实际应用而存在的文档是没用的。 它们对你没有帮助。 你在作的所有事都应该最终变为真实存在的。 如果一个文档在变为真实之前，就停止了，那它完蛋了。
谁也不会去读它
我从不会去数在我们研发队伍的身边有多少这样无聊的，未读的，沾满灰尘的，有很多页的产品规格书或者业务需求文档。 我们只管去编码，讨论问题，质疑和进行用户测试。 我也和那些写了好多冗长的，描述性的电子邮件或者编码规范文档的研发人员一起工作过， 同样那些文档也没人读过。
开发Web应用并不会因为有丰富的文档就会一帆风顺。 软件开发是一个不断变化的，反复迭代过程，这其中包含着 相互作用， 快速决策 和一堆在前进路上不断遇到的无法预测的问题。 这些没有一个是能够，也不应该在文档中捕获的。
不要浪费时间去堆砌这些冗长成册的不实文档； 没人去读它。 如果你给你的产品足够的空间去成长，到最后这个产品无论如何也不象你写到的那样，这个事实应该是你得到安慰。
—Gina Trapani, web developer and editor of Lifehacker, the productivity and software guide
告诉我一个短故事
写故事,别写细节
如果你发现你确实需要来解释一个新的特征或概念,写一个简短的故事说明之. 别陷入技术或设计的细节,只讲一个短故事. 象你在正常的交谈时和一个人讲话的方式一样。
它并不需要成为一个短文。只要象记流水账似说明发生什么事。如果拿出你正在开发的屏幕作背景，来简述这个故事,那就更好了。
坚持经验,而不是越来越拘于细节。考虑战略,而不是战术。一旦你开始建立的你的那部分应用，战术自然就会适得其所。现在你只是要想出一个故事,发起讨论,然后使你步入正轨。
使用平实的语言
填入真实的文字而不是测试用的胡乱用语
测试用的胡乱文字（Lorem ipsum dolor）一直是设计者的忠实伙伴。 虚拟文字帮助人们认清设计完成后的观感。但是这些虚拟文字会很危险。
测试用的胡乱文字改变了拷贝的视像。 使得文本内容弱化为一个视觉设计元素 — 文本形状 —而不是其本来面目：有价值的某人录入/或要读的信息。 虚拟文本意味着你不会看到当真实信息录入后出现的不可避免的改变。这意味着你不会知道在你的站点填写表格时会是什么样子。 虚拟文字是隔在你和现实之间的面纱。
你需要真实的拷贝去认识某个字段要多长才合适； 你需要真实的拷贝去懂得表格是怎样扩展或收缩的； 你需要真实的拷贝去感知你的应用看起来究竟怎么样。
只要有可能，你就要使用真实，准确的用语。 如果你的站点或应用需要数据输入，那就录入真正的交易数据。并且要敲入实际的文本–不要从其他来源拷贝粘贴。 如果那是一个姓名，就敲入一个真实的姓名。 如果是个城市， 录入一个真正的城市。如果是一个密码，就要重复2次，录入2次。
确实，从上到下过一遍表格并把每项都填入垃圾数据（”asdsadklja” “123usadfjasld” “snaxn2q9e7″）是很简单。但是这不真实。 你的客户一定不会这样使用。当客户被强迫要长途跋涉时，你却走捷径，这能算是精明么？ 当你用连发开火的方式快速录入假数据时， 你根本不会体会到填表格时的真实感受。
象你的客户那样去做，你才能更好的理解他们。 当你更好的理解他们时， 你会感同身受，做出更好的界面。
胡乱用语垃圾
由于没有想象力想出真实内容“大概”应该怎样， 一项设计考虑因此丢失。“这里该是文本”使得含义晦涩，因为没谁意识到这些文本是要实际被读到的，明白易懂性大打折扣。机会也会浪费，因为这些你使用的胡乱用语垃圾不是真实内容，你无法从中悟出机会。这些文本的作用很小，因为，不能这样用，我们兴许也可以创建一堆可爱的空格。
—Tom Smith, 设计师及开发人员 (摘自 我憎恨 Lorem Ipsum 和 Lorem Ipsum 使用者)
个性化你的产品
你的产品的个性类型是什么？
把你的产品想象成一个人。 你要赋予他什么个性类型？ 有礼貌？ 严肃的？ 慈悲的？ 精确的？ 有趣的？ 无表情的？ 认真的？ 自由的？ 你想它以怎样的面目示人，是偏执的 还是令人信服的？ 是作为一个万事通？ 抑或是谦逊并且人见人爱 ？
一旦你确定下来，就要在构建产品的过程中时刻记得保持这些个性特征。利用这些个性指导拷贝写作，界面设计 和 功能项配置。 一旦你想要改变什么， 自问一下这会不会改变你的应用的个性特征。
你的产品有声音—会一天24小时的不停地与你的客户交谈。
