难用即bug
一般在项目收尾阶段拒绝任何改动，因为不管改动有多么正当，理性的理由，哪怕最小的改动都会带来更多的bug风险。
以后我们可以给一个产品定性一个自带的bug属性，那就是是否受到用户的欢迎。这个bug是区别于功能的，区别于测试阶段发现的任何bug。
如果你的系统有一个出色的界面，并且你在资金和时间方面预算充足，你就可以继续在这个系统上工作。即使这个系统有bug或者运行缓慢，你也可以去改进它。但如果你的系统有一个糟糕的界面，你基本上就一无所有了。所以这个自带的bug和界面有不可分割的关系。
用户并不关心
当你的产品发布上去让用户使用的时候，你觉得用户关心的是什么？人们往往会更加关心他们所看到的，用户根本不想知道你产品服务端的界面有多么牛逼，你在visio画了多少了不起的架构设图，用户界面就代表了你的软件。系统的界面有多重要，想象一下，最高深的服务架构+超级糟糕的前端界面。
有时候提升服务端的性能可能会花上很大的成本，而且客户可能并不买帐(因为客户并不关心他们不可触摸的东西)，然而改变一下你界面的一个小细节带来的成本或许少的多。用很小的成本换回用户超高的体验，我们何乐不为呢？
纸上原型设计
接下来的问题是，在不依赖我们的开发工具的前提下，我们怎么来为用户界面做原型设计呢？有个很简单的方法，就是在纸上做。
从某种程度上来说，纸上原型设计是一种永远也不会过时的方法。
*纸上的原型设计除了会影响你当前项目的质量以外，它有另外一个好处——它有助于你职业生涯的发展。在你学到的所有知识中，有多少在10年以后仍然有用？20年以后呢？技术的保存期跟香蕉一样。
相比之下，纸上原型设计方法的保存期接近于纸张的保存期。一旦你学会了纸上原型设计，就可以在你接下来的职业生涯中参与的每一个项目里都使用它。20年之后什么用户界面技术会比较流行，但我相信，我们还是必须对那些设计做可用性方面的评估。
纸上原型设计的电子化对于软件开发来说是一种革新：原型设计感觉有点交互性了；相比于纸上更加容易修改；电子化更加适合于分布式开发的团队协作模式。
Jensen Harris——作为office 2007团队的首席用户界面设计师，他介绍Power Point 做原型设计——呵呵。这个不是唯一的选择，对于一些简易的设计，网上有在线的工具可以进行原型设计。