业务场景

不要想着把对应的业务逻辑、交互逻辑传递给开发就OK了！ 你还需要考虑你的原型触达对象是谁？ 如何帮助他们理解原型中的业务将会产生的价值更重要！ 因为只有有人用才能让产品产生价值。

当原型的触达对象不只是 开发同志 ，还有像是 市场、销售、运维 的人员时，

需要基于需求功能，对涉及的 业务场景 进行介绍。

针对多个角度，对业务场景尽可能还原，围绕业务场景上下文补充对应的内容

可以帮助他们对功能有更全面的认识。

更新历史

如果想知道每次改了哪些内容？ 后续复盘调整基于哪些内容？ 回顾功能的迭代路径从哪里开始？

缝缝补补的原型，在一次又一次的审核调整中，做出了大量调整。

功能也在缝缝补补中，不断被完善。

可是时间一久，某些设计上的细节就会遗忘，曾经没有考虑的内容，再次回到那个问题面前极有可能重新错一次。

此时，查找 过去的设计思路 以及 回顾当初的考虑 就会耗费很多时间，

如果迭代历史清晰可见，回顾之路必定省时省力。

业务流程

繁杂的页面交互看不出到底做了什么功能？ 长篇的流程图无法快速知晓业务主流程？

不妨在原型中插入一个业务主流程，让阅读者 30s 内即可知晓

后续的长篇累牍中，阐述的需求涉及的核心流程。