页面原型驱动

UI界面：面向客户+开发工程师和测试工程师
UC：面向开发工程师和测试工程师

以前公司的开发流程给我改成页面原型驱动了，用着种方式来做为需求调研的辅助手段非常不错，只是对于美工的压力和要求就更多了。

总得来说实施效果不错，不论是用户也好开发团队也好都比较认可这种模式。

我记得以前敏捷过程的一本书上说如果对于一个半年的项目来说，你能在两周之内拿出一个可以看得见摸的着的页面原型出来，用户的反应是非常惊喜。

1.从我理解，这是一种非常好的和客户沟通的手段，但是需求还是要明确文档化。
2.应该以实现业务功能为主，如果用户对界面要求高，让美工出一些效果图给他们。总的来说这两种情况还是可以分开的。
3.这些静态页面的另外一个好处是，后面开发直接可以用，基本的CSS样式都有了，开发填填代码就可以了。不用丢弃。

页面原型确实是一种比较好的实践，我们公司也用了好多项目，基本都是吸取了很多教训走到了这条路上。

如果真的估算，我觉得不能把人员的能力，美工的协同这样的因素联系到一起。因为客户是不会承认你这样原因的。
至于后面的两项，如果可以的话，我们可以通过数据收集，进行基于历史数据的估算，单位上有很多中，可以按照画面项目数进行估算，最后乘以一个复杂度系数。

UC不仅仅是一系列的Use Case图,文字描述的Use Case同样可以用来跟用户交流的.
界面原型做驱动,不是不可以,前提是你可以把用户的意图在系统中有很好的把握和反映,不然你的时间就浪费在页面原型的改动上了.
一个大系统事先如果不做足细致的分析和设计,上来就给用户一堆的原型页面,有点忽悠用户的嫌疑.

页面原型只服从于需求，其它所有工作都服从于页面原型

页面原型不仅仅是视觉上的示意表现，其源码应包含文档和功能语义

页面原型的改动就代表需求有了改动，和有没浪费你的时间毫无关系

(x)html天生适合干这事，CSS稍加修饰、javascript稍显交互（数据可暂时虚拟）
——项目的基础架构就建立和展示出来了

——最关键的是，进入开发编码阶段就是围绕这个(x)html来做，服务器端在页面内repeat数据，或是javascript创建一些功能性的DOM用来展示、交互、ajax异步读取，根本不需要在制作另一套页面了，设计上也仅仅是换个皮肤而已。

不理解和感受不到这种巨大优势的同学，通常是很难跳出服务器端mvc的传统模式。

同意楼上前部分不过不太理解最后一句话是什么意思, 页面原型驱动跟mvc有什么关系? 什么叫服务器端的mvc?难道还有客户端的mvc?

我来开发，也偏向于页面原型驱动。

用页面原型和客户进行需求商讨，对于开发更有好处，可以少浪费点时间。

昨天刚画完页面原型。有点想法!
我们现在其实是有产品发不的，但是很多时候是需要客户化的，这样客户肯定需要在某些地方进行修改。
我们画页面原型的方法就是先将我们现在产品的页面进行保存，然后再用PSpad等编辑器打开来做调整及可以了。
因为是保存原来的，所以页面的元素和布局什么的都没有变，只是其中展示的表格或者按钮位置变化了。
但这样在改动量不大的前提下，一般针对一个比较复杂的模块，新手也就需要两天就可以完成，因为对他而言就是写html了！

页面原型相当有用,一方面比张纸上的需求更贴近最终的要求,另一方面可以使你少做很多无用功,因为除了部分相对固定的逻辑外,页面元素的表现很多时候都会影响到代码的组织.