4.1 撰写交互文档用什么工具？输出什么格式？

您平时倾向于使用哪些软件来制作交互式文档？比如、Adobe 、Axure等等？

您通常偏好哪种格式来呈现您的交互式文档？是PPT、PDF还是HTML等？

我亦会自问，究竟何种工具与格式最为适宜？经过一番实践，我得出以下结论：

若是大项目或复杂的大需求，推荐Axure输出HTML格式。

Axure配备了站点地图功能，能够直观地呈现层级结构，便于实现场景间的顺畅切换。此外，它还支持通过分享链接进行实时更新，极大地提升了团队协作的便捷性。

若是小需求，推荐输出PDF格式。

绘制原型速度快，生成的PDF文件既美观又全面，内容不易遗漏，不受设备与网络条件的限制，阅读起来十分便捷。然而，由于缺乏站点地图，对于大型项目或高需求的情况，阅读体验并不理想。

若是方案概述，推荐PPT输出PPT格式。

该演示文稿易于上手，操作便捷，呈现效果正式且优雅，不受硬件和网络条件的约束。然而，单页PPT所能容纳的界面数量有限，并且缺少站点导航图。

4.2 交互文档应包括哪些内容？

根据企业或项目的具体状况sketch和axure区别，DRD可灵活确定文档的具体内容、构成要素以及表现形式。我所编制的这份文档结构模板具有一定的通用性，它包括文档封面、更新记录、图例说明、设计理念与思路、业务流程概览、页面交互设计、特殊说明以及废弃内容收集区等若干部分。

DRD封面

该图片不商用，若涉及侵权请联系本人

DRD封面内容涵盖文档的标题，即项目或产品的名称，以及版本号、发布日期、作者等关键信息。根据需要，还可以添加参与项目的各个部门或团队的负责人名单，例如产品经理、交互设计师、视觉设计师、开发人员、测试人员以及团队名称等。

更新日志

项目更新记录中详细列出了新增或调整的具体内容，以及负责修改的人员和日期。在日常工作流程中，对方案的调整与完善是常见现象。这份记录有助于团队成员迅速识别关键更新点，同时便于开发者联系相应责任人进行交流，从而提高工作效率。

其他细节经验分享：

文档的更新时间按照最新的顺序排列在最上方，并且建议用不同颜色标注，以便于快速查找；这样做可以避免因日志记录过长而花费过多时间寻找所需信息。

点击最新修订的页面即可直接链接至目标页面，便于迅速定位所需文档。

文档图例

为了便于读者理解，需对该文档中引用的图例进行详细阐释，以辅助阅读。特别是对于那些初次接触您DRD模型的读者，这样的说明将有助于他们更好地把握文档内容，尤其是那些非标准化的符号标识。

设计背景/思路

项目涉及背景资料、需求剖析、用户研究、竞争对手分析等内容。这些内容旨在梳理设计理念并予以记录，便于阅读，有助于评审会参与者把握项目整体设计思路，同时便于未来回顾与归纳设计成果。然而，并非需将所有分析内容悉数纳入，只需结构化地整理关键信息即可。

需求分析需涵盖业务及功能方面的具体要求，同时也要包括用户的需求，并对这些需求进行深入的分析与总结。以下是一个简单的示例，仅作参考：

业务流程图

主要是针对整个业务流程的图表。在日常工作里，通常由产品经理负责绘制，随后经过交互设计师的沟通与整理后上传（本次内容将不进行详细讲解）。此外，这个流程图还可以根据不同项目的需求进行位置的调整，比如跟随页面交互的模块或流程进行编排。

页面交互

页面交互构成了DRD的核心内容，涵盖了信息架构、任务流程图、界面交互图以及交互说明等多个方面。在构建页面交互结构时，需依据产品信息架构进行设计。功能层级需明确，命名规范，格式一致，更新内容需有统一标识，以便他人能够便捷地浏览和查找。

信息架构构成了产品的核心框架，其性质较为固定。通常情况下，当需要对信息架构进行调整时，往往意味着将推出全新产品、新增功能或进行产品的大规模升级。借助信息架构图，我们能够在项目初期对产品结构进行系统梳理，并在后续迭代过程中遵循这一宏观架构，同时使得信息的理解和浏览变得更加便捷。

在构建信息架构的过程中，必须依据产品的特性来选定架构的样式，同时要确立功能的优先顺序。这包括对功能的重要性、商业效益以及使用频次等因素进行评估，并据此进行排列。此外，还需提炼出关键功能。同时，还需兼顾架构的扩展性，以便于后续的更新和优化。

任务流程图是对产品逻辑关系的步骤和过程进行图形化展示，具体包括用户在操作产品后所获得的各种结果和反馈。

你必须充分掌握需求，从用户立场出发进行思考和指导，以帮助用户达成目标。留意用户操作不仅有助于你思路的清晰，还能确保操作流程的完整性。同时，这也有利于他人迅速把握要点。

其他细节经验分享：

单独分步骤进行编写，将整个流程集中在一个大流程中并不便于查阅，同时也可能导致遗漏某些环节或出现错误。

流程图的“开始”和“结束”避免半天找不着；

流程主次分明，顺畅地浏览住流程，也能全面看到各流程；

在绘制流程图时，应尽量使图形简化，力求流程线直截了当，避免曲折迂回，若多个流程指向相同的结果，则可考虑将它们合并。

3. 每页交互文档的内容：

文档每一页的上方通常会有一个标题，它标示了当前页面所涉及的具体模块或流程，这样有助于阅读者迅速定位信息，避免在阅读过程中感到困惑。

在命名时需留意，确保名称便于在交互稿件中实现相互引用，例如在提及“跳转至【XX页面】”或“返回至【XX界面】”的状态时。

建议界面尺寸依照实际比例适当减小，以免你的设计主观臆断，与规范不符，同时也能防止界面过大而降低阅读体验。

设计说明需涵盖逻辑关联、操作步骤及反馈信息、元素所处状态、字符数量限制、异常或特殊状况等内容。

流程线：说明界面间逻辑关系；

通过跳转链接，用户可以轻松访问其他页面，比如子流程，这样开发伙伴阅读资料将更加便捷。

特别说明

涉及某些需特别指明的事项，比如普遍适用的指导性说明、默认页面概览、动画效果描述、音效细节等，这些内容需根据具体项目需求来决定。这些内容不仅有助于确保设计的一致性和产品的标准化，同时在文档中无需对每个细节进行重复阐述；此外，它们也有利于视觉设计师和开发团队全面了解项目。此类信息通常会被纳入“页面交互”这一章节中。

废纸篓

废纸篓，实质上便是DRD的“补救良方”。在方案屡次修订与完善的进程中，那些原本看似无用的草稿，都被一一存放在此处，以防未来可能派上用场。（改动多次，其中的门道，你定能心领神会。）

其他细节经验分享：

在“废纸篓”之后，建议添加“请忽略此部分/仅供UE查阅”的说明。若不然，极有可能会有困惑不解的人前来询问，究竟这个页面与之前的哪个版本才是最新的……

4.5 其他小经验分享

1. 别为了写文档而写文档，要为了解决问题。

DRD主要功能是存放设计方案、交互原型及说明等资料，并负责归档及向相关人员提供参考。鉴于此，撰写文档时不应仅为了完成写作任务，而应着重于解决实际问题。

2. DRD要做到逻辑严谨，文本简明

DRD的内容布局和页面交互设计应思路明确，逻辑性强，与产品架构的层级结构相吻合。文档撰写需遵循逻辑原则，表述简洁，以便更有效地将交互设计的理念和方案进行直观和简化的呈现。

3. 美即适用，注意文档的体验

DRD也要考虑美？答案是肯定的。

DRD并非仅供专业人士使用，同样需要关注用户感受。此外，个人在其他领域（比如逻辑思考、产品创新等）的才能是否足够卓越，以至于可以弥补在表现层面的不足？如果确实如此，那么你无需过分纠结于形式。然而，DRD对于“美”的理解与视觉上的美感有所区别，它应当是既美观又清晰，易于使用，并遵循用户体验的基本原则。实际上，它更倾向于一种基于逻辑的审美，一种以用户体验为核心的审美。

在制定方案的过程中，首先要对常规情况进行充分考量并完成相关内容，然后才能着手绘制所有可能出现的异常页面或相关内容。

从全局着手进行，若中途领导或需求方希望审视方案，便能迅速获得一个阶段性完备的成果；再者，若大流程与页面设计尚未明确，那么过度细化又有何意义呢？

5. 一页交互文档一个任务/流程。

单页所能承载的信息量是有限的，若信息量过大，便可能引发问题；同时，这也便于构建通用的任务或流程。

6. 同一界面/页面的不同状态最好在同一页交互文档展示。

以免造成修改或阅读混乱。

7. 交互原型尽量使用黑白灰。

确保原型图不会对视觉设计师造成干扰，以免妨碍其创意发挥。此外，若颜色与视觉稿有所出入，测试人员将询问应采用哪种方案。

8. 对齐让文档可读性更好。

确保界面与设计说明的一致性，以及界面与界面之间的协调，能够显著提升文档的可读性。

五、总结

交互文档至关重要，然而其本质并非仅仅追求外在的视觉美感，对于交互设计师而言sketch和axure区别，关键在于设计过程中需全方位进行深入思考。

本文虽未对需求分析与设计理念进行深入探讨，然而，这一点确实至关重要，真的，真的，真的非常重要！

深入探究业务需求，反复思索其背后的原因，不断探寻最本质的问题，提炼出关键的业务需求，挖掘出用户最深层次、最真实的需要……

针对这些需求与挑战，我们应如何寻找对策？何种策略最为出色？是否还有更佳的方案存在？设计师若能在全面思考之后，进行权衡与选择，便能够显著提升产品的用户体验。如此一来，自然也能确保DRD的质量，避免逻辑上的瑕疵。

如此一来，你的方案进展如何，只需查看DRD便一目了然；至于你的DRD质量如何，同样也是一目了然。

如有侵权请联系删除！