最近有设计小伙伴咨询，什么样的互动讲解最好，大家喜欢。当他写的交互描述文档提交给需求评审会的成员评审时，大家都建议他写得合理一些，这让他很苦恼。我告诉他：首先，工作目标不同：没有完美的交互描述能够打动和惊艳所有人。毕竟，由于阅读交互式文档的对象不同，他们对交互式文档的要求也不同，这是工作属性造成的。比如前端开发要细化字段、初始默认值、数据检索接口等，而领导只需要看确保业务方向正确的交互大链接即可。二、同一岗位认知不同：同一岗位不同成员的认知、经历、个人喜好、性格、脾气，也会导致无法有一份完全适合每个人的交互式文档。比如一个在某个行业工作多年的前端工程师，即使你的交互文档没有那么详细，他也能从你已有的文字中推导出其他方面，同时帮你补充；一个前端工程师，你写的不详细，他会抓狂，项目时间紧的时候，交互细节他自己补。之后，你走过检查的时候会发疯，但是没用。谁让自己没把交互细节写清楚，就漏了。第三，使用场合不同：不同场合需要的交互文档也不同。比如与对方面对面交流时，可以少写一些互动性的说明文档；但是通过在线工具与对方沟通时，需要写的尽量详细；如果是会议式的review，一定要做好各方面的功课。简单来说，就像准备PPT一样：同一个话题的PPT，对外演讲和公司内部演讲，同一张PPT需要设计两个版本，一个是内部版，一个是公司内部版。外部版本。原因是它的用途不同。第四，产品阶段不同：交互文档描述的是一个产品的交互，而不是其他的。如果产品处于成熟期，产品的交互文档往往已经积累了很多通用规则，可以重复使用，所以现在的交互文档写得比较少，问题不大；但是产品处于探索或者成长期，一般来说，可复用的交互资产是不存在的，所以交互文档需要准备的比较好。有设计小伙伴说，既然不可能让所有人都满意，那我就按照自己的想法来写吧。这不可能。毕竟我们的主要工作有一部分是编写交互文档，这需要认真、严谨、专业的工作态度才能做好这部分工作。那么我们就来看看编写友好的交互文档要注意什么。什么是交互描述文档？交互描述文档是用来告诉参与产品开发的团队成员页面交互细节的描述文档，包括页面之间的逻辑跳转、页面内模块的交互、页面功能的状态等。越详细的交互描述文档写的越有利于产品开发各方的正确执行。需要改进的交互式文档我总结了一些在日常工作中需要改进的交互式文档形式，看看存在哪些问题。1、文字密密麻麻，没有结构。几乎所有刚入职场的设计师，在写交互文档的时候，都怕自己写的少了别人觉得自己不专业，不完整就无法表达页面的细节，导致密集的交互式文档。是文字，让读者几乎无法阅读，找不到视觉立足点。2.描述简单，不完整。有几年工作经验的设计师，由于很多通用的交互规则已经很明确，在写交互描述文档的时候比较简单，有些交互没有写在文档上，导致在开发的时候忽略了某些交互。3、数据太假，没有逻辑。交互式草稿数据没有逻辑，这是很多设计师经常遇到的问题。一部分原因可能是产品经理在提交设计师画图之前没有理顺产品逻辑和细节，另一部分原因可能是设计时间紧迫，来不及做所有数据在互动稿件上逻辑合理。我遇到过关联值无法关联，表单中字段对应的值不匹配，表单填写的数据与实际情况不符的情况。建议大家在时间允许或产品经理协助完善数据的情况下，尽量展现数据的真实性和逻辑性，有助于开发者和相关读者高效理解。4.图文距离太远，找不到。有几次我注意到设计师提交的交互说明会标有“见图X”之类的字样。也就是看完一段说明，你要到页面的某个角落去寻找对应的图片。这种体验非常糟糕。交互设计的原则之一是“待在家里”。“待在家里”是指在当前页面可以解决的事情不要转到其他页面；附近可以做的事情，不要离得太远。频繁的切换跳转会打断用户的心流，容易造成用户思维的中断，思维不畅，甚至对产品产生反感。同理，我们的互动讲解文档中的图文也要尽量相邻。通过一目了然的文字和图片，让用户看得顺眼、看得舒服、理解得快。5.零散、一句一句、一句一句、一句一句、一句一句是指互动讲解文档中的文字应该作为一个整体来描述，却分成几个部分来解释，这对阅读文档的人来说是一场灾难。他需要自己重新梳理交互思路，串联交互规则。当我们编写交互式文档时，我们尽量避免上述常见问题。什么是好的交互式文档网上搜索什么是好的交互式文档有很多。在这里我将根据自己的经验与大家分享什么是好的交互式文档。首先要明确什么是好，有了好的标准之后，再说说如何做好。1.什么好？通常情况下，交互式文档会展示给产品经理，以审查设计方案是否符合要求；视觉设计师指导视觉解决方案的呈现；给前后端开发者指导开发逻辑；供测试工程师协助编写测试用例。基于此，一个好的交互描述文档关系到设计方案能否最大程度的实现。而如果交互文档的文字很长，逻辑不清晰，不仅让人难以阅读，而且与开发工程师的沟通也需要额外的时间。一份好的交互文档，我认为，至少需要具备以下7点：清晰的价值考量全面、通俗易懂结构清晰，图文清晰仅此一篇修改记录《交互案例》给大家讲解。清晰的价值可以通过文档帮助项目成员更顺利地完成工作任务，帮助用户解决问题，实现产品目标。是一个很好的交互说明文档。文档对各方都是有价值的，是一个好的交互文档的起点。那么，如何写实现上面的结果?一方面是写清楚这个文档的价值，包括说明交互设计的背景，需求来源，需求列表，说明交互的理论基础设计，可以给用户带来价值等。另一方面，需要向会员宣传这些内容，让会员感受到他们要做的工作很有价值。“表单验证”发挥作用：考虑到文档阅读对象等相关因素的综合抛弃，一般来说交互需要考虑以下几个方面：整体交互流程整体交互流程是指产品页面与页面之间的交互逻辑。b.页面模块交互描述页面模块交互描述是指模块本身的交互描述，或者是同一页面中独立模块之间的交互逻辑，或者是不同页面模块之间的交互逻辑。比如点击导航树节点，会刷新右边表格的内容；点击banner会跳转到对应的商品详情页面，并定位到页面1/2位置。C。页面功能交互描述页面功能交互描述是指对单个功能的各种情况的描述。比如在搜索框中输入文字，通过回车触发相应的页面跳转。d.尝试显示尽可能真实的数据。虽然是交互式描述，但我们尽量模拟真实数据，否则很容易让读者做出错误的判断。不是每个人都会逐字阅读文档。因此，尽可能多的真实数据将有助于读者更有效地理解。e.特殊情况的补充说明很多情况下，由于某些原因会出现极端的交互情况，此时需要补充完整。F。在通用交互的地方，建议交互团队为产品建立一个通用的交互描述库。如果遇到类似情况，可以直接调用。事实上，我们在写交互指令的时候，并不知道如何去细化，很多指令混杂在一起。“形式验证”发挥作用：通俗易懂是指让文字、语言、图片等易于被受众理解和感知，让信息在传递过程中尽可能少的丢失传输，这也与人类的理解有关。百度百科是这样解释理解能力的：“理解能力是指一个人对事物乃至知识的一种记忆能力。理解分为三个层次：低层次的理解是指：感性层面的理解，即是认识和识别物体的能力，能够命名物体并知道它是什么；中级理解是：在感性层次理解的基础上，揭示事物的本质和内在联系，主要表现在能够理解概念、原理和规律的内涵，知其然；高级理解属于间接理解，是指：在概念理解的基础上，进一步系统化、具体化，重新建立或调整认知结构，实现知识的精通，使知识广泛传播，知道它是“为什么”。在人类理解水平参差不齐的情况下，我们必须在工作中尽量简化专业知识（或Simplifiedthecomplexityforthecrowd），增强沟通效果，最终达到完成团队目标的结果。交互式文档尽量用人话来说话，而不是谈论一堆技术术语。记得有一次交互设计师在一次会议上讲解他的交互方案时，提到了“提供邀请”的原则。由于参会成员都是开发工程师和产品经理，所以他们问“提供邀请”的原则是什么，大家就这个问题讨论了很久。可见表达方式通俗易懂，非常有必要。结构清晰交互式描述文档除了要易于理解之外，还需要结构清晰。结构清晰的内容不仅能让读者一目了然，还能让读者明白作者的用意。要做到文档结构清晰，除了要遵循一些规则外，还不能脱离当前文档的实际情况。“形式验证”发挥作用（将文本加工成段，提取关键词）：图文相辅相成，可以加深读者对文本的理解，同时防止读者想象出相应的结果文本。由于人们对同一段文字的理解不同，建议设计师尽量安排与图表相对应的交互插图。“表单验证”发挥作用（左图，右文字）：只有这个是唯一的，这意味着在向团队交付交互式文档时不能有多个副本。之前我们的前端小伙伴拿到了两份交互文档，一份是纯原型交互文档，一份是可视化草稿交互文档。两者描述的信息是相似的。此时建议将交互文档的信息合并，只提交一份完整的给前端小伙伴，让前端小伙伴集中精力理解一份。修订记录建议交互式文档保留修订记录。一方面可以了解交互式文档的变更历史，另一方面有利于回溯查找资料。修改记录一般包括修改人、修改时间和修改内容。总结由于项目进度和业务复杂度的不同，我们不可能每次都写出最好的交互文档，但是我们可以想办法写出相对易读易懂的友好文档。交互式文档。我们常说我们在做用户体验，交互文档是体现我们交互能力的一个方面。除了完成交互描述文档之外，如果想让开发者真正理解交互描述，还需要与开发者当面交流。别以为我写的很详细，为什么他的实现还有偏差。其实就像开头说的：同一个岗位不同的人，认知理解不同，工作经历不同，个人喜好不同，性格脾气等等，也会导致理解不同。特别是对于我们一些非常创新的、特殊的交互点，需要重点关注和开发澄清。而且，基于业务的发展，交互文档会不断迭代。我们要多听，多想，多思考，多接受的态度，不断优化我们的文档，努力写出友好的交互文档。.
