聊聊线框图——为线框图多留点时间

线框图是交互设计师必不可少的产出物，它在交互设计师的工作中扮演了如此重要的角色，以至于交互设计师经常被认为是个画线框图的，但是无论是设计师本人还是项目组成员，对于线框图存在的意义未必有足够的认识。

项目为何需要线框图？

为什么不缩短周期，直接跳转到视觉设计呢？

对于设计师而言，疑问一样存在：

线框图给我们带来什么价值？

在我们想进行线框图培训时，疑问有：

不就是画个草图吗？还需要学习？

如果大家都把线框图理解成“草图”，那么按照正常逻辑，草图的产出一定是比视觉稿更快而不是更慢才对，但是在很多项目里，为何线框图的时间反而花费得更多？

这往往会引起不解，因为在多数人看来，线框图也就是个没有任何视觉加工过的简单简陋粗暴不美观的草稿，加上我一再声称做线框图的工具是10分钟就可以上手搭建线框图的超白痴工具，而线框图本身就完全无需精雕细琢刻意加工，那么，为何会在线框图阶段停留那么久？其他人都在干嘛？时间都花在哪里？

在我自己回顾过去的项目或者看手里的项目时，我也发现，为何过去的线框图阶段都比较长？而目前在做的项目，由于资源靠自己去安排，自己预安排的资源，比如只有3天，实施过程中发现太紧张，远远不够？

再细想一下，发现也许这三天，我用了1天半就搭建了一个满足基本需求的线框图（从商业需求来讲，这是大家能够预计到的主要的页面），但是在1天半后，我开始进行多种方案的探索与创建，然后发现更多分支流程与异常处理页面，之后，我完全没有为线框图的讨论与确认留下充分的时间！

而，线框图如果做出来不是让大家来争论和确认的，而是仅仅做出来给大家过目一下就移交了，基本上，线框图已经失去了原本存在的价值。

时间都花到了哪里？

并非所有的项目都需要线框图，但是如果需要线框图，那么线框图就需要多留一些时间，不要单纯从最终的线框图产出物的“样子”去评估需要多少资源。

用页面的个数去评估工作量，在视觉设计师也许是适用的——建立在产品视觉风格确定的前提下。

（视觉设计师的资源也需要划分成两段，一段用来做探索，确定产品风格，比如主题色，质感，图文比例与用图风格等，这个阶段也有比较大范围的评审与确认，所以时间上反而会比具体的页面视觉设计来得更长），前端工程师也可以用页面个个数与复杂程度去预估需要多少天，但是对于交互设计师，这比较是个难题。只有交互设计师将需求讨论清楚，自己将页面流程图画好，将各种分支情况考虑清楚，脑子里才会逐渐对需要多少个页面形成概念，哪些页面需要更高的单页面交互设计形成概念，而当他完成这一步，交互的大部分工作都已经做完了，剩下的单纯去设计各个页面，占据了线框图阶段的很少的时间。更多的时间是花在什么上？

讨论——评审——讨论——评审——确认

是的，线框图的作用之一是用来吵架的承载物，交互设计师为线框图确认需要召开很多次评审会（视项目不同而不同），直至大家对线框图达成共识，然后在有的公司，还需要对线框图本身进行可用性测试以发掘更多问题。

若线框图不拿来吵架，评估，确认，而是就是为视觉设计师搭搭架子，那么线框图真的就失去了存在的价值。

80%和20%

交互设计师可能会有20%的精力真正花在线框图本身的制作上，而且他也认为这也许是没有什么技术含量的。剩下的80%的精力，用在：

——需求的了解与讨论，“我认为这个标记出现在搜索结果页，也许并不是合理的场景……”“为什么只针对××会员类型开放这个功能？”在商业初始需求确认后，交互设计师与产品经理是配合最紧密的两个角色，他们需要将商业需求一步步细化，落实到具体的页面与功能的实现上。需求越清楚，以后的阶段就会越高效。这个阶段，交互设计师还需要借助site map，页面流程图（page flow），或者故事板等等工具，来帮助自己和项目组了解产品需求。

有时，工作量绝对不想看起来那么少，产品经理需要把做什么和为什么描述清楚，他们会在“做什么”时也会讲一下“如何做”，但是很多产品经理并不或者被要求不要深入太多解决方案细节，但是交互设计师不一样，必须从宏观到细节，将产品的交互逻辑认认真真仔仔细细思考清楚，细枝末节的东西如果不关心，到了项目进行过程中，还一定会被开发工程师追着补充各种流程中的页面。

——创造性的方案探索与尝试，“如果我这里换一种交互方式，会怎么样？”“还有更好的实现办法吗？”“缩短一步操作会怎么样？”“印象中好像曾经有个网站采用了一种更加高效的方法，我想想看？”所有设计师都有精益求精的“特质”，或者“毛病”，我们需要做这种自我激发的头脑风暴。

从设计来看，设计本身就意味着方案的筛选与确认：也许最后设计师在确认会上只给出了一到两种方案，但是大多数设计师在自己的电脑里或者大脑里尝试过很多方案。

设计本身是一种在期望和限制下进行的探索，并且将探索后的成果实施。交互设计师需要不断围绕需求与期望，进行探索并在逐步的限制中，缩小设计范围。他做的是他应该做的，他不应该将过多的问号传递给视觉设计师，视觉设计师本身也需要进行探索与限制，但是我们更加期望他们的天赋应用到品牌感、质量感、专业感、情感化设计的探索上，而不是分散精力到产品逻辑的思考中去。

——设计方案的评审与确认，正如上图所示，设计师需要分出不少精力，在设计的评审与确认上。他首先从自己的头脑风暴里解脱出来，从若干个方案中筛选一二，然后召集需求方、涉众、其他设计师，进行方案的需求。有时，这样的确认会会召开至少三轮：

第一轮，线框图初审，线框图基本完整后，与需求方以及技术方代表就线框图展开讨论，这是不是商业方也即需求方想要的东西，线框图满足商业期望，确认整体结构、页面上对于内容块的定义，技术方的参与能够就可行性方面给出意见，并且能够根据线框图进行初步的开发资源评估。

第二轮，线框图设计专业评审，让更多的设计师参与讨论，从交互设计层面给予更多意见。这个评审是第一轮评审的补充，在既定的商业需求上就设计本身展开讨论，筛选最佳的方案。

第三轮，线框图终审，设计师在前两轮意见中进行评估，对线框图做一些调整，发起第三轮确认会，商业方代表与设计师代表，技术方代表，以及相关的涉众（比如客服、销售代表）等面前再次宣讲设计方案，告诉大家本次是终审，终审确认后，将会进入视觉设计阶段，到时候将不再做轻易的结构与内容块定义的调整，让大家足够重视并对线框图达成一致。

在这三轮评审中，需要穿插多次小范围的讨论，比如可行性的评估，资源的评估，以及和产品经理反复去讨论需求和需求背后的意义。可以说，线框图的作用之一，就是为了讨论、确认，吵架，然后在一次次迭代与确认中，最终尘埃落定，推动项目进入下一环节。

交互设计师的挑战

挑战绝非在于线框图本身如何专业，或者把线框图做得如何快，而是在于对于需求的把握、挖掘与快速呈现，在于全程中对于各种想法的吸收与管理，在于能不能让大家都快速明白了解设计的原因和背景，并对方案达成一致。

不要让争议、问题带入到真正的实施环节，比如视觉设计，比如开发。

因为从投入产出比来看，把架吵到线框图阶段，是最高效最合适的。

不等于商业需求讨论环节，有很多有创造力的人，却不善于空想，对着商业需求文档，无法让创造力的脑细胞活跃起来，大家都只能对着产品经理的商业方案点头称是，但是到了线框图阶段，具体的产品原型会激发更多的想法，因此这个阶段，最适合进行产品开发过程中的第二次头脑风暴。

不等于视觉设计与开发环节，线框修改起来是非常容易高效的。而且它故意做得如此简陋难看，就是想把最核心的需求呈现给大家，这个产品是这样的，而不是这个产品看起来是这样的。

因为，“看”，“感觉”不可避免会带入很多主观的因素。同样是红色，有人觉得太鲜艳刺眼有人觉得热情澎湃，而恰恰在产品规划初期，我们是不希望过早去关注这些细节，我们需要先解决最核心的问题。视觉稿容易一开始就让大家陷入到各方向的讨论中，有人还在思考产品是不是需要再增加一个功能，或者在争论一个功能是否有足够的价值时，已经有人开始为“黄色”还是“红色”争论得不可开交。

另外，我们必须得承认，在视觉设计阶段，修改的成本非常高，视觉设计师是对每一个像素精雕细琢，产品定位的改变，也许对于他们是“灭顶之灾”，这可能会意味着很多个页面要重新开始设计，当视觉设计已经到了一定的地步时，视觉设计师对“修改”慢慢会变得有点抗拒，谁不喜欢自己生出来的孩子？如果一个视觉设计师不喜欢他生出来的孩子，那他可能不是一个合格的视觉设计师。但是交互设计师是很乐意在线框图上进行任何的可能性的探索，他会更加包容这个阶段涌入的任何想法，因为他明白这个是中间产物，而且看起来就不像“完美”到可以当成自己的孩子。

总结几句：

1. 线框图能够帮我们将需求具体化，从而引入更多的想法，完善产品；

2. 线框图能够帮助我们理清思路，怎么做，如何做有了更加系统化的认识；

3. 线框图制作起来非常容易，因此能够帮助我们在各种方案里评估和筛选；

4. 线框图是用来吵架的，交互设计师需要欢迎吵架包容各种想法，更重要的是对吵架进行管理。

5. 80%的时间并非在做线框图，而是花在需求的了解与讨论、多种设计方案的头脑风暴与尝试，设计的评审与确认上，但是这80%的时间投入让剩下的20%更加高效。

6. 作为交互设计师，在那80%里提升的空间会更大，很多时候，剩下的20%是自然而然的结果。

关于线框图还有很多问题值得讨论的，比如：什么阶段下开始做线框图，线框图制作工具与方法，几种不同的线框图的作用等等，就不过多讨论了。以上的部分也欢迎继续探讨。

文章来源：heidixie.blog.sohu.com 转载请注明出处链接。

标签： 线 蛲

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。