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

作者：AlibabaGroupUED

 

 

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

 

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

 

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

 

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

 

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

 

 

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

 

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

 

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

 

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

1. 红草莓  红草莓是闲鱼内部长期回复用户反馈的机制，所有项目组成员轮流每天回复用户的问题，搜集到的问题会流转到对应的解决者。

2. 微调研  微调研是每周会有跟用户面对面交流的机会，拿着设计方案或是问题与用户进行简短沟通，获得我们想要的讯息或是反馈。

3. 社交媒体 （App store/微博等）

4. 自我发现

 

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

 

 

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

 

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

 

 

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

 

 

 

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

 

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

 

1. 状态考虑不周全

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

 

 

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

 

 

2. 走查不到位

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

 

 

3. 功能不全

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

 

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

 

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

 

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

 

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

 

 

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

 

 

 

 

文章来源：AlibabaGroupUED

======================================================

不知不觉UXRen社区官网已经2岁了， 在这里小编要感谢那么一如既往支持本站的油茶人。

UXRen.cn欢迎油茶人投稿，提供有价值的资讯、线索、点子及建议。 

邮箱：contact@13tech.com.cn 
注明：本站内容及数据部分来自互联网及公开渠道，如有侵权请及时联系我们。
======================================================