【阿里干货】动态的设计—过程驱动设计方案演化

几乎所有的设计师同学在做方案评审时都经历过撕逼大战,有时东风压倒西风,有时西风压倒东风,无论如何,都令人身心惧疲。为什么这样子?项目组成员对设计的讨论和挑战,通常都是「自我参考」式的。无论是要做简化去掉某功能还是要增加新功能,总会有人跳出来说这个功能对用户(我)很重要,或者我觉得这个功能用户根本不care,最后变成谁强势谁就赢。当我们需要对一件事情提出意见时,习惯性的总是从自我经验出发,主观的下结论,这是一种追求效率决策的本能。我们总是擅于把毫无关系的两件事情关联起来,然后认为互为因果。但是这样的联系可能是错的,或者说可能被错误的套用。同样的事情,在产出设计方案的时候也是时有发生,设计师从一个自我体验式的方式去分析问题,在自我的纠结中,提出一个主观的设计方案,俗称“憋大招”。

设计师应该在渐进的洞见过程中掌握事实依据,以过程驱动设计方案演化,而不仅关注设计方案本身;设计师亦当是创意环境的塑造者,以一定的设计流程执行与团队共建创新。设计需要以用户心理、用户行为相关的客观事实为依据去执行,而非以一种自我体验的方式进行论述。设计更多的是关于不断地展望与想象不存在的体验,设计师需要的是增强在现有配置下对未来多样性的洞察力。

设计师应该做些什么呢?在设计思维的流程定义上,都是大同小异,因为试图体现的都是人类思维过程最普遍的发散收敛过程。以Design Council归纳的4D设计流程为例:包括Discover(发现)、Define(定义)、Develop(发展)、Deliver(执行)四个阶 段。现存状况是我们做的很多”设计”工作都是后面两个D的执行,而在前两个D的定义阶段花了非常少的功夫。可以说这也是为了追求效率的一种下意识体现,把 功夫花在看似有确定性反馈的执行效果上。

q2

然而后续有效的执行,一定是围绕前期确定的一个明确的原则性的定义。这个定义需要不断的被拿出来,作为执行方案确定与否的原则,并且来来回回基于执行的验证反馈不断被打磨更新,这就是动态的设计过程。

q3

在设计过程中,有非常多的设计工作可以使用。比如说同理心地图,用户旅程图和服务蓝图等。工具本身也是一种协同工具,让项目组的成员可以基于共同的语言沟通-比如用户,可以视觉化思考的过程,时时回溯,保证大家在一个明确的原则性上工作。在此环境中发散创新,找到创新。

q4

设计过程中最忌讳的是拍脑袋,所有的设计应该都是基于事实依据来做出的判断。事实依据很大程度上来源于用户。很幸运的是闲鱼一直很重视与用户的互动,我们随时从用户反馈中知道产品的问题,并及时响应,进行修复,提升用户体验。

与用户的互动不是简单你问我答的过程,这样不能建立一个高效,敏捷的解决问题的体系。为了更好的利用这些有价值的事实依据,更好的解决推进沉淀,闲鱼找到了一套机制,帮助产品迅速迭代。

解决用户体验问题本质上是提升用户体验,除此之外,更高阶的运用是利用问题来验证设计,同时不断在在问题中抽离出需求,最终设计师可以在用户体验问题中为产品找准目标,为设计找到方向。所以闲鱼的这套机制专注于发现与解决问题,根治与利用问题。

闲鱼发现问题的渠道主要有以下四个途径:

  1. 红草莓  红草莓是闲鱼内部长期回复用户反馈的机制,所有项目组成员轮流每天回复用户的问题,搜集到的问题会流转到对应的解决者。
  2. 微调研  微调研是每周会有跟用户面对面交流的机会,拿着设计方案或是问题与用户进行简短沟通,获得我们想要的讯息或是反馈。
  3. 社交媒体 (APP STORE/微博等)
  4. 自我发现

搜集到问题后需要对问题进行分类,长期对问题的浏览发现,问题无外乎集中在以下几个方面:用户常用功能的反馈比如交易相关,不是必经的体验流程比如设置,还有一类是视觉问题比如间距,字号,图片变形等。因此我们把问题分为主体验节点、其它体验节点、设计规范三大类。为了更好地让大家理解主体验节点,我们又做了定义归纳。

q5

问题分好类之后就需要组织相关人员一起来看这些问题,商量如何去推进。为了让这个解决问题的过程变得高效以及常态化需要有“规矩”,可执行。因此我们确定了每周某个时间点开碰头会,所有利益相关人要参与,比如接口的PD、开发、测试,最重要的是每次喷头会下来需要对各个问题的解决时间有结论——能在哪个版本解决。

为了让以上过程可被关注,设定了问题从发现到解决的几个重要节点:

q6

在讨论过程中最容易引起分歧的是哪些问题该优先解决,不同角色对问题的认知是不同的,想要解决的迫切程度也不同,为了让大家可以达成统一,我们设定了问题的重要程度分级,每个级别对应有具体描述,让大家可以清晰定性问题。

q7

当有了这一套可被执行的机制后,用户体验问题便可以轻松地运转起来,每周或每个版本都会有一个完整的to do list告诉项目组成员有哪些体验问题要解决。

问题发现后如果只是针对单个问题逐一击破,我们会发现同类型的问题还是会接二连三出现,所以要想办法找到这些问题出现的根本原因是哪里,这样才会让问题越来越少,我们的解决问题的成本也会降低。通过问题不断的积累,发现闲鱼里用户反馈的大量问题都跟以下三点有关:

1. 状态考虑不周全

通常设计中我们会忽略掉极限状态的设计和异常状态的设计,所以带来用户的反馈。通过整理发现上述两种状态多对应以下情况:

q8

q9

为了避免以后再出现同类型问题,整理了一个check list

q10

2. 走查不到位

版本正式上线前,设计师都会对页面的视觉进行走查,由于走查的过程没有规范化的操作,很容易遗留一些盲区,导致版本带着问题上线。为了避免走查不到位引起的问题,我们整理了走查清单,在走查过程中来使用。

q11

3. 功能不全

由于闲鱼是创新业务,很多功能都是从零开始尝试,没有任何参照,难免会有没有思考到的场景,产品也是从雏形来时一步步迭代前进再完善。对于功能不全的问题,只能通过后续版本迭代的方式来完善功能,但不见得每个用户的诉求都能满足,我们可以把这些反馈进行分级处理,看哪些是急需解决,哪些是需要待验证的。

q12

当把体验问题解决后,还需要去关注问题解决的效果如何,对业务,对用户有没有带来实际价值。数据是验证成果的有力证据。有些问题的解决可以带来业务指标的提升,比如我们从用户的反馈中发现了某个需求,当这个需求上线后带来使用量的激增。有些问题的解决可以带来问题的反馈逐渐减少。

对于结果的关注也可以形成一套机制,我们把它称为用户体验量表。

体验量表里只记录主体验节点对应的页面,每个页面都会有对应的业务指标,这些是需要关注的常态信息,是一个参考值,当我们对页面做了新的功能或是问题的解决,会带来数据的变化,同样也会记录下我们需要验证的指标的变动,以验证解决的效果。

闲鱼使用这套机制已经有一年,整个过程中发现了145例问题,解决了106例。剩余未解决的都是需要验证或是不是闲鱼重要用户群体的诉求。

用户体验问题是设计师最常接触到的外界信息,以往他们都是碎片化的信息,利用起来并不是很能体现本身的价值,当闲鱼系统化运作这件事情后才发现背后的矿藏。不仅仅是提升了产品的用户体验,同时也提高了产品设计、开发的效率。大家不妨尝试用用。

2 4 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部