交互设计的输出文档撰写方法-技术圈

交互输出文档的作用

文档这个东西，我们又爱又恨，爱的是它能够记录并且在工作中让大家高效的协调合作，恨的就是很多人对文档嗤之以鼻非常敷衍，以至于文档不但没有起到它应有的作用，反而成为了一个不负责任的借口。所以一份合格或者优秀的交互输出文档对于一个项目的流转以及团队的配合来说是至关重要的。交互文档的主要利益相关者通常是以下几个角色：交互、产品、开发、UI

交互

首先优秀的交互文档必须在交互组内部进行过审核，包括一致的撰写标准和模式的使用，一个比较规范的交互设计组对于交互的撰写标准也是有严格的规范的，以及在什么情况使用什么交互模式还有组件库的调用都会有详细的说明，那么你的交互输出文档就必须满足团队设定的规范。

其次对于其他交互设计师来说，你的设计方案中是否会出现其他人负责的模块，那么在评审的时候需要同步，虽然交互输出文档对于其他交互来说不是直接受益人，但是在团队同步过程中也是非常重要的。

产品

每个公司对于文档的要求和规则不一样。小公司可能没有交互设计这个岗位，那么可能产品连prd文档也没有，仅仅只是一个简易的需求说明文档，就更不用说针对交互规则的说明文档了。

很多有完善规模和流程的团队不仅会有详细的需求说明文档也有很完善的交互说明文档。我们首先要明确的一点是那么多文档最后是给谁看的，一共在项目中会有多少文档产生。

通常产品经理会在项目初期做一份prd文档（Product-RequirementDocument，需求说明文档），这个prd文档主要是给业务方、交互和开发看的，在这个文档中需要包含一些业务规则以及交互规则，所以交互的输出文档是需要和产品的prd文档合并的。

当然如果你是一位很有自驱力的人，那么你可以自己推进需求并落地，一个人就可以完成prd文档的撰写和需求的落地了。

开发

特别想给各位提个醒，在开发需求评审的过程中，请一定记住你们评审的目的，开发同学也要注意，请把重点放在需求是否能实现以及开发相关的地方即可，请不要考虑为什么要这样做，或者你觉得应该怎么设计，一旦进入了开发对需求和设计的评头论足那么这个会议效率就相当低下。专业的事情就交给专业的人去做吧，可以私下讨论但不要在评审会上各抒己见。

交互输出文档对于开发的作用就是，开发可以更好的还原该功能中交互的跳转以及逻辑，所以我们尽量把交互规则写明白写详细，比如按钮在press和default时候是否样式会有变化，或者页面转场的方向，这都是一些细节，减少不必要的低效沟通。你会发现有些时候为什么开发总是来问一些规则，就是因为文档中没有描述准确，所以开发和交互都需要花时间去同步这个细节。

所以这个也非常考验交互设计师对需求文档撰写的功底，并不是图片文字随意摆放就可以的。和开发合作时也是一项内部的体验设计，你把文档写好了，开发看起来也舒服，满意度也高。如果是一堆文案，连基本的对齐都没做到的话，谁来看都会看不下去。

交互输出文档对于UI来说，作用就非常简单了，但是这里也会碰到问题，那就是交互同学只需要把信息的层次表示出来即可，千万不要画到连视觉同学都没有发挥余地的程度。所以为什么现在UXD体验设计那么火，就是因为交互和UI其实重合度是很高的，只要有智能化组件库和工具做支撑，那么在交互和UI的设计流程中，时间就会大大降低。

交互输出文档的内容

在这里，我们就将整个prd文档的内容给大家分享一下，不仅仅是交互需要输出的部分。因为一个高阶的交互是需要能够独自产出prd文档的。然后不同的公司对与文档的要求也是不同，大家做参考即可。

一份基础的prd文档主要由这几部分组成（其实就是这个需求的来源以及推导过程和如何落地的说明）：

1.项目概要

a.需求背景

这个是一个项目最重要的部分，可以说背景没有搞清楚，后面都可以不用做。这个指的就是我们做这个需求的价值和原因。比如我们app中业务方（运营）需要做一个扫一扫功能，那么这个功能首先我们就从业务价值和用户价值两个方面去评估，根据对业务方的沟通之后我们发现扫一扫功能将会在周年庆的时候通过物流包裹上的二维码，让用户进行扫码参与活动这样的玩法。

所以这个需求对于业务方来说是一个转化手段，通过扫码参与活动-领券-消费，确实是一个不错的玩法，但是大家如果只盯着眼前的问题或许就不够了，比如当周年庆结束之后这个功能还有什么用，他在以后的规划中的存在是怎样的。在所有的包裹中印上活动的二维码这个时间周期和成本有多大。

其次，对于用户来说，扫一扫并不是帮助他们解决了某个问题，而是我做了一个东西，同时搭配着这个功能让你们去使用，对用户来说是一个很可有可无的功能，如果线下包裹上的二维码破损了也是非常影响体验并且是不可控的。那么综上所述，既然要做一个临时的活动用其他的方式会不会更好？

所以在这个文档中的第一步，首先就是要确定需求的背景、价值，也就是说，你这个需求是怎么来的，比如再来讲我们一个店铺的优化项目，在这个项目中，首先我们必须在评审的时候说清楚我们为什么要对其进行优化和改版，一定是出现了或者我们定义到了某个比较严重的问题，这边大家对我们app业务可能不是很了解我就简单说了，就是个人中心和店铺营销场景重合过多，并且卖家的同时可以买和卖两个场景存在，所以店铺页通过我们的数据分析和用户的访谈我们发现了一些机会点，以及我们必须突出一个核心场景让用户有明确的分辨。

另外就是背景的描述也可以带上你的调研结果和分析，比如之前我们做首页优化，我们观察了近5个月的数据，都呈现下降的趋势，所以之后有进行了一系列的访谈和用户体验地图分析才有了这个需求的背景产生。

b.需求目标

目标很好理解，就是我们希望通过这次需求迭代达到一个什么成果，比如我们之前做过一次整体的体验优化改版，那么我们的目标就是减少用户的流程跳失、提升整体体验满意度、提高用户的任务转化率，其中我们做了一个商品关注的功能，由于是限时特价商品所以是限量的，在规定时间进行抢购，为了让用户的使用场景统一我们打算在应用内做一个商品关注功能，所以在这个需求的初期，我们对这个功能的目标和预期是提升xx百分比的转化，提高x%比的gmv，提高用户对关注商品下单的效率和满意度，之前很多用户想要购买商品需要自己在手机端设置闹钟，不方便。所以这个功能的一个目标就是解决用户场景迁移的问题。设定目标之后，就是为了在上线后对其进行复盘和数据跟踪还有用户跟踪。

可以用一句话来描述：针对什么用户在什么场景下解决用户的什么问题，达到什么目的？

c.需求范围

需求范围也相当于范围层，指的就是在该需求中我们需要做哪些相关功能以及功能涉及面。举个例子，之前说的扫一扫功能，不同的产品定位对于扫一扫功能的要求也是不同的，比如说微信在扫一扫功能中承载了：扫一扫、相册、封面、街景、翻译、手电筒等诸多功能，再比如淘宝，有扫一扫（ar、拍立淘）、相册、历史、帮助、手电，这说明了不同产品对扫一扫功能有不一样的要求，所以在需求范围内我们需要把本次需要做的功能进行描述，并且该功能是否影响其他功能的使用和对整个产品的影响范围。并且我们也会讲所需要的功能进行拆解和优先级拆分，在表格中编辑。

d.调研分析

调研分析其实就是为我们第一步背景和价值做准备，由于汇报方案和评审，或者在项目推进时，我们需要有相应的论据来支撑我们方案的客观性，所以在这一板块中输出的结论就非常重要，比如之前的首页改版，经过用户研究小组的访谈和数据分析得出相关的结论，通过埋点找到相应板块的点击数据和异常点，然后再进行一系列的问卷和访谈研究，找到结果，都是为了辅助项目的背景以及在评审中大家对需求价值的灵魂拷问。由于数据和调研结果比较敏感就不过多放了。

e.版本日志

日志是一个非常重要的组成部分，做过开发的同学都知道log 的重要性，当我们跑不通的时候我们都会去检查log，然后多测试几遍可能就找到问题所在了，其实我们的版本日志的作用也是这样，但是一个是对自己来说可以记录自己的工作过程，还有思路的变化，第二就是对外，包括和需求方的讨论，会议的纪要等。

要注意的是会议纪要在备注中需要详细说明，以做证据。同时也要邮件通知相关人员和负责人。可能有些公司还会放一些评审记录，比如各部门负责人对方案和需求的建议，业务方和技术负责人的一些建议也会放在项目概要中，而这个prd文档也可通过内部服务器进行实时更新和保存，如svn。方便大家对需求的进度和迭代有一个直观的追踪。

f.项目成员

这个就不用多说了，产品、运营、交互、视觉、开发各司其职，照相馆人员即可，就不至于当项目开始进行了人员分配还没到位就尴尬了。

2.需求方案设计

a.业务、任务、界面流程图

有些同学不是特别明白业务流程图和任务流程图的区别，这边给大家简单介绍一下

业务流程图：

意思就是在这个需求系统中，相关利益者的业务关系，任务信息的流向的一个图标。比如这个简单的例子，用户在点外卖这个场景中，相关的利益者有用户、店家、外卖员三者，那么当用户开始触发流程后，这3者在这个流程中就会各司其职，而业务流程图也很明显的告诉大家所有联动者的指责和流程走向。

任务流程图：

用户在具体执行某一个任务时候的工作流程，以及其核心任务的操作步骤，比如在登录注册这个任务中，用户需要进行一系列的操作，在这个流程中用户的操作引发的系统判断需要详细说明。

界面流程图：

界面之间的跳转关系和路径，在这个流程图中，我们不需要吧详细的说明写上，只需要将需求中涉及到的页面跳转进行叙述即可。

b.相关说明和规则

接下来就要开始我们交互文档最为关键的部分了，如何书写交互说明，以及交互说明应该包含的内容。

1.全局思考

在做交互方案也就是我们画原型的时候会思考一些问题：

a.整体思考

1.信息架构是否容易理解，信息分类是否合理，比如我们的信息架构是否采用了用户容易理解的，市面上常用的信息架构。

2.信息层级和路径是否合理，不一定要最简，但是要高效，信息的优先级是否放置准确，信息组织是否具有相关性、逻辑性。

3.主题是否清晰，3秒内告诉“我”在哪里，并且可以做什么

4.方案的延展和后续功能规划的可扩展性

b.用户权限

根据不同用户的权限对该需求进行检查，比如普通用户、vip用户、内外网用户、游客用户，在登录未登录时候对需求内功能的使用是否有影响

c.登录方式

用户登录和注册、终端的兼容，不同方式注册的用户是否需要补填相关信息等等

d.流程

1.该需求中的功能流程是否和其他类似或者相同功能流程保持一致性；

2.逆向流程和非正常流程的思考有没有完全；

3.流程的闭环有没有做好；页面跳转的方式是否合理；

4.中断后的恢复状态如何呈现；

5是否保留原信息等等

2.内容、状态和显示

a.内容的获取来源

例如下方的图片为例，banner的图片来源和发现feed流的图片来源肯定是不同的，那么就要写清楚，图片或者数据的来源是来自于用户的上传还是系统后台的配置获取；并且获取的方式是如何的，是需要手动下啦刷新还是切换页面自动刷新，还是设定时间自动刷新。

字段、图标是从接口获取还是前端写死，以及气泡展示的规则等等。另外一张图片可能用在多个地方，而可能呈现的尺寸不同，所以在涉及到相关图片使用时要注意剪裁规则和图片的来源。

b.缓存机制

图片以及一些资源通常我们需要对其进行缓存，有些同学不清楚什么是缓存，缓存是在计算机上的一个原始数据的复制集，一般来说需要缓存的内容是通过浏览产生的，包括图片以及cookie等，浏览过的视频和广告也会被缓存。同时在不同的网络环境下缓存的时间标准也不同，无网络那肯定只能读取缓存文件，wifi环境下缓存时间可设置的短一些，而流量环境下时间就可以设置的偏长。

c.状态

状态大家都应该都会写，主要包含的就是初始状态（冷启动无缓存第一次进入）、空状态（无任何内容比如空的购物车）、常规状态、异常状态（网络中断、接口报错）还有过期状态等

d.显示

数据和内容的极限值，最大和最小，比如粉丝和关注的数量，小于1万人则显示完整的数量，大于等于1万小于11000则显示1万，大于11000小于12000则显示1.1万，这样的方式。另外包括标题极限为一行显示，超过部分的显示规则。敏感信息、错误提示以及超时的信息提示。金额的格式使用¥xxx还是xxx元，小数点保留的规则。日期的显示格式是xxxx年xx月xx日还是xxxx-xx-xx还是xxxx/xx/xx等等

3.反馈、提示、手势

反馈和提示的样式有很多种，一般反馈指的是用户对某一个控件进行触发后获得的反馈，比如按钮按下的反馈，以及之后收到的反馈，是进行跳转还是给用户提示，采用的是模态还是非模态的提示。比如点击关注某个人的按钮后会提示关注成功，比如退出某个图文编辑会二次确认是否退出，再比如抖音长按后出现的3个操作反馈，还有支付成功后的动效提示、恶意多次操作后的提示等等

如果有手势交互也需要说明，比如滑动后内容置顶、拖拽、左右轻扫的tab滑动、重按的3dtouch等等

4.加载

使用模态还是非模态，如果是模态加载请尽量使用情感化设计来减少用户焦虑。如果是非模态，根据信息呈现和体验采用分步加载还是预加载还是智能加载。如果是分布加载就选择先加载资源较小的内容，再加载图片，可以先将图片模糊化粗渲染给用户呈现，包括在浏览信息流的时候的分页加载也是可以的。如果更智能化一些也可以预判用户的行为进行内容加载，例如当用户在某个图文前停留时间达到某个值后就预先给用户加载里面的内容。

加载的全局方式在方案中需要考虑，页面加载、下啦刷新等等，需要统一。

5.环境、设备与场景

a.不同设备、厂商的不同版本

都会影响到方案的落地和用户体验这个要非常注意。比如一些交互控件我们在6、iphonex和大屏幕尺寸上使用起来效果很好，但是小屏幕的时候这个交互控件显得就很难受，所以需要仔细斟酌用户的使用情况。另外还有横竖凭情况的交互方案是否兼容、是否需要与其他硬件进行兼容。

b.白天和晚上是否需要做不同的风格设计，以及在是否需要给用户遮挡隐私的功能。

6.文案

文案这点很多设计师都忽略了，你们有没有听说过一个叫文案设计师的岗位。其实文案在我们产品设计中是非常重要的。首先一个产品的文案对应的语气和产品调性也是相关的，就好比我们说产品有它自己的性格一样，另外文案的使用直接就影响用户对该信息的理解，比如一个对话框的文案是：确定退出吗？下面会有两种不同的选择，一个确定，一个是退出，大家觉得哪个比较好？还有就是不加“吗”，就变成了：确定退出？这样描述出来的语言给人感觉很冰冷，甚至有一些威胁。

所以首先我们的文案是否有温度，和产品的个性是否相匹配。其次文案的表述是否准确和通俗易懂，比如你告诉程序员一句话，帮我去菜市场买西瓜，如果有西红柿，帮我买两个，你会带什么东西回家？程序员版：if（看到西红柿）西瓜等于2；else 西瓜=1。buy 西瓜。条件：看见西红柿执行命令：买两个西瓜一语道破版：其实吧，看到西红柿呢是卖两个西瓜的触发条件…没看到就买一个西瓜，看到就买两个西瓜。所以这里出现的不仅仅是程序员的思维和我们的差异化，也说明了一句话没有表述清楚所带来的问题是很大的。

另外就是文案用语的一致性，在整个产品同样的场景中，我们需要统一文案用语。

7.常见控件

具体见下方列表

8.撰写方式

作为一个设计师，不管是否在做视觉，我们都需要对文档有一个美化意识，如果你的文档非常凌乱，那么在别人眼里就会觉得你是一个比较粗心大意，不够负责任的人，所以我们尽量在做交互输出文档的时候也画的美观一些。

首先在目录的撰写时候要进行分类，通常我做的时候会对该需求以页面父子集关系进行创建，父集为核心页面，子集为其下的相关子页面，这样页面的流转和归属关系就不会搞错。

说明

在撰写规则与说明时可以通过标签法进行标签说明的撰写方式，同样在视觉上保持美观，对比与对齐的运用，具体该写什么东西上面已经说明就不赘述了。除了交互规则以外，高阶的交互设计或者产品经理还需要补充业务规则，比如排序、商品抓去规则、权重、算法、活动规则等等这里就不展开说了。

总结

文档的形式有非常多种，针对不同的公司和产品也需要作出相应的调整，能够满足需求和方便协作，目的就达到了，我们并不希望过多的时间花在文档的撰写上，而是希望大家在做设计时多思考业务，本次分享就到这里啦～