软件开发过程往往就决定了用户所得。早先，瀑布模型是在所有的内容都提前规定好，各个步骤有固定顺序（例如，一个虚构的事物）。到软件开发完成时，用户得到的是有一定功能的东西，但并不是他们所想要的或需要的。然后各种螺旋模式出现了：迭代模型，敏捷模型，XP极限模型。和瀑布模型不同（朝一个方向进行，从不回头），螺旋模型能开发出更接近用户要求的软件。螺旋模型拥护可用性，可用性也促进了对螺旋模型的需求。但是可用性之后呢？还会有新的开发方法来支持它么？

嗯，我想我问了两个有点相关的问题。这只是一个非常粗鄙的想法，因此尽管把它砸烂、揉碎、再重组，然后加上你自己可靠的想法。

可用性之后是Flow(顺畅)
“感谢你给我这么好用、设计美观还很有用的东西。现在，你能让它像一个游戏或者一项运动那样充满吸引力么？你能让我离开纷杂的日常事物全心投入其中么？能让我永远不被软件自身干扰么？能让问题来自我要做的事情而不是来自软件的使用么？”
就算用户不过分要求顺畅…能提供这样的产品就是一个极大的机会和优势。（拥有充满热情的用户是产品的一个至关重要的品质）

想了解更多关于Flow（顺畅）的信息--我强烈支持我们所有人都研究它--这里有一些资源：

The original FLOW book
曾获过奖的游戏设计师Jenova Chen的一个关于Flow(顺畅)理论的极好概括，包括一个采用顺畅理论的诱人的游戏。

游戏设计者Raph Koster的博客，还有别忘了他杰出的著作《娱乐原理》。
以及两篇我早先的文章：着迷的用户和认知诱导

关于开发模型
我真的不懂了。像Jonathan Kohl 和Jason Gorman一直在谈论敏捷模型，但是关于敏捷模型是什么或到底是什么方法并没有一个论断。有人认为它只不过是能做到最好的一种实用方法，不要成为敏捷模型的绝对狂热者。换句话说，敏捷模型并不值得崇拜。

另外，在这里我实际在谈论网络软件，不是大的公司的话没必要有这种新型网络软件（或者游戏）的压力。正是新的网络软件的发展需要超快发布和近乎即时的用户需求反馈（用户不一定要求）。有为此工作的敏捷模型么？或者只是更快，更紧密的迭代？

我们能加速螺旋式开发么？或者用完全不同的方法？这怎么符合像稍微有争议的37Signals的Getting Real方法这样的东西？我说有争议的是因为有人认为它一点也没有创新，或者更糟--- 苍蝇坐板凳——完全摸不到边a fly-by-the-seat thing that absolutely Does Not Scale, 或者...
那么，你怎么看？

（如果我能更聪明一些的话，我愿意完成这个工作，而不仅仅是在餐巾纸上画画草图了，这就是我对此的粗略想法。好像也不是那么遭…）

Kathy Sierra写于2007年1月7日

自从成为游戏开发师的第一天，Kathy Sierra就开始对大脑和人工智能感兴趣。
她也是世界上最大的商业网站之一的javaranch.com的创办者。Kathy Sierra喜欢滑雪、跑步，她的冰岛马和gravity，她刚刚热爱上Dance Dance Revolution(热舞革命)。

本文作者 Kathy Sierra , 最初发表于 http://www.uigarden.net/chinese/ke-yong-xing-zhi-hou-ne。如想阅读更多类似文章，请到： www.uigarden.net

© ui花园版权所有，经许可转载。

中国创意设计人才网相关职位信息：
[深圳]腾讯拍拍网 - 交互设计师
[上海]华为技术有限公司 - 终端交互设计师
[杭州]阿里妈妈 - 交互设计师