交互设计文档的元问题

有关于交互文档撰写和输出的话题，已有无数文章进行讨论。本文主要集中与交互文档以及文档规范设计的一些少见的关注点和一些交互文档规范设计的经验教训。

#受众

前公司曾经有一套相对复杂的交互文档设计规范——这套文档规定了设计师需要在visio上进行流程图绘制且在axure上进行原型绘制和输出。其中，visio内的流程图以及相关注解采取不同的颜色不同类型的线以及不同颜色的注释框进行注释，甚至关于点击和双击都有对应的不同符号。整套较为繁琐交互文档的假设在于协作者（主要是研发）会经常阅读此注释并能长此以往能够记忆这些注释的规范从而提高效率。

然而现实并不那么美好：首先除非能保证稳定的对接对象以及一定的频率，否则研发很容易会忘记这些小细节的意义。许多复杂的箭头、符号和颜色区分本身并不方便记忆同时视觉区分度也不一定足够，所以研发也可能有所遗漏，相反简单直接的文字倒是更能抓住视线。

同样延伸出一个常见的说法：交互文档需要提供变更日志。的确，对于较大的项目而言的确应该提供设计变更的日志以阐释设计上的增删和变化，但是对于日常绝大多数的文档而言，开发者更宁愿看见一个终极版本而不太在意版本的变更状况或是因为产品需求的变化而带来的变动点（因为通常到产品开发阶段后，方案都会最终确认除非某些意外状况）。

#为文档撰写者而设计

本人尝试为交互文档中的注释提供一套tag系统...简而言之就是每一条注释前面都用上一个标签说明这条注释的要点：或逻辑，或细节，或动画等等诸如此类。但是这种设计最终并没有得以在团队中顺利推广——因为太繁琐了。设计师每写一条注释都要添加一个tag，并且本来简单一句话就能说明的东西为了tag可能要拆分并且为此添加tag…除此以外，tag的来源是axure的library，且axure本身对于富文本多样式和页面排版的支持着实有限（意味着如果需要在注释中插进一段新内容，需要选中一堆东西后往下移动，十分繁琐）

这个tag系统的推广失败延伸出另外一个问题——文档撰写者的使用体验同样重要。一份过于繁琐和复杂的交互文档体系对于维护者而言是一种负担，不仅仅增加新人的学习成本也变相促使使用者偷懒（文档中一些模棱两可的组件可能一直没人用等等）。交互文档规范的设计应该尽可能减少不必要的繁琐细节，让设计师用尽可能少的控件就能组装出最终的文档。

由此甚至可以进一步延伸：交互文档规范的设计实际上是制度设计的问题，需要考量使用者与阅读双方的平衡性。某些网络上的讨论甚至主张交互文档中需要涵盖产品立项原因和目的等等诸多“方便开发者”的内容，除非直接合并双方文档否则就会让设计师增加不少工作量以及风险（毕竟产品经理才是决策者啊）…难以想象这种理想化的交互文档会被更多设计师所接受。

#设计工具——偏向于图形绘制还是文档撰写

我从未找到一款足够趁手的原型绘制工具：sketch和affinity designer（1.5版本后对于ui相关的功能才开始完善起来）能够让我快速的绘制图形，管理样式——却从未能提供绘制流程图与撰写文档的工具（sketch notebook只能算勉强可用）。axure内虽然能绘制流程图甚至制作页面原型却对于图形绘制的支持相当糟糕（比如sketch内的文本填充和样式管理有craft等等工具，还有很多插件提供对齐的快捷方式（如间隔为16px横向居中对齐））。

对于sketch而言，得益于周边插件生态系统的支持，能方便的导出文件到其他工具制作动画效果。axure虽然自带动态面板和页面跳转等种种动画演示方式却难以调试动画的逻辑和细节。在axure内撰写文档我只能老老实实用snapshot，引用原型图并且给出注释。而通过sketch notebook插件我则直接在图形的旁边进行注释然后通过插件隐藏或是显示相应内容。

用于原型设计的工具而言各有特色，但是针对于不同团队特性选择不同工具极为重要。一个专注于移动端设计的团队sketch+principle+skechnotebook插件 输出原型和gif就足以应对多数情况，因为移动段本身逻辑复杂度更低且注重于细致交互。对于pc web端产品，axure的页面跳转功能就相当简单且便于演示… 与此同时，团队对于设计师产出的期许更为重要——如果希望设计师更多花时间进行细致的设计（axure上需要用很多trick才能出较好的效果），那么或许sketch提供的设计上的便利性更为重要。如果团队倾向于跨平台合作或是文档产出，axure中的自带note功能也能提供一定的便利（前提是研发会去一个个手动点击）。

无论采取何种工具，文档的方式和倾向性都会对应产生变化....

附注：adobe xd现阶段提供的功能着实有限。

#交互原型的存在形态

「文档中的原型制作——好钢用在刀刃上」

某些设计leader希望团队成员能够制作精细的axure交互原型（通常表现为非常多的动态面板和变量使用）——以此凸显设计师的专业性并且在开会评审时尽可能对于这些细节所需要的工作量进行评估。如此美好的愿望却可能会引发出不少问题：设计师在调试原型逻辑上花很多时间（这也是我倾向于用principle等时间线工具做动画的原因，输出个gif或者动画，能变相逃避某些需要处理的问题，原型如果点击过程不顺畅给人感官并不好）；与会者对于细节毫无兴趣（除了少部分状况或者实际的研发人员）；让设计师不愿意修改已有设计（人都是又惰性的）;研发不一定有兴趣自行点击原型进行查看

如今想想，有时间应该花在尽可能多绘制和设计一些不同版本以及使用最方便简单的工具制作出动画效果（无论是不是axure）。同时在原型演示的过程中尽可能展示要点——而不是做到尽可能提供可交互内容。对于多数研发而言，他们对于需要自行点击才能出现的面板毫无兴致（如果产品文档并不能平铺直叙而是需要点击100次才能窥见全部内容，那么设计师们也会抓狂吧。）

「文档中的注释撰写——减少不必要的劳动」

很多对于交互文档产出的讨论都强调细节处理：如输入框和按钮的多种状态，针对网络情况的处理，页面的异常情况处理等等。这类问题最好不在每个交互文档当中进行处理（除非有特殊的案例），而是尽量和开发团队合作，形成一份共有的实践规范。这样能避免设计师在每个文档（乃至于许多小注释当中）都写进许多重复而无谓的内容。同时也能减少开发者的阅读负担也促使其关注文档内容。

#文档仪式主义与官僚主义下的考核体系

「文档之存在」

很多团队并不存在交互设计师这一职位或是并不能意识到交互相关的文档内容的工作量所在——对于这些团队而言，撰写且维护相关规范的必要性依然存在（除非只是打算做个demo）。撰写和整理文档本身提供了细致思索以及反思的机会，也提供文档这一媒介以供团队形成共识。依赖于简单的口头描述或是会议讨论对于仔细考虑具体细节并不有有利。从这种意味上而言，文档的撰写过程中设计师经历着某种仪式状态，通过这种刻意被区划出的工作时间对已有的草稿进行修正与细化，文档本身也象征着设计工作中的严肃性环节。

「考核与责任」

一份文档的最终落实程度不仅仅在于设计师本身是否周全详密的提供了最好的方案，产品特性甚至是团队的个性本身于此也息息相关。对于一个成员关系僵硬，倾向于追究责任而不是解决问题的团队，成员们自然倾向于避免麻烦（比如研发会相对更加不愿意和设计师沟通，设计师也倾向不倾向于提供或是尝试更好的设计以减少风险....