怎么样的交互说明才是最好的，是大家都喜欢的

最近有设计伙伴咨询，什么样的交互描述最好，大家都喜欢。最近他写的交互规范文档提交给需求评审委员会成员评审的时候，大家都建议他写得更合理一些，这给他带来了很大的麻烦。

我告诉他了：

首先，工作目标不同：没有一个完美的互动描述可以打动和惊艳所有人。

毕竟c语言 图形用户界面，由于读取交互规范文档的对象不同，他们对交互规范文档的要求也会不同，这是作业属性的结果。比如前端开发希望细化字段、初始默认值、数据检索接口等，而领导只需要看大的交互链接，保证业务方向没有错。

二、同一岗位的不同认知：同一岗位不同成员的认知、工作经历、个人喜好、气质等，也会导致不可能有完美适合每个人的互动文档。

比如一个深耕一个行业多年的前端工程师，即使你的交互文档不是那么详细，他也可以从你现有的文字中推导出其他方面，同时可以帮你补充和补充提升。

对于刚入行的前端工程师，你不写详细他会发疯的，项目时间紧迫的时候，他会自己补交互细节。之后你去查会生气，但也没用。谁让自己错过了交互细节而不写下细节。

第三，用例不同：不同用例所需的交互描述文档也不同。

例如，如果你与对方面对面交流，你可以编写较少交互的文档；但是当你通过在线工具与对方交流时，你需要写尽可能多的细节；如果是会议式的复习，则必须各方面做好功课。

简单来说，就像准备一个ppt：同一个话题的ppt，对外演讲和对内演讲，同一个ppt需要设计成两个版本，一个是内部版本，一个是外部版本，原因是使用场合不同。

第四，产品阶段不同：交互规范文档描述了一种产品的交互，而不是其他产品。

如果产品处于成熟阶段，那么产品的交互文档已经积累了很多通用的规则，可以复用，所以现在的交互文档写的比较少，问题不大；但产品处于探索或成长阶段。，一般情况下，可复用的交互资产是不存在的，所以交互文档需要比较完整。

有设计小伙伴表示，既然不可能让大家都满意，那我就按照自己的想法来写吧。这是做不到的。毕竟，我们的部分主要工作是编写交互式文档。这需要认真、严谨、专业的态度来做好这部分工作。那我们来看看吧。

一、什么是交互文档？

交互描述文档是一个描述文档，用于告知参与产品开发的团队成员页面交互的细节，包括页面之间的逻辑跳转、页面内模块的交互、页面功能的状态等。交互描述文档越详细，越有利于产品开发相关各方的正确执行。

二、交互文档待完善

我整理了一些可以在日常工作中改进的交互文档，看看存在哪些问题。

1. 文本密集且非结构化

几乎所有刚进入职场的设计师，在写交互文档的时候，都怕自己写的不够，别人会觉得不专业。几乎无法阅读，没有视觉立足点。

2. 描述简单不完整

有几年工作经验的设计师，因为很多通用的交互规则已经很好理解了，写交互描述文档的时候比较简单，有些交互没有写在文档中，导致开发过程中，忽略了某些方面。一些互动。

3. 数据太假了，没有逻辑

交互草稿数据没有逻辑，是很多设计师的通病。部分原因可能是产品经理在提交设计师图纸之前没有理顺产品逻辑和细节。所有数据在逻辑上都是合理的。

以往存在关联值无法关联、表单中各字段对应的值不匹配、表单填写的数据与实际不符等情况。

建议您在时间允许或条件允许产品经理协助改进数据的情况下，尽量将数据呈现得真实、合乎逻辑，这样有助于开发者和相关读者高效理解。

4.图文太远找不到

有几次我注意到设计师提交的交互描述会标有“见图X”之类的文字。也就是看了一个描述后，还得跑到页面的某个角落才能找到对应的图片，这是一种很糟糕的体验。

交互设计的原则之一是“待在家里”。“宅在家里”是指在当前页面可以解决的事情，不要去其他页面；可以在附近做的事情，不要离得太远。频繁的切换和跳转会导致用户的流程中断，很容易导致用户思维中断、思维不佳，甚至可能对产品产生反感。

同样的，我们的交互描述文档中的图文也应该尽量相邻，让用户看一眼就可以流畅、舒适、快速的看懂文字和图片。

5. 东、西零散

东句和西句是指交互描述文档中应整体描述的文本。分几个部分来解释。这对于阅读文档的人来说是一场灾难。规则被链接在一起。

我们在编写交互式文档时尽量避免上述常见问题。

三、什么是好的交互式文档

对于什么是好的交互式文档，我在网上搜索了很多。在这里，我将根据自己的经验与您分享什么是好的交互式文档。

首先，让我们澄清什么是好的。有了好的标准之后，我们再来谈谈如何做好。

1. 什么是好的

基于此，一个好的交互规范文档关系到设计方案能否最大程度的实现。而如果交互文档的文字较长，逻辑不清晰c语言 图形用户界面，不仅人阅读困难，还需要增加额外的时间与开发工程师沟通。一个好的交互文档，我认为至少需要具备以下7点：

清晰的价值考虑 全面且易于理解的结构 清晰的图形和文字 只有这一个修订记录 2.

为了让大家学习和实践，我用“表单验证”的互动案例来给大家讲解。

(1）显式值

它可以通过文档辅助项目成员更顺利地完成工作任务，可以帮助用户解决问题，并且可以实现产品目标，是一个很好的交互文档。文档对各方都很有价值，是良好交互式文档的起点。那么，要怎么写才能达到上面的效果呢？

一方面，这个文档的价值写得很清楚，包括这个交互设计的背景、需求的来源、需求清单、交互设计的理论基础，以及它能给用户带来的价值。另一方面，有必要向会员宣传这些内容，让会员觉得自己要做的工作是有价值的。

“表单验证”开始发挥作用：

(2）综合考虑

除了文档阅读对象等相关因素外，一般来说，交互需要考虑以下几个方面：

一个。整体交互流程

整体交互过程是指产品页面与页面之间的交互逻辑。

湾。页面模块交互说明

页面模块交互描述是指模块本身的交互描述，或者是同一页面中独立模块之间的交互逻辑，或者是不同页面模块之间的交互逻辑。比如点击导航树节点会刷新右侧表格的内容；点击banner跳转到对应的商品详情页面，定位到页面的1/2位置。

C。页面功能交互说明

页面功能交互描述是指对单个功能的各种情况的描述。比如在搜索框中输入文字，通过回车触发对应的页面跳转。

d。尽可能真实地显示数据

虽然是交互式描述，但我们尽量模拟真实数据，否则很容易让读者做出错误判断。不是每个人都会逐字阅读文档，因此，尽可能真实的数据将有助于读者更有效地理解。

e. 特殊情况补充说明

很多情况下，由于某些原因会出现极端交互，此时需要补充。

F。一般交互可以在一个地方完成

建议交互团队为产品建立通用交互描述库，类似情况直接调用即可。

事实上，我们在写交互描述的时候，并没有把它们划分得那么细，很多描述是混合表达的。

“表单验证”开始发挥作用：

(3）通俗易懂

易懂是指使文字、语言、图片等易于被受众理解和感知，从而最大限度地减少信息传递过程中的损失，这也关系到人的理解能力。

百度百科解释理解能力：

“理解能力是指一个人对事物甚至知识的理解的一种记忆能力。

理解分为三个层次：

当我们了解到人类的理解水平参差不齐时，我们应该尽量在工作中（或为人群）简化专业知识，增强沟通效果，最终达到完成团队的目标。结果。

交互式文档应该尝试使用人类语言而不是一堆技术术语。记得之前有个交互设计师在一次会议上解释他的交互计划时，提到了“提供邀请”的原则。由于参会者是开发工程师和产品经理，他们询问什么是“邀约”原则，并围绕这个问题进行了长时间的讨论。

可见，要表达通俗易懂。

(4）结构清晰

除了表达易于理解的交互式文档外，还需要有清晰的结构。

结构清晰的内容不仅让读者一目了然，理解成本低，而且让读者了解作者的意图。要做到清晰的文档结构，除了遵循一些规则外，不能脱离当前文档的实际情况。

“表单验证”发挥作用（将文本处理成段并提取关键字）：

(5）图文并茂

图文结合可以加深读者对文本的理解，同时防止读者想象文本的相应结果。由于人们对同一段文字的理解并不完全相同，因此建议设计师尽量安排与图对应的交互描述。

“表单验证”开始发挥作用（左边的图片，右边的文字）：

(6）这是唯一的一个

仅一份意味着向团队交付交互文档时不应超过一份。之前我们前端小伙伴拿到了两个交互文档，一个是纯原型交互文档，另一个是可视化草稿交互文档。两者描述的信息相似。

这个时候，建议将交互文档的信息合并，只提交一份完整的副本给前端小伙伴，让前端小伙伴集中精力了解一份。

(7）修订历史

建议在交互式描述文档中保留修订记录。一方面可以了解交互文档的变化历史，另一方面有利于回溯和查找信息。修改记录一般包括修改人、修改时间和修改内容。

四、总结

由于项目进度、业务复杂度等方面的差异，我们不可能每次都写出最好的交互文档，但我们可以想办法写出相对可读易懂的友好文档交互文档。我们常说做用户体验，交互描述文档是我们交互能力的一个方面。

除了完成交互描述文档之外，想要让开发伙伴真正理解交互描述，还需要亲自与开发进行沟通。不要以为我写的很详细，为什么他在实现上还有偏差。

其实正如开篇所说：同一岗位上不同人的认知理解、职业经历、个人喜好、气质等，也会导致不同的理解。尤其是对于我们一些非常创新、特殊的交互点，需要重点和开发指导。

而且，根据业务的发展，交互文档会不断迭代。我们要以多听、多想、多想、多接受的态度，不断优化我们的文档，努力写出友好的交互文档。.

#专栏作家#

知果公众号：知果日记，人人都是产品经理专栏作家。浙江工商大学品牌设计硕士，《B面思维——产品经理的自我修养》作者。在产品设计过程、产品设计原理、产品设计方法、产品设计规范等方面拥有丰富的经验。

本文由大家是产品经理原创发表，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议