
现在很多企业里的“密集会议文化”使项目团队的项目目标很难达到预期的进度要求,特别是在增强产品的用户体验的方面。通常来说,会议中充斥着太多的项目议程,态度不冷不热的头脑风暴与偏离会议的闲谈,如果你在那种会议文化的环境中工作,试着用为期一天的工作坊可能是个绝佳的方式摆脱老套的会议。
- 某人制定并安排了一个会议
- 大家在会上讨论一些问题以及可能改进的方面(这些改进的方面可能又不一定和会议前准备讨论的问题相关)
- 接着有些人就开始跑题并且脱离了会议开始提出的问题
- 然后大家就散了又去参加另一场会议
- 此时有人又开始安排后续会议
- 接下来在会议里老问题改头换面继续讨论,新问题又被加了进来
上述的流程看起来就这样无限的循环下去,导致解决的问题很少,能采取的行动就更少。假如改变这个无限循环是可以有更好的方法,但是在这为期一天的会议时间内,如果你能在全部的改进提议中提炼出的有意义的焦点,大家伙能准确定义出问题所在,头脑风暴有能提出解决问题的方法,然后提出优先的决绝方案,也不一定让大家参加一整天的工作坊。
工作坊 – 工作坊的角色
「参与式工作坊」的角色有三种,分别为「参与者」、「专业者」、「促成者」。
参加活动的人称之为「参与者」,如:群众。
具有专业技能,对于进行讨论之专业主题直接助力者称之为「专业者」。
至于主持及协助工作坊进行的人则称之为「促成者」。
促使工作坊有效推动的人包括如何让参与的民众彼此之间进行有效的沟通,或是协助参与者在讨论的过程中发现并提出问题,但绝对不是强势的为参与者做出决定。
工作坊 – 工作坊的分类
工作坊的操作与进行的方式,随着不同的议题发生,而变更操作上的手法,但是基本上,基本的模式与架构是不变的。
(1)资讯的分享 工作坊第一个实施的步骤,就是必须将原有的基本资共同分享。透过这样分享的过程,可以将参与者所持有的资讯、讨论成果互相分享,让参与者能够在平的立场下共同讨论、交换意见,进而凝聚意识。
(2)小组提案设计 第二个阶段主要利用分组讨论的方式,让参与者可以继续互相讨论。透过小组讨论的过程,让参与者之间可以互相交流意见、激汤脑力、共同创造。透过凝聚意识的过程,拉近参与者之间的关系,以利往后活动的顺利进行。
(3)全体表达意见 最后的阶段就是各小组的发表时间。发表之前共同讨论出来的成果,和其他小组互相交流。随着各个小组的价值观与立场的不同,利用客观的角度来分析事情,希望借此沟通协调的机会,共同思考出一个最适合的方向,延续伸展至之后的活动上。
然而为什么要组织大家参加工作坊?
- 良好而积极的动机
- 产生共同的目标感
- 一天内集中涵盖了会议需要几周或数月完成的事情
- 使得每个人都能在解决方案上参与合作
如何开展工作坊?

发现问题
- 通过收集一些呼叫中心代理人员分享的关于消费者预约中遇到各种问题的故事
- 打印通话日志、调查结果与页面点击流数据在一个大幅面报告上并贴在墙上
- 让那些对这个产品不熟悉的用户(比如你的朋友、家人、来自别的不相关部门的同事等)使用你的产品然后让他们谈谈对产品的体验
- 收集有参考性的以前关于可用性会议的视频或可用性报告的副本
- 发现以用户的角度的工作坊参与者在体验网站时出现的问题(尝试让他们注册自己家庭的成员)
- 采集工作坊参与人员的一些相关的传闻轶事(例如:“我听到人们抱怨在确认页的时候不知道怎么再点击下一步”)
当工作坊的参与人员产生了关于“产品为何不依据用户习惯来设计?”产生的“怨念”与想法时,不需要花太多的时间在细节问题上(例如:”为什么不在这一块多些留白?”或“我不喜欢绿色”),而是使用挂图与便签让参与者捕捉这些“怨念”,并保证在随后的时间里解决这些问题。一旦把这些采集到的问题制成列表,优先考虑这些问题的严重程度同时选择出重要度第一和第二位的问题为工作坊的下一阶段的主要关注点,问题的严重程度反映在设定的问题优先级与预定目标内。
头脑风暴解决方案
- 优先考虑并解决一两个问题强于试图解决所有的问题
- 把参与者分解成跨学科的小组并汇总各个小组的讨论的结果
- 鼓励每个参与人员贡献想法,越多越好
- 推迟关于解决这些问题需要付出多少成本这类话题的讨论,允许这些讨论出的解决方案是耗时且高成本的,并且在理想的源配置内就能实现这个方案
- 提供草图等的材料,鼓励每个参与者视觉化解决方案
如果头脑风暴会议环节开始证实了正确的方向,那么从发现问题到解决方案这条道路就会异常的顺畅,但值得注意的是,在头脑风暴环节中会出现这样的陷阱,也就是经常会接受第一个可行性方案、发出最响亮声音者的那个方案以及地位最高者提出的方案,可是这些往往不是最好的对问题的回答,所以分小组讨论能很好的避免这一问题,同时一个好的主持人有更多的方法能保证所有的想法能得到彻底的平等对待。
按大小与优先级排列解决方案

- 在T恤大小的区域内对这些可能的解决方案进行影响力与投入成本大小排名(例如最大、中等、最小)
- 如果技术团队对某一方案猛烈抨击,那就得承认这方案的实际工作负载可能存在问题,同时得承认技术团队以最小投入的那个方案是最可能往前推进的方案
总结你的工作坊
- 收集了更多的问题(例如“用户在登记的过程中在哪里流失的?”)
- 探索了替代的解决方案(例如“尽管我们最喜欢的这个提案,但是耗费资源太大,还是在下一次用户线上登记时期之前采用更快速的改进方案可能更好”)
- 研究范围更细致(例如“IT研发团队在两个备选方案中需要知道哪一个的开发成本更低”)
工作坊的基本要素
结论
作者介绍:Beth Koloski, EffectiveUI的熟悉体验架构师,有12年web端软件界面用户体验设计的经验,她为Orbitz、Domino’s、 Red Bull以及 Standard & Poor’s这些的客户完成了很多成功的项目。