注：heidi写这系列的专业文章，并不说明目前heidi做得有多好，相反，每当我发现自己做得不够好时或者遇到问题时，都喜欢反思并总结，可是由于以前养成的不良习惯，导致我最终写出来的东西总是像专业教程，这也导致会有一些小朋友误认为我是专业人士，其实真的不是这样，我写出来未必是专业文章（有时只不过表现如此），我只是觉得这个话题值得探讨，值得分享，也值得自己继续努力而已。所以，也请不要四处转载。
-—————————————————————低调的分割线——————————————————
线框图是交互设计师必不可少的产出物，它在交互设计师的工作中扮演了如此重要的角色，以至于交互设计师经常被认为是个画线框图的，但是无论是设计师本人还是项目组成员，对于线框图存在的意义未必有足够的认识。
项目为何需要线框图？
为什么不缩短周期，直接跳转到视觉设计呢？
对于设计师而言，疑问一样存在：
线框图给我们带来什么价值？
在我们想进行线框图培训时，疑问有：
不就是画个草图吗？还需要学习？
如果大家都把线框图理解成“草图”，那么按照正常逻辑，草图的产出一定是比视觉稿更快而不是更慢才对，但是在很多项目里，为何线框图的时间反而花费得更多？
这往往会引起不解，因为在多数人看来，线框图也就是个没有任何视觉加工过的简单简陋粗暴不美观的草稿，加上我一再声称做线框图的工具是10分钟就可以上手搭建线框图的超白痴工具，而线框图本身就完全无需精雕细琢刻意加工，那么，为何会在线框图阶段停留那么久？其他人都在干嘛？时间都花在哪里？
在我自己回顾过去的项目或者看手里的项目时，我也发现，为何过去的线框图阶段都比较长？而目前在做的项目，由于资源靠自己去安排，自己预安排的资源，比如只有3天，实施过程中发现太紧张，远远不够？
再细想一下，发现也许这三天，我用了1天半就搭建了一个满足基本需求的线框图（从商业需求来讲，这是大家能够预计到的主要的页面），但是在1天半后，我开始进行多种方案的探索与创建，然后发现更多分支流程与异常处理页面，之后，我完全没有为线框图的讨论与确认留下充分的时间！
而，线框图如果做出来不是让大家来争论和确认的，而是仅仅做出来给大家过目一下就移交了，基本上，线框图已经失去了原本存在的价值。
时间都花到了哪里？
并非所有的项目都需要线框图，但是如果需要线框图，那么线框图就需要多留一些时间，不要单纯从最终的线框图产出物的“样子”去评估需要多少资源。
用页面的个数去评估工作量，在视觉设计师也许是适用的——建立在产品视觉风格确定的前提下。
（视觉设计师的资源也需要划分成两段，一段用来做探索，确定产品风格，比如主题色，质感，图文比例与用图风格等，这个阶段也有比较大范围的评审与确认，所以时间上反而会比具体的页面视觉设计来得更长），前端工程师也可以用页面个个数与复杂程度去预估需要多少天，但是对于交互设计师，这比较是个难题。只有交互设计师将需求讨论清楚，自己将页面流程图画好，将各种分支情况考虑清楚，脑子里才会逐渐对需要多少个页面形成概念，哪些页面需要更高的单页面交互设计形成概念，而当他完成这一步，交互的大部分工作都已经做完了，剩下的单纯去设计各个页面，占据了线框图阶段的很少的时间。更多的时间是花在什么上？
讨论——评审——讨论——评审——确认
是的，线框图的作用之一是用来吵架的承载物，交互设计师为线框图确认需要召开很多次评审会（视项目不同而不同），直至大家对线框图达成共识，然后在有的公司，还需要对线框图本身进行可用性测试以发掘更多问题。
80%和20%
交互设计师可能会有20%的精力真正花在线框图本身的制作上，而且他也认为这也许是没有什么技术含量的。剩下的80%的精力，用在：
——需求的了解与讨论，“我认为这个标记出现在搜索结果页，也许并不是合理的场景……”“为什么只针对××会员类型开放这个功能？”在商业初始需求确认后，交互设计师与产品经理是配合最紧密的两个角色，他们需要将商业需求一步步细化，落实到具体的页面与功能的实现上。需求越清楚，以后的阶段就会越高效。这个阶段，交互设计师还需要借助site map，页面流程图（page flow），或者故事板等等工具，来帮助自己和项目组了解产品需求。
有时，工作量绝对不想看起来那么少，产品经理需要把做什么和为什么描述清楚，他们会在“做什么”时也会讲一下“如何做”，但是很多产品经理并不或者被要求不要深入太多解决方案细节，但是交互设计师不一样，必须从宏观到细节，将产品的交互逻辑认认真真仔仔细细思考清楚，细枝末节的东西如果不关心，到了项目进行过程中，还一定会被开发工程师追着补充各种流程中的页面。
——创造性的方案探索与尝试，“如果我这里换一种交互方式，会怎么样？”“还有更好的实现办法吗？”“缩短一步操作会怎么样？”“印象中好像曾经有个网站采用了一种更加高效的方法，我想想看？”所有设计师都有精益求精的“特质”，或者“毛病”，我们需要做这种自我激发的头脑风暴。
从设计来看，设计本身就意味着方案的筛选与确认：也许最后设计师在确认会上只给出了一到两种方案，但是大多数设计师在自己的电脑里或者大脑里尝试过很多方案。
设计本身是一种在期望和限制下进行的探索，并且将探索后的成果实施。交互设计师需要不断围绕需求与期望，进行探索并在逐步的限制中，缩小设计范围。他做的是他应该做的，他不应该将过多的问号传递给视觉设计师，视觉设计师本身也需要进行探索与限制，但是我们更加期望他们的天赋应用到品牌感、质量感、专业感、情感化设计的探索上，而不是分散精力到产品逻辑的思考中去。
——设计方案的评审与确认，正如上图所示，设计师需要分出不少精力，在设计的评审与确认上。他首先从自己的头脑风暴里解脱出来，从若干个方案中筛选一二，然后召集需求方、涉众、其他设计师，进行方案的需求。有时，这样的确认会会召开至少三轮：
第一轮，线框图初审，线框图基本完整后，与需求方以及技术方代表就线框图展开讨论，这是不是商业方也即需求方想要的东西，线框图满足商业期望，确认整体结构、页面上对于内容块的定义，技术方的参与能够就可行性方面给出意见，并且能够根据线框图进行初步的开发资源评估。
第二轮，线框图设计专业评审，让更多的设计师参与讨论，从交互设计层面给予更多意见。这个评审是第一轮评审的补充，在既定的商业需求上就设计本身展开讨论，筛选最佳的方案。
第三轮，线框图终审，设计师在前两轮意见中进行评估，对线框图做一些调整，发起第三轮确认会，商业方代表与设计师代表，技术方代表，以及相关的涉众（比如客服、销售代表）等面前再次宣讲设计方案，告诉大家本次是终审，终审确认后，将会进入视觉设计阶段，到时候将不再做轻易的结构与内容块定义的调整，让大家足够重视并对线框图达成一致。
在这三轮评审中，需要穿插多次小范围的讨论，比如可行性的评估，资源的评估，以及和产品经理反复去讨论需求和需求背后的意义。可以说，线框图的作用之一，就是为了讨论、确认，吵架，然后在一次次迭代与确认中，最终尘埃落定，推动项目进入下一环节。
交互设计师的挑战
挑战绝非在于线框图本身如何专业，或者把线框图做得如何快，而是在于对于需求的把握、挖掘与快速呈现，在于全程中对于各种想法的吸收与管理，在于能不能让大家都快速明白了解设计的原因和背景，并对方案达成一致。
不要让争议、问题带入到真正的实施环节，比如视觉设计，比如开发。
因为从投入产出比来看，把架吵到线框图阶段，是最高效最合适的。
不等于商业需求讨论环节，有很多有创造力的人，却不善于空想，对着商业需求文档，无法让创造力的脑细胞活跃起来，大家都只能对着产品经理的商业方案点头称是，但是到了线框图阶段，具体的产品原型会激发更多的想法，因此这个阶段，最适合进行产品开发过程中的第二次头脑风暴。
不等于视觉设计与开发环节，线框修改起来是非常容易高效的。而且它故意做得如此简陋难看，就是想把最核心的需求呈现给大家，这个产品是这样的，而不是这个产品看起来是这样的。
因为，“看”，“感觉”不可避免会带入很多主观的因素。同样是红色，有人觉得太鲜艳刺眼有人觉得热情澎湃，而恰恰在产品规划初期，我们是不希望过早去关注这些细节，我们需要先解决最核心的问题。视觉稿容易一开始就让大家陷入到各方向的讨论中，有人还在思考产品是不是需要再增加一个功能，或者在争论一个功能是否有足够的价值时，已经有人开始为“黄色”还是“红色”争论得不可开交。
