赞
踩
我一共参与过五六次 Design Workshop,每次都有不同的感悟。
2011 年我在知乎工作,8 月的一天收到俊煜的邮件,邀请我作为评审嘉宾参加豌豆荚内部的 Hack Day。在那次 Hackathon 里,我看到了 7 支内部小团队在短时间内迸发出了无限的想象力、创造力和实际动手能力,第一次为这种新颖的产品开发形式所吸引。
图来自王俊煜个人公众号猫窝
2014 年初,我加入豌豆荚团队,当时的项目对我而言是一个陌生的行业。面对多样、杂乱的需求,当时搭挡的设计师主持了一场团队内的 Design Hackathon,通过高效的 Brainstorming,对需求进行了地毯式的遍历搜集并分类,帮助我快速地看到了全局。这一次,我感受到了正确的 Brainstorming 姿势的重要性。
离开豌豆荚后,我在社交领域开始了第一次创业 —— 这是一个需求广泛但产品形态亟待创新的市场。一段时间后,产品增长遭遇瓶颈,于是我在团队内组织了一场 Design Workshop,以「如何让两个陌生人进行有效见面」为主题,开展了魔镜 2.0 的设计探索,做出了全新的产品方案。尽管最终我们没有将这一版上线,那场 Workshop 无疑对我们团队而言是一场整齐高效的交流讨论。
Design Workshop 强调创新思考、追根溯源、去伪存真、动手创造,这个方法不仅适用于互联网产品,也适用于日常生活中碰到的一些问题。去年 11 月,我参加豌豆荚「豌豆大篷车 · 深夜酒馆」聚会,跟俊煜聊到想围绕产品设计方法论做分享社群的尝试,他提出可以与他的新公司「光涧实验室」一起合作,我当时就觉得非常棒 —— 能把豌豆荚内部实践多次行之有效的设计方法论推广给行业内更广泛的职人,这事儿太有意义了。
光涧实验室联合职人社计划在 2017 年举办一系列的 Design Workshop。
为了确保 Workshop 启动的质量,第一期 Design Workshop 由光涧实验室的联合创始人王俊煜亲自设计和主持,保证全程推进效果,并特别邀请了两位嘉宾进行经验分享。光涧实验室和职人社共同进行参与者的招募。职人社特别推荐了几位资深产品经理参与,全程跟进记录,并将在之后和光涧实验室一起共同改进 Workshop。
俊煜从众多选题中选择了大家关心度比较高的「日常场景中易用的小程序」。为了让设计流程更加流畅高效,还预先在每个小组进行了背景、经验的精准搭配,以期产生更多有趣的想法碰撞。
*Design Workshop 是 Googke、IDEO 等业界顶尖公司内常用的产品设计方法和工具。在一定时间内以头脑风暴的形式,最大范围内搜寻产品的可行性,抽象地整理出这些想法背后隐藏和核心概念和用户需求,快速整理出正确的产品设计方向,将想法转化成合适的方案草稿图,最终变成产品故事板。整个的设计过程我们几乎没有做任何方向的限制,我们让产品设计师、工程师等不同角色的朋友讨论互动,相互激发灵感获得丰富的创意。
—▌为 Design Workshop 充分准备
简单来说 Design Workshop 可以分为提问、头脑风暴、Idea 分类和完善、方案设计四个环节,遵循思维从发散到抽象到具体的过程。
材料上的准备:
人数:Design Workshop 人数以 8-15 人为宜,鼓励在角色上更加多元,除了产品设计师以外,运营、工程师、BD 等角色都可以参加。
场地:场地需要有容纳 5-7 组桌椅,确保成员可以在方案设计环节无障碍分组,进行写纸条和绘制线框图。
物料:每个成员有至少一支马克笔,一本 N 次贴,3-5 张 A4 纸,场地内有一块大白板,PPT、投影仪和计时器看情况选择。根据分组情况准备 5-7 个白板。
(点击原图清晰大图)
在动手之前,需要每个参与者对今天设计的命题以及设计流程做足够的了解。俊煜分享了他理解的设计方法论:
第一,需要对问题做一些了解;
第二,在命题中寻找机会;
第三,设计方案,对命题做一些验证;
第四,对方案做一些迭代,完善方案。
衡量设计的好坏可以从三个角度去思考, Desirability(用户渴求)、Feasibility(技术可行性)和 Sustainability(商业可持续)。好的 Idea 应该实现这三者的交叉。
当天的设计环节分为三个部分:
第一,学习小程序。俊煜邀请了轻芒联合创始人、前豌豆荚技术负责人范怀宇,以及有可能学院 CEO、知名博客「可能吧」的作者阿禅(Jason Ng )分享关于小程序的想法,参与者会基于他们的分享,加深对小程序的理解。
第二,找小程序的机会和设计解决方案。避免大家 Brainstorming 的过程太零散,花费更多的时间,俊煜会尝试用结构化的方法带领大家完成 Brainstorming 的过程。
第三,交付解决方案。这次我们准备了足够的便利贴和白板,鼓励大家把解决方法用视觉化的方法展示出来。由于时间关系不能做用户测试,我们这次会尝试做一次有效的设计评审。
▌寻找正确的问题
设计是创造性地解决问题的过程。而比解决问题更重要的是找到正确的问题。
什么是「问题」,什么是「解决方案」?
发现问题和解决方案是两个不同的含义。很多时候大家都会忽略明确问题的这个过程直接跳到解决方案上。
俊煜举出的问题是「飞机上的熊孩子很吵」,大家当下反应出的解决方案:去批评熊孩子让熊孩子闭嘴、或是去和熊孩子的父母理论。设计的方法应该是找到问题背后的「机会」,这样就会重新定义问题,比如:「我想在飞机上休息,HMW(How might we) 让熊孩子不吵到我?」。经过这样 HMW 对问题重新定义之后,一副好的降噪耳机也许才是更好的解决方案。
今天大家尝试提出正确的问题,不急着给出解决方案,而是用 HMW 提出其中的机会。
无拘无束地提出机会需要遵循几个规则:
不对别人的 Idea 有 Judgement。大家在提问题的本质是为了找到最有价值的 Idea,要用 「Yes, and」 的积极心态看待别人的 Idea。
数量大于质量。整个过程中追求尽可能多的 Idea。
鼓励狂野的 Idea。也许最后正是这些狂野地想法产生了更多的可能性。
不要害怕借鉴别人的 Idea。在 Brainstorming 环节中借用团队 Idea 做一些改良,是被允许的。
鼓励把 Idea 图形化。我们只准备了粗笔,希望大家把 Idea 写得尽量简洁。
▌从小程序的分享开始 Brainstorming
小程序是一个新的技术,发展阶段还比较初期。
根据「创新扩散理论」,俊煜用用户群的概念*把用户分为职业鉴赏家、专业发烧友、业余爱好者、匆忙路人甲和围观群众几种类型,定义了我们要影响的人群会是专业发烧友和业余爱好者。这类人群的特点是不抗拒使用新的东西,但并不会为了尝鲜而尝鲜,只有这个功能真实有用,他们才会愿意继续使用。
俊煜分享了一些过去公开的研究成果,引导大家用 HMW(How Might We) 来表达小程序的机会。比如对于大多数安卓用户来说,装很多的 App 意味着手机不安全、遭受推送的骚扰和手机变卡,所以他们会减少 App 的安装;对 iOS 用户来讲,16G 大小手机占用户比重比较大,而这类用户相对喜欢尝鲜。
接着每组参与者轮流分享大家在体验不同小程序时发现的好用的小程序场景以及用法,大家在交流中继续寻找新的机会,做更多 HMW 的提问。
经过这一轮相互启发之后,大家手里的 HMW 渐渐多了起来。接下来范怀宇给大家分享了小程序的技术特点和可行性,可以从以下几个层面开始思考小程序的机会:
交互:小程序在可行性上目前能做出什么样的东西
设备:小程序对手机设备有什么样的权限,可以获得哪些信息
微信服务:小程序寄附在微信当中,可以从微信得到什么样的功能
获取和回流:小程序作为比较新的产品,和其他传统产品的区别
阿禅为大家分享了他在小程序商业机会的思考。阿禅在业界首先提出了微信小程序从线上链接线下场景的方向,成功的小程序应该做到即用即走,提供与线下场景特别相关的服务,更好的利用还没有被开发的用户流量和用户时间。如果这个使用场景还具有可传播性,整个环节将会更加完整。
大家与阿禅进行了长达半小时的 Q&A,对于一些与服务号的区别、特定的服务场景以及小程序的生态进行更深入的提问,在交流过程中大家产生了更多的场景可行性的想象。俊煜根据范老师、和阿禅的分享,把用户体验做了更准确梳理,做了更完整的用户体验地图。
分享环节结束,白板上已经贴了近百个 HMW 的提问。接下来大家对这些 HMW 进行分组,整个过程大家只看展示不做任何交流和引导,基于自己的理解对机会进行分组。分类的过程不必要求完美,遇到不理解的 HMW 就放到一边。大概十分钟的功夫就完成全部的分类。
接下来大家用一开始准备好的小圆点对分类之后 HMW 进行投票和决策。所有的成员可以根据自己的理解给这些机会投票,每人有三张贴纸,如果大家认为一个问题非常值得解决,可以投多次来体现问题的价值。当主持人把票数最多的几个 HMW 转移到用户地图的对应位置时,大家就可以很直观地看出在哪些环节,潜在的问题或机会最多。
每一个小组基于用户体验地图,对每个机会的入口、分享等环境进行了一些思考和讨论。从用户需求角度出发,每个小组认领了一个问题。
每个小组又明确了一次小组想要解决的问题。这个时候只需要明确需求的场景和问题,而不需要给出具体的解决方案。这里的句式是「如何解决什么场景下的什么问题」。
到现在为止,大家已经完成了「前期立项」的工作。
▌总有更好的解决方案
每个小组把自己认领的问题明确地写出来,尝试用 Brainstorming 的方法设计解决方案。这个过程需要大家的思维不断发散再收敛,从「问题到故事板」的过程要进行至少三次发散收敛的过程,这样做出来解决方案会更加经得起推敲。
第一次,围绕着问题写出 Idea。一开始可以根据直觉画出一些 Idea,这些可能是零散的,不成体系的。
第二次,每个人整理出一个成体系方案。这个环节大家可以用粗笔来画,回避很多设计细节。
第三次,小组成员一起设计出一个更加完整的 Story Board。把用户使用小程序的过程画出来。它可以是一个界面,可以是某线下场景的整体流程。
第一步大家要在组内榨出足够多的 Idea。我们准备了一些 A3 的纸。每个人有 16 分钟,每隔 4 分钟画出来 4 个 Idea 贴在纸上,然后传给右手边的同学。每个同学需要先理解一下上一个同学的 Idea,然后再画出 4 个 Idea。这样每组可以得到 4 × 4 × 4 个 Idea。
由于时间短,鼓励大家依靠直觉,思维尽可能得发散。强迫自己在规定时间内把 Idea 画出来。可以是对整体系统的 Idea,也可以是某个环节上的 Idea。不用担心 Idea 跟其他同学是重复的。
接着大家用分类和投票的方式对 Idea 进行整理。大家安静地把每组 64 个 Idea 进行展示和分组,然后进行不限次数地投票。标记出 Idea 的设计细节或者方案中亮点。不限次数的意义在于,可以在 Idea 中画出热点图。
完成了 Idea 的整理和投票后,每个人有 5 分钟的时间按照自己的喜好把每个环节串进去,画出更系统化的方案草图。这里的保真度需要做到用简单的三屏草稿纸来描绘「用户是怎么进入到这个小程序的」、「用户做了什么动作」、「用户得到了什么结果」。这里每个人应该思考更多的应该是流程的完整性,避免陷入具体细节钻牛角尖。
每个组产出四个方案草图,大家在组内继续对这个四个方案草图用小圆点贴纸进行投票和讨论,不但要投出喜欢的方案,还要去贴具体喜欢哪点设计。之后大家就可以从大家最喜欢的部分里提取出产品的 Story Board。
做方案设计的过程中小组成员难免会遇到分歧。当组内的成员对于将要形成的故事板无法达成一致时,俊煜给小组分别引导,用一些方法*帮助大家走出设计的僵局:
第一个方法是再收敛。很多情况下,有争议是因为组员的背景信息不同,导致大家心目中的场景设定、目标用户有偏差,给出的解决方案不能互相认同。这时就需要将命题进一步收敛到一个更加具体的要解决的问题。比如说有一组认领的命题是「HMW 让用户更好的完成医院的就诊流程」,大家会先将这个命题的场景缩小到「去一家普通三甲医院看病,可以挂得到号,各环节排队人很多」这样的背景,在此基础上再去各自设计方案,大家的思路就不会偏差太大。
第二个方法是引入决策者。当无限次投票等方法没能产出结果时,可以引入决策者来拍板。决策者需要从各个角度理解大家的立场,做一个综合考量再做出决策。
▌对设计方案做有效的评审
「设计评审」的环节有两种方法,一种是大家去看别人的 Idea,然后投票点出自己最喜欢的点。这样做的目的不是选出设计最好的方案,而是找出方案中的最好的部分然后继续细化。
这次俊煜选用了 Thinking Hat 的方式对设计方案做评审。首先每个小组展示自己的故事板,展示之后其他参与者有 15 分钟的时间可以分别从 User Advocate(用户),Optimist(乐观主义者),Pessimist(悲观主义者),Feasibility(技术可行性),Idea Generator(点子大王)这五个不同的角度提出意见,给小组团队更多的反馈。
在这个过程中,大家给出了很多有趣的评审观点。比如「去一家普通三甲医院看病,可以挂得到号,各环节排队人很多」这个场景,原本设计的结果分享给家人,现场同学以 Idea Generator 地角度评价说可以把最后一步设计成为众筹,一方面帮助患者解决了费用负担问题,另一方面为医疗捐助做了可信验证。
通过 Design Workshop 的方式,我们能够快速、准确地整理出一条正确的产品设计方向。但在实际进行产品设计的过程中,我们需要把产品实现出来,通过用户反馈,迅速反应和调整,对产品进行一次次迭代。经过下午三段发散到收敛,大家都拿出了保证度相对比较高的解决方案。最后大家把活动的感受和疑问都整理出来贴在了光涧的白板上。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。