和大多数公司一样,我们的设计流程都是跟着产品周期一起,没有太过特殊之处。这边和大家分享三点是我们比较强调的。
同时,为了能够保障上述流程的落地,我们精选了一些设计方法,以及对应的产出物,大家可以在下面的图片里面看到详细内容,至于具体方法的细节,我就不展开了,网上有太多的方法学分享,请自行百度谷歌之。
我们还有一些方法学的标准文档、沟通文档,保障设计师能够快速上手一些常用的设计方法,保障合作沟通的效率。
为什么要做体验度量?我们是如何基于 Google 的 HEART 模型实践,最终根据企业级产品实际情况修正得到的 TECH 度量模型,我之前就已经写过一篇文章,详细讲了我们的过程,大家可以参考:《TECH 模型:企业级产品体验度量实践》
我们的体验度量模型如下:
目前我们的 TECH 度量模型已经深入到蚂蚁多个企业级产品实践中,这些产品的功能功能囊括了资金、运维、研发、安全、风控、效能管理等。
基于这么多的实践,我们发现,产品不同阶段,他们有着不同的体验需求,我们的度量也需要有不同的侧重点,并不是之前想象的一个模型打天下的节奏。
比如,对于稳定迭代的产品来说,H 是拿来监控的,通过满意度监控发现哪里有问题,就去细节挖掘。T 和 C 需要密切关注,通过迭代来优化这两个方面。对于成长期的产品,T 和 C 是重点。而对于未上线的产品,首要是 E,没有满足需求,产品上线了也白搭。
体验运营这一块,我们做了以下一些事情:
所有这些,我们都是在营造体验的气氛,能够让大家一起来重视体验,做好体验。多年经验下来,有一些肺腑之言和大家分享。这两天也陆陆续续收到同行们的消息,感慨说现场听到我的这两句话,几乎老泪盈眶。感谢这些同行的共鸣!
我们体验运营之后收到了大量的合作邀请和报名参加我们的体验一起造活动,这里边对于重点业务线的产品,我们打造了一个 ” 伞兵团 “ 的项目组,包含设计师、产品、开发等同学一起,在一个礼拜之内,快速拿到结果。
我们要的是过程可落地、快速落地。以前的各类用户研究,总是太多的停留在了研究报告阶段,导致很多事情无法推动下去。我之前也做过用户研究,这种传统模式的套路我深受有感触。现在好了,我们团队有用户研究的同学,也有设计师,我们要尝试的是,如何快速的把调研结果落地到设计、落地到产品。否则时间长了,黄花菜都凉了,这是我们做的改变。
这样的做法有时候看起来可能比较激进,但我要说的是,这样最大程度的将各个合作方融合起来,一起参与做一个产品的优化,远比我们做个体验度量、产出一个度量报告的效果要好。这就是我现场讲的:from enable to involve。
这一块,讲的是将体验度量的优化后的案例,沉淀为最佳实践,反哺给 Ant Design。因为我们最终要的是体验好的设计,我们希望有部分产品、或者说模块,可以先跑起来,做到我们提供的就已经是体验优化的。
我们目前通过体验度量发现一些高度可复用的模块,比如:标准化的帮助体系、权限管理、成员管理,等等这些都是可以优化后直接运用到其他产品或者系统的。
我们最终的目的是:
这一年多来,摸着石头过河,我们基于蚂蚁企业级产品的体验度量实践提出了自己的 TECH 度量模型,这中间曲曲折折,冷暖自知。很高兴,可以有一些我们觉得做得还不错的东西拿来分享。也算是对自己这一年付出的交代。
真心希望,这些内容能够帮助到面临类似问题的同学们。也希望大家多加实践、一起讨论,补充、丰富 TECH 度量模型。
再次附上 SEE Conf 演讲视频:优酷地址
原文:https://zhuanlan.zhihu.com/p/32807855
既然来了,说些什么?