PIT BOSS 掉坑永无止境

本文主要以某海外银行个人网银登录后的首页设计为案例，尝试解析交互设计过程中前期设计这一步骤的要点。本文主要分为上下两篇，上篇主要列举出前期设计的要点，下篇则通过一些案例解说前期设计当中某些具体步骤。 #引言 除了部分极为简单的项目，多数设计都需要经历前期的概念尝试和后期方案完善及文档输出两个阶段，区分这两个阶段有助于提供更好的交付产出以及与周边的同事形成更好的协作与沟通。（因为可以提供一些方案给他们选择，并且在方案中期及时沟通优于方案完成后临时修改。） #为什么需要前期设计 ——分批交付成果，在设计阶段中就与同事及时沟通和交流 ——不同阶段关注不同问题，避免眉毛胡子一把抓 ——在前期设计阶段就与产品经理等需求方进行沟通，推动需求细化与更优方案，落实需求细节 ——尽可能通过前期设计尝试一些新的可能性，并且分辨一些概念是否靠谱 ——在前期设计的过程中找出当前设计的难点和关键要素，便于规划时间分配 #前期设计做什么 ——阅读产品需求，并且确认其中细节并且进行相关沟通。 ——尽可能收集相关数据或者已有的反馈，作为设计的依据 ——关注相关竞品设计或类似组件的设计（只要其本质相通即可） ——查阅资料（根据具体项目和设计师熟练度而言） ——构思大体布局以及基本使用流程，并且产出几个预选方案 ——分析预选方案的主要优缺点以及受众的阅览顺序和关注重点（通过 高斯模糊的办法 ） #除了画图，在提供预选方案的时候还要做什么 ——尽可能找出当前备选方案可能存在的优化点（比如信息分布过于松散）—后续详细设计时可能会进一步重点优化 ——明确当前每个预选方案的特点与亮点所在（方便对付那种一句话解释你这个方案的情况） ——记录下关键要点，如每个方案的缺陷/限制/或者其他注意要点（这个很重要！） ——关注自己在设计的时候受到的一些前提限制 ——如果排除了某些设计方向，最好进行简单的记录和分析 ——除非有特殊状况，避免在某个细节中耗费过多时间 ——如果需要运用动画或是不常见的切换等交互，在这个阶段就尽可能提供gif或者视频给研发or产品以供参考 #前期设计需要避免哪些坑 ——过度关注于某个既定的方向（除非产品的要求非常清晰和明确，而场景本身也不需要太多新的设计方案

有关于交互文档撰写和输出的话题，已有无数文章进行讨论。本文主要集中与交互文档以及文档规范设计的一些少见的关注点和一些交互文档规范设计的经验教训。 #受众 前公司曾经有一套相对复杂的交互文档设计规范——这套文档规定了设计师需要在visio上进行流程图绘制且在axure上进行原型绘制和输出。其中，visio内的流程图以及相关注解采取不同的颜色不同类型的线以及不同颜色的注释框进行注释，甚至关于点击和双击都有对应的不同符号。整套较为繁琐交互文档的假设在于协作者（主要是研发）会经常阅读此注释并能长此以往能够记忆这些注释的规范从而提高效率。 然而现实并不那么美好：首先除非能保证稳定的对接对象以及一定的频率，否则研发很容易会忘记这些小细节的意义。许多复杂的箭头、符号和颜色区分本身并不方便记忆同时视觉区分度也不一定足够，所以研发也可能有所遗漏，相反简单直接的文字倒是更能抓住视线。 同样延伸出一个常见的说法：交互文档需要提供变更日志。的确，对于较大的项目而言的确应该提供设计变更的日志以阐释设计上的增删和变化，但是对于日常绝大多数的文档而言，开发者更宁愿看见一个终极版本而不太在意版本的变更状况或是因为产品需求的变化而带来的变动点（因为通常到产品开发阶段后，方案都会最终确认除非某些意外状况）。 #为文档撰写者而设计 本人尝试为交互文档中的注释提供一套tag系统...简而言之就是每一条注释前面都用上一个标签说明这条注释的要点：或逻辑，或细节，或动画等等诸如此类。但是这种设计最终并没有得以在团队中顺利推广——因为太繁琐了。设计师每写一条注释都要添加一个tag，并且本来简单一句话就能说明的东西为了tag可能要拆分并且为此添加tag…除此以外，tag的来源是axure的library，且axure本身对于富文本多样式和页面排版的支持着实有限（意味着如果需要在注释中插进一段新内容，需要选中一堆东西后往下移动，十分繁琐） 这个tag系统的推广失败延伸出另外一个问题——文档撰写者的使用体验同样重要。一份过于繁琐和复杂的交互文档体系对于维护者而言是一种负担，不仅仅增加新人的学习成本也变相促使使用者偷懒（文档中一些模棱两可的组件可能一直没人用等等）。交互文档规范的设计应该尽可能减少不必要的繁琐细节，让设计师用尽可能少的控件就能组装出最终的文档。