交互说明，是交互设计师必不可少的‘写作能力’，它能让研制朋友愈发了解你的方案说明、交互看法。
但写得不好，容易出现流水账式、逻辑不清楚、文案臃肿等情况，给自己带来额外的工作量，还影响着与研制同学的对接效率。所以明天想总结个人对‘交互说明’这块的知识，让你和研制朋友愈发愉快地打闹~
目录：01.技术型交互说明02.只写最重要的
03.它只是个‘黑板报’
04.按模块来展示说明05.建立交互说明库06.真实的数据展示07.复杂说明另外展示08.有修改时及时告知09.好的态度
01.技术型交互说明传统的交互说明，是依据自己的意识、主观看法进行描述，但因为每位人的文采不同、思维形式不一样，容易出现非常零乱的说明，相关室友看了表示压力山大想拔刀...
其实我们可以借助开发熟悉的技术术语、代码逻辑来探讨交互说明，使开发对交互说明有愈发直观的理解，比如if else逻辑、switch case逻辑、数据库标示数组。
· if else ：一种判定逻辑，根据判别条件正确与错误来执行对应的操作。它可以更直观地抒发逻辑关系，更利于开发朋友的理解。比如用户登入的多逻辑说明，可以如此写：
· switch case：
一种选择逻辑，根据选择项执行对应的操作。比如按照用户投入美钞的面值，决定可选择的商品类型。
‘default’是容易疏漏的选项：匹配不存在时做的事情。比如前面的反例，若是用户投了1元，或者投了一张纸如何办？这是就须要‘default’的处理了。
· 用数据库标示数组另外，一些‘动态参数’用数据库里的数组名称来标记也是一个不错的选择。比如：‘用户’，在数据库里的存储数组是 #UserName#，用它来替代交互说明里的动态参数，可以提高开发的理解效率。
怎么晓得每位数组对应数据库的抒发?接口文档：前端和后台之间拿来传输信息的文档，那里既有数据库的抒发，也有对应的英文描述。注：以上事例来自-唐韧《产品总监必懂的技术那点事儿》
02. 只写最重要的密密麻麻的文字说明，是初期交互设计师比较常见的‘毛病’。一是列全所有说明，可以降低被diss‘考虑不周到’的可能；二是间接证明自己的专业能力。
但是！交互说明其实是要给人看的，堆积的文字谁看得下去？？只会带来额外的阅读压力和极高的理解成本，交互设计师更改上去也麻烦。一俩个页面还好，多个页面都是这样的说明，开发没约你‘一起去登山’就不错了。
图片来自百度图库
所以个人建议，只针对有异常状态、特殊交互、分支流程、关键节点等特殊地方进行说明即可。对于一些常识性、无异常点的地方就不用写了。无非常需交待的地方，写了只会让开发形成怀疑：这个地方是不是在特殊交互？
03.它只是个‘黑板报’不要幻想单凭一份交互说明，就能让开发完全、正确明白你的看法，那几乎是不可能的事。在我看来，交互说明只是个和开发传达内容的黑板报，一个沟通工具。
图片来自百度图库想让开发真正理解你的交互说明、方案逻辑等，还是得基于黑板报上的内容，亲自与开发沟通对齐。这样就能确定方案的有效性、实现难度、是否有须要调整的内容等，让双方的看法保持对齐。
前期与开发沟通清楚了，后面交互说明可以起到一个‘回顾、确定’的作用。而对齐的形式可以是交互评审会、工位口述、电话沟通等。只要目的能让开发理解你的交互稿，对齐方式可自主调整。
04. 按模块来展示说明这个‘模块’有2层意思：一是类似于‘内容组件’：对于重复性强、出现频度高的内容，设置一个模板内容及说明即可。对于重复出现的地方，直接取代过去就行，能够大幅度降低交互设计师的工作量，开发也便捷理解。
二是分页面/位置来展示：当整体交互原型较多时，没必要全都铺在同一个页面进行展示说明，会变得整体页面很臃肿、浏览上去比较费劲（尤其是文件很大时）。可以尝试：单独展示某个模块、分支流程、场景等下的交互稿。小而集聚，内容更精简、理解更方便。
若各模块/分支流程/场景中的交互稿存在一定的关联性，可以先变成一张总体性的‘概览图’，再去单独展示。让开发晓得整体方案之间的关系、又能了解各个细分方案里的交互说明。
05.建立交互说明库像一些常见、使用频度较高的说明，完全可以构建起一个‘交互说明库’。一是便捷自己及时调阅，节省时间与精力。二能统一你的交互说明风格，减少开发的理解成本，也能提现出你的专业素质。
06. 真实的数据展示想必这个你们都晓得，随便性地举例、描述数据，会让开发对内容的真实性、有效性、逻辑关系等形成怀疑。比如以下那个‘发文数’，更容易让人理解与‘启用数、启用率’之间的逻辑关系？
为了减轻这些误读，还是用最新、真实合理、上线数据等进行描述。如果在大会上让leader、boss对那些数据/内容提出了疑惑，就丢大发了，也会让同学指责你的基础能力、责任心。
07.复杂说明另外展示交互稿里总有一些比较复杂、难以文字来说明的看法，像是一些动效、状态、流程演示等。对于这一些比较复杂的说明，完全可以用demo演示、视频、gif图等方式来演示你的看法，让你的说明愈发可观性。像一些按键或功能存在多种状态时，也可以‘表格/列表’的方法进行展示。
08.有修改及时告知
除了以上情况外，若交互原型有了调整（包括交互说明），一定要与团队成员告知！！并提示更改位置（在那个页面）。否则产品、前端、后台、测试等朋友的相关看法、工作会逗留在上个交互稿里。别由于信息没对齐而导致了不良影响。就算改了一处小东西，也尽量和同步一下。
09.好的态度最后想说一句，没有人百分百、完完全全疑虑到所有细节和场景，即使你完全地走查了一遍甚至好几遍...
但因为不同角色的职业视角、预览目的、经验看法等就会提出新的疑惑、挑战你的方案说明。这是很正常的事~
更何况，在方案没对齐前，交互稿（包括交互说明）上都存在太多的未知性、待优化点。即使当前阶段确定了所有的细节与场景，随着方案时间的推动，后续总有新的看法、遗漏点、优化点涌现下来，那些我们认为的‘完全OK的方案说明’，也都弄成了‘过去式’...
我们要做的，必须是多听听多方视角的声音，并尊重、虚心接受别人的意见，而不是责怪自己为何考虑不周全、停留在原地钻牛角尖。
↘好文推荐：
点个“在看”吧
