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

前言：我希望自己在一年结束时留给自己感慨的不只是“我画了几百张交互稿”或者干巴巴的“完成了几个上线项目”，也非常感谢网易saga前辈耐心的指点，还有“多总结、多思考”的建议。

有感于这样的建议，近期开始，我将陆续把今年实际项目中遇到的一些经验教训，以及团队协作过程中遇到的问题和解决方案以文章的方式做一整理。

1交互文档的形式和内容

交互文档是交互设计师自己的“产品”，而相信每个选择从事交互设计的同学，都有着一颗有情怀的心和做好经手的每个产品的愿望。

那么，对展示我们自己交互岗位成果的产品，自然也要用设计一个产品的态度去精益求精。

整体呈现上自然不用说——一份整洁清晰、排版舒服的文档总会更让阅读者心情愉悦，也更能感受到设计者的用心程度。

而在此之外，无论在文档结构、内容上还是形式上，都有不少值得注意的地方，可以帮助我们的交付物更好地通过Review，也更好地让下游的UI、前端同学领会我们的意图，增进团队效率。

交互文档的定义和形式都没有太通行的定论，和团队的习惯有很大关系。

一般而言，形成一份排版整齐的PDF文档打印出来，对参与人数较多的评审过稿来说效果更好。

但对全线采用Axure的团队来说，直接写在Axure的HTML里也是一种不错的形式。在实际项目中两种方式都接触过，也很难界定哪种更好。

交互是一个承上启下的中间设计环节，这决定了它的交付物只要做到表达清晰、有足够的说服力，拘泥于形式没有太大的意义。

本文中将以我实际在项目中的做法作为示例，并不代表这种就是最优的做法，也欢迎同行提出更好的建议~

在很多人的印象中，线框图就是交互设计师的输出物。线框图也确实是交互文档中篇幅最大的部分，但绝对不是最重要的部分。

在通过线框图具体展示设计方案之前，目标分析和全局性的流程方案是更为关键的一部分，也是实际项目中最花时间和精力的部分。

我的交互文档一般由以下几个部分构成：

目标分析、信息架构设计、流程设计和线框图这四部分中，需要注意哪些方面才能提高文档的质量？本篇将结合实际项目的一些小例子逐一地进行总结。因为实际项目基本都是B端项目，因此本文的的大部分叙述都是针对B端项目进行的。

当然，涉及具体方案的部分不方便以公司项目作为例子，会用个人的一些C端side projects里中原理相通的案例做示例。

而对最后一步——自查，会在后续更新的其他文章中对如何建立适合自己工作习惯和业务背景的自查表进行总结。

2目标分析篇：底气来自过程

把目标分析写进交互文档的最大作用就是让方案有过程可查、有据可循，增强评审时的底气。

对交互设计师自己来说，打开文档时首先映入眼帘的是设计目标和整体流程，有助于时刻提醒自己所有方案都是为设计目标服务的，避免埋头画了几十张线框图后发现已经离设计目标十万八千里了，这时候无论是想方设法勉强自圆其说、还是含泪返工，都是一件痛苦的事情。

对参与评审的产品方、客户而言，首先看到扎实的目标分析、完整的思考流程，可以在内心对你的专业性、方案的推演过程产生不错的印象分和信任感，基于对目标分析的了解再去看具体方案的时候，言辞尖锐的challenge自然也会减少不少。

毕竟，让方案更具说服力、顺利通过Review对设计师而言才是工作被认可、带着好心情下班的关键。

对下游具体与交互设计师合作的视觉、前端同学而言，相比直接拿到干巴巴的交互稿开始做视觉稿、写页面，看到交互设计的思考过程想必心里会更踏实，而不是一边搬砖一边心理犯嘀咕：

“这个bar为什么要这样设计？”

“会不会评审后又要改？”

“现在做的是不是白做？”

同理，如果文档里的思路足够清晰，而你的视觉、前端同学的理解能力也不错的话，”这里一定要这样设计吗？能不能……”之类的问题会减少很多，大大降低团队内的沟通成本。

当然，文档作为交互设计师自己的“产品”，也有自己的产品目标——沟通。所以，文档的最终目标是可读、易读，而不是展示自己搬了多少砖、有多少苦劳。所以，写进交互文档用于评审或者协作的内容应该尽可能精简。

2.1 产品目标

产品层面的目标其实说简单很简单。

无论做一个妙趣横生的C端产品也好，还是一个崇尚高效的B端应用也好，终极目的都是……赚钱。

所以，无论是言简意赅地在交互文档的开头用最短的一句话写明产品目标时，还是完成任何方案的具体设计时，都要谨记：

自己的任何方案都是为利益服务的。

在交互文档中，开篇可以用一句精炼的话描述产品目标。

比如帮一个客户公司设计办公管理平台APP时，显然产品目标就是提高客户公司的办公效率，让客户满意服务，产生长期使用意愿，积累产品口碑和传播量，吸引更多客户与我方合作建立类似的平台。

2.2 业务需求

一个业务需求是由业务目标和业务目的构成的有机整体。

业务目标：做这个需求是想实现怎样的目标和成果？通常客户或者产品方提供给交互设计师的也是这一层面的指标。

业务目的：实现这样的目标后呢？真正动机是什么？最终是想要什么结果？并且，一个合理的业务需求是可以通过一定的信号和指标衡量的。

但实际项目中，有时PM会提一些缺乏依据的衡量指标（比如某流程执行效率提高50%，50%从何而来？），甚至提出一些没有衡量指标的需求（原因通常是“因为竞品做了XXX我们也要做“、”客户觉得有这个功能更高大上“……）等，这时盲目接收需求的话，痛苦和被问责的都是自己。

所以一定要抱紧PM大腿不放直到刨根问底搞清楚为止。

这里我习惯用表格的形式，将业务需求和相应衡量指标的推导过程展示在交互文档中，评审时一目了然。

2.3 用户目标

用户目标的分析中，有条件时可以通过问卷、访谈、现场观察等方法获取真实的用户信息，因客户企业的管理制度或时间所限、没有相关条件时，也可以向团队内熟悉客户业务的产品同事求助。

总之，这一步是基于真实用户的反馈进行还是基于设计师自己的臆想进行，对后续设计流程顺利与否的影响非常大。

用户目标部分应该体现在交互文档中的内容主要有：

1.目标用户的角色分析（用户画像）

2.用户任务目标和相应的场景分析（故事板）

3.由以上分析得出的用户需求和用户体验目标。

这一年中所做的项目都是以B端产品为主，而个人的side project则以C端产品为主，因此能很清晰地感觉到两者之间在用户目标分析中的差别。

B端产品的角色多与工作角色或职责相对应，而C端产品用户的角色通常与家庭角色、态度、相关活动方法、兴趣、选择生活方式的能力等对应，两种产品在做角色和场景分析时方法有所不同。

具体分析方法可以参见《B端产品的角色与场景分析：以会议申请功能的设计为例》，这里就不再展开了。

在交互文档的篇幅有限的情况下，相比大段文字的场景描述，故事板是最适合在交互文档中展示角色和场景的形式，而当场景被质疑时，再拿出具体的场景描述也不迟。

下图就是开始构思一个”发起在线投票“功能时的故事板

同时，在获取真实用户信息的环节如果有拍照的话，在篇幅允许的情况下也可以放进交互文档，增强提案的说服力。

2.4 设计目标（需求提炼）

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!