1.如何写一份交互说明文档

交互说明文档，是交互设计师 的输出物中必不可少的一项，它关系着设计方案能否最大程度的被实现。

交互新人，大多会烦恼如何写交互文档，今天来聊聊这个话题。 交互文档，写给谁看 交互文档可以看做交互设计师 输出的”产品”，它面向的”用户”是下游的同事——视觉设计师、测试工程师、开发工程师。

他们会根据文档中的线框图、交互细节说明等等，来输出视觉设计稿、写测试用例、用代码实现产品设计方案，并以此为依据完成验收测试等工作。 交互文档，写什么内容 最初写交互文档时，很多人会有疑惑该写些什么内容。

我的看法是，开发同事在写代码时需要考虑的与界面显示逻辑、用户操作相关的内容，几乎都要在交互文档中体现，建议越全面越好。 如果有遗漏的内容，开发可能会找你讨论，也可能懒得费时间沟通直接按照自己的理解去实现。

最终，验收测试的效果不如意，你也不能全赖开发。所以尽量将交互文档写的全面些，别消费开发同事对你的信赖值。

那么，到底交互文档中，需要写哪些内容呢？ 1、页面流程（界面之间） 页面流程图，可以表达产品的整体结构，帮助同事了解界面之间的关系。在撰写交互文档时，也可以以任务、子任务为模块来详细介绍界面如何跳转、何时跳转。

2、内容布局（界面内） 正在加载状态、加载完成有内容的状态、加载完成无内容的空状态、失败状态（比如网络异常/权限未开启）、不同角色的用户看到的内容是否一样、不同状态的文案图标变化 内容的加载方式，何时加载、何时显示、何时刷新 其他 … 3、交互操作与反馈（界面内） 根据用户与界面之间发生的交互操作，提供相应的反馈，可能是提示内容，也可能是界面内或界面之间的跳转。 刚入门的交互新人，喜欢把重心放在界面之间的跳转，而遗漏了界面内的内容布局和交互操作。

对此，我的小技巧是，先整体看界面全局，再review界面上的每一个元素，思考各种不同场景下这些元素是否变化、如何变化。 以登录界面为例，看看怎么写交互细节说明 下图，是一个简单的登录界面，我们试着先整体后部分的方式，看看这个界面的交互说明需要考虑哪些方面。

1、登录界面的跳转流程 什么情况下，从哪些界面可以进入登录界面 登录成功后进入哪个界面 取消登录后回到哪里 界面转场方式，比如从下向上进入界面，从上往下离开界面 2、账号输入框 字段格式要求，字段长度、字段类别（汉子、字母、数字、手机号） 是否有默认提示文案，如果上次登录过是否显示上次的账号 光标是否置入此输入框，键盘是否显示，键盘用哪种视图 何时检测用户填写的是否正确，填写正确的提示，填写错误的提示，反馈提示何时显示、何时消失 输入框中的内容是否支持一键清除 3、密码输入框 字段格式要求 何时检测格式是否符合 光标置入后显示键盘的哪种视图 输入框中的内容是否支持一键清除 是否支持密码可见、如何切换可见状态 4、登录按钮 按钮是否有可用不可用之分，何时可用状态、何时不可用状态 点击按钮之后提示正在登录的方式 登录成功如何提示、跳转进入哪个界面 有哪几种登录失败的场景（比如账号未注册、网络异常等），不同失败的情况下如何提示 多次登录失败提示方式是否变化 5、注册按钮 点击进入哪个界面 界面的转场方式是怎样的 6、关闭按钮 点击进入哪个界面 界面的转场方式是怎样的 以上只是抛砖引玉，给大家打开思路。虽然只是几个输入框，但其细节比大多数界面都要复杂。

你可以找一款优秀的APP，去研究它如何设计这些细节，是否还有我没有提到的点，研究透了下次自己设计才能做到更加全面。 当然，交互细节说明，只是方案的表述，每一个小点都有好几种设计方案。

如何权衡选择体验更优的方案，才最是考验交互设计 师的能力。你可以对比研究几款优秀产品，看它们在细节设计有何不同，分析其中的缘由，想想是否有更好的方案，学无止尽。

如何提升交互文档的浏览体验 交互设计 师的目标是提升产品的体验，我们输出的文档本身也应该有上佳的浏览体验。为了达到这个目标，我也在不断优化文档的撰写方式和排版。

下面聊聊我尝试过的几种方式。 方式1：一页纸表示所有的线框图，配上箭头+简单的文字说明 网上流传着很多这种风格的图，最初觉得这样的图很有范儿，以为这就是他们输出的全部交互文档，所以按照这种模式产出。

等到自己做的多了会发现这类图大多只表达了某个界面的正常状态，并没有详细的交互说明来体现界面的内容布局和交互操作反馈。 方式2：一页一个界面，每个界面建一个交互说明文件夹，分功能模块写交互说明（Web产品） 工具： Axure Web产品的特点是，层级复杂，每个界面比较大而且内容很丰富。

通常会组织好页面层级，再画每个界面的原型，待几轮讨论过后界面布局和内容基本确定之后，再为每个界面撰写各自的交互说明。 考虑到每个界面中的内容模块和功能点不少，我没有在确定好的界面上直接标注交互说明，而是将这个界面划分为几个功能模块，并给每个功能模块新建一个页面用来写交互说明。

如下图，分别是 Axure的文档目录（左）、某个功能模块的交互说明（右） 方式3：一页显示。

2.一个网站的交互文档该怎么进行撰写

1.首先做到有效的沟通：

和UI沟通页面用的什么栅格，文字大小、颜色，通用的样式等

和产品经理沟通产品的流程，用户操作流程，业务需求等

前端和开发一起沟通一些具体的交互动作哪些属于服务器异步，哪些属于刷新页面等

这样会减少一些BUG和开发时间

2.原型图：

主要的功能做完后可以先给开发看一下，这样他们能提前进入一些功能的开发

我个人在用axure做原型的时候，第一页：修改记录，第二页：会把一些通用的东西提出来放进去统一说明，第三页：功能点复杂的就配上页面流程图，下边就是具体的页面原型，简单的动作顺手就做了，复杂的就分开表示，写上详细的说明，如涉及到表单验证会单独的写一份表单验证说明。

可能说的比较乱，凑合看吧，欢迎讨论

3.如何写一份易懂的交互文档

1. 首先界面本身的问题：导航关系不明确，缺少必要的导航和标题。

不仅工程师不知道界面之间的关系，恐怕用户看到这个页面也要困惑。2. 交互逻辑缺失：点击注册之后，信息一定能成功提交么？如果有信息缺失，或者格式不符合要求，怎么处理？密码不一致怎么办？如果这个手机号已经被注册了怎么处理？出错信息是实时反馈，还是点击“注册”按钮后反馈？如何显示？验证码超时之后会怎样？这些全没有体现出来。

3. 交互细节缺失：用户的真实使用场景中，会有“弹出键盘（数字键盘还是字母键盘？）”、“切换到下一个输入框”、“收起键盘”、“查收短信验证码”等很多操作流程，这些在交互稿里都没有体现。4. 文档组织欠缺考虑：a. 流程图缺乏良好组织。

举例来说，三个箭头分别是：向右、向下、向左。从逻辑上实际都是向前推进的。

如果一个流程从左边开始，右边结束，那么这三个界面的关系应该是从左向右依次排列，才更符合逻辑。b. 不同页面，以及相同页面的不同状态，应该标注下页面标题，方便引用以及讨论。

总的来说，设计师需要从文档读者的角度去组织文档，这也是设计考验的一部分呢。一个完备的交互文档，应该是流程和细节说明结合的，题主给出的下图，可以结合逻辑清晰的流程图，就能避免你担心的不能很好“表现流程”的问题。

对于移动端产品，详细说明和流程图可以很方便的放在一张大画布里。如果是桌面端产品，有时候我会先提供一个概览性质的逻辑流程图，上面标注页面编号，然后再在单页里给出每个页面的详细说明。

4.如何写详细设计文档

在大多数软件项目中，要末不作详细设计，要么开发完成后再补详细设计文档，质量也不容乐观，文档与系统往往不能同步，使详细设计文档完全流于形式，对工作没有起到实际的帮助。

·

详细设计是相对概要设计而言的，是瀑布开发流程的一个重要环节，在概要设计的高层设计的基础上，从逻辑上实现了每一模块的功能，是编码阶段的主要参考资料，是从高层到低层、逐步精化思想的具体实现。

详细设计文档的内容包括各个模块的算法设计，

接口设计，

数据结构设计，交互设计等。必须写清楚各个模块/接口/公共对象的定义，列明各个模块程序的

各种执行条件与期望的运行效果，还要正确处理各种可能的异常。

·

在开发过程中，由需求及设计不正确、不完整所导致的问题是项目进度拖延、失败的一个主要因素，而软件系统的一个重要特性就是需求和设计的不断构建和改进，在写详细设计文档过程中，

详细设计实际上是对系统的一次逻辑构建，可以有效验证需求的完整性及正确性。

如果不写详细设计文档，一般就从概设直接进入编码阶段，这时开发人员所能参考的资料就是需求规格说明书及页面原型、数据库设计等，不能直接进行开发，需要进行信息的沟通，把页面原型不能体现的设计讲清楚，这样既容易遗忘，也容易发生问题，详细设计文档可以作为需求人员、总体设计人员与开发人员的沟通工具，把静态页面无法体现的设计体现出来，包含整体设计对模块设计的规范，体现对设计上的一些决策，例如选用的算法，对一些关键问题的设计考虑等等，使开发人员能快速进入开发，提高沟通效率，减少沟通问题。

对于系统功能的调整，后期的维护，详设文档提供了模块设计上的考虑、决策，包括模块与整体设计的关系、模块所引用的数据库设计、重要操作的处理流程、重要的业务规则实现设计等等信息，提供了对模块设计的概述性信息，阐明了模块设计上的决策，配合代码注释，可以相对轻松读懂原有设计。

·存在的问题要由专门的人写，是比较麻烦的，也是很需要时间的，会对进度造成压力，也容易形成工作瓶颈，使设计人员负担过重，而开发人员无事可作。对于现在一般的以数据库为中心的管理系统而言，这个工作始终是要作的，区别只不过是不是形成专门文档，形成文档可能会多花一两周时间，但相对于规避的风险和问题来说，也是值得的，另外由于现在高级语言的流行，所以更详细的设计应该直接体现在代码的设计上，而文档则只体现设计上的一些决策，协调整体设计与模块设计的关系，把页面原型所不能体现的设计情况文档化，所以所花费的时间是有限的。

设计内容容易过细，但设计阶段是不能考虑特别清楚地，时间也不允许。

对于这个问题，一个对策是上边所提到的，文档只体现设计上的决策，页面原型所不能反映的信息，详细设计只体现总体设计对模块设计的一些考虑，例如对功能的数据库设计等等，而具体的实现实现，则到代码中再去实现，相关的设计也仅体现在代码中。

需求、设计需要不断的被更新、构建，则设计文档需要不断的重新调整，文档的维护需要跟上，否则文档和系统的同步就很难得到保障了，且造成多余的工作量。文档的内容易流于形势，质量糟糕，不能成为开发人员的参考手册，一是要建立起相关制度，如有修改，先改文档，后作开发，从工作流程上切实保障文档与系统的同步，二是要规范文档质量，对文档该写什么，不该写什么，标准是什么，粒度是什么，语法应该如何组织，有明确的标准和考虑，同时，建立审计文档评审、审核制度，充分保障系统的使用。·

首先是文档的内容，根据项目和团队的不同，详细设计文档的内容也有所不同，一般说来，粒度不宜过细，不能代替开发人员的设计和思考，但要把有关设计的决策考虑进去，包括与其他模块、整体设计的关系、操作的处理流程，对业务规则的设计考虑等，有一个标准为，凡是页面原型、需求规格说明书所不能反映的设计决策，而开发人员又需要了解的，都要写入文档。

其次是文档所面向的读者，主要为模块开发人员、后期维护人员，模块开发人员通过详细设计文档和页面原型来了解所开发的功能，后期维护人员通过实际系统、模块代码、详细设计文档来了解一个功能。

再有就是谁来写文档，因为文档主要考虑的是设计上的决策，所以写文档的人应该为负责、参加设计的技术经理、资深程序员，根据团队情况和项目规模、复杂度的不同，也有所不同。

还需要保证文档的可读性、准确性、一致性，要建立严格的文档模板及标准，保证文档的可读性及准确性，同时建立审核及设计评审制度，来保障设计及文档的质量，另外在工作流程中要强调，要先设计、先写文档，再进行开发。

5.交互设计师如何做交互

尽管很多谈及交互的书上都已经回答过了：发现用户需要，建立明确需求提出设计方案制作设计原型用户测试和评估还是有很多对交互设计有兴趣的朋友会问我这个问题，并希望我能回答得详细，具体到我工作中的每个细节。

其实交互设计需要做什么，会随每个交互设计师的工作内容差异而不同，具体到每个项目也会有区别。下面分享下我是怎样做交互，方式不一定是最合适，希望大家多指点，共同学习进步。

发现用户需要的方式有很多种，我们可以在用户反馈里收集到许多用户提出的想法，他们希望我们能提供帮助解决问题的产品；我们也可以主动去观察一些生活中的信息，为灵感的迸发做储备。比如说日程管理项目，有不少用户跟我们的邮箱反应说，他们忙碌的时候会忘记一些重要的事情，比如一些会议或者约会，所以希望网易邮箱能提供一个专业的日程管理功能，能够帮助他们有效的管理和安排每天的日程。

确认了用户的这一需要，我们的产品同事就会组织立项，把用研和设计组的同事呼唤过来一起进行调研，确定我们的目标用户。用研组会通过问卷调查等方式尽可能多的去收集信息，交互设计师也会参与分析调研，组织会议帮助用研组完善信息，我们会采取一些有趣的方式，比如一堆人在一起头脑风暴，大家回忆各种相关的生活场景，然后把一些关键词记录下来。

这一步我们的目的是要知道：用户想要什么？通过这些步骤我们提炼出一些最重要的功能需求，接着产品组会整理出需求文档，设计师就位。通过调研，我们得到了大量数据信息，并建立了明确的需求，下一步就是开始提设计方案。

这个阶段我会做一些概念设计，类似于做实物产品时设计一个水杯，我会描述它说：我要设计一个旅行用的水杯，它能叠成一个小圆盘，喝水的时候只需要把小圆盘的圆心部分往下按，就能变成一个杯子。互联网产品也是这样，需要赋予它一个概念，例如日程管理：这是一个专业的日程管理功能，通过使用它，我们可以有效的管理自己每天的日程和时间，以提高工作效率，并且不会再错过每个重要的约会！这些文字并不一定非是交互设计师所总结，但是交互设计师必须要做到对产品心里有数，明确我们要做什么。

同时需要进行的还有初稿设计，在这里我所谓的初稿，并不一定是严格要求中的交互原型，可以是用Axure把主要的页面流程做出来，也可以手绘草图，只要能清晰表达设计构思的，什么样的方式都可以。制作设计原型，也就是常说的交互稿，区别于做设计方案时的初稿，这份交互稿我会尽可能细致的把流程和具体操作形式表达出来。

考虑到做交互是一个迭代过程，我会在设计稿的首页为设计的产品做一份交互更新日志，记录下交互更新时间、版本名称、更新类型、更新内容、参考需求文档与交互负责人。这份更新日志的意义在于：更新时间-便于全程跟踪记录项目，掌握每个时间点版本名称-便于项目参与人员查找上一版本的交互稿更新类型-了解每次更新需求的性质更新内容-清晰呈现每一次更新的内容，并提供一个直接去到更新页面的链接，这样在进行迭代时我们的伙伴不用一页页去寻找更新点参考需求文档-便于项目参与人员查找对应的需求文档交互负责人-记录每次迭代的交互负责人，并能方便工作交接交互稿的制作过程，一般是用Axure做原型，像邮箱这样视觉比较成熟且相对稳定的产品，我会偏向做高保真模型，我们会整理一个控件库，这样能提高制作效率；做一个全新项目时，黑白稿线稿都是可用的方式，如果交互设计师能对大概的视觉效果有把握，也能做得精致些。

这些我想大家都很了解，所以不多说了。之所以把这部分内容提出来单独写一段，是因为之前和很多做交互的朋友讨论过该怎样做好交互说明，大家各有看法，很难找到这部分工作的衡量标准。

交互说明书在整个设计过程中，也许只会占用小部分工作量，但是作用不小，它能帮助我们减少沟通成本，辅助交互稿描述设计理念，表达交互流程，更细致的展现我们的设计。与做设计稿不同，个人认为，交互说明这部分工作，需要我们更多了解它作说明的对象，即产品经理、视觉设计师、开发人员的需求，从而达到真正的“辅助”效果，而不是盲目凭自己主观去长篇大论，否则我们要为此花费时间，而且这部分工作只能沉积为一堆我们自己欣赏毫无意义的文字。

为此我曾与合作过的各组同事进行沟通，提炼出一些他们对交互说明的需求，不求全面，但求能说明一些问题。1.交互说明最好是图文并茂（all）便于阅读和理解。

2.页面跳转的说明（产品&程序）页面跳转是涉及多个页面关系的操作，产品人员在看交互稿时，会更多去关注多个目的性的任务操作流程，而对页面跳转的记忆是有限的，所以需要页面跳转说明。3.交互说明能否考虑与产品需求文档结合（产品）开发文档会涉及产品概念、技术方案、业务执行角色等内容，和交互设计稿有着紧密关联，所以交互说明书与开发文档是可以相互做补充，整理成一份文档，这样也能避免工作内容重复。

4.对交互稿中不明显的交互动作或隐藏的设置项作说明（产品&视觉&页面构架）细节和动作需要描述清楚，比如说鼠标focus、click的动作，或。