深度长文｜如何输出一份让团队满意的交互设计交付物精选.pdfVIP

深度长文 ｜如何输出一份让团队满意的交互设计交付物 本篇是系列小结的第 篇 ，简单总结一下自己对如何提高交互文档质量的一些思考。 希望自己在一年结束时留给自己感慨的不只是“我画了几百张交互稿”或者干巴巴的“完成了几个上线 项目” ，也非常感谢网易saga前辈耐心的指点 ，还有“多总结、多思考”的建议。有感于这样的建议 ， 近期开始 ，将陆续把今年实际项目中遇到的一些经验教训 ，以及团队协作过程中遇到的问题和解决 方案以文章的方式做一整理。 1 交互文档的形式和内容 交互文档是交互设计师自己的“产品” ，而相信每个选择从事交互设计的同学 ，都有着一颗有情怀的 心和做好经手的每个产品的愿望。 那么 ，对展示我们自己交互岗位成果的产品 ，自然也要用设计一个产品的态度去精益求精。 整体呈现上自然不用说——一份整洁清晰、排版舒服的文档总会更让阅读者心情愉悦 ，也更能感受 到设计者的用心程度。而在此之外 ，无论在文档结构、内容上还是形式上 ，都有不少值得注意的 地方 ，可以帮助我们的交付物更好地通过Review ，也更好地让下游的UI、前端同学领会我们的意图 ，增进团队效率。 交互文档的定义和形式都没有太通行的定论 ，和团队的习惯有很大关系。一般而言 ，形成一份排版 整齐的PDF文档打印出来 ，对参与人数较多的评审过稿来说效果更好。但对全线采用Axure的团队 来说 ，直接写在Axure的HT ML里也是一种不错的形式。在实际项目中两种方式都接触过 ，也很难界 定哪种更好。交互是一个承上启下的中间设计环节 ，这决定了它的交付物只要做到表达清晰、有足 够的说服力 ，拘泥于形式没有太大的意义。 本文中将以我实际在项目中的做法作为示例 ，并不代表这种就是最优的做法 ，也欢迎同行提出更好 的建议 ：） 在很多人的印象中 ，线框图就是交互设计师的输出物 ，线框图也确实是交互文档中篇幅最大的部分 ，但绝对不是最重要的部分。 在通过线框图具体展示设计方案之前 ，目标分析和全局性的流程方案是更为关键的一部分 ，也是实 际项目中最花时间和精力的部分。 我的交互文档一般由以下几个部分构成 ： 目标分析、信息架构设计、流程设计和线框图这四部分中 ，需要注意哪些方面才能提高文档的质量 ？本篇将结合实际项目的一些小例子逐一地进行总结。因为实际项目基本都是B端项目 ，因此本文 的的大部分叙述都是针对B端项目进行的。当然 ，涉及具体方案的部分不方便以公司项目作为例子 ，会用个人的一些C端side pro ect s里中原理相通的案例做示例。 而对最后一步—— 自查 ，会在后续更新的其他文章中对如何建立适合自己工作习惯和业务背景的自 查表进行总结。 2 目标分析篇 ：底气来自过程 把目标分析写进交互文档的最大作用就是让方案有过程可查、有据可循 ，增强评审时的底气。 对交互设计师自己来说 ，打开文档时首先映入眼帘的是设计目标和整体流程 ，有助于时刻提醒自己 所有方案都是为设计目标服务的 ，避免埋头画了几十张线框图后发现已经离设计目标十万八千里了 ，这时候无论是想方设法勉强自圆其说、还是含泪返工 ，都是一件痛苦的事情。 对参与评审的产品方、客户而言 ，首先看到扎实的目标分析、完整的思考流程 ，可以在内心对你的 专业性、方案的推演过程产生不错的印象分和信任感 ，基于对目标分析的了解再去看具体方案的 时候 ，言辞尖锐的challenge 自然也会减少不少。毕竟 ，让方案更具说服力、顺利通过Review对设计 师而言才是工作被认可、带着好心情下班的关键。 对下游具体与交互设计师合作的视觉、前端同学而言 ，相比直接拿到干巴巴的交互稿开始做视觉稿 、写页面 ，看到交互设计的思考过程想必心里会更踏实 ，而不是一边搬砖一边心理犯嘀咕“这个bar 为什么要这样设计 ？会不会评审后又要改 ？现在做的是不是白做 ？“ ，同时 ，如果文档里的思路足够 清晰 ，而你的视觉、前端同学的理解能力也不错的话 ，”这里一定要这样设计吗 ？能不能……”之类的 问题会减少很多 ，大大降低团队内的沟通成本。 当然 ，文档作为交互设计师自己的“产品” ，也有自己的产品目标——沟通。所以 ，文档的最终目标 是可读、易读 ，而不是展示自己搬了多少砖、有多少苦劳。所以 ，写进交互文档用于评审或者协作 的内容应该尽可能精简。 2.1 产品目标 产品层面的目标其实说简单很简单。 无论做一个妙趣横生的C端产品也好 ，还是一个崇尚高效的B端应用也好 ，终极目的都是……赚钱。 所以 ，无论是言简意赅地在交互文档的开头用最短的一句话写明产品目标时 ，还是完成任何方案的 具体设计时 ，都要谨记自己的任何方