现在很多企业里的“密集会议文化”使项目团队的项目目标很难达到预期的进度要求，特别是在增强产品的用户体验的方面。通常来说，会议中充斥着太多的项目议程，态度不冷不热的头脑风暴与偏离会议的闲谈，如果你在那种会议文化的环境中工作，试着用为期一天的工作坊可能是个绝佳的方式摆脱老套的会议。
在一个典型的合作团队的环境里，对线上或者移动端产品用户体验的改进流程就像以下所示：
· 某人制定并安排了一个会议
· 大家在会上讨论一些问题以及可能改进的方面（这些改进的方面可能又不一定和会议前准备讨论的问题相关）
· 接着有些人就开始跑题并且脱离了会议开始提出的问题
· 然后大家就散了又去参加另一场会议
· 此时有人又开始安排后续会议
· 接下来在会议里老问题改头换面继续讨论，新问题又被加了进来
上述的流程看起来就这样无限的循环下去，导致解决的问题很少，能采取的行动就更少。假如改变这个无限循环是可以有更好的方法，但是在这为期一天的会议时间内，如果你能在全部的改进提议中提炼出的有意义的焦点，大家伙能准确定义出问题所在，头脑风暴有能提出解决问题的方法，然后提出优先的决绝方案，也不一定让大家参加一整天的工作坊。
然而为什么要组织大家参加工作坊？
工作坊有几点优于会议的地方：
· 良好而积极的动机
· 产生共同的目标感
· 一天内集中涵盖了会议需要几周或数月完成的事情
· 使得每个人都能在解决方案上参与合作
如何开展工作坊？
这里是一个基本的把为期一天的工作坊划分为三个相等时间段的方案：
为了验证这个方案，让我们找一个假设性的问题——一家健康保险公司拥有一个独立的网站，这家公司发现在在线登记的过程中出现了问题，因此公司要搞清楚如何在下一次在线登记上线之前及时做出更好的流程改进方案。
发现问题
多数的企业在正确定义那些需要解决的问题方面做得都很糟糕，常有强烈的欲望直接跳到“修复”阶段，这样做就直接导致大量的心血花在短期的改进或是解决了错误的问题。在这个健康保险公司的网站的案例中，建立“解决一些用户体验问题”工作坊是个新的开端与好的方式来证明这些真实存在的问题，获取这些问题的途径大概有：
· 通过收集一些呼叫中心代理人员分享的关于消费者预约中遇到各种问题的故事
· 打印通话日志、调查结果与页面点击流数据在一个大幅面报告上并贴在墙上
· 让那些对这个产品不熟悉的用户（比如你的朋友、家人、来自别的不相关部门的同事等）使用你的产品然后让他们谈谈对产品的体验
· 收集有参考性的以前关于可用性会议的视频或可用性报告的副本
· 发现以用户的角度的工作坊参与者在体验网站时出现的问题（尝试让他们注册自己家庭的成员）
· 采集工作坊参与人员的一些相关的传闻轶事（例如：“我听到人们抱怨在确认页的时候不知道怎么再点击下一步”）
当工作坊的参与人员产生了关于“产品为何不依据用户习惯来设计？”产生的“怨念”与想法时，不需要花太多的时间在细节问题上（例如:'为什么不在这一块多些留白？”或“我不喜欢绿色”），而是使用挂图与便签让参与者捕捉这些“怨念”，并保证在随后的时间里解决这些问题。一旦把这些采集到的问题制成列表，优先考虑这些问题的严重程度同时选择出重要度第一和第二位的问题为工作坊的下一阶段的主要关注点，问题的严重程度反映在设定的问题优先级与预定目标内。
头脑风暴解决方案
头脑风暴阶段在整个工作坊部分是比较轻松的环节，参与者大多数在的思考如何解决这些问题，以下有一些关于如何让这一阶段更有效率的小贴士：
· 优先考虑并解决一两个问题强于试图解决所有的问题
· 把参与者分解成跨学科的小组并汇总各个小组的讨论的结果
· 鼓励每个参与人员贡献想法，越多越好
· 推迟关于解决这些问题需要付出多少成本这类话题的讨论，允许这些讨论出的解决方案是耗时且高成本的，并且在理想的源配置内就能实现这个方案
· 提供草图等的材料，鼓励每个参与者视觉化解决方案
如果头脑风暴会议环节开始证实了正确的方向，那么从发现问题到解决方案这条道路就会异常的顺畅，但值得注意的是，在头脑风暴环节中会出现这样的陷阱，也就是经常会接受第一个可行性方案、发出最响亮声音者的那个方案以及地位最高者提出的方案，可是这些往往不是最好的对问题的回答，所以分小组讨论能很好的避免这一问题，同时一个好的主持人有更多的方法能保证所有的想法能得到彻底的平等对待。
按大小与优先级排列解决方案
这里有个基本的矩阵，你为了得到一个特定的方案，可以用这个矩阵来权衡对它投入的成本大小与这对这个优先级方案会产生的潜在利益，最终希望能选择出最可能的解决方案：
例如下表中开始列出你的潜在的解决方案的矩阵列表。
工作坊中的这个阶段是比较困难的，经常会在例如“我们貌似知道的方案还不够多”这样的疑问中停滞不前，为了更有效率的方案的大小与优先级进行权衡，有以下几个小贴士：
· 在T恤大小的区域内对这些可能的解决方案进行影响力与投入成本大小排名（例如最大、中等、最小）
· 如果技术团队对某一方案猛烈抨击，那就得承认这方案的实际工作负载可能存在问题，同时得承认技术团队以最小投入的那个方案是最可能往前推进的方案
总结你的工作坊
从定义发现的问题到列出可能新的解决方案这条路并不是一帆风顺的，如果你一天内仍然没得出集体的决定，不要灰心，这也是常事。如果你用完了规定的时间发现还是没有任何决议产生，试着从“产生决议”转变到再次分配任务与再进行下一个步骤。所以在工作坊的结尾，常会有很惊喜的输出分享给大家：
· 收集了更多的问题（例如“用户在登记的过程中在哪里流失的？”）
· 探索了替代的解决方案（例如“尽管我们最喜欢的这个提案，但是耗费资源太大，还是在下一次用户线上登记时期之前采用更快速的改进方案可能更好”）
· 研究范围更细致（例如“IT研发团队在两个备选方案中需要知道哪一个的开发成本更低”）
工作坊的基本要素
1. 哪些人来参加：最好尽可能请跨学科的人员参加，比如说，邀请话务中心代理人员、项目经理、销售团队的人员、设计师、文案人员以及工程师团队人员参与工作坊来共同解决问题。
2. 关掉手机电脑设备：在开始工作坊之前确保参与人员不在发短信、收发邮件以及与本次工作坊无关的事情，如果大家不能全身心的参与，他们是根本没必要来参加这个工作坊的。
3. 时间安排：给工作坊的寻找问题——解决方案——权衡方案三个阶段各分配两个小时的时间，还要确保安排了休息的时间；否则参与者在中途产生疲劳迷茫的状态。所以安排他们吃东西的时间，收发邮件的时间，上洗手间的时间以及还有些闲聊的时间。同时提供零食和饮料可以有效的减少各位参与者的疲劳迷茫的状态产生。
4.指定一个主持人：需要有个人确保所有需要的材料都准备齐整，把握工作坊的每个阶段的方向与讨论的目的，确保遵守时间限制，及时的记录在白板上的信息。几乎任何一个参与者都能扮演主持人身份，但是一个有经验的主持人能让工作坊更有效率，尤其是有些事情没再往前推荐的时候重新定义方向的能力，霸气的管理风格，又能保证能够达到设定的目标。如果你没有机会从外部找到一个主持人，自告奋勇你自己做这个主持人身份并推动整个工作坊往前进。
5. 克服第一次的紧张感：如果你是第一次开展工作坊又很在意成功与否，其实只要能在这一天中专注于你设定的那个清晰明确的目标（例如，为在线登记系统指定一个可行性的改进方案）与制定完备的活动议程，你可以从参与者那里寻求相关的帮助,以判断你是否达到了预定目标。你可以根据指定好的议程坚持往前推进，尽管你不完全确定活动的每个环节中是否按照计划行事。
结论
建立工作坊形式提供了一个受欢迎的方式并且缓解了苦逼的“开会”带来的磨蹭拖沓的感觉。当工作坊实施的得当，它就能提供了很有建设性的解决问题的方式，同时让每个参与者都很兴奋的参与其中。工作坊是积极快乐的，就这两点就足以让你和你的组织抛弃无聊的会议，搞个颇有成效的工作坊吧。