体验设计师可以改进的5个习惯

by Zichuan Xiong on May 13, 2012

周末参加了UXDAY2012的活动即Designing Shanghai2012,活动的过程是去中山公园观察公园里的老人,以及探访老人之家,寻找到可以设计可以帮助老人建立更好生活体验的地方。活动很精彩,在整个过程中我也发现5个体验设计师可以改进的习惯,这里我总结一些我的方法和经验,希望给大家帮助。

用户情境观察的结果是感受或结论,而不是事实

活动第一个环节是去中山公园和老人之家观察老人的行为,回来以后我们将收集的信息展示在黑板上。我看到了诸如“消极和悲观”、“孤独”、“希望社交”、“热衷于被关注”的信息,而在我看来这些信息都不足以成为建立情境所需要的高质量的信息。

体验设计的第一步是建立一个尽可能真实的情境,在这样的情境中才可能产生尽可能真实的问题(problem),于是一个真实的情境需要真实的素材来构建。当你说“老人们热衷于被关注”的时候,你是基于什么有这样的结论──我们需要一个真实发生的故事。

对于“热衷于被关注”这一点,我也有类似发现,而我更多是表达一个“故事”:领头的老人会把报道他们的报纸叠成豆腐块,随时揣在口袋里,拿出来说给关注他们的年轻人看。这是一个“故事”,而不是一个“推断”。

情境应该基于“故事”,而不应该基于一个武断的“推断”,有足够多这样真实的故事,就可以让我们的情境变得更加丰满,因此而发现的问题或机会,就会变得贴和用户的需要。

如果可能的话,把这些小故事用草绘的形式(或照片)表达出来,贴在墙上,布置一个情境房间,在房间里进行设计。


这是一个在参加Service Design 2012 Melbourne看到的案例,把所有拍摄到的“故事”贴在一个模特的周围,布置一个情境房间。

用自己的感官感觉替代用户的感官感觉

在老人院的时候,作为有优越生活的一群人,我们不自然地对整个环境有了一个先入为主的判断,在头脑风暴时,很多人的发现是“缺乏幸福感的环境”、“潮湿阴暗无助”、“缺乏对社交的帮助”等等。


很多对环境的感官感觉是主观的结论而非基于一个真实的故事(insights)

也许有老人也是这么想,但是作为用户和情境的研究者,我们不能用自己的感官感受来代替使用者的感官感受,在这里,我们同样需要各种各样的故事去支持这些感官的评价。

人对情境的感官感觉来自于对周边每次互动时的反馈。于是我们需要思考的是老人与整个环境的互动,例如:走道的扶手;洗手间的扶手;灯的开关;床;轮椅;门以及门的扶手;座椅等等,这些就是交互触点(touchpoint),对所有触点的整体体会才构成了对整体情境的评价。

而我们作为设计师,第一次来到这个环境,对整体情境的评价只来自于视觉、嗅觉、以及与以往经历的比较,而没有亲身体会那些老人们每天都在接触的交互触点,那么我们的感官判断是不准确的。

对现在的解决方案不敏感

发掘用户问题最好的方法是去研究现有的解决方案,因为绝大部分情况,只要还在使用的解决方案,背后一定有一个被解决或解决不好的问题,研究他们,自然能够挖掘出真实存在的问题。

而我观察到我们很多人的方案更多还是与老人们直接沟通,问他们有什么问题,感觉怎样,而对现有的解决方案并不敏感。并不是说这种直接沟通不重要,而在于对于现有解决方案的了解有助于理解用户当前真正的需要,有意思的是,用户大部分情况会因为习以为常而忘记他周围常用的工具到底解决什么问题。

因为时间有限,我观察了一个老人身边现有的一些解决方案,例如,健身器材,我看到因为在户外,健身器锈迹斑斑,有一个老人来锻炼的时候,还需要另外一个人帮助她抓住有些高的把手,注意,这些都是观察结果,要做的只是忠实记录,而不是做判断;其他的解决方案还包括报警器、每日的药盒、电视机和遥控机、纱门等。


这些是我拍摄的部分解决方案,每个现有的解决方案背后一定有真实存在的问题正在被不同程度地解决。

如果时间充裕,我们应该对老人周围所有用到的解决方案进行一个完整的分析,分析结果应该包含每个解决方案应该解决的问题,有什么使用困难(改进点),各个解决方案之间有没有联系(创新点)等。

这个解决方案图谱完成之后,相信你就会对目标用户有一个完整的认识,当然,了解解决方案的最佳方式是亲自体验。

还没想清楚为什么这样,就开始想为什么不那样

我看到最严重的问题是对解决方案的痴迷。在我看来,有创造力的含义是发现和定义一个用户真实存在问题,甚至不是解决了这个问题──发现和定义问题是一切设计的核心,当你发现了问题,最有本事的事情是用一个现有的东西去解决而非重新创造。

这种痴迷体现在还没想清楚为什么是现在这个样子,就开始想为什么不那样。当我们谈老人院的时候,在我们还没有想清楚,这个我们看来“阴暗无助充满社交阻隔的地方”为什么是现在的样子前,我们马上就开始思考如何把这个地方变得“幸福活力阳光充满欢乐”。

这件事的核心在于还没确定这是个问题就开始尝试解决问题,那么在我看来,这是承担巨大假设风险的。在进入解决方案的讨论前,应该明确的是两个问题:一是这是不是一个问题?二这个问题是不是我们应该最先解决的?如果这两个问题没有被很好的回答,除非运气极好,最后的结果无非是解决了个根本不是问题的问题,或者解决了不该现在解决的问题。

不愿意做小

很多人热衷于颠覆性的设计,而不愿意做小的改进,把创造等同于创意。我对这个问题的理解是,当你没有很好定义出典型用户、场景、和他们在场景中遇到的具体问题,而是用一个宽泛的断言代替设计方向,那么设计就会变得巨大。

如果你的设计挑战是如何让老人变得快乐,你设计很可能变得漫无边际;而如果你的设计挑战是如何让在中山公园组织老人活动的老王更好地宣传他们的社团使得更多人参加,你的设计就可能变得实际和具体。

也许有人说,那么你设计的东西就会变得狭隘,这是限制创新,其实并不是,当你深入到老人的情境中,梳理出更多基于真实故事的设计挑战,例如:如何让老人院的张爷爷记住自己喜欢的电视节目;如何让他锻炼自己的手指头;如何鼓励中山公园的社团参与者更多资助社团活动等等,这一系列小的设计挑战被解决以后,自然是整个体验的提升,自然是一件大的事情。

体验设计中把设计环节需要的心智模型(mentality)定义为“可实现”(rationality),而把发现问题环节定义为“创造力”(creativity)确实不无道理,创造力应该体现在发现具体问题并转化成具体设计挑战的过程中,而设计过程应是切中要害,最忌天马行空,没有商业和技术支持的设计不产生任何价值。

说多过于画

在表达解决方案的时候,我仿佛回到了H公司的需求讨论现场,要么所有人都在说,要么只听一个人说,其他人不敢说,没有人使用任何可视化的工具引导讨论,后来我画了几张关于解决方案的草图才让无休止的讨论回到正轨。

这就是为什么我们更加注重视觉引导的能力──如果可能事先把设计过程的框架用视觉化的方式搭建好;尽可能地使用白板,持续不断地把已经达成一致的东西写在白板上;更好使用贴纸的颜色,及时对信息进行组织和验证;对同一个设计挑战分组进行草图设计并展示,避免设计被那些口才好,强势有气场的人绑架


图中右下角是我们最后的故事板,添加了一些草图后使得沟通更加有效率,其他两副图展示了我们做workshop的时候推崇的过程可视化的场景,大量使用草图、白板、并随时将过程产物贴在墙上。

写在最后

我能理解这样的活动不需要太多条条框框的设计方法进行限制,这只是我的一些思考和经验分享,并不代表大家是不够格的设计师。

 

另外非常感谢techyizu组织这么好的活动,我曾经在牛津参加Design Jam,组织形式类似,它有个环节是在报名时每个人需要提供一个角色:例如designer, developer, 或者strategist等,以保证每个设计团队有足够平衡,供参考。但这个全球性的活动当时并没有用户研究的环节,而正是这个深入用户进行研究的活动真正让我学习到了很多东西,谢谢大家的努力,也希望不久的将来能在北京看到类似的活动。

最后的最后

如果你发现这篇文章实际上是六个习惯而不是五个习惯,那么你真的没有除了上面五个习惯之外,设计师应该改进的第六个习惯:不会数数。无论如何,至少你仔细看了,应该谢谢你。

敏捷体验设计的5个设计工作坊模版

by Zichuan Xiong on April 27, 2012

和以往的那种简单粗暴的“头脑风暴”,或者索然无味的“需求评审”不同,敏捷体验设计中的过程永远是开放的,强调在和客户的互动中识别需求,并产出设计,最终对项目交付内容达成共识。过去的五年里,我参与了几十次和客户的设计工作坊,这里把我经常使用的五种设计工作坊形式分享给大家。

模版1:用户价值定义

用户价值的定义是任何软件体验设计的基础──到底解决了什么用户的什么问题。对于问题的定义越准确和清晰,越能够对产品或特性设计方向达成一致,当所有的客户都认为,解决用户A在情境B下遇到的问题C是本次交付的核心目标,那么自然,与解决这个问题之外的任何设计、功能、甚至讨论都应该放入低优先级。这个活动可以经常性进行,可长期保留这个用户价值板,将识别的用户问题放在板上统一进行管理和评价。

过程

  1. 梳理出典型用户放在画板的最左侧;
  2. 头脑风暴出用户可能遇到的问题;
  3. 对于每一个问题进行扩展──什么情境下出现这个问题?问题带来的痛苦是什么?为了解决这个痛苦用户现在是怎么做的?
  4. 将每个问题进行扩展后再对每个维度进行数字评估──情境和问题发生的频度?痛苦程度?和临时解决方案的风险大小?
  5. 总结所有的问题,将数字相加,配合典型用户的优先级,梳理出最应该关注和解决的问题,再进入设计阶段。

元素解释

  1. 用户:谁会遇到这样的问题?
  2. 情境:在什么样的情境下会出现这样的问题?
  3. 问题:如何定义这个问题?
  4. 痛苦:因为这个问题的出现,会造成什么样的痛苦(直接或者间接)?
  5. 暂时解决方案:为了减轻这个痛苦,这个用户是怎么做的?

提示

  1. 尽量避免描述性的抽象表达,而尽量使用基于事实的语言,例如:表述痛苦时避免说“工作效率低下”而说“每天处理不必要的人工错误时间超过1小时”──更加基于事实的表达让设计师更加实质性体会到痛苦本身;
  2. 尽可能生动地表达情境,用简短的关键字描述出该用户遇到痛苦的实际情境;
  3. 使用数字进行估值时使用1,2,3,5,8数列进行估计,首先定义标准1的值,再进行比较,凭感觉;

演示

上图中红色箭头便是具体要进入细节设计的用户问题,当这些问题被解决,所产生的用户价值一定是在当前产品中价值最高的。

模版2:组织改进计划

做产品本身就是在做商业模式,而商业模式的基础是组织运作,在产品设计之前需要对组织现状进行了解,帮助客户寻找到为了达到产品愿景的目标组织级别还有什么地方需要改进,为接下来的产品设计做准备。

过程

  1. 使用“Tomorrow Headlines”的游戏让客户团队对未来产品或组织愿景达成统一认识,将达成统一认识的海报贴在画板的右上角,如演示中右上角所示;
  2. 使用一种运营模型收集对现状的描述(使用名词+形容词的表达),在演示中使用的是,资源-产品-消费者的价值传导模型,可以根据情况选择合适的模型;
  3. 将所有贴条进行归纳分组,梳理出一些维度,例如说:销售资源分配不足可归于“销售资源”维度。对每个维度使用滑块进行竞争力评价,越往右说明竞争力优势越大,越往左则反之;
  4. 找到竞争力最差的维度进行单独讨论,这些维度就是阻碍我们达到共同愿景的绊脚石;
  5. 对每个绊脚石头脑风暴出行动列表,在一定时间内进行改进,并制定责任人,定期进行反馈;

提示

  1. 这个活动可以用于任何级别的组织,只是愿景不同;
  2. 对于模型的使用可以自由抽象,大部分组织行为都可以抽象成,资源、活动(服务或产品)、服务对象、反馈等;
  3. 定期(每两周)对实现愿景的行动列表进行展示或验收,及时收集反馈,持续改进;
  4. 行动应该是准确和结果可验收的,“和销售团队达成对销售支持人数4人的共识”要比“找销售团队要人”要明确得多;

演示

模版3:客户体验地图

从客户(Customer)的角度出发,定义客户在完成用户目标过程中经历的步骤,在情境中发现客户的痛点,并将痛点转化成设计挑战,为接下来的设计活动做准备。在完成设计稿之后,从设计中梳理出来的用户故事也能被完整地展示在图板上,给团队完整的上下文,了解每个用户故事都是在解决哪个典型客户的什么问题,优先级也一目了然。

过程

  1. 将梳理好的典型客户放在画板最右边;
  2. 梳理出对于这个客户存在的用户目标;
  3. 用贴条展示出客户现在完成用户目标过程中经历的步骤;
  4. 在心情曲线上将所有步骤串联起来,心情越好贴条贴得越高;
  5. 分析心情最不好,即贴条位置最低的几个步骤;
  6. 对每个位置最低的步骤,梳理出设计挑战,尝试为客户解决其中的问题;
  7. 对设计挑战进行优先级分析,建立设计挑战墙进行设计;
  8. 将设计草图贴在设计挑战周围;
  9. 从设计草图中梳理出用户故事;

提示

  1. 从最核心的用户类型开始;
  2. 心情最低落的位置代表这个步骤中存在一个问题;
  3. 最完美的情况是寻找一个和典型用户最匹配的真实客户一起参与到这个活动中来;
  4. 有大量关于客户体验地图的资料可以参考:例如这里

演示

模版4:产品全景图

这个实践帮助我们在全局的角度了解一个产品的全局,产品的目标用户是谁?提供的核心用户价值是什么?这些价值通过产品的哪些特性进行交付?产品背后的资源是什么?限制又是什么?各个元素之间是否有不匹配的情况?

好的产品规划是用户价值、功能特性、目标用户的完美结合,这个实践帮助我们发现那些不匹配的东西,例如目标客户不需要的用户价值;不被现有资源支持的功能;不能交付用户价值的功能;或者交付多余用户价值的功能。此外,这也可以成为每一个新特性的实验场,每个新功能都应该放在全景图中进行验证──背后的价值是否和目标用户契合?现有的资源是否支持?当前的限制是否使得其成本过大?

过程

  1. 梳理出产品的目标客户,放在画板的第四栏;
  2. 梳理出产品提供的核心用户价值──产品解决用户什么问题?放在画板的第二栏;
  3. 梳理出产品的核心功能──那些用户价值通过什么功能进行交付?放在画板的第三栏;
  4. 梳理出推动产品不断交付用户价值的资源放在画板的第一栏;
  5. 梳理出阻碍产品不断交付用户价值的限制放在画板的第五栏;

提示

  1. 任何一个新需求(无论以问题出发还是以核心功能出发)都应该放在全景图中进行验证──是否有足够的资源支持?限制会不会过大?是否有明确的目标用户?是否解决用户的问题?
  2. 可以在图中选择一些应用的界面放在核心功能栏目中给团队更多的上下文;
  3. 体现核心用户价值和核心功能间的关系;

演示

模版5:产品演进策略

产品的核心在于吸引用户、留住用户、和将更多用户转化为利润。基于一个已有平台的产品无外乎三件事:其一,如何通过平台从其他产品中获得更多用户,以及如何为平台其他产品提供更多用户;其二,如何提供更好的用户功能体验,留住更多用户;其三,如何提供更多的用户价值,提高用户价值到商业价值的转化比率。

这个产品演进策略工作坊的目的就是在这三个方向寻找到创新点进行演进,创新的三个方法是:和现有平台更好互动,利用现有平台其他产品作为获客渠道;提供更好体验留住用户;提供更多用户价值,使产品增加潜在商业价值。

过程

  1. 将平台上其他已有产品放在画板的最左边;
  2. 在画板的右侧做一个坐标,横轴是更多的用户价值,纵轴是更好的功能体验;
  3. 在横轴基础上识别出目标客户全体验上的价值诉求,以一个汽车险潜在用户为例,他的价值诉求是:调查车、咨询车、决定、购买车、调查险、咨询险、决定、购买车险、出事故、理赔等;
  4. 在纵轴上对识别的价值进行覆盖,哪些功能覆盖了这个步骤的用户价值?
  5. 将现有平台的已有产品进行关联,如果产品A中某个功能对当前产品某个用户价值可以吸引客户,将这个产品卡放在左侧并用箭头表示客户转移,反之亦然(参考第二副图);
  6. 头脑风暴出可能的创新点(体验增强或价值增补)用粉色卡片贴在对应的位置;
  7. 对创新点进行设计,并将设计草图贴在创新点周围;
  8. 将创新点的草图设计转化为真实设计并进行用户测试,充分了解用户的诉求,最后进行交付,实现产品的演进。

提示

  1. 现有产品往往最好的获客渠道,在制定产品目标时也需要考虑未来现有产品中消费者的相互营销;
  2. 这个环节的下一个阶段是对设计的验证过程,在真实消费者环境中验证假设,然后进入交付,实现演进。

演示


总结

这次我们总结了五种我作为体验设计师经常使用的几个工作坊模版,每个工作坊都强调互动性和持续性,而非简单的头脑风暴。一个合格的敏捷体验设计师应该融会贯通每种设计工作坊背后价值,在实践中锻炼引导客户的能力,真正让设计成为合作开放的过程。如果想了解更多内容,例如说这里用到的ppt模版,请通过新浪微博“一只土贼”和我联系,希望有更多志同道合的朋友加入我们。

敏捷体验设计师具备的5种思维模式

by Zichuan Xiong on April 23, 2012

这篇我想写得散文些,篇篇都写成软文也不是个事儿。

我们有个香港的设计师哥们,整体穿着裙裤,Nike Airforce的珍藏版,一开口就是:满他力体(Mentality)我打算给翻成思维模式。他的意思是,设计师需要不太一样的思维模式。我就在思考这个问题:到底一个敏捷体验设计师需要些什么样的思维模式?

共情Empathy

共情的话题曾经在这篇博客中提到,核心观点是你得明白,作为一个设计师,你基本没有为自己设计的可能,而你所面对的未来用户,可能跟你想的完全不同。

共情设计(Empathic Design)广泛用于广告或者工业设计领域,例如下面这张David Bowie的宣传海报,这位上世纪80年代的摇滚符号性人物涂抹非洲土著油彩,有着强烈跟随效应。

而在商业领域,共情设计充分体现在为目标消费者所处环境的专门定制,例如在菲律宾,东芝电视机的销量不足,是因为菲律宾人通常喜欢在客厅里看电视,睡觉前又把电视搬到卧室睡前继续看,减轻电视机重量以及增加把手的坚固和舒适度便使销量立刻反弹,这就是共情的设计。

而共情本身是成本巨大的,如果不在四大会计所工作过,就不知道他们的显示器大部分都是竖置并两个并排,更不会知道他们讨厌分页;如果没来过中国的菜市场,就不知道讲价这件事情是生活方式,不能讲价的百思买就不会那么快输给苏宁国美;如果没有在中国传统社区成长,就不会知道中国曾经的小区是没有咖啡店、便利店、后院义卖会这种东西,风靡世界的CityVille在中国就不会有这么多麻烦。

花一年的时间做用户调研越来越难发生,除去可以被固化的实践(不在这里展开)还更多靠知识补全,而知识可以来自于文化的间接传播,或来自于直接的生命体验,前者我指读书,后者我指旅行。

放下那些教程或者所谓的用户体验设计的经典,读文化、历史、游记、和风俗史,有一些东西,积攒多了就能发酵,孕育出共情;看看这个世界,就呆呆地看着,看人的着装,争吵的样子,每个细节和动作,也许有天都能让你绘声绘色地跟你的客户描绘他们所在的世界,在这样的世界里客户和你才能挖掘出消费者真正的需要。

好奇Curiosity

当你构筑一个足够的共情世界后,是什么驱动你发现那些也许你的客户看起来不是问题的地方?是你的好奇心。

保罗本耐特(Paul Bennet)同学是IDEO的一位设计师同志,他把他的博客叫做好奇编年史,在这个博客里记录了关于盆栽、伊卡特针织、人类对于超级大树喜好等等;Localhost同学是ThoughtWorks的一位设计师同志,她的博客里同样记录着关于冷笑话的设计模式、尿钟法的可行性、以及站在巨人肩膀的诡辩,就像下面这个关于衬衫位置的问题:

他们一位是巨子一位是妹子,可对于好奇心这件事情却出奇的一致──在看似平常的世界中看到不一样的东西;他们总是用另外一只眼看这个世界,创新的闪念有时候就存在于这种不循规蹈矩、打破常规的习惯。

好奇心同样帮助你在客户的情景中,发现他们也许不认为是问题的问题──始终把你的好奇心体现在下面这两个问题上:

  • 这样做是解决什么问题?
  • 不这样做有什么麻烦?

当然,或许你就不能有自己的好奇心,很多地方,这被认为是越权或者不愿意执行的借口。

如果你生命就是延续着各种老大们的宿命,已经厌倦了当你好奇问为什么时他们“无条件执行”的回复,请把你画了千百遍的原型图丢在他们脸上,一字一句地告诉他们:我他么也能有好奇编年史。

现实Rationality

你确定你能分的清设计和艺术的区别?设计的本质是一种解决方案,一个解决方案应该有的基本元素是:第一问题能被解决,第二它的总成本应该比不解决的总成本低。艺术的本质是一个情感诉求,一个情况诉求应该有的基本元素是:第一表达了情感,第二诉求能够被帮人听见或理解。

恐怖的是,好多人只表达了情感,甚至都不在乎是不是被人理解,更不要谈解决了问题,以及成为一个方案。

我听过最让人毛孔悚然的“设计师”反问是:“你有什么权利拿实现困难剥夺我们设计师创新的激情?”──那个场景,就好像瞬间看见程序员的怨念投射在背后墙上,隐约现出个“日”字。

为了满足你说的创新的激情,可以选择蓄起胡子,若你愿意把自己归于设计师一类,请挽起袖子。

灵活Agility

我说的是做软件不是建大楼,你没有办法避免变化,而你的身价就来自对变化的应对能力。这样的能力无非体现在:做正确的变化;成本更低地进行变化,于是逻辑上这包含两件事情:

  • 真正做到影响客户,左右客户的变化,减少不必要的灵活。简单的策略是:成本和价值,客户提变化你觉得没理由,你要主推成本,弱化价值;你主推的变化你要主推价值弱化成本;谈成本时多考虑业务成本,IT成本说服力最低,因为跟你客户无关;谈价值时多考虑“不作为成本”,即如果不做这个变化造成的损失;
  • 降低你变化的成本。简单的策略是:尽可能使用轻量的软件表现设计,多使用草图,如下图,反复确认的方式减少假设;尽可能让更多人(甚至客户)更早参与设计过程,尽早的挑剔总比最后集中挑剔要好;尽可能在每个层次上(策略、内容、架构、交互、视觉)分别达成一致,尽早进行演示。

你需要接受的观点是:设计是个生命体,不是一蹴而就也非一陈不变。而设计正在灵活生长的过程,需要你用开放的心态去看待它,即不盲从于别人的观点,最终成为缺乏灵魂的东拼西凑,也不过度保护自己的意志,期待独自(埋头)完成一个足够视觉完美的设计,使得所有人不会挑剔。

验证Measurability

设计的不确定性体现在:策略的不确定──应不应该做以及做什么;结果的不确定──做得好不好。前者的不确定影响我们做正确的决断;而后者的不确定影响我们越做越好。对与前者的关注决定了一个设计师的领导和决断力,而对后者的关注决定了一个设计师的学习能力。

策略的不确定性主要体现在下面两个方面:

  • 怎么确定我设计的产品用户会使用?
  • 怎么确定我设计的产品值得投资?

对这两个不确定性的思考,决定了设计师的高度。从这篇文章里可以看到卫哲作为一个设计师的高度,卫哲3+1的理论本身实际上是对前两个不确定性的验证:带来什么样的用户价值;以及值得不值得投入。参考卫哲的3+1,这两个种不确定性应该问的问题是:

  • 解决谁的什么问题?有多少人有这个问题?他们有多痛?现在是如何解决的?
  • 解决用户的问题后在网站数据中会产生什么变化?

而结果的不确定性主要体现在:

  • 用户能不能完成一个用户目标?
  • 用户的完成过程是不是满意?

对与这两个不确定性的验证,主要通过演进式的原型测试,或者基于产品用户行为数据的度量,虽然这是一个广泛使用的实践,但大部分设计师不参与后期的演进,主要由产品经理完成。

我具备这些思维模式吗?

请自评下面这五个描述:

  • 我具备想象一个真实场景到到官能兴奋的地步,比如说傻乐、频繁点头、流口水等;
  • 我总是觉得我的关注点很奇怪,十万个为什么;
  • 我真正把东西做出来过,哪怕是手工;
  • 我不怕把还很丑的东西拿给别人看,愿意在别人注视下做事情;
  • 我更关心东西是不是有人用和赚钱,其次才是漂亮;

觉得满足这五种描述的同学,请我联系,你可以选择我请(不是请我!)吃将太无二、金钱豹、杰斯汀、大董等。机会难得,先到先得哟。

敏捷体验设计师应该具备的12项技能

by Zichuan Xiong on April 16, 2012

Agile UX和传统瀑布式UX不同之处在于它与交付过程的强关联,对于人的要求也更加全面,这也意味着你将改变你曾经绝大部分时间只在角落里做一件事的习惯,你被要求更加开放和学会合作,而从技能交付出发,在策略(Strategy)设计(Design)和研究(Research)三个方向有12种技能需要掌握。

策略层

和以往不同,你将会面向你的客户,而不是你的产品经理,你有足够的时间陪伴着你的客户,倾听他们的需要,不,更多地是帮助他们具象化他们的需求,形成产品设计方向的共识,并最终形成交付可行的计划。为了达到这一点,你需要以下4种技能:

讲故事(Storytelling)

你的目标是让客户达成对设计方向的共识,这个过程的效率取决于你对客户想法把控能力的高低。Empathy(同理心)是将客户不同想法归于统一的常见方法──把客户引入到同一情境之下,在情境中思考和做出绝断。那么,情境的建造就成为引导客户的首要技能。我们把这个情境的建造过程叫做“讲故事(Storytelling)”。

讲故事的方式有很多种,例如:

  • 视觉沟通(Visual Communication):视觉沟通是使用图形化的互动方式将沟通过程在白板和Flip-chart逐步展现出来。
  • 故事板(Storyboarding):使用大型白板,将一个完整的故事完整地展示出来,让所有人了解一个典型用户在完成不同用户目标完整的所有步骤。
  • 草图(Sketching):使用草图的方式来描述一个用户问题,或者一个概念性的解决方案,尽可能生动地让客户体会。
  • 讲演(Pitching Presentation):用讲演的方式将故事的前因后果完整地进行表达,让更高层级或者未参与的客户了解项目启动的背景,增强客户信心。

this is an example of visual facilitation
这是一个使用视觉沟通的例子

this is story board
这是一个故事板的实例


使用草图的方式表达消费者可能遇到的问题,这个是Localhost同学的草图本

journey-map-to-pitch-client
使用高质量的文档表达项目背景

概念模型(Concept Generation)

在充分理解问题和背景知识之后,你需要带领客户和其他设计师进行概念模型的建立。概念模型的建立过程通常是:

  • 在完整的消费者情境中寻找设计挑战,例如:如何能够让我第一时间获得航班变更信息?如何能让我避开高峰选择最合适的路线前往陌生城市的机场?
  • 对设计挑战进行优先级排序──哪些是当前影响消费者最严重的挑战,哪些是最能获得消费者青睐的。
  • 使用Five Sketches的方法,用五张草图表达对某个特定设计挑战的解决,分组展示,找出最受欢迎的亮点。
  • 综合各种设计中的亮点,绘制出最终的概念模型草图并展示。

sketch-a-concept
使用草图的方式绘制一个解决方案

sketch-board-to-integrate-conceptual-design
这是小爱同学的面试作业,用各种草图设计表达概念模型,天生的好材料

概念模型的建立过程应该是开放的,并避免由于过于精细的设计而导致的设计权威问题,设计是综合所有人(特别是客户)意见和灵感的过程,而非一家之言。

战略策略(Strategic Envisioning)

客户往往什么都需要,一个好的体验设计师除了需要充满想象力的设计灵感和必要的逻辑思维之外,还需要在战略层面上,通过帮助客户建立一个战略层次上的事务优先级机制,建立产品演进的路线图,引导客户在正确的时间做正确的事情。

最简单的一套战略策略实践是VGA:Vision, Gap, Actions.


这是一个使用VGA进行战略分析的实力,通过在资源、生产、产品、消费者接维度对现状进行评估,产生改进点

  • Vision: 了解对未来的愿景,这里的实践包括:Tomorrow Headlines, Product Box, Speedy Boat, Hot Balloon等等,通过互动的方式帮助客户对未来达成共识;
  • Gap:为了达到未来的愿景,通过在资源、生产方式、产品、消费者关系、消费者几个维度上对现状的评估,寻找到现实和未来之间的差距,并寻找到最应该被及时缩小的差距作为改进点;
  • Actions:围绕差距分析中被总结的改进点头脑风暴出可以执行的任务,每项任务应该结果导向,充分具象并可测试,指定责任人在一定时间内进行改进,并定期回顾。

交付计划(Delivery Planning)

体验设计师往往是项目交付的灵魂之一,这也体现在其对整体交付内容的把握。你需要时刻坚守M.V.P(Minimum Viable Product)的原则,尽可能引导客户缩小第一个交付的范围。在这个过程中你需要用到的实践例如:

release-planning-story-wall
展示不同交付阶段的最小交付范围

  • 用户故事识别:在完整的客户体验地图(Customer Journey Map)中识别出最基础的用户故事(Backbone User Stories)用于建立起整个交付的骨架;
  • 用户故事评估:带领开发人员进行用户故事的复杂度评估(后将另撰文描述如何进行项目启动时的工作量评估);
  • 交付计划设计:通过采用盲估团队能力的方法(Gut Feeling Velocity)设计出估计的交付计划。

这部分的实践有时也由BA(Business Analyst)完成,体验设计师也会全程参与。

设计层

这个层次的技能是传统用户交互设计师基本具有的,Agile UX鼓励融合的设计过程,这也是为什么我们反对在一个技能环节完全简单重复(这里是wireframe做到死、做用户研究做到死、切图切到死的苦逼通道),而期待更多的技能重合,将职位模糊,使设计过程更加开发和透明。为了达到这一点,你需要以下五种技能:

内容策略(Content Strategy)

你的目标是和客户一起对当前客户以存在内容进行梳理,了解目标用户对于内容的需求,制定合理的内容发布机制,工作内容甚至还包含Taxonomy的梳理和设计,内容文字风格的确定。确实有这样的项目存在对这部分技能的要求,例如英国卫报,实践包括:

  • Card Sorting: 使用卡片的方式进行信息组织和分组,寻找到最佳的信息分组方式,参考这里
  • Search Query Analysis: 分析在现有产品上用户的搜索行为也可以了解到用户对信息的需求分布情况,可参考这里
  • Site Map: 设计网站地图建立起站点级别上的内容组织,最终对内容分布达成一致;

信息架构(Information Architecture)

信息架构是在页面级别的信息组织──如何通过清晰和保持一致的信息组织架构,让用户第一时间了解所处位置和轻易获取所需信息;除了页面内的信息组织,还需要设计信息在不同页面模版间的流动方式。信息架构是体验设计师必备的技能,任何体验必须基于清晰的信息设计和流动,实践包括:

user-flow-with-speech-bubble
使用用户流图表达页面中信息的流动

  • 草图Sketching:之前在概念原型中提到的草图技巧在信息架构中同样重要,现在草图本上进行绘制,梳理思维,第一时间展示,帮助后期继续的喜欢,可参考这个教程
  • 线框图Wireframing:这里的线框图技巧包括Paper Wireframing以及传统意义上的线框图制作,不在乎你使用什么工具(Balsamiq, PowerPoint, Visio, Keynotes, 或者Omnigraffle等等),这可能是最基础的交互设计技巧,当年跟随Marc McNeil靠的就是一手没日没夜用ppt制作线框图的技能,那时候我被称作Wireframe Monkey。
  • 用户流图User Flow:用户流图是从用户的角度出发看信息是如何流动的,用户对所接受的信息如何反馈,下一步的行为会是怎样,整个过程是不是通畅,可参考这里

交互设计(Interaction Design)

a web design sketch board example
一个设计图版的实例

a ui created by balsamiq
使用Balsamiq制作交互设计图

如果说信息架构是“静”的信息设计,交互设计则是信息设计“动”的表现──必须通过用户的操作才能表达和处理信息,而不是简单的结构化表达。交互设计也是传统交互设计师的必备技巧之一,与信息架构的实践类似,其中包括:

  • 设计图版Sketch Board:梳理出核心的用户目标,用草图的方式描述交互过程,在大型图版上进行展示,可参考这里
  • 低保真原型Lo-fi Prototyping:使用手绘草图的方式以目标用户的视角描绘详细的交互过程,可参考这里,或者使用原型工具进行制作,例如Balsamiq或Auxre

前端开发(UI Development)

体验设计师需要了解一定的前端开发知识,保证能在最短的时间内开发出高保真原型进行终端用户测试,往往这个部分的工作由体验设计师和前端工程师结对完成,体验设计师保证设计真正体现在前端代码中。这里需要的技能是HTML和CSS,以及部分简单的流行JavaScript框架,例如jQuery。我们习惯于使用直接手写HTML+CSS的方式制作高保真原型,而不使用Fireworks进行切图,当然殊途同归,工具不是关键。

视觉设计(Visual Design)

具备一定的视觉设计能力能够迅速提升产出物的品质,我们也鼓励在这方面进行培养,不可避免的是,视觉能力是需要长期专业培养才能获得的能力,一个合格的体验设计师,对视觉设计能力要求的底线是“知道什么样子是不好看了,且不能容忍”。


至少不能比上面这个差

研究层

这个层次是传统交互设计团队用研人员和产品经理的技能范畴,一般出现在交付项目的开始和演进阶段,更多关注目标用户群体研究,用户测试,产品演进等方面。研究层技能包括以下几个方面:

消费者研究(Customer Research)

消费者研究帮助客户在项目启动前了解目标消费者人群的基本特征,在其特定情境中充分挖掘用户价值,寻找潜在商业潜力,我们经常使用的消费者研究方法有以下几种:

  • 用户约谈Customer Interview:我们会要求客户在市场上招募典型目标消费者进行约谈,通过用户建模(Persona)和消费者体验地图(Customer Journey Map)的方式挖掘消费者的用户目标(User Goals)、内在驱动(Motivations)以及痛苦(Pains),对于消费者的理解将帮助我们在未来的设计过程中建立其真实的情境,使得最后设计贴和终端使用者;
  • 用户价值挖掘Customer Value Finding:除了用户约谈,我们还尝试用其他方法挖掘用户价值,例如使用社交网络了解目标消费群体对于特定话题都在关心什么,他们对竞争者有什么抱怨或者赞许;社交性的问答网站往往是发现用户价值的宝库,在其中可以看到消费者都在需要什么的帮助,而未来的产品设计能够解决这些问题,便能产生潜在的用户价值;产品本身也可能挖掘潜在价值,例如某个装修灵感收集产品在卧室图片旁边添加一个“想知道这间卧室的风水吗?”链接,通过统计点击链接的情况,了解用户对卧室风水信息的需求程度。

用户测试(User Behavior Research)

敏捷体验设计中的用户测试以按优先级排序的用户目标完成作为主线,并与交付同时进行,随时产出新的设计反馈进行变化,这点与传统瀑布式交互设计者中“需求冻结”的方式截然不同。

测试过程由两位体验设计师和真实用户共同完成,两位体验设计师分布负责引导和捕捉行为,测试环境为高保真的产品原型;每次用户测试的结果都会被总结成新的“设计挑战(Design Challenges)”,例如:如何让用户不再为筛选条件所迷惑;然后根据优先级进行设计,设计过程同样是开发和透明的,甚至邀请用户进行参与;最后将设计产生的变化加入下一个交付迭代,同时演进高保真原型,为下一轮用户测试做准备。

与交付同步的用户测试保证了设计在产品上线前就能进行对用户体验的验证,及时拥抱变化;在项目进行的后期,可直接采用测试环境进行测试,甚至可采用内部上线的方式,获取更多反馈。

数据演进(Analytics)

传统互联网中产品经理最多关注的是基于使用数据的产品演进,作为一个合格的体验设计师,也需要一定知识为有产品演进需要的客户提供服务。

a-product-evolve-practices-map
这里是基于数据的产品演进中将使用的实践

这里所提供服务主要指A/B Testing──在敏捷体验设计中,A/B Testing有如下几个步骤:

  • 充分了解产品当前在盈利模式、使用者、信息架构等方面的情境;
  • 在情境中按照商业价值梳理出一系列用户目标,分别代表一定用户价值;
  • 评估当前用户目标的完成情况(转化率),寻找到核心改进点;
  • 对改进点进行开放式设计,尽量保持设计方案的简单有效,并进行一定的用户测试;
  • 将新设计部署到生产环境,让消费者产生分流,通过数据统计决定最佳方案;
  • 迭代式地持续进行A/B Testing保证产品持续性演进和优化;

写在最后

这就是一个敏捷体验设计师应该具备和努力发展的12种技能,很多技能之间又存在或多或少的内在联系,每个项技能又有多种实践进行支持,如果大家某项技能中的细节感兴趣,可以微博私信我;如果你愿意寻找和我们一起成长的机会,或者厌倦每天重复的工作,也可以和我联系。

关于Agile/Lean UX更多参考

UX and Agile Development: 2012′s Challenges and Opportunities
Lean UX: Getting Out Of The Deliverables Business | Smashing UX Design
From User Stories to Storyboards to Tasks « Zen Agile
From Sketchboards to Blueprints – facilitating detailed conversations about the evolving design | the architecture of everything
Agile + UX: six strategies for more agile user experience
Twelve emerging best practices for adding UX work to Agile development

写给西安的小同志

by Zichuan Xiong on April 4, 2012

本篇写给西安的小同志。

体验设计而不是用户体验设计

体验设计没有假设消费者是用户,这就是Experience Design和User Experience Design的区别。在这里,我们把体验当成一种和商业模式交互的“触点”,某种意义上体验设计是在设计商业模式。

你要明白设计的价值体现在“可实现”

任何对交付不负责任的设计都是耍流氓。这个世界有两种思维模式,一种是基于直觉(Intuitive Thinking),一种是基于分析(Analytical Thinking),而每个XDer应该在这两种思维方式之间,我们把这个叫做Design Thinking。

Design Thinking设计思维

设计思维的核心概念是用优秀的客户体验和可承担的成本,实现客户价值最终创造商业价值。从这个角度出发,UX的概念并不简简单单停留在用户体验,而扩散到对成本的控制能力,和对商业价值的体现。因此除了用户交互设计领域的技能,你还需要理解成本的意义(收敛能力),和从商业的角度思考设计。

发现问题比解决问题往往更难

这是个解决方案的世界,一个对问题的清楚表述,比一个优雅的解决方案更加有价值。真实存在的问题代表着用户价值,这个价值是驱动产品常青的动力。你会学到各种分析方法和实践去定位问题。

你不得不成为全才

没有任何理由你不能够,你不可能是某个设计环节上熟练手,只有成为从策略到设计到交付再到演进的全才你才能真正理解Design Thinking。

你的压力来自于技能必须增值而不是避免贬值

我们的开放性决定了你的技能不可能一直成为“权威”,你现在所掌握的技能比在其他公司贬值得更快,而你要做的是“增值”而不是神秘化和权威化以避免贬值。这个“增值”首先意味着我们要在你每次重复的实践中看见变化,其次意味着你的实践也可以成为别人的实践。

你是你自己的创业者

这里不把你当成工具,而是创业者。你选择的是一份事业而远超越一份职业,你享有创业者的自由,却同时付出创业者的自律、投入、和寂寞。

这是一个专业服务公司

专业服务公司的特点:加入者必须热爱新挑战;不成长自然会被淘汰;“被替代”是你的责任;

自由的代价

在这里,组织尽量扁平,你几乎不需要考虑“政治”这件事情,这里是理想主义者的小窝,你会见到各种各样有创造力、聪明、单纯、同时勤奋的人,但是,自由不是白得的。你要付出比其他公司更多的学习时间(压力比你想象的大),你要花更多精力平衡家庭和事业,你要出差。希望你能理解这个世界上没有一份工作是:自由、高报酬、受到尊重、不用出差的。任何事情都有代价。

我的一点想法

我从来没想成为什么乔布斯,也不想挣大钱,我没有乔布斯的天赋,也没有真正创业者的商业头脑。我只想做一些不一样的事情,在我力所能及的范围里,影响力所能及的人,而不是拿着丰厚的薪水,演现实主义的哑剧。如果有一天你和其他的五个人,都觉得,你的生命就是不断给自己设计体验,而不是按照别的谁的功能列表活着,我觉得就足够了。