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 小时都在与你的客户交谈。

你可能感兴趣的:(Getting Real 第十一章)