UI开发到底占用了应用开发的多大成本???

我认为UI，User Interaction和Domain Model是软件设计的两只脚。
只精通其中一种，那设计出的软件也是残疾的。

UI和DM都是对业务功能一种描述，
UI是输入和输出，DM是逻辑处理。

良好的UI和DM都应该有可用性强，美观舒适的的特点。
可用性体现在UI就是布局、操作习惯和便捷程度。
同样是操作系统，为什么linux就不如win普及的多？
体现在DM就是良好的抽象、依赖分离以复用和移植
美观舒适体现在UI就是美术设计，体现在DM就是设计模式、重构

所以我认为UI非常重要，由于自动化如测试等比较差，占用比DM更多成本完全有可能。
UI同样也是业务。不可忽视。

个人观点。。

呵，虽有些跑题；不过观点到是极为赞成！

至于这个比例：恐怕是和具体的项目需求相关的。

你们过于夸张UI开发的成本了，对于我来说，单纯的UI开发占项目总体的成本不超过30%。

一个项目，界面的布局交给美工去做，而我们开发人员设计持久层和业务层，在这些开发工作中，其实任务最繁重的还是持久层的开发，我对过去使用JDBC或者CMP每天写得昏天黑地记忆犹新，现在使用Hibernate，工作量已经减轻了一大半了。毕竟通常的应用软件开发都是围绕数据库的数据存取和查询展开的，说白了就是两件事情：

1、数据的存取和查询，这是持久层的工作
2、数据的录入和显示，这是UI层的工作

但是UI层我们使用MVC模式，V的页面是美工去做的，M的代码是业务程序员在Action里面写的，这样算下来纯粹的UI开发工作只剩下了在模版语言里面嵌上标记，或者JSP里面写上tag，来把数据render出来。然而这些工作量也是很小的。

那么UI层工作量大在哪里呢？大在写Javascript进行各种人性化的交互上了，例如form检查，选择框选择，层的显示隐藏，动态菜单，诸如此类。然而对于一个成熟的软件公司来，应该积累自己的Javascript组件库，有了这些组件，做这些工作也不是什么难事和费时间的事情。

单就程序员而言，UI开发的工作量也许没有那么大，不过一个项目围绕UI的工作，比如美工设计、原型设计、界面模板制作、脚本编写、程序开发，加上内部评审、客户评审、协同开发、联调测试等工作，UI方面的工作会在整体项目开发工作中占相当大的比重，有时候可以说UI工作是贯穿整个项目开发过程。

没看清楚楼主的标题，如果只是成本的计算，也许没有我说的那么多，毕竟美工和前台页面制作或前台程序员的工资不是很高，可以把公司做的项目做一个统计，不同的公司会有不同的结果。

robbin，做好交互设计不是你想象的那么简单的，美工的工作量难道不算项目的工作量吗？而且有些事情不是美工力所能及的。我们并不认为好的程序员做 UI 开发就是一种浪费。只要是用户非常关心的方面我们就应该做好，否则怎么体现软件是一种服务呢？

这句话其实适合于表示层、业务层、持久层的任何一层，只要注重积累，都会等到云开月明的那一天的，这实际上是所有成熟的软件公司的共同特点。

这点上我同意dlee的看法，好的UI设计确实不容易，
而且表现层的代码一向是全部代码里头最繁琐的，
表现层的工作量应该占到全部工作量的60%以上。
  关于积累的话，软件公司确实需要积累，这就是为什么我推崇Tapestry的原因，Tapestry可以开发可复用的UI组件，包含javascript能力。对于一个公司的长远发展是很有好处的。事实上如果做一些小项目，复用Tapestry的组件可以很快地开发好。
  关于其他层的积累的话，跟dlee的意见一致。

UI在有积累的情况下可以把工作量下降到30-40%.其实很容易发现不是你制作UI使用的时间多，而是修改UI使用的时间多。而且大家都知道一个道理，修改的成本随着时间的推移而慢慢增大的。在项目或者产品开发（代码开发）没有开始之前UI是否可以确定。实际上是可以的至少可以确定80%.

但是，好像很多人都以为写界面的就只是做做网页，根本不必要了解业务，结果写出来的界面也就是单纯的输入、输出。随着时间的推移，界面上到处都是东拼西走凑出来的按钮，整个流程根本就不顺畅，看起来就不舒服，更不要说操作起来了。
另外，普通的修改还好，但是如果开始考虑的不周全，调整界面的逻辑的时候，几乎所有的东西都要调整。

以前我一直希望能让界面和后台开发完全独立，最好能并行开发，界面就只要做界面，不需要理解业务，后来发现没有用，界面设计和制作人员如果不理解业务，界面会无法使用。
项目小组的分工是技能上的，对业务的理解应该都站在同一层次上，很多公司将页面制作、测试等人员视作辅助角色，可以公用，效果上会很差。

偶最近也老这么想