公司的项目接近尾声，我也总算有时间来回查几个月来的工作。通过这段时间与产品、技术同事的合作，了解了许多设计之外的东西，这里做一下总结：
关于交互文档
作为交互设计师，输出交互说明文档、页面流程图、交互demo是我分内的事情，但越是到了项目的后期，我越来越认识到细致、详尽的交互文档是何等重要，如果让我从新梳理这些产出物，我想我会着重注意输出文档的以下几点：
1、事无巨细
项目的参与人员并不像交互设计师一样熟悉各类产品，部分方案对开发人员来说可能相当的陌生，为了达到预期效果，详细的交互文档+面对面的沟通+与预期效果相似的案例，都是必要的。曾在在知乎上听说，淘宝的交互输出文档中会把设计中的思路、多个方案的优略对比、相似产品的页面截图等一起写入文档，当时觉得累赘，但现在发觉这样做真的有用。
2、文档的实时更新
项目方案通常受多方面的影响如：需求变更、设计变更、实现困难、开发进度等原因需经过多次迭代，交互更新后的文档一定要及时发送给项目全体人员，对更新部分的内容应该有详细的记录和说明（包括修改思路、时间等），这样做一方面能够保证大家的信息同步，防止出现重复开发和错误开发，另一方面，当项目后期进行回查时，大家都能清楚的知道页面修改的根本原因（前期项目我自己在这方面没有做到位，曾导致不少问题，一定程度上影响了项目进度。）
3、规范文档结构
清晰的文档结构，不仅方便大家查找页面，提高工作效率，还能帮助自己理清思路，建立清晰的产品架构。通过了解其他公司的交互文档规范，并结合公司项目的实际情况，我将文档结构调整如下：
文档基本结构
简介--一句话描述产品的基本定位、核心功能以及产品属性；
用户--用户模型，确定产品面向的人群（以后细说）；
目标--不同用户的核心目标（可以继续细分）；
用例--为用户完成目标而设计的事件流，包括1个基本事件流和多个例外事件流，通过一个用例用户可以达成一个目标；
操作定义与交互规范--产品中的主要操作以及普遍的交互逻辑（这里并不是制定具体的控件、元素规范，而是定义产品不同页面中各类问题的基本思考逻辑）
修改历史--设计修改记录，应包括修改时间、修改内容、修改原因
交互设计稿--页面框架图、页面流程图、交互说明，（需考虑基本的视觉排版等，可使用不同层次的灰度表示重要内容元素，不应定义色彩、质感、符号、形状等）
分享内容落地页面--可分享页面分享成功后的落地页（产品有touch版与无touch版落地页会有较大区别）
特殊状态--详细描述产品不同页面在不同状态下的异常反馈、显示、状态等（一般可以根据产品的整体结构来书写）
4、关于沟通
交互设计师除了输出书面文档，绝大多数时间都在和产品、开发进行沟通，在沟通的过程中，我们不但要把自己的方案、想法解释清楚，更加应该把产品思路、思考逻辑、设计方法传达给其他人，这样做的好处，一方面在于让别人了解你的任何方案都是经过思考和对比得出的，绝不是无中生有（也可以有效的树立你的专业威望），另一方面，通过日积月累的了解和磨合，彼此之间的想法会更加趋于一致，工作也会更加顺利。
网友评论