PIT BOSS 掉坑永无止境

最近好些前同事向我咨询一个问题，就是他们团队引入了交互设计师但是却不知道原型以及其意义更不知道交互设计师应该如何产出以及产出质量如何判断。笔者根据有限的经验尝试对这个问题进行一定讨论。 #这是个蛋糕 理论上而言，不仅不需要视觉设计和产品经理也不需要单独的交互设计。遗憾的是，许多产品本身并不小而且决策与项目实施过程中需要有大量的工作。即便是较为精英化的团队，也难以避免其成员的能力有所偏重（我才不相信市场上有那么多人在交互、设计和产品上都有足够经验呢）。事情应该是这样的，在有限的时间中人的精力是有限的。如果时间都分配给了产品设计，那么留给交互本身以及视觉设计的余地就相对较少，反之亦然。团队职位的设置不一定是问题（也就是ui与交互还有产品是否有专职），问题是蛋糕本身要做多大以及该如何分配才是问题。假设产品经理一个功能给出一句描述就完了，那么设计师可能要处理大量功能设计上的细节那么就无暇对细节本身进行雕琢。假设交互稿件上只有大致的布局而对信息层次以及实际使用效果考虑不足，那么ui设计师就要花费大量时间思考和脑补而不是慢慢选配色调节细节——根本没这时间。 所以，产品经理是否应该画原型图以及交互设计师是否应该每天就是把产品描述转化为axure上的原型，其归根结底都是取决于这个团队希望产出何等质量和类型的产品。如果有交互设计师，那么产品经理应该更深入的思考他的决策原因以及大致的功能逻辑和异常处理，而交互设计师也需要给出更为专业的产物如相关的文档，动效的说明以及有着恰当比例和轻重得宜的交互稿。 # 设计师的交付物 交互设计方面的产物质量和视觉设计以及程序员的代码质量一样，都需要内行人才能看得出来... 本文尝试总结一份关于交互设计师可能产出的内容的清单提供给那些不知道应该要求设计师产出什么的产品经理们。 ——手绘设计草图 手绘草图中通常包括一些方案尝试和选择，这几乎是进行实际用软件绘制之前比较重要的步骤。 ——软件绘制的交互图 使用axure或其他工具绘制的原型图，尽可能重点明确而比例恰当，最好有着恰当美感。部分项目可能要给出不止一份的方案进行选择。这个阶段给出的交互产物应该已经考虑到现实的使用状况以及错误处理和各种异常状况。 ——流程图 对于业务流程以及用户使用流程以及功能细节运作方式进行描述的流程图。流程图应

#前提 本文专注与讨论web/app/桌面端界面设计（包括交互与视觉）的思考以及决策方式，并不讨论设计决策中那些与具体业务和产品设计的部分。 在谈论设计师在接受了需求后如何进行设计，那么除了理解需求的重点以外还有很多与设计本身相关的决策环节。在这个过程中，设计师通过知识和经验以及一定的尝试选出较好的选项构成最终的设计方案。外行人会以为，设计师只需要简单的理解需求并且画图就好了。可是在此过程中的思索以及其带来的取舍，才是设计中最重要的环节。笔者在此将会介绍自己在设计中的决策机制。 首先，虽然笔者会提供一些参考要素，但是对于不同产品以及与不同人沟通并没有必要把全部流程走一次。其次，针对不同产品的不同阶段，会侧重于某些角度对自己的设计方案进行审视与打磨。 #还原 关于设计，有无数的教程和案例也有着无数的相关知识和理论。在日常工作中，只有部分典型场景才会有直接的现成大量直接的知识可以参考（比如注册登录模块\新手引导流程）。设计师在日常的阅读以及积累有助于帮助设计师学习业界所总结的经验从而更好的做出设计决策。许多知识虽然不能显性的提供即刻的指引，但是却能提高设计师解决问题时的能力以及提供更多的角度。比如关于设计原理与手法的介绍，再如各个平台的设计风格的演变历史，再如对于用户行为和决策的一些现成研究和数据。当一个设计师基础知识扎实，那么在碰到某些问题的时候就更可能跳出困住自己的小房子从而从更多角度发掘和尝试新方案。比如改良官网的产品介绍模块，可以还原为展示性页面的内容呈现逻辑与叙述手段以及内容管理相关的一些核心要点。 * rss/邮件订阅有助于你定期集中了解行业内的动向和知识 * 适当看书，即便他们不能立竿见影的提高设计质量 * 有些东西需要等自己有一定设计经验的时候才能理解 * 基础知识要扎实，比如发现自己对字体选择不确定那么可能要好好系统的补习一下 * 许多现有的互相重合与冲突的原则，根据场景以及这些知识产生的推理和背景进行选择 #数据 关于数据有很多，有些来源于现成的产品有些来源于更加广泛的研究与调查；也有来自于部分用户的反馈与需求。面对任何现成的数据与反馈，最好抱着警惕的态度对待他们。无论是什么性质的数据，关心其来源的情景以及恰当的处理方式都很重要。无论定性还是定量数据，从数据到结论都并非如此理所当然

去年年底，笔者曾经作为交互设计师参与过某个slack-like产品的设计当中。因为最后该项目被全盘推翻并且笔者在后期因为项目变动离开该项目组，所以特意把项目过程中的一些教训写出来告诫后来人。 #人人都是产品经理 每个人对于产品都有自己的理解但是并不是每个人都应该主导产品设计。在产品设计阶段的早期因为实际的决策者并不是直接管理的产品经理而且直接决策者（估计因为时间不足）也没有留下任何系统性的文档（比如竞品研究 思路阐述等等）并匆匆开工导致后面许多问题的出现和决策都处于扯皮状态。后面接手的产品经理一方面并不一定理解和认可先前的决策，同事也因为制度不周全而要同时监管多个项目而无暇思索，导致早期产品设计一团糟。 产品设计一团糟的表现通常为产品理念不清晰以及逻辑问题以及对异常状态处理机制的思考不周，比如群组被删除后相关文件怎么办以及群组内的文件被分享出去后和该群组的关系等等。这种设计上的混乱倘若加上多平台不同的限制和接口上的设计问题在项目中期很容易成为一团乱麻。后期产品经理尝试思索并且解决这些问题，然而他并没有通过很好的方式共享他思索的成果和判断依据。导致在中后期依然为了同样的问题研发、设计、产品依然始终在兜圈。遗憾的是，相似的功能由于在某些版本（比如web）上线，导致某些领导对此有特殊的理解（这些理解可能基于经验也很可能是随便一说）导致有问题的设计不能及时纠正或是重新理清。 参与产品设计讨论的每个参与者可能都有项目管理工具与通讯工具的使用体验和角度，这些经验会让他们会产品本身提出许多可能有益的建议。问题是当每个人都可以用自己的体验说事或是企图把一切都推给迅速上线后等数据验证而放弃充分的思考，那么如何衡量功能点的设计目标以及是否达成目标甚至是改进方向就成为了问题。“国情”和“用户体验”在没有经过审视的情况下容易变成幌子，为一个产品揉入一堆无法互相配合甚至是互相冲突的功能。同时由于这群功能都可能有着先天残缺（因为也很可能和别的残缺的功能混在一起成为更大的模块），导致后期产品经理很容易得出一个结论——这个产品看着还好但是小毛病很多。 ——磨刀不误砍柴功，不要充忙进入开发阶段 ——团队知识要共享，否则团队根本没有共识... ——盲目的敏捷开发容易导致产品全盘推倒重来 ——产品经理对于产品的全面思考很重要 —— 用户体验/敏捷

前提 本文讨论的动效设计表达基于类似origami类，基于逻辑与参数组合为基础的工具。与此同时，本文讨论范围也基于小团队特别是至少一位设计师能熟练使用origami类工具的团队。最好该团队使用Mac工作，并且拥有对于交互设计，视觉设计，基本代码能力的设计师。本文也不打算讨论偏向于展示以及较为复杂的交互动效如何与文档耦合。 #why 本文并不希望讨论为什么需要动效设计而是讨论为什么需要写这篇文章。关于动效设计，有许多传达方式。有些是基于AE，叙述层次关系以及时间线变化以及动效曲线参数，有些完全基于代码与其逻辑，如framer和许多js库。更有基于逻辑与参数组合的origami like工具。这类工具都能提供调试具体参数与变化的方式，但是对于整理具体功能以及交付相关文档给研发进行开发，完善的文档依然有必要。同时对于一个较大的项目而言，必然有不少与动效相关的输出物（因为许多origami file或是AE文件不可能做一个完整的产品，资源不足）。这些输出物需要有对应工具进行整理与反思以保证整套方案的完整性与一致性。 #具体业务之外，核心表达之中 对小团队而言，动效设计以及其文档表达始终有些尴尬。其一团队成员少因而时间有限，而部分动效高度依赖于高保真图与最终页面内的细节呈现。这也就意味着，本来小团队就更容易发生的高保真迟迟不能定夺现象，导致留给动效设计的空间极为有限。或许许多页面的呈现，比如从列表进入详情页面这个过程的动效并不过于依赖于具体业务。但是这类动效的展示却依赖于整个产品核心信息架构与理念上的清晰，比如基于卡片为单位传达信息与基于群组为单位展示信息，也应该有针对性的动效设计辅助使用者理解产品内不同的信息与层次。如果一个产品的核心方向始终摇摆不定，那么设计师容易不分场景较为粗暴的随便仿效或使用系统原生效果目标。 #文档内的粒度 个人建议文档内的描述基于单个的场景甚至是单独的控件且其中panel的变化较为单一。这种设计原则有两个考虑：其一是减少因为单场景内内容过多带来的复杂性，其次越大的场景内动效的设计越可能与多变的具体页面的相关业务耦合。即便针对简单场景的细致描述也考验交互设计师对逻辑和交互过程中各个状态变化的理解以及对细节到整体的把握。把粒度变小有利于通过更深入的把握细微的变化，从而更好的从宏观层面统合整个产品的动效甚至是信息展现逻辑。

#为什么选择origami 虽然origami是一种不易上手更不易精通的动效设计工具，但是却有着难以替代的优势。其一其基于osx的原生图像处理机制，相对于别的动效app具有更多拓展空间。其次origami强调交互逻辑以及状态变化比起强调时间线机制的hype更接近交互设计师所关注和力图解决的问题。其三，origami背后有github上众多开发者的支持以及facebook的投入。 #origami的缺陷 上手难度较高，需要不断练习（掌握所有基本patch）和思考才能掌握origami的基本逻辑以及解决问题的大致思路。同时，学习origami意味着要有一点英文基础（中文资料少的可怜）以及对程序运作和逻辑的思考能力。再者，origami本身的开发工具链条并不完善，缺乏足够好的debug机制。总而言之，学习origami对于设计师而言是检验自我学习能力的好机会 = =！ #如何学习基本的origami动画设计 要使用origami进行动效设计的前提是拥有一定ui技能（要点在于能独立设计并且输出ui图）。其次大概就是拥有一台mac，并且安装好quartz composer和origami。老老实实看facebook的教程以及把facebook提供的案例都下载下来看一下。重点在于搞清楚基本操作和大致连接各个patch的逻辑，理解从触发到行为之间这种变化方式。 在研究facebook提供的案例以及Martin. RGB大神翻译与个人总结的经验后，估计对于origami就有一些非常基础与零碎的认识了。在这个阶段除了老老实实做练习以外，还要不断思考每个patch的作用和意义。碰到问题除了不断尝试还要多看看别人做的范例，有时候网上并没有直接的答案。但是类似的情况以及类似patch的使用却能人许多启发。 #一些小经验 * 那些patch的含义是我掉了很多坑才理解的= =！老老实实看patch说明很重要。 * origami不是axure，注定有很长的上手时间。 * origami内各种变量是有type的... * 我个人强烈建议好好管理各个patch的命名，命名就是注释。 * 模块化思维（把模块都按照逻辑和一定的粒度组成marco patch），并且更多用boardcaster和re