作为一名交互设计师，我们平时工作最大的产出就是交互设计文档。 很多刚转行的同学都会在网上找模板直接应用或者自己逐步摸索。 本文将教你如何完成一次完整的交互。 设计文件。
为什么要写交互设计文档？ 交互设计文档有什么用？
首先，交互设计师的交互设计文档就像UI设计师的PSD文件一样，用来保存和记录自己的设计想法，但交互设计师的任务不仅仅停留在页面上，还包括产品需求分析，用户画像、竞品分析、产品数据分析、用户交互逻辑等
我们都可以写在交互设计文档里作为记录，为我们的交互设计提供依据（其实就是为了防止开发骚扰你，问你设计依据是什么，你应该立即把分析放在上面）以避免尴尬）。
第二点，交互设计师是产品的上游。 一般的开发流程是产品总监负责收集交互设计师的需求进行交互设计并编写交互设计文档。
然后文档审核通过后，UI朋友负责UI设计，然后提供后端朋友进行界面开发，后端朋友根据交互稿搭建框架和业务逻辑。
因此，交互设计师通常处于产品线的上游阶段，撰写标准规范的交互设计文档极其重要。
因为我们需要用交互设计文档来表达我们的设计思想，通过交互文档，我们可以让UI朋友知道页面需要向用户表达什么情感，要达到什么目的，告诉后端朋友页面跳转逻辑以及如何编写交互模块，帮助前端朋友清晰搭建后端框架、数据库和产品业务逻辑。 最后，测试童鞋会拿你的交互草稿进行单元测试，并编写测试用例。
所以只有先把文档写好，才能防止副产品开发中出现问题。
第三点，也是最重要的一点，就是我们以后跳槽加薪都会利用笔试作品。
内行看窍门，外行看热闹。 如果你在参加交互设计师笔试的时候，仍然带着一份网上同样排版的长篇JPG或者PDF作品集，在面试官眼里就会变得不专业（也许你会接触到一个性格很好的面试官） （毕竟每个人都有千面，面试也很因人而异）。
因为专业的交互设计师为了防止日常工作中对UI友设计的干扰，只用黑、白、灰进行交互草稿，并且很少制作很长的PNG或JPG，所以我们可以对作品集进行适当的打包，但如果太多的话会让人感觉不踏实，或许只停留在起步阶段。
所以在技术笔试的时候，我们可以拿着我们的交互设计文档，向面试官解释产品是如何从需求层面思考完成交互设计的，解决了用户的哪些痛点，取得了什么样的结果。最终，以及获得了什么样的数据。 相信成功的几率会高很多（PS：请在使用交互设计文档进行笔试之前对公司绝密信息进行脱敏处理，以免产生争议）。
交互式文档中包含哪些内容？ 以及如何编写交互式文档？
1.交互设计文档包含哪些内容？
一般来说，一个基本的、规范的交互设计文档应该包括文档封面、更新文档、设计描述文档、业务流程图、交互原型、垃圾桶等模块。当然，这些模块不是永恒的，有些是必要的网站设计开发文档模板，有些是选择性添加的。 至于那些模块的功能以及如何写，本文将一一为大家分享~
（注：笔者比较习惯使用Axure软件来编写交互设计文档，大家可以根据自己的爱好或者公司规定进行选择（如sketch、figma、PS等）。
引用一句话：软件只是一个工具，它不能限制我们的思维。 好的工具可以让我们走得更快，但不能让我们走得更远——Wo Zikishod。
1. 文件封面（必填）
文档的封面相当于一本书的封面。 用于记录产品名称、版本号、日期、文档负责人（以便开发童鞋能准确找到你撕X）。 只要能显示以上信息即可，其他信息（如产品负责人是谁等）可以自行添加。
2.更新日志（必填）
之前我习惯把更新日志放在产品文档旁边，但是随着工作时间长了，我发现在SVN上打开设计文档后，发现我做的第一件事就是检查更新日志，所以我带了这个稍后翻页（是的，设计文档也需要像产品一样不断优化迭代）。
更新日志主要用于记录产品迭代变更的内容，以便开发者能够快速了解本次迭代发生了哪些变化以及他需要做哪些工作。
我的更新日志很简单。 只有日期、更改内容、页面和注释四个数组。 这里唯一需要注意的是，日期必须是前面最新更改的内容网站设计开发文档模板，之前的日期在底部。 很多朋友每次迭代都会时不时的在下栏添加内容，让开发者每次都必须滚动到底部查看信息。 兄弟，你是交互设计师，请专业一点。
3、产品项目背景（必填）
产品项目背景是一个项目的核心关键。 告诉所有团队成员我们想要创造什么样的产品，我们需要创造什么样的价值。 就像我们写习题时的中心句一样，提醒我们牢记初心。 为团队成员开发项目提供指导。
前段时间，有朋友来找我问我，他们最初是作为校园教育系统开始的，但随着产品逐渐迭代，功能逐渐变得更加强大。 最近老板希望给系统增加财务功能，对于用户来说学习成本已经很高了。 ，如果加在一起会不会适得其反？
虽然我不知道这位朋友的CEO的产品策略是什么，背后是怎么想的，但在我看来，这样的行为不能说是不忘初心。 我做）。
那么，上面的产品背景、产品目标和定位等内容应该怎么写呢？ 是的，我复制了。 一般情况下，我们只能在项目批准文件或者招标文件中找到这些内容。 我们不需要自己写（但是我们可以设计），或者我们可以找产品总监来理解。
或者你可能会说，小公司既没有立项批文，也没有招标文件，而你是产品总监，那你该怎么办？ 那么你就要充分发挥自己原来的中考写作水平，主动了解产品背景定位，努力完成这一部分，因为信息的传递是消耗品。 只有做好产品的上游，才能为团队服务，为我们的努力提供方向。
4.产品要求（必填）
产品需求清单用于记录产品需要做什么[功能点]。 我们通常可以从产品总监或项目经理那里获得这些功能点。 当我们收集到需求后，我们需要根据重要性级别P0、P1、P2对它们进行分类。
我的分类原则是KANO规则（不知道的朋友可以百度一下），P0级是必须要做的需求，比如陌陌的聊天，淘宝的支付功能等，P1是锦上添花，如果时间紧急，可以再做一次上次做的事情，比如陌陌的语音、视频聊天等。
行尾Pn是一些不必要的功能，可以做也可以不做。 即使完成了，也不会有太大影响。 你可以联系领导确认是否要做（比如炸屎，你们现在还有人炸屎吗？什么？连屎都不知道？那就假装我没说）。
5、用户画像（可选）
所谓知己知彼，百战不殆。 通过用户画像，我们可以快速了解产品目标用户群的特征，分析目标用户群的期望、需求、动机等，然后根据用户场景进行设计。
有了用户画像的支持，我们就可以在设计过程中避免不必要的诱导。 例如，如果我们的目标用户是中老年人，那么按钮和字体就应该适当放大，排版应该简单明了。 对于中学生来说，可以进行个性化的款式设计。
当然，如果是小公司，可能没有那么多资源来做用户监管。 在这里我想分享一个我在初创公司经常使用的快速专业的获取用户画像的方法。
这里需要用到一个网站：艾瑞数据（），打开它选择自己的产品类型（比如学习、教育），网站会按照用户数量从高到低给你展示产品类型，然后我们选择一个类似的竞品点击查看其用户特征，最后Ctrl C+Ctrl V 到我们的文档，完成。
6.竞品分析（可选）
竞品分析相信大家都很熟悉了。 我之前的文章也教大家如何对竞品进行详细分析。 我们。
如果认真分析竞品，可以快速了解产品业务，熟悉用户的使用习惯。 同时，我们在制作交互式原型时，可以提供快速参考(cao)(xi)。 所以建议有条件的朋友尽量去尝试。 做吧。
7. 数据分析（可选）
数据分析是交互设计师必不可少的技能，也是验证设计结果的重要激励。 如果缺乏数据分析，仅依靠个人主观激励，我们无法解释设计疗效的优劣，毕竟现实中会出现各种意想不到的情况。
所谓“不比较，不分析”，一般的数据分析就是对数值进行比较，检查数据是否相对上升、下降、持平，是否与之前的设计预期相同。 对于早期的产品，我们会更关注产品的一些DAU（日活跃数）、GMV（总交易值）、付费人数等，因为这类数据的增减直接影响整个产品的生存。 如果产品的DAU持续增加，那么一定要立即找出原因并及时调整，避免恶性循环。
一般情况下，日常生活数字等简单数据可以通过后台询问好友直接获取，而用户个别链接的存活率和转化率则需要依赖【数据埋点】。 市场上也存在很多第三方数据埋点。 ，比如Sensors Data、Growing IO等等，这里就不讲了，但是笔试的时候你可以告诉它，它会变得非常专业。
8.信息架构（必修）
信息架构属于用户体验的结构层，就像产品的骨架一样，信息架构设计就是对产品信息进行结构化和分类的设计。 信息架构可以防止我们遗漏产品功能点，同时也可以传递产品的通用信息。 信息架构观察产品设计是否合理。
一般来说（干货来了），产品结构分支可以分为程度和层次，好的产品的信息结构在广度和层次上恰到好处。 下面我给大家举两个例子来帮助大家理解。
产品结构的广度太宽（不懂的看右图）：信息结构的广度太宽，也就是说页面承载了很多信息，没有优势和缺点。 这样，用户点击页面后就会思考很长时间，感到不知所措。 最经典的是，某家宝和某城市，新用户踏入首页，确实很暧昧。
产品结构层次太深：信息结构层次太深会导致另一个问题就是页面太多，想要找到一些功能的话操作起来非常困难。 钱），您是否多次尝试过百度退款或取消某个APP会员资格？ 反过来想，如果你不希望个别功能被用户发现，但它们又是必不可少的，你就知道如何设计它们。
9. 业务流程图（可选）
绘制业务流程图的目的是对业务流程进行梳理、分析和优化。 我知道很多朋友在做UI设计师的时候完全可以忽略业务，直接去做设计，但是作为一个交互设计师，了解产品业务是极其重要的，因为如果不了解业务，你就无法完成交互设计和业务场景优化。
举个反例：在教育考试系统中，通常的流程是：教育局发出通知→学生报名考试→老师初审→报名通过→老师安排中学生考试名单→学生开始考试并就座→教育局公布成绩→学生查看成绩→考试结束，看看这一系列流程。
因为关联太多，如果不熟悉业务，设计起来会特别不方便。 如果前期因为不熟悉业务流程而设计出错误的交互稿，后期会很麻烦。
那么如何勾勒出一个完整的业务流程：
如果你的产品总监比较专业的话，他可能会直接给你一张现成的业务流程图，这样可以省去很多麻烦。
如果没有产品总监，最直接的办法就是问用户。 我这里介绍的最常见的方式是“听、问、确认”。
一听：先听客户代表或业务方的介绍。 在倾听的过程中，在不打断对方的情况下，以最简单的形式引出主要脉络，即理清基本要素中的角色、活动、协作关系。
第二个问题：完成上一步后，您可以提问。 主要是沿流程提问，重点关注分支和产品关系。 查看是否有分支机构以及协作之间是否有可交付成果。 询问并改正。
三确认：最后一步是自己讲流程，与客户代表或业务专家进行最后确认。
10.交互原型（必填）
几乎可以说，以上所有的事情都是在为交互原型的完成做铺垫。 相信大家对交互式原型已经很熟悉了，但是我会跟大家分享几个经常出错的点。
[1] 页面上尽量只使用黑、白、灰配色方案，避免干扰UI朋友的设计。 这是你经常犯错误的一点。 毕竟你的很多朋友曾经都是UI出身的。 当你制作交互式草稿时，你也会顺便匹配颜色。 这尤其会影响UI设计的朋友。 我也不希望有人指着门）。
因此，我们在制作交互式草稿时，只使用黑白灰就足够了。 灰度的大小代表了信息的重要性，只要简洁、规范就足够了。
【2】虽然用连接线来表示页面跳转很方便，但真正厉害的人不会到处炫耀自己的技巧。 有些朋友在交互稿上加上了很多花里胡哨的东西，比如各种跳转、动态面板、重复器等等，这让开发朋友看起来很心酸，所以往往用最简单、最清晰的形式来表达连接。
[3]如果涉及多端设计（IOS、Andriod、PC），除非产品很大，否则应该放在同一个设计文档中，避免多个文件供后期审核。
【4】创建适合自己的元件库。 在日常设计中，80%的控件可以重复使用。 制作一个合适的元件库可以节省很多时间。
11. 垃圾桶（可选）
在制作交互式文档时，垃圾桶相当于后悔药，因为有些页面删除保存后无法恢复。 因此，如果在编辑稿件时可以将一些暂时不需要的页面扔进垃圾桶，就可以避免最终回到原计划。 重做是浪费时间。
2. 总结
嗯，文章分享了很多内容，但并不是每个部分都要做，而且文档也不是绝对的规范。 每个公司交互设计师的职责可能会有所不同，大家可以根据自己的需求因地制宜。
有人曾经说过，设计的本质不是让简单的事情变得复杂，而是让复杂的事情变得简单，所以我希望在三天的时间里，大家都能把交互设计文档变得非常简单，把产品做得非常好。 然后和我分享一下经验，这就是我写这篇文章的初衷。
最后希望你能有所收获，与你共同进步~~
