本文是对产品和交互设计师初级合伙人学习经验的总结:如何让交互文档说话？

交互式文档的受众

交互文档是一个交互设计师或产品经理制作的最基本的协同文档，目标读者是在第一线与你共事的精英部队:UI、开发、测试、运营，或者其他产品经理/交互设计师。

交互式文档的状态

经常听到同行抱怨明明是产品经理，为什么交互设计文档要写的很详细？说他是交互设计师，但是每次开始需求(交互)评审，他都发展的很差。他们是不是故意找茬？

有些公司没有交互设计师，所以产品经理很大程度上承担了交互设计师的部分责任。因此，交互文档可能是产品需求的最终产品。

因此，交互式文档起着重要的作用。一个好的交互式文档的输出可以帮助你解决很多你认为在开发中经常“找茬”的问题。

有哪些好的交互文档标准？

什么是能高效交谈合作的互动文档？

好的交互文档可以让你捋清自己的设计思路，和开发相关人员对接时可避免无效沟通。好的设计文档可以让你一册在手，追根溯源。防止背锅，有理可依，有据可查。好的交互文档，易读易懂、非常实用，就像一本使用说明书，直观明了。我们进入正题：如何让交互文档开口说话？

交互式文档的内容结构

交互式文档内容结构

交互式文档框架

先说说除了(4)互动稿(详见第二部分)之外需要完成的内容，如P1和P2所示。然后我们会拿起一些比较难的结构性内容来解释:

(1)封面:版本号、涉及的设计师、时间。

(2)版本维护:这个文档在整个设计开发过程中非常重要。每次更改要求或修改设计稿时，都要打印一次版本号，并尽可能通知相关人员(电子邮件、微信、口头等)。).可以专门为维护和版本跟踪创建一个Excel文档。

内容信息:修改时间、原因、修改人(需求或简单界面)、修改内容等。试想一下，如果修改后没有通知到位，很有可能开发者会用没有迭代过的版本来开发，后果可想而知，这也是为什么总有“PM和开发干架”的原因之一。

(3)设计流程:包括需求记录、需求分析、研究与竞争产品、数据灵感记录、产品信息结构(当然根据自己的项目需求，选择不同的信息)

1)需求记录:

可以包括初始需求记录、评审后的会议记录、需求变更记录(或者保留相关邮件、聊天记录截图等)。).同样，时间、变更内容、人员、原因都要写清楚。

2)用户体验分析:

您可以使用用户体验图(如P3所示)-它显示了用户在使用产品和服务过程中每个阶段的体验，包括行为、感受(痛点和满意点)和想法。

值:

让产品设计者有更全面的视野，从体验地图中挖掘需求核心和痛点。 从用户痛点中，发掘是否有创新的项目 或者 是否具有产品战略上的机会点。当然啦，可以进行需求分析的方法还有很多，在这里就不一一赘述了，我也将会推出关于需求分析方法的文章。

3)产品功能结构图

以脑图的形式展示产品信息、功能、基本交互信息。(是我在我们公司做的一个产品的功能结构图。因为涉及商业秘密，有些信息已经被像素模糊了。请见谅！)

接下来，我们揭开互动选秀的神秘& # 8230；…

互动稿的目录是怎么生成的？

答:交互稿的目录结构是从产品功能结构图中派生出来的(如图)，所以你首先要完善你的产品功能结构图。

产品功能结构目录

交互式草稿应该包含哪些元素？

如图所示:

互动草稿的内容结构

页面标题：建议固定浏览器顶部。界面标题：方便交互稿互相索引。作者信息：方便他人联系设计师。跳转链接：可以通过点击界面上的某个功能，实现跳转。

交互解释的规范和原则

交互式解释规范和原则

交互式草稿

交互描述位置:不要统一在界面的底部或左侧或右侧。

对应清晰:界面描述的点要用1、2、3或者A、B、C角标一一对应交互描述的内容。

巧妙运用网格系统:可以使布局有序清晰:网格布局-网格和辅助线-网格设计，间距40px。

界面描述:页面逻辑描述、动态效果描述、动态数据的来源和去向解释、功能操作描述等。

如果交互式描述太长，请使用动态面板:

动态面板轴承界面描述

交互式文档可以代替PRD文档吗？

我不这么认为。交互文档是用来携带交互指令并交付给前端、测试和开发工程师参考的文档。

PRD文档是一个产品项目从“概念化”阶段到“可视化”阶段最重要的文档。其适用对象包括:开发、测试、项目经理、交互设计师、运营等业务人员。

根据PRD开发能了解整个产品的逻辑；测试可以根据PRD构建用例；项目经理可以根据PRD拆分工作包，分配开发人员；交互设计师可以通过PRD设计交互细节。