页面原型驱动

现在手上这个项目调研已经接近尾声,要把系统原型做成页面统计给他汇报，包括整个系统都需要哪些页面，每个页面上有哪些元素，页面的名称,访问路径,页面之间的导航关系等等

然后根据这些统计给我手下的人做工作分工和时间计划安排,另外同步的我们的美工正在做页面DEMO
不知道大家自己带项目的时候这块都是怎么操作的?我的感觉是页面驱动比UC驱动显得更直观,并且结果是可以给关键用户直观感受或者小程度使用的半成品,同时可以接受客户反馈进行修正,这不正是跌代的思想吗

By ozzzzzz大虾

跟老大谈谈，说为了让统计工作做得更好，你有必要告诉我统计这些主要目的是什么，我好针对这个来做。也许是报价，也许是工作量，然后得出一个系统中整体的东西。我估计是这些

我只是不知道如何来估计开发一个页面需要的时间
这跟开发人员的能力,美工的协同,页面的复杂程度,框架的数量程度都有关系阿...

不是吧！你这个弄得这么细没用的吧！一般用UC来估计吧！每个页面上有哪些元素（调研的时候确定。设计的时候不会变？)项目估算一般只能是个大概。可以根据下面的人的情况以及项目的难易度，还有以往的经验来搞一个估算！项目进度也是！----个人意见而已！

我们的项目从来没有一个是基于Use Case做的，暂且不说这样可取不可取，至少这样让开发者更加直观，而且让测试的人员也更好测。我们做的计划在表现层这块一般都是按照页面来做的
记得之前dlee有专贴讨论页面原型的重要性的问题

界面原型和Use Case都是需求的组成部分，光有一个界面原型，是不能搞清楚整个业务逻辑的

我们的UI原型就是其中的操作流程和page navigation其实就是Use case的实例化，其实用例是有的，但是我想无论是客户还是开发人员，用例都不是直接可用可看的成果（当然除了最后的功能测试人员）。可能我没有说清楚，这里的页面原型已经是可以进行最简单操作的可使用品，而不仅仅是几张离散相互毫无关联的Page而已

对于不懂技术的一般人（客户）来说，用例显然是不够直观的；“客户”通常是根据页面原型判断是否和功能需求匹配。这样页面设计人员和“客户”必须具备良好的沟通，设计人员必须根据需求制作出一连串相互关联可以操作的静态页面（而不是零散的Page或效果图），等页面确定下来，然后将其交付给编码人员实例化，这暂且可以理解为“基于客户需求的页面驱动开发”模式。对于设计人员来说这无疑是一种工作量比较大的体力活，而且工期也相对较长。 从编码人员的角度来看，编码人员编写用例的时候一般只需要基本的页面元素，样式表这些零部件就可以了（当然有完整可靠的界面参照是不错的选择）。这样设计人员的工作就会轻松不少，为程序员定制出页面元素风格样式表就可以了。当然制作这些基本的页面元素也是“基于客户需求的页面驱动开发”的一部分前期工作。所以，很容易得出一个结论，页面设计人员先出一些基本的和可复用的页面元素，这些元素的风格是统一的基于同一类型的样式表，并将这些页面元素和样式表整理成一套样板，交付给编码人员使用；后面再和“客户”沟通合作制作一整套表现业务流程的页面原型（如果时间人手足够的话）。

对于一个界面为主的系统来说UI永远是最重要的，因为它将最终决定给你发薪水的人是否有money给你发

所以一个UI系统第一步就是沟通需求，然后做保真模型，客户认可了（他们大部分只关心界面），我们再进行后台的功能设计（这个才是大头）

什么樣的系統是一個以界面為主的系統? 你說的未免有些空洞了哦
現在的情況是根據業務接口人員那邊的要求對我們的demo演示做了若干修改,但是感覺在給關鍵用戶演示的時候他們仍然有些不太理解或者不能一目了然, 這個錯到底在他們還是在我們? 我想如果他們稍微認真看看我寫的系統方案書,能提出的意見或者建議恐怕就比現在多得多.所以現在的問題是我們作為一個技術開發部門,到底有沒有必要去做系統的推廣工作?尤其在管理未能規范的情況下,這個職責到底是由技術部門還是有系統接口支持部門來執行,是個問題.偏題了呵呵