Framework开始构建起产品的形，抽象出通用的布局原则，页面上大概有哪些模块，这些模块之间的主次、优先级关系是怎样的，每个模块要帮助用户完成怎样的目标。思考清楚了这些问题，接下来的设计才会减少目标偏离与方案返工出现的概率，能把握住界面的整体结构、模块关系呈现等，而不是陷入细节，结果让次要的东西喧宾夺主。
Wireframe
Wireframe在Framework的基础上具化出了产品的完整骨架，在这一步需要仔细考虑到每一个可能的使用场景，包括极多极少、错误等特殊情况都要包括在内。
我一般习惯在Axure文档里以建立很多页面，每个页面按照场景进行命名，再在页面里画Wireframe，具体到每一个模块可能出现的一些特殊场景等，则直接在页面里以模块的方式在主界面旁边呈现，如果是比较简单的情况，也可用文字直接说明。总之，每一个角落都要考虑得当，不能有遗漏，因为水平经验还比较稚嫩，一开始遗漏了较多内容，也非常感谢合作伙伴和团队前辈们的及时指出。
Wireframe虽然不是Mockup，但在视觉效果呈现上却马虎不得。一开始我觉得不是视觉稿没必要考虑那么多，在画Wireframe时完全没考虑栅格之类，最终的视觉效果感觉也比较粗糙。后来被指出在Wireframe这一环，文案等内容基本就确定了，如果不考虑视觉效果，可能在实际的视觉稿产出后，会发生因为文字内容过多溢出，导致整个页面结构都要被迫调整之类的情况，最终增加了产品的设计成本。作为交互设计师，我们可能不用考虑太多配色、创建角色形象之类的视觉细节，但一定要懂基础的UI设计规范，甚至在视觉要求不高（如很多B端产品）的时候，需要直接扮演视觉设计师的角色，这也是我们区别于“能画线框图的产品经理”的重要价值。
还有文案，通俗来说就是“说人话”，各种导航标签、各种引导提示问题、各种按钮说明等的文案也是交互设计师需要思考的，目前我在这方面做得还比较弱，文案有啰嗦、用户不容易理解等问题，正在努力看书写作试图弥补中，就不多谈了。
Mockup
Mockup作为表现层的主要产出，在Wireframe的基础上完成配色表现、图标绘制等视觉细节的呈现，为产品的骨架覆盖上最终的皮肤。在Wireframe已经充分考虑到各种场景的情况下，Mockup不需要再面面俱到，而是选择关键场景的界面进行绘制表现即可，注意一些Hover/Active之类的状态表现，再就是标注交付前端了。
最后放一张自己的设计文档结构截图吧，虽然Axure很多人黑，但我觉得在文档结构呈现这块真的是最好用的。
