Heidi格物志

接《前言》重点分享一下在UED日常工作中常见，且经常组织的会议。

1. 头脑风暴

此会议有个很响亮的名字，你或许也被人拍着肩膀说：hi，有空没？一起来风暴一下。

这种在中国人来看不就是一个茶话会吗，结果老外们很认真给命了名，而且还发展出一套规范来。

但我们记住了它的名字，却没有引入早已成熟的章法，所以这种会常开得乱七八糟，人神共怒，最容易延迟。

• 组织很随意，大家背景了解不充分，不知道说什么。
• 或者，大家不敢说，害怕被人笑话。
• 要么，乱说，偏题太远。

所以，开头脑风暴会议前，作为组织者，要先有一个谱在心里，在没有获取对于头脑风暴充分的知识之前，请不要轻易尝试头脑风暴！抱怨头脑风暴无效的，往往是因为自己没有有效组织，而与会议本身无关。

使用阶段：

头脑风暴定位于无限制的自由联想和讨论，其目的在于产生新观念或激发创新设想。可以被应用到任何阶段：

• 为新产品命名；
• 设计一个图标，需要让更多人一起来贡献头脑里的意象。
• 探索新的产品所应该具备的功能

和其他大部分会议不同，头脑风暴不是决策会，而是主意大会。

头脑风暴的原则：遵循这些原则，让头脑风暴更加有效。

• 对每一个想法不做任何批评。不但不要批评，甚至连咳嗽、赞扬、皱眉、叹气、提问都尽量不要有。
• 数量比质量更重要
• 鼓励狂热和夸张的观点——反正不一定采用，但是有可能刺激别人的想法
• 有话就说，不私下交头接耳

对主持人的建议：

• 遵循规则，在召开前自己最好了解相关知识。这当然不是鼓励你墨守陈规，如果你有兴趣，哪怕自己生造国际象棋的游戏规则也可以，但是你得保证和你下棋的人心里也有同样的规则。
• 开张名义：给大家讲清楚邀请大家来头脑风暴的主题，给出必要的且已经确定的限制，让大家的天马行空更加靠谱。同时，要给大家宣扬一下头脑风暴的游戏规则，比如：不批评。
• 控制，不要对某个想法过于深入，也不要离题太远。
• 两顶帽子：做主持人，也做参与者。做主持人话不要太多，隐身起来但是时刻要进行控制。

其他的，也不在此班门弄斧了，有兴趣的可以点击查看这个教程《头脑风暴十全大补》

2. 线框图评审会

对于交互设计师来讲，线框图评审会是再熟悉不过了。我不像内部分享一样展开述说了。有兴趣的邮件给我。

正如我之前的《为线框图多留些时间》一文所言，往往线框图阶段会花费比视觉更多的时间，线框图的过程正是把不确定转化为确定，把确定转化为方案，把方案转化为规格参数的过程。这就意味着，这个过程一定是有着很多次评估、讨论、评审和确认。

在不同的阶段，面对不同的人，有：

2.1 线框图内部评审会

也叫初审，定位是“problem discussing”，先和需求方（很多时候是产品经理），在交互设计前期，一起讨论一下待确认的问题。所以定位为“问题讨论会”。

说到这里，不得不提一下项目流程。流程因项目和公司而已，若你所参与的项目流程和我说的不一样，也没啥好纠结和争论的。即时在阿里巴巴，也不见得都是走我说的这种流程。大体上一致，细节上不同。偷偷说一句，我是个流程控。我从两年前就不断对这个流程进行修订，一直到现在，我觉得它可以解决大型和中型产品开发项目的很多问题。

在我定义的流程里，确定了要做什么东西后，产品经理与交互设计师就同时开工努力去探讨这个产品要有什么功能，以及功能详细的方案和实现。产品经理去撰写PRD(产品需求文档)，而交互开始做线框图。两者同时开展工作目前是被证实比较有效同时能够结合两者长处的合作方式（要知道，在去年的时候，流程未调整时，总是有交互设计师在抱怨说，每次什么都确定好了，就让他出个原型图，这时他即时对产品需求有质疑或者有建议，被接受也比较难）。

无论是 PRD和线框图都需要不断迭代着逐渐细化，而PRD初审和线框图内部评审就是迭代过程中的会议。

阶段：交互设计前期，PRD初审之后（这并不严格要求，有些产品若设计本身的重要性大于商业规则，则可以是由交互主导的，PRD可以在交互之后写一份功能规格清单而已）。

目标：逐渐缩小可能性范围，明确方向

• 确定商业规则
• 确认交互流程
• 确认信息结构和内容定义
• 消除私下讨论无法解决的争议

有人说，既然已经有PRD评审，为何还需要线框图内部评审会呢？

• PRD初审是评审一个产品所具备的功能列表和商业规则，缺乏原型的时候，很难暴露出更多问题；
• 交互设计师是带着脑袋画线框图的，他在工作中，一定会冒出一些问题和想法来，这些未必能够体现到frd里。
• 虽然有一些紧密的私下讨论，但是一般是两个人的小范围，有时有些建议并不被接受，需要引入更多的角色来评估是否可行

所以，线框图内部评审最好有的角色是：

• 交互设计师（也是发起人）
• 产品经理
• 开发代表人（做技术可行性的评估）
• ued其他代表（可能是重要的支持者）
• pd其他代表

这是保证设计质量的重要会议，也是重大的决策会，充满了是和否的判决，在血雨纷飞中，道路却越来越清晰了，不再存在太多选择。

承载物：粗略线框图、问题列表等。

2.2 线框图专家评审：

在线框图内部评审之后，解决了一些待讨论的问题之后，交互设计师调整和细化线框图，既然决定了做什么，下一步当然就是怎么做的问题了。

大的方向定了，但是围绕某个功能点的设计上，解决方案仍然是非常多的，界面如何展现，排版布局以及细节交互等。产品经理有时并不关心这个，在缺乏可用性测试资源时，邀请其他设计师或者行业专家来进行专家评审是成本最低的评估。

与内部评审不同，这里的结果可能不再是“是”或者“否”，而是“好”，“不好”。

这定位成为“ask for feedback”。强调这个，正是为了建议组织人也就是交互要转变立场和态度，有时我们开确认会开多了，就会很屏蔽别人的建议，面对挑战也好，建议也好，总是第一反应不是take，而是push回去，别人一问就解释，别人一提建议就否决，那就没有了专家评审的必要了。

你只是征询建议，只要存在问题，或许你需要的不是解释，而是询问为何会产生这样的问题，其次才是回答。

产生阶段：交互设计中后期，线框图确认之前。

会议目的：为设计质量把关，征求建议，接受反馈，优化设计方案

参与人：做这个项目的交互设计师，以及可邀请到的其他交互设计师（人数在5到6个就可以了），产品经理（在场的话，不但能够帮忙解释产品的背景，在涉及到万一有可能修改商业逻辑时也节省了解释成本），前端和开发代表，在场可以帮忙就每种方案提供技术评估。

承载物：多种解决方案的线框图，如：

2.3 线框图技术评审

到此，不但大方向确定了，连分岔的羊肠小道也被关闭了。但是还会有技术评审，人少时，是个规模很小的会议，达成目标就可以了。

目的：向前端和工程师详细讲解设计需求。让他们当面沟通技术解决方案以及配合模式。

补充一下，在这个会议之后，就真的一切变数都没有了。不要把技术可行性评估放到这个会议上，给他们看的就是可行性的方案，评审的是怎么做，怎么配合而不是能不能做。关于能不能做的问题，在之前的内部评审以及专家评审上就应该解决。

承载物：详细线框图和设计说明文档

阶段：这个会议可以根据情况放到frd终审之前或者之后。

有时不可避免还会有一些线框图和frd的细微调整，发个邮件再确认一次就可以了。

这几个会议，只所以放出来，是因为这是交互设计师主要要组织的会议，当然有些项目需要增加一线框图确认会，当涉众很多而且很在意界面和交互细节时，且在PRD确认时并未将重点放到这些地方上。

和产品经理的会议如何配合呢？如图：

整个项目里，还有kick off，uc评审，tc评审，发布计划评审……不说了，反正我也说不太清楚。 

六. 向有效的会议前进

终于到了最后一节了。这一节是分享一些关于如何组织会议的心得。

前面说了，现在很多的会议，因为缺乏有效，导致要么我们是被别人浪费时间，要么是自己去浪费别人的时间。

不管别人如何做，我们能不能保证，自己不做罪恶的人，首先，你能保证你组织的每次会议都能够准时结束吗？

现在，向有效的会议前进！