之前在项目经验还没有那么多的时候，写了一篇原型的设计。现在看来，基本是在写自己的理解。现在来结合自己的实际项目，谈谈项目实践中的原型。

理解业务

在一个项目开始后，首先必须要理清业务和业务流程，当然这个不属于我们的工作范围。但是有一点很重要，在业务和业务流程出现后，作为设计师的我们必须清晰理解业务和业务流程（设计师的基本素养之一），不仅是设计师，参与到项目中的成员也一样。

如何对业务和流程方便易于理解？这个方法很多，例如文档，例如上一篇中我提到的：

4.5. Simple Framework：新增的一项。原型一个很重要的功能是向没有参与到需求会议的成员快速展示业务，在时间紧张的情况下，选择参考相近类型的成熟项目，快速进行原型的输出。注意，是原型的 输出，并不是原型的 设计。此步的目的仅在于展示业务。再次注意，个人认为，增加此步从时间上来说是增加了工作时间的，目的应该集中于展示业务和产品特色；

除了有详细的文档，我们团队里的原型使用 Axure，模仿某网站的页面布局结合自身的业务，输出了一稿 原型 Alpha，只看 Alpha 团队里的每个人基本都能理解新产品的方向。在进行了会议讨论后，对业务的部分内容进行修正，输出了 原型 Beta。Beta 只需要能完整流畅展示业务流程即可，细节方面无须纠结。

功能清单 - Function Map

在确定开发之后，需要对不同功能的开发优先度进行排序，在排序前必然会产生一个所有页面和其功能的列表。对于设计来说，看的和想的未必有需求人员那么仔细，故如果直接有现成的可以直接拿过来使用。使用的目的是什么？主要是进行下一步的 UI Flow，以防疏漏。同时，在此流程开始，功能需求的讨论和页面的设计两条流程将会同时进行，设计师的我常常也要加入到功能的讨论中去。此处获得功能清单.xls 一份。

UI Flow

页面设计的数量，主要由页面个数和状态决定的，故 UI Flow 主要以这两个为依据来整理，同时理清页面的流程关系。从功能清单中提取页面数量。

同时，整理优先度。再进一步，根据功能清单及每个页面，整理页面可能的状态，整理出需要设计的页面：

图片丢失了实在找不回来了，不过也不重要。

列表中包含优先度，完成度，列表将在项目讨论过程中不断更新修改，大的增删用备注标记。

开始阶段基本就到这里为止了。