元宵节一过，这春节算是彻底过去了，不知道有多少人还沉浸在节日的快乐中呢？新年伊始，继续上路了：）～～

接上回：Oops~设计过程进展还算顺利。慢着！这仅仅是刚刚开始，后面要做的还很多。进入项目开发阶段了，遇到新的问题:仅对于一个操作，可能有5种甚至10种可能，如何跟前端工程师进行合作呢？怎样的交付物能够将各种界面信息无误地传达给工程师利于开发？ 如何保证这个过程顺利的推进，而且效果能跟自己的预期相符呢？

———————————————————————————————————————————

如果没有相对明确的原型，在后期会导致大量的返工甚至纠结的讨论，整个项目时间计划因无法细化，也会很难制定。

作为前后端的工程师，最大的期望来自于能够在做之前看到上线后的全貌，这样才可以保证所作的底层架构以及接口设计是准确完备的。项目在一直迭代，同时设计和开发一般是在并行，交互设计就需要尽可能的表现出产品的形态

SNS game需要怎样的交付物，尝试了下面三种方式：

1. 完全将所有的交互进行定义，做成可以运行的版本。

之前在进行web设计演示方案时，时常会将所有的页面及交互做成不同的层，然后讲解给大家。

这种方案的好处是可以一目了然，让大家更熟悉整个系统的运作。缺点也很明显，就是做起来层层相嵌相当麻烦，原型的量成倍的增加，会需要更多的时间。更大的成本来自于迭代后的修改，如果要改某一处，整个原型都将伤筋动骨(即使使用自定义的组件库)，非常不方便。更重要的是，讲解后很多时候工程师不知道该点哪里，导致在拆解任务时容易有疏漏。

这种原型交付物，更适合于产品后期进行用户测试，而非提供给设计师和开发工程师。

2.将主流程视图画出来，将操作的交互细节写在文档里，后期的细节不断与工程师沟通

一些游戏公司里应该是这种配合方式，通过word文档将主要界面以及一些交互过程通过文字大体描述，后期再不断地沟通。

但是对于涉及到表现的前端工程师，通过文字的表现仍然会有很多的疑惑。甚至很多时候，看文字本身就是一种负担，在沟通的时候还会牵涉很多的经历，效果仍不甚满意。

3.一切以图说话。

尝试使用了状态图来进行表现，虽然原型上带来了一些成本，但是整个项目都减少了很多无效沟通时间，效果非常不错。

每个视图的每个点击，以及不同的变化状态都用原型图来示意，基本上可以保证最终效果相似了。

 房屋建造状态图（点击小图看大图）

   状态图原型的小技巧：

•     我们不需要将整个页面都画出来，可以只将某重要视图表现即可。例如上面图中灰色区域都省略了一些固定导航。
•       Axure虽然不支持直接画图，但是如果利用好最基本图形组合，也可以抛弃图像直接进行示意的效果。例如我们可以用几个方框来表示一栋建筑，几个圈圈来表示进行建造的动画等等。灵活运用最简单的图形组合，可以节省很多的时间。

     下一篇：这不是设计

打印  |  类别：信息和交互  |  源地址