介绍一种好的设计方法——在软件设计前先画界面图

先画界面，再将界面组合起来，考虑一个界面流。
理由是：界面更重要，而界面之间怎么导航应让位于界面。
用例用来描述一个过程合适，但不好描述界面。
好像设计一个机械，设计那个操作台面总是很需要思考的。
有时一个界面需要包括很多功能。

做界面我也是比较倾向在白纸或白板画出界面的样子和元素，大家讨论过后，分头去做，另外，《软件创新之路》讲的很好，不过努力了几次，都因为时间的问题，总是不很充分

界面图有时候并不是很有效。特别是在用户的业务逻辑比较复杂的情况下。用户的注意力被界面吸引了，而忘记了自己真正的需求。给用户看一个界面，用户会对界面的外观提出很多看法，从而浪费了我们宝贵的时间。
界面未必是易于理解的。不说客户，就是从事编程工作的我们，拿到一个新的软件，也要花不少时间才能理解它正确的用法。可见，给你全部的界面，也未必能很快掌握其中的逻辑。客户同样也很难通过看界面理解你表达的逻辑。而且，如果发现理解有误怎么办？回去再画一个吗？客户能有多少耐心陪你天天看一个不能运行的程序呢？客户经常回答的一句话就是：“你先作出来，我们再看看。”要是做出来再看，项目就玄了。往往项目应用之后，开发才刚刚开始。
界面是易变的。同样的逻辑，可以用很多种方式去展现。我们需要知道的，是业务逻辑和需求。而不是界面。通过界面去捕获需求，只能做为一种辅助的手段，仅仅依靠界面来设计，是非常危险的。因为前面讲过，界面不能表达复杂的逻辑。界面只是表达了交互的方式。从这种交互中我们可以得到部分需求和业务逻辑。
制作界面也是相当费人力的。做的差了，客户会留下不好的印象。做得好了，又会花费太多的时间。
很少有用户能够准确的表达自己的业务逻辑。也很少有客户能说出自己单位全部的业务逻辑。如果你问客户，他需要什么，他一定说不清楚。但是如果你问他是不是这样，他应该能说出是或者不是。问一个人是不够的，一个人不会了解所有的业务。为了防止遗漏需求，应该考虑到所有可能使用系统的人员。所以，搞清客户单位的组织结构非常必要。
最终我们要得到的是什么？我们需要发现所有的业务对象，弄清楚它们之间的静态关系和它们在每一个业务中状态的变化。
如果一定要谈谈理论，那么可以扯上Use case，UML,UP....不过，U开头的东西总是能让我头疼脑热疲惫不堪之后浑身无力（象是流行感冒的症状），所以现在总结出规律，碰到U开头的东西就躲着走。
我以为，用界面来捕获需求是效率比较低的，而且不能捕获全部的需求。
我总结的方法就是：
找到所有的人
以人为线索，访问每一种角色的客户
与客户交流，不断对客户的业务作出各种假设，直到提不出问题
对任何不知道的东西提出疑问
以上过程可能需要重复两三次。因为你对客户的业务不熟悉，可能一开始不能理解所有的业务。所以，对于客户的行业背景知识，准备得越充分越好。不懂就问，客户一般不会不高兴，反而会因为得到理解而兴奋。千万不要为了表现自己理解能力强或者怕得罪客户而在客户说话的时候拼命点头，那样最终是害了自己。如果你是个笨蛋，千万不要试图装作聪明，那样只会使你更笨。如果提问会得罪客户，早点得罪他是一种好的选择，总比项目验收时才得罪他好。
如果客户提出了很多要求，那么请记住，客户的十个要求，我们只能拒绝一个，留着这个宝贵的机会，把它用在最难做的那个要求上。客户计算要求是按数量，而我们是按工作量。
满足前面的九个要求是为了积攒客户的满意度，拒绝最后一个要求是为了消费满意度。

我的做法略有不同
如果客户提了十个要求，应对的比率大致如下：
两个直接满足
三个讨价还价后满足
两个直接拒绝
两个无限扩张后把难题踢回给用户，从此搁置
一个提出比用户更好的解决办法并且将其实现，用户的满意度几乎都是靠这一类要求积累起来的……

　　如何拒绝那些大风险或不合理的客户需求，又不影响客户的满意度，真需要不少的技巧啊。

　　关于界面图，我们是这么做的。需求分析时，在关键业务基本了解的同时，用纸笔画出简单的界面框架征询客户的意见，可以补充功能需求的细节，同时与客户交流界面交互的设计。这种方式比简单原型的代价小，速度快。当然如果你习惯了visio,ppt,dw甚至photoshop的形式也是一样。
　　同样在需求到设计过程中，用快速原型的方式进一步细化需求细节，界面细节，交互细节。多次交流沟通在功能和操作上与客户达到最大程度的一致性。
　　之后到下一环节是在原型上迭代开发还是抛弃原型重新开发，就要看项目大小、时间充裕程度、开发成本等问题了。