撰写交互文档的全流程指南,绕过产品设计的那些坑

笔者从概念出发,分享了编写交互文档的全过程指南,经验分享带你走遍产品设计的坑。

最近停了一段时间,一直在想交互式文档。其实几个月前我就整理了一部分,自己关闭之后,就去规范平台了。好了,废话不多说,开始谈正事。

在制作交互式文档之前,我们首先要了解什么是交互式文档,为什么要做,谁应该看。

什么是交互式文档

交互文档,即交互设计文档。英文Design Requirement Document,简称DRD。主要用于承载设计思路、设计方案、信息架构、原型线框图、交互描述等。

为什么需要交互式文档

有些人可能会对文件之类的东西感到厌恶,尤其是很久没有工作的朋友。事实上,你工作的时间越长,你就越会意识到文档的重要性。它可以帮助你理清你的想法并记录下来以便于回顾。在工作方面,有一个标准化的文档可以让你的设计更有说服力,更容易使用,提高他们之间的沟通效率。

谁是交互式文档?

其实交互文档应该由谁来阅读,其实具体情况详细分析。一些公司老板还需要密切关注互动文件,还有甲方的父亲和运营部的同事,都可以查看。

但无论如何,有 4 类人必须是交互式文档的忠实“读者”:

产品经理:产品经理和交互设计师可能是沟通最多的人。产品经理主要是确认文档中的设计思路和业务流程,然后通过页面交互模块。视觉设计:UI设计师通常最关注页面交互模块。有产品思维和体验思维的设计师,也会对设计思路和产品背景进行更深入的了解,从而更好地了解产品的商业逻辑和用户心理。开发者:前端开发同事,如UI设计师,最关注页面交互模块,其他改进有助于理解。后端开发人员更关注业务逻辑、信息架构和操作流程。只有清楚了这些,才能输出准确、合格的开发文件。测试人员:因为测试人员是检查产品发布的一群人,所有模块和步骤都应该彻底了解,以便提出有效的错误。如何编写交互式文档

本文主要介绍Axure软件作为编写工具。您可以根据自己的实际需要决定使用什么软件(Sketch、PPT、Word、PS、AI等)。

例如,您可以将 Sketch 用于小需求,快速高效。如果是甲方的父亲/大老板,使用PPT会帮助他们更好的理解。

通常,一个比较基础和标准化的交互文档(DRD)由文档封面、更新日志、文档图例、设计背景​​/想法、业务流程、页面交互、全局概述、废纸篓八个部分组成。当然,这也不是绝对的,可以根据自己的实际工作需要增减。

比如如果是C端产品,用户调研的结论、用户画像、用户体验图等都可以放进去参考。尤其是在当今如此关注用户体验和产品思维的环境下,这些数据支撑是非常强大的。同时也可以帮助开发者和界面设计师培养产品思维和体验思维,共同把产品做得更好。

其次,还需要保持交互文档的整洁美观。相信在过去的几年里,很多人都遇到过这样的产品经理(和交互),他们会输出一些自己有时不了解的线框图,或者直接从其他竞品中输出。当开发人员和界面设计师质疑时,他们说线框并不重要,重要的是里面的业务逻辑。实际上,在产品思维中,交互文档是交互设计师的产品,看到的人是用户。保持良好的可读性非常重要。

1. 文档封面

交互文档的封面如上图所示,通常包括产品名称、标识、版本号、版本发布时间、所属部门、连接/连接负责人。

2. 变更日志

我们都知道,在产品迭代的过程中,需求/功能会不断的调整。更新日志用于迭代。一般由修改日期、修改内容、修改人、版本号和备注组成。

如果是新的功能或模块,建议添加链接直接跳转到新的内容,如上图。

版本号是一样的,要加上对应的版本链接,让观看者可以回到之前的内容,与当前的新版本进行对比。

这对于开发者来说非常重要,其次对于新同事对产品的深入了解也有很大的帮助。

修改日期通常按时间倒序排列,更方便查看。

3. 文档图例

文档图例,顾名思义,就是对这个文档的一些辅助说明,目的是为了让读者更好的理解文档。如上图:操作/跳转图例、标签图例、流程图示例、手势操作图例。

4. 设计背景/想法

设计背景,并根据实际工作需要放置一些关于思想和灵感来源的安排的文件。比如利用调研报告、用户画像、竞品分析报告、商业画布等,增强文档的说服力,让大家了解产品的战略目标和商业逻辑。

图为本人今年对接最长的是一个B端产品项目,所以整理了一个产品画像,仅供参考。

5. 业务流程

业务流程图,不是操作流程图或页面流程图。它是产品的整体业务流程c语言编写通讯录程序,与业务直接挂钩,可以说是产品的核心流程。

比如淘宝APP,买家的购物流程从头到尾就是它的业务流程。它通常以泳道图的形式展示,并且在大多数情况下是由产品经理绘制的。

以上是我负责的产品的核心业务流程图。由于是B端产品,涉及角色较多,因此单独画出三个有代表性的角色,仅供参考(涉及保密协议,所有关键词均已去掉)。

6. 页面交互

1)信息架构

信息架构属于用户体验的结构层,是产品的骨架。一般由产品经理或更高级别的经理给出。除非它是一个大的产品迭代,否则它不会发生巨大变化。

2)权限说明

如果是C端产品,权限部分比较简单,容易整理。B端产品涉及角色较多,可能需要单独分析梳理。以上仅供参考,具体情况你会详细分析。如果功能很单一,这个模块也可以从交互文档中省略。

3)操作流程图

产品操作流程图是通过图形化的表达,在功能层面描述产品的逻辑和信息。它可以更加清晰直观地展示用户在使用某个功能时会产生的一系列操作和反馈的图标。

注意:不要将所有流程汇总在一张表中或在同一页面上显示,而是将它们与特定的操作或功能模块一起放置。时刻想着看文档的人的感受,多么容易明白怎么来。

上图为登录、注册、找回密码的操作流程图,仅供参考。

4)页面线框

页面线框是一种图形表达方式,用于在页面级别说明产品的信息。包括:

以上为注册页面线框图,仅供参考。

以上是登录的线框图和详细的交互说明。用红色突出显示重要内容可以使查看者更容易一目了然地理解文档。

7. 全局通用指令

全局通用描述是指可以在整个产品中通用或重用的元素。一般是在做文档的时候整理一下,方便自己或者接手项目的设计师直接调用。其次,对开发可重用控件的及时封装也有参考价值。

1)常用控件

常用控件类似于 UIKit,通常将重用价值高的控件组织在一起,方便及时调用。

2)复用接口

顾名思义,就是一些内页可以全局复用,比如选择联系人、独立搜索页面等。

3)时间规范

在制作产品的第一步,您应该就时间规范达成一致。否则,如果每个终端都开发了,你会发现iOS是斜杠的,Android是单杠的,WEB是点点滴滴……如果你一发现就改,真的会互相崩溃。

4)默认页面摘要

默认页面一般包括加载失败、加载中、网络中断、没有数据的空白页面。空页面可以按照模块进行分组,方便UI设计师在最后将默认页面设计在一起c语言编写通讯录程序,保持风格统一。

8. 垃圾

废纸篓被誉为交互式文档的“后悔药”。在需求不断变化的情况下,请在修改过程中将您的修改稿放在这里!!!因为很有可能最后会使用第一种解决方案(此刻有点绝望)……

总结

文档和软件只是工具,最重要的是必须实施和实施才能帮助产品。所以在写文档的每一刻,都应该站在“读者”的角度去思考。他们读了会有什么感觉,会觉得很难理解吗?

此外,您还需要耐心,耐心地向他们解释他们不明白的地方。

用朋友的话总结:好的设计是被滥用的(其实哪个行业不是..‍♀️重要的是:心态和心态~)。

本文旨在提供参考,而非绝对规范。

本文由@WANSUOriginal 发表于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论