同时需要进行的还有初稿设计，在这里我所谓的初稿，并不一定是严格要求中的交互原型，可以是用Axure把主要的页面流程做出来，也可以手绘草图，只要能清晰表达设计构思的，什么样的方式都可以 。制作设计原型 制作设计原型，也就是常说的交互稿，区别于做设计方案时的初稿，这份交互稿我会尽可能细致的把流程和具体操作形式表达出来 。
考虑到做交互是一个迭代过程，我会在设计稿的首页为设计的产品做一份交互更新日志，记录下交互更新时间、版本名称、更新类型、更新内容、参考需求文档与交互负责人 。这份更新日志的意义在于： 更新时间-便于全程跟踪记录项目，掌握每个时间点 版本名称-便于项目参与人员查找上一版本的交互稿 更新类型-了解每次更新需求的性质 更新内容-清晰呈现每一次更新的内容，并提供一个直接去到更新页面的链接，这样在进行迭代时我们的伙伴不用一页页去寻找更新点 参考需求文档-便于项目参与人员查找对应的需求文档 交互负责人-记录每次迭代的交互负责人，并能方便工作交接 交互稿的制作过程，一般是用Axure做原型，像邮箱这样视觉比较成熟且相对稳定的产品，我会偏向做高保真模型，我们会整理一个控件库，这样能提高制作效率；做一个全新项目时，黑白稿线稿都是可用的方式，如果交互设计师能对大概的视觉效果有把握，也能做得精致些 。
这些我想大家都很了解，所以不多说了 。制作交互说明 之所以把这部分内容提出来单独写一段，是因为之前和很多做交互的朋友讨论过该怎样做好交互说明，大家各有看法，很难找到这部分工作的衡量标准 。
交互说明书在整个设计过程中，也许只会占用小部分工作量，但是作用不小，它能帮助我们减少沟通成本，辅助交互稿描述设计理念，表达交互流程，更细致的展现我们的设计 。与做设计稿不同，个人认为，交互说明这部分工作，需要我们更多了解它作说明的对象，即产品经理、视觉设计师、开发人员的需求，从而达到真正的“辅助”效果，而不是盲目凭自己主观去长篇大论，否则我们要为此花费时间，而且这部分工作只能沉积为一堆我们自己欣赏毫无意义的文字 。
为此我曾与合作过的各组同事进行沟通，提炼出一些他们对交互说明的需求，不求全面，但求能说明一些问题 。1.交互说明最好是图文并茂（all） 便于阅读和理解 。
2.页面跳转的说明（产品&程序） 页面跳转是涉及多个页面关系的操作，产品人员在看交互稿时，会更多去关注多个目的性的任务操作流程，而对页面跳转的记忆是有限的，所以需要页面跳转说明 。3.交互说明能否考虑与产品需求文档结合（产品） 开发文档会涉及产品概念、技术方案、业务执行角色等内容，和交互设计稿有着紧密关联，所以交互说明书与开发文档是可以相互做补充，整理成一份文档，这样也能避免工作内容重复 。
4.对交互稿中不明显的交互动作或隐藏的设置项作 。
【交互说明怎么写】
文章插图