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

这话是对的。
问题是：是不是要弄清楚包括易用性和用户友好等所有这些需求之后才能开发。
实际上，连核心功能往往都是在开发和多次小发布的过程中才逐渐清晰的。易用性需求往往是发布到beta版，开始大规模试用的时候，用户才陆续提上来的。
当然，以上“往往”是我做项目的经验体会，或许ddd碰到情况不同。
所以我觉得对我来说，在前期把界面设计进行到底“非不为也，实不能也”

系统易用性和友好性不是靠满足“需求”得到的
如果为了满足这两个需求而在前期设计界面，那只需要给出一两个界面，让用户了解操作风格就可以了。

可能我强调界面设计不能拖后被你误解了，我从未说过界面设计一定要完事才能做别的设计，我对这个问题的个人看法是设计时根本就不要分什么是界面，什么是核心功能，一定要齐头并进，将二者分开基本属于花架子。
关于能不能把界面设计进行到底，我不清楚有什么现成经验和现成方法，我的经验是：看你往不往这方面想了。我个人是近两年才往这方面想，当我有这种思维的时候，我回顾以前我做过的东东，其它人做过的东东，以及那些名满天下的东东，有了新的认识，就是说成功的让自己能够多一个角度看待软件开发。
上面所说的是经过短暂整理后的东西，不是经过长时间整理思维的结果，混淆、错误、自相矛盾难免。因为要回答你这些问题已经不能随手而应了。

那你认为系统易用性和友好性是通过什么得到的？
让用户了解操作风格满足不了系统易用性和友好性的要求。

恩，也就是说人机交互的方式和界面的设计也应该和核心功能的开发一样贯穿在整个开发过程中，是这意思吧？
这个观点很有启发，多谢多谢!

在开发过程中，完全可能随着对需求理解的深入和客户的反馈，对人机交互方式和界面设计进行修改甚至彻底颠覆

刚才又重新看了一遍这个主题的所有跟帖，似乎ddd的意思和dlee引用《面向使用的软件设计》的第 5 章所要表达的意思是一个意思啊
dlee说的：“界面设计是整个交互设计过程中比较靠后的一个阶段。”实际也是说在开发过程中应该不断思考用户真正要完成的工作和完成该工作最方便的方式，以便开发出最方便用户、最易用的界面.所以，界面的完成变成了比较靠后的一个阶段
然后，ozzzzzz说的也是同一个意思啊，就是说一开始的那个界面只是帮助了解需求的手段，而不是真的界面，真的界面还是要在开发过程中逐渐了解的。
我在和稀泥吗？
还是我理解错了？

系统易用性和友好性是通过设计中的概念一致性得到的
我认为这更接近于“推”或者说“灌输”的做法，也就是把开发方的设计理念灌输给用户，让用户接受。
而不是用户说“在这里加个按钮”、“把那边改成红色”……之类的“需求”
满足这类需求往往只是满足了少数用户（往往可能是少数高级用户）的特殊要求，反而忽略了其他大多数用户

呵呵，我也是在仔细阅读了《面向使用的软件设计》后再看 Word 这样的软件，感觉到有了很多新意，对于其中一些地方为什么要设计成这样有了比较深入的理解，同时也发现了一些可用性方面的问题。因为 M$ Office 大家用的很多，非常熟悉，所以这本书里面的很多反例都是拿 Office 举例的（一个现成的靶子）。不过 M$ 确实在软件的可用性方面下了很大的功夫。Linux 应用软件要想占据桌面的一席之地，在可用性方面也需要下很大的功夫。

我其实是倾向于 ddd 的看法的，而不大同意 ozzzzzz 和 notyy 的意见。界面设计不能等同于原型，界面设计以及对于用户如何使用软件应该在很靠前的阶段就加以充分考虑。我的意思只是说在界面设计之前还应该有一个任务建模的阶段，要完全搞清楚用户想要使用这个软件来完成什么任务（是用户真正的目的，而不是程序员惯用思维所强加给他要做的一些事情，例如敲键盘）。界面设计对于细化需求确实有非常大的帮助（使需求变得非常具体），这一点 ozzzzzz 说的很对。不过不要一上手就画界面图，那样未必能得到支持用户完成任务的最佳的交互设计。当然界面设计和软件设计未必一定要有明确的先后顺序，适当的时候并行进行是有可能的。

另外再澄清一下一些比较容易混淆的概念：
界面设计 != 交互设计，界面设计是整个交互设计中的一个阶段。
界面设计 != GUI，在《面向使用的软件设计》中举了一个嵌入式系统使用声音和信号灯做界面的例子。GUI 做的再花哨，如果没有进行过深思熟虑的设计，在可用性方面未必一定比字符界面更好。
易用性不是交互设计的唯一目的，一个好的软件应该对于初学者和熟练用户都能提供很好的支持。对于熟练用户，易用性并不是他们主要关心的目标，他们更关心的是完成任务的效率。所以我很少说“易用性”，而总是说“可用性”。
“使用鼠标即可完成全部操作”，只是做了一半工作，一个可用性非常好的软件，应该使用键盘就可以完成所有使用鼠标可以完成的操作。因为熟练用户更喜欢使用快捷键的操作方式，可以达到更高的效率。

实际我还没整理清晰思路，意会吧
齐头并进这个词语用的不好，还是在开发过程中把二者分开了，应该是抱成一团一个头前进。
从例子中总结经验也许要失去重要的东东，我直接说一个例子吧。

我宿舍前不远有一个提款机，提款排队，我前面一个人操作了半天也没出来，他要提50，但机器内只有100元的，而机器提示信息是让他输入50的整倍数，然后提款机一阵响，什么也没有，他就蒙了，幸好他后面是个弄过计算机的，我脑子一阵转，想到有可能是这个原因，就让他输入100，成功。

这个提示信息有问题，这就是界面设计/交互设计中胡乱设计的结果，导致误导用户。
能输入密码和提款么？能。
易用/可用么？不。
用户碰到这种情况认为提款机满足用户要求了么？没。

其实就是一种渐进原型的方法。
既可以用于捕获用户需求，也可以作为快速开发的基础进行开发，同时还可以给新进的员工解析业务。

用例一定是文字的
用例图实在不能说明问题，不够确定
按照uncle bob的说法USE CASE图只能做做演示文稿的封面

另外，个人感觉界面是非常不稳定的，改动最多的地方就是界面
程序可能会有针对不同细分群体采用不同风格样式用法的UI
这个其实归属于交互设计，Cooper也反复强调的也是交互设计，应该由交互设计师来设计人机交互
但这和系统设计是不同的
业务逻辑不应该依赖于界面，因为界面是不稳定的
我们应该使逻辑系统依赖于用例
从另一方面来说画出界面的目的是为了明确用例
至于怎么好用怎么用的舒服那是交互设计的事情