整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
互文档该怎么写呢？这个问题不只是新手在问，在工作中要负责交互问题的产品经理、设计师，都在纠结这个问题。本篇文章就从基本认识、工具选择和制作过程这三部分内容来为大家讲解交互文档要怎么写，快来看看吧。
今天要分享的，是后台和社群里几乎每天都有人问的交互文档该怎么写的问题。不只是想要往交互设计师方向发展的新手，还有工作中要负责交互问题的产品经理、设计师，都对它存在大量的疑问。
所以我们在今天这篇分享里完成一次深入的扫盲。
交互文档，是一份用来解释项目交互方式、内容、规则的说明文档，也叫 DRD ( Design Requirement Document )。
在过去的分享中，我们有解释过，B端项目会包含大量的交互内容，需要前期绘制交互原型来展示和确认交互方案。
如果是比较简单的小型项目，或成熟产品的小迭代，那么这样的连线图确实就足以表达交互的意图和方案了，写太多注释文字反而会画蛇添足提高观看者的认知成本。
但是，如果项目和展示的流程内容，逻辑非常复杂，包含非常多的选项和状态，那么单靠原型和连线是绝对不够的，添加更多的图文说明就变得非常有必要了。
同时在团队协作场景中，就需要将这些内容制作成一份规范的 “文档”，用来进行统一的展示、备份、归档。
所以做交互光靠画交互原型是不够的，“文档” 就成为必要的输出成果。
在产品侧（非开发），文档就有好几类：
BRD 和 MRD 是一个产品经理行业内部也在反复科普讨论的东西，和我们没多大关系可以暂时忽略。设计规范文档 DGD 大家应该也有概念，比较容易辨识，也不需要在这里强调。
而产品需求文档 PRD，是和交互文档最撞脸的文档类型。它们的文档规格、样式几乎一致，还包含大量界限模糊、相互交叉的内容范畴，会对新手的理解造成很大的不便。
要理解产品文档和交互文档的核心差异，就得从他们各自的工作职能说起，产品经理的主要产出是解释产品要做的功能和逻辑，所有的原型和连线的目标都是为了解释功能本身。
部分产品经理会 “顺带” 在这个基础上增加交互的元素，以及相关的说明。这恰恰是问题的关键所在，因为产品经理制作产品原型的过程是可以覆盖一部分交互信息的，所以很多设计师也天真的认为交互内容是应该由产品来出的。
这当中一定要关注里面的 “顺带”，因为一份有效的 PRD 主旨一定不是以交互为核心的，在面对需要大量图例、连线、方案、解释的交互问题下面，产品经理往往选择直接跳过，只把功能描述清楚，剩下的就交给交互设计师还是 UI 设计师来完成具体的交互方案。
所以，交互文档就是在产品文档的基础上，进行交互内容的补充，专注于解释项目的交互内容，让设计师和前端开发可以更直观得理解后续的工作内容。
来自 UEDART 的付费文档，案例地址：http://vip.uedart.com/interactive.html
交互文档和产品文档是相互独立和补充的，当产品文档无法完成对产品交互的有效解释时，我们就应该选择输出独立的交互文档，来提升项目协作的效率。
主流的交互文档输出有三种方式：
Axure 和墨刀是用来制作产品原型的软件工具，也是目前在产品经理、交互设计行业中应用最广泛的原型工具。
它的主要优势，在于可以比较方便的制作可交互的组件、连线、导出。
当然，光制作原型图并不能叫交互文档，它们还提供了比较全面的内容标注、文本记录、图形绘制的功能。
这就可以让我们完成原型绘制以后，结合页面结构的管理，添加交互文档所需的其它信息，并最终输出文件。
而在一些比较传统的行业或外包领域，使用的记录文档往往要使用 Word 或 PPT（方便开会演示或要打印）。这就要在原型完成以后，导出原型图例，并使用这些文档软件进行文字的记录和连线。
受限于 Word、PPT 的布局限制（强行分页），使用它们做交互文档是非常难受的，并且这些文档需要保存到本地，存在各种文档版本管理的问题。
所以还有另一部分也希望使用普通文档格式记录，并满足云端同步、备份、版本管理的团队，就会使用 Wiki 类的工具来制作交互文档。如语雀、飞书、Confluence、Notion 等工具。
如果只是一些比较小的项目迭代、一次性使用的交互文档，使用前两种方法都可以胜任。而真正大型、系统性的交互文档，往往都使用团队内部的 Wiki 进行创建和管理。和设计稿不同，这些使用了内部账号或需要内网访问的文档资料，是不会没事发到网上来分享的，这也是在网上找不到完整交互文档的主要原因。
和你们网上可以找到的大多数交互设计干货不同，我即不推荐你们使用 Axure/墨刀 来画原型，也不推荐用它们或普通文档、Wiki 的形式来输出交互文档。因为：
—— 太低效了！
产品经理和交互设计师的主要产出物就是文档，自然可以耗费比较多的精力和时间去制作原型和编写内容。而 UI 设计师的主要工作肯定是最终的视觉界面和交付，所以用最复杂的方法去制作交互文档，显然是不合理的。
同时还要提一句，Axure/墨刀 等软件用来制作一般的线框图原型，效率实在是太低了。且绝大多数情况下的页面跳转、交互都是可以忽略不做的。而且随页面增加，它的左侧导航层级、数量会非常庞大，导致查找和浏览的效率进一步降低。
我始终都建议直接使用你们正在用的云端 UI 设计软件直接绘制产品、交互原型并输出文档，如即时设计或 Figma。原因包含：
比如下面这样的原型案例，就可以通过一个简单的链接快速分享出去，或者添加团队成员自由查看。
在我过去长期的实践体会中，这种方式是优势最明显、效率最高、最易懂，也符合 UI 设计师工作需要的。如果项目中有其它因素要求，你们也可以选择前面的方式输出。
任何文档的目标都是为了书面记录和让看的人更容易理解我们要表达的信息，不要被固定的方法局限住，要努力去探索适合团队当前场景的方式。
前面把基本的信息聊完了，这里就来具体讲讲交互文档应该如何进行输出。
当然，输出交互文档前需要先理解交互是什么，交互设计的具体设计内容和步骤。交互文档是对你已经设计出来的方案的书面记录，你不能在对交互一无所知的情况下强行编写文档。
交互文档制作首先要确认文档的记录内容和文档结构。
记录内容指的是你在该文档准备放哪些交互内容进去，并不是每次项目设计都要把项目所有页面和流程交互都重做一遍。
比如一次中等规模的迭代，新增几个通用的列表页面，调整了一些细节字段，增加了一个功能流程。那么文档重点记录内容肯定就是流程而不是所有页面。毕竟通用的列表页和细节更改，在产品需求评审阶段就可以完整的解释，而功能流程则不行。
如果是全新的项目，包含数十上百个页面。把所有流程、页面的交互内容全部表现出来的工作量是顶不住的，在绘制原型的过程中，你就会发现有大量的重复页面、流程和交互。所以制作文档就要有目的性的对重复的内容进行合并，以及只保留重要的页面和流程。
具体该放什么要考虑项目的实际情况，需要设计师自己评估。除此以外，标准的交互文档里面会包含背景介绍、编辑日志、文字图例、业务流程、名词解释、页面结构等等。
这些 “文绉绉” 的细节，并不是必备的，你可以根据当前场景自己决定需要加哪些。比如项目、业务背景前面的产品需求已经讲清楚了，业务流程、名词解释团队成员也都了如指掌的时候，那么这些页面模块就完全没有放的必要。
并且，基于前面对放置内容的考虑，结构的顺序并不一定要类似下方案例，完全按照产品的导航目录来走。
所以，根据一个中等规模的迭代项目，我会制定一个这样的一级文档结构：
每个1级文档结构对应 UI 软件中的 Page 目录，力求所需的 Page 数量越少越好，而不是像 Axure 的做法一样密密麻麻的。
结构可以根据复杂程度做进一步的细分，它像写文章的大纲一样，帮助我们提前规划好后续完成文档所需的内容和工作量。
有了结构，就要在对应的 Page 中填充内容了。其中一般的文字介绍、流程图、思维导图，只要正常输入或将导出的图例黏贴进来就可以。
而针对具体的交互内容，流程解释上，则重点处理连线和标注说明。比如下面是我自己在课程演示中的一个简单的交互流程演示案例。
在 UI 软件中，制作连线其实是很简单的事情，只要画出一个直线，再设置箭头和尾部图形、描边色彩和粗细即可。
然后，将该线段的图层放置在画布之外，起点放置在触发交互的区域之中，终点尖头则紧贴目标画布的边缘（不用特意延伸进画布内）。如果使用水平、垂直的方式连接两个画布，那就可以双击进去添加锚点制作 90 度的折角。
连线的应用是非常简单的操作，不要舍近求远通过插件或是其它的一些功能来实现。而除此之外，我在文档中添加的解释性文本主要有两种，交互事件和交互规则。
交互事件代表了连线的两个页面是如何被触发跳转的，所以我会在线段中帖一个文字卡片，解释触发的条件和交互操作是什么。
然后，就是页面或流程中的交互细则，包含两个部分，数字标签和对应文字注释。它们都是用 Auto layout 可以快速制作出来的组件，每次要做备注的时候，只要复制标签到页面上，设置对应的数值，再将右侧的文字卡片复制到页面旁边，再加上对应的数字、内容信息即可。
在设计软件中，画布的自由度极高，你想要怎么备注和添加内容都没关系，只要在内容翔实的基础上保证 —— 团队成员能看懂，就是一份优秀的交互文档。多在绘制过程中和同事沟通，优化展示的做法，可以避免很多会出现的问题，进一步加速我们的制作效率。
将文档全部做完以后，最终就是关于交付和协作的问题了。
既然我们使用线上的 UI 软件来完成交互文档的制作，那么文件设置公开访问权限，再分享链接自然是最简单的办法。
但每次项目分享个网页链接，或者并行有好几个项目，需要其它成员自己去收藏网址，也是挺麻烦的。所以尽量充分应用软件中的团队协作功能，通过创建一个团队，添加成员，让他们自行查看当前文件目录中的交互文档。
查看过程中，团队其它成员可以通过评论的功能对交互内容进行纠错、提问、建议，方便我们进行优化改进。
通过这种简单高效的文档协作模式，我们可以非常快得完成整体交互内容的定稿，并开始后续的工作。
再回到前面的话题，我们是 UI 设计师，不是全职交互设计。原型文档输出完了，下一步可是要做视觉界面的，所以交互文档就可以不用管了嘛？
交互文档的最佳状态是 —— 应用最终界面图例解释交互内容。
也就是当我们把所有页面内容设计完成后，强烈建议将界面的展示和交互文档进行整合。除了前端和产品可以看到最终的交互落地效果外（有时候最终设计和前面的交互不一致），还可以直接通过这个文档查看界面数值标注，而不用往返于交互和设计文档来回切换，这才能让文档作用最大化。
以上就是关于交互文档的相关解释，下一篇，我们会聚焦在和表单有关的交互干货分享。
我们下篇再见。
作者：酸梅干超人；公众号：超人的电话亭（ID：Superman_Call）
本文由 @超人的电话亭 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash ，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
辑导语：作为交互设计师，离不开交互设计文档，刚入行的小伙伴可能会在网上找模板套用或者是自己摸索，这样效率低下且容易走弯路。那么，如何完成一份完整的交互设计文档呢？作者总结了以下几点，教你手把手撰写交互设计文档。
作为交互设计师，我们平时工作最大的产出就是交互设计文档，很多刚转行的同学会在网上寻找模板直接套用或者自己慢慢摸索，而这篇文章会手把手教你怎样完成一份完整的交互设计文档。
为什么要写交互设计文档？交互设计文档有什么用？
第一，交互设计师的交互设计文档就好像UI设计师的PSD文件一样用于保存记录自己的设计思路，但交互设计师负责的任务不仅仅停留在页面当中，还包括产品的需求分析、用户画像、竞品分析、产品数据分析、用户交互逻辑等等。
我们都可以写在交互设计文档中做记录，为我们的交互设计提供依据（其实就是避免开发怼你、问你设计依据是啥，你就马上把分析摆他脸上，避免尴尬）。
第二点是交互设计师作为产品的上游，一般开发流程是产品经理负责收集需求给予交互设计师进行交互设计，撰写交互设计文档。
然后文档评审通过后，UI同学负责UI设计，接着提供前端同学进行界面开发，后端同学则根据交互稿搭建框架和业务逻辑，开发完成后进行测试，反馈测试结果，如此循环。
因此交互设计师一般处于产品线的上游阶段，撰写一份标准和规范的交互设计文档是非常重要的。
因为我们需要利用交互设计文档去表达我们的设计思路，通过交互文档我们可以让UI同学知道页面需要给用户表达什么情绪，达到怎样的目的，告诉前端同学页面跳转逻辑以及交互模块怎么写，帮助后端同学清晰搭建后台框架与数据库以及产品业务逻辑是怎么样的，最后测试童鞋还会拿着你的交互稿进行单元测试，编写测试用例。
所以只有我们先把文档写好了，才能避免后面产品开发出现问题。
第三点也是最重要的一点就是未来我们用于跳槽加薪面试作品。
内行看门道，外行看热闹，如果你面试交互设计师的时候还是带着一条长长的JPG或者是网上千篇一律排版的PDF作品集，在面试官眼中显得不入行（或许你会遇到性格好的面试官，毕竟千人千面，面试特别看人）。
因为专业的交互设计师在平时工作中为了避免干扰UI同学设计，只会使用黑白灰做交互稿，也很少做成一条长长的PNG或JPG，我们可以适当包装作品集，但是如果过度了会让人觉得不落地，或许只停留在刚入行阶段。
所以在技术面试，我们可以拿着我们的交互设计文档跟面试官叙述产品从需求层面怎样思考完成交互设计的，解决了用户什么痛点，最后取得了什么样的成果，得到了怎样的数据，我相信成功几率会大很多（PS：用交互设计文档进行面试前请注意把公司机密信息做脱敏处理，避免发生纠纷）。
交互文档包含什么内容？以及怎样撰写交互文档？
一般来讲，一个基础、规范的交互设计文档应该包含文档封面、更新文档、设计说明文档、业务流程图、交互原型、垃圾桶等模块，当然了，这些模块也不是永恒不变的，有些是必须要，有些是选择性添加的，至于这些模块有什么功能和怎样进行撰写，这篇文章会逐一分享给大家~
（说明：作者比较习惯使用Axure软件撰写交互设计文档，你们可以根据自身爱好或者公司规定进行选择（例如sketch、figma、PS等等都是可以的）。
这里要引用一句话：软件仅仅是工具，并不能限制我们的思维，好的工具能让我们走得更快但不能使我们走得更远——沃·兹基硕德。
文档封面就相当于一本书的封面一样，用于记录产品名称、版本号、日期以及文档负责人（这样开发童鞋就能精准找到你进行撕X），只要能展示以上信息，其他信息（例如产品经理是谁等）可以自行添加。
以前我都习惯把更新日志放到产品文档后面，但是随着工作时间变久，我发现开发童鞋在SVN上打开设计文档后第一时间就是查看更新日志，所以后来把这一页提了上来（是的，设计文档也是需要跟产品一样不断优化迭代的）。
更新日志主要用于记录产品迭代修改的内容，让开发同学快速了解这次迭代修改了什么内容，他需要做哪些工作。
我的更新日志特别简单，就只有日期、变更内容、所在页面以及备注四个字段，这里唯一注意的是，日期必须是最新修改的内容放在上面，以前的日期在下面，很多同学每次迭代的时候会在下面列进行内容添加，这样开发同学每次都必须滚到最下面查看信息，大哥，你是交互设计师，专业一点好吗。
产品项目背景是一个项目的核心关键，告诉所有的团队成员我们要做一个什么样的产品，需要创造什么样的价值，就好比我们写作文时的中心句，时刻提醒着我们要不忘初心，为团队成员开发项目指明方向。
前段时间有个同学来问我，他们本来是刚开始是做校园教育系统的，但是随着产品慢慢迭代，功能逐渐强大了，最近老板希望在系统中加上财务功能，本来用户学习成本就高，如果再加上去会不会适得其反？
虽然我不知道那位同学的老板产品战略是啥，背后是怎样思考的，但是在我看来这样的行为就不能是不忘初心，这顶多能算不忘出薪吧（拒绝谐音梗从我做起）。
好了，至于里面产品背景、产品目标以及定位的内容应该如何撰写？对，我抄的。一般情况下，这些内容我们都能够在项目立项文档或者在招投标书上就能找到，我们不用亲自写（但可以加以设计），再不行也能找到产品经理去了解。
或者你会说，小公司既没有立项、也没有招投标书，产品经理也是你，那该怎么办？那么你就得发挥出自己当年高考的作文水平，积极了解清楚产品背景定位，努力完成这一部分，因为信息的传递是有消耗性的，只有我们作为产品的上游做好了，才能为团队成员后面的努力提供方向。
产品需求列表用于记录产品需要做哪些【功能点】，这些功能点我们一般能在产品经理或者项目经理上获得，我们收集需求后需要对其按照重要程度P0、P1、P2等级进行分类。
我分类的原则是KANO法则（不知道的同学可以百度），P0等级是非做不可的需求，例如像微信的聊天，淘宝的支付功能等，P1是锦上添花的需求，时间紧迫的话可以下次再做的，例如微信的语音、视频聊天等。
排到最后Pn就是一些不必要可做可不做，就算做了也没太大影响的功能，就可以与领导层商讨是否确认要做（例如炸屎，你们现在还有人炸屎吗？什么？炸屎你都不知道？那当我没说）。
所谓知己知彼百战不殆，通过用户画像我们可以快速了解产品目标用户群体特征，分析目标用户群体的期望、需求、动机等，再根据用户场景去进行设计。
有了用户画像的支撑，能避免我们在设计过程中出现一些不必要的因素，例如我们目标用户是中老年人的话，那么按钮、字体就应该适当的放大、排版简单明了，而针对青少年就可以偏个性化风格设计。
当然，如果是小公司的话可能没有那么多的资源去做用户的调研，在这里分享一下我当年在创业公司经常使用的一种快速获取用户画像的方法，既快速又特别专业。
这里需要借助一个网站：艾瑞数据（https://index.iresearch.com.cn），打开后选择自己产品的类型（例如学习教育类），网站会把该类型的产品按照用户数量从高到低展示给你，然后我们选择一个差不多的竞品点击去查看他们的用户特征，最后Ctrl C+Ctrl V到我们的文档中，完成。
竞品分析相信大家都特别熟悉，我之前的文章也教过大家怎么进行详细的竞品分析，这里就不细讲了，虽然在交互文档中竞品分析可做可不做，但是在产品初期阶段我们。
如果认真做竞品分析的话能够快速了解产品业务、熟悉用户的使用习惯，同时当我们在做交互原型的时候能提供快速借（cao）鉴（xi），因此有条件的同学还是建议尽量做一下。
数据分析时交互设计师必不可少的一项技能，也是验证设计成果的重要因素。如果缺少了数据分析而单凭个人主观因素的话，我们难以说明设计效果的好坏，毕竟现实中会出现各种意想不到的情况。
所谓“无对比，不分析”，一般数据分析都是通过数值进行对比，去查看数据相对是上升、下降、还是持平，是否跟当初设计预期的一样，对于初期的产品会更关注产品的一些DAU(日活数)、GMV（成交总额）、以及支付人数等，因为这些数据的增减是直接影响到整个产品的存活，如果产品的DAU不断下降的话，那你就要马上查找原因，及时调整，避免恶性循环。
一般情况下，像日活数那些简单的数据可以直接问后台同学就能获得，而用户某些环节的存活率、转化率等就需要利用【数据埋点】，市场上也有很多第三方做数据埋点的，例如神策数据、Growing IO等，这里就不展开说了，但是面试的时候你能说出这些就会显得很专业。
信息架构属于用户体验的结构层，就像产品的骨架一样，而信息架构设计就是对产品信息进行构架、归类的设计，信息架构能够防止我们对产品功能点遗漏，同时也可以通过产品大体的信息架构观察出产品设计是否合理。
一般来说（干货来了），产品架构分支可以分为度和层，而好产品的信息架构在广度和层度都是恰到好处，下面我举两个反例大家就懂了。
产品架构的广度太广（不懂的看下图）：信息架构的广度太广意味着页面的承载信息量特别的多，没有侧重点，这样用户点进页面后会思考很久而不知所措，最经典的就是某某宝和某同城，新用户进入到首页真的模棱两可。
绘制业务流程图的目的就是：梳理并分析优化业务流程。我知道很多同学做UI设计师的时候可以完全不管业务，直接做设计，但是作为交互设计师了解产品业务是非常重要的，因为不了解业务你就无法完成交互设计，优化业务场景。
举个例子：在教育考试系统中一般流程是：教育局出通知→学生报名考试→老师审核→报名通过→老师编排学生考试名单→学生开始考试对号入座→教育局公布成绩→学生查询成绩→考试结束，看这一些列的流程。
因为关联特别多，如果对业务不熟悉的话设计起来会非常的不便，如果前期因为业务流程不熟悉而设计出错误的交互稿的话，后面就会特别麻烦。
那么如何去绘制完整的业务流程：
如果你的产品经理比较专业的话，可能会直接给你一个现成的业务流程图，那样就能省事很多。
要是没有产品经理的话，最直接的就是问用户，这里介绍我最常用的方法就是“一听二问三确认”。
一听：先听客户代表或者业务方的介绍。听得过程中，不打断对方，以最简单的方式勾出主体脉络，即基本要素中的角色、活动、协作关系梳理出即可。
二问：完成上一步后，就可以进行提问了。主要是沿着流程进行发问，重点放在分支、产物关系上。看看是否存在分支的情况，各协作之间是否有交付物。一边问，一边修正。
三确认：最后一步就是自己讲一遍流程，和客户代表或者业务专家进行最后的确认。
几乎可以说，上面所有的东西都是为了完成交互原型做铺垫的，我相信对大家来讲交互原型都非常熟悉，但是给大家分享几个经常犯错的点。
【1】页面尽量只采用黑白灰配色，避免干扰UI同学设计。这是大家经常犯错的一个点，毕竟很多同学以前是UI出身，做交互稿时也顺便配配色，这样会非常影响UI同学设计的（不在其位不谋其政，你做UI的时候也不希望有人在旁边指指点点吧）。
所以我们做交互稿时只采用黑白灰就够了，灰度大小就代表信息的重要程度，简洁规范即可。
【2】页面的跳转用连线表示其实就很方便了，真正厉害的人不会到处炫技。有些同学在交互稿上各种跳转、动态面板、中继器等花里胡哨一大堆，这样开发同学看起来特别的难受，所以很多时候用连线的方式表示往往是最简单明了的。
【3】如果涉及到多端设计（IOS、Andriod、PC端）的话，除非产品非常庞大，不然就放在同一个设计文档中，避免以后评审还要弄多个文件。
【4】创建一个适合自己的组件库，在日常设计中，80%的控件是可以重复利用的，做一个合适的组件库能节省大量时间。
做交互文档时垃圾桶就相当于后悔药，因为一些页面如果删掉保存后是不能还原了的，因此在改稿时如果一些暂时不需要的页面可以丢到垃圾桶中，避免到最后用回以前的方案时重新再做浪费时间。
好啦，文章分享的内容比较多，但是并不是每一部分都非做不可，文档也并不是绝对的规范，每一家公司交互设计师的职责可能都不太相同，所以大家可以根据自身需求因地制宜。
曾经有人说过，设计的本质并不是把简单的事情做复杂，而是把复杂的事情做简单，所以我希望有一天你们能把交互设计文档做到很简单，而把产品做得非常好，然后跟我分享经验，这才是我写文章的初心。
最后希望大家有所收获，与大家共同进步，共勉~~
本文由 @北沐而川 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
大多数优秀的企业网站建设中，他们的设计方案通常会包含了视觉部分、交互部分以及管理员使用部分这三大板块的精雕细琢工作。而很多深圳很多企业负责人往往会只注重视觉设计部分，忽略了交互部分的定制。今天跟大家分享的这个阴阳脸交互设计，是在不少领域、不少高级品牌网站中能看到的。所谓阴阳脸交互，即用户在一个屏幕内会看到左右平均分布的两块内容，随着用户自动拖拽内容后，从左往右展开或从右往左展开视窗的宽度，从而让一半显示更全的交互逻辑设计。
阴阳脸网页交互设计通常会用在艺术行业、科技行业、医疗行业等领域，它的特色就是神秘感、互动感，在某些不适合渲染这种氛围的行业，就不能随意使用这种交互，效果会适得其反。
为了更好地展示这个交互效果，我们找来了一个在线的深圳公司网站案例
访问深圳网站建设官网，查看动态的交互效果
https://www.gloshine.com/
值得设计师们注意的是，阴阳脸网页交互设计，需要注意它的承上启下作用，要么作为官网Banner区域的全屏模块内容，要么作为下面两个板块之间的衔接模块，这时需要注意虚实结合的节奏。而阴阳脸通常都是深色为主的，所以它的上面和下面，尽量不要都是深色区域，至少有一个是浅色的（或颜色对比度稍微大一些的），避免连续三个重色模块，导致视觉无法呼吸。
在看另一个深圳网站建设案例，这是一个产品H5专题页的形式
访问深圳网站建设官网，查看动态的交互效果
http://www.coleder.com/products/ace-block/47.html
阴阳脸交互设计在网站建设中的运用
注意阴阳脸交互设计运用的上下环境搭配
好了， 以上就是今天跟大家分享的，通过阴阳脸交互设计让深圳网站建设公司提出的设计方案与众不同的好技巧。
*请认真填写需求信息，我们会在24小时内与您取得联系。
