勿忘初心

个人签名

530篇博客

用户体验与开发实现之间的博弈——半年交互工作心得体会

勿忘初心2018-09-18 15:02

本文来自网易云社区


作者:任琼瑶

入行互联网8年有余,但真正开始了解整个产品开发流程中的细节、困扰、各个角色之间的合作,还是在转岗交互之后的短短半年里。


之前8年一直做的是用户研究工作,接触最多的角色是产品经理和交互,但一直有这样一种困惑:我们发现了许多用户体验问题,在给出问题以及解决建议后,总是很难看到有效的产品改进。


那时候总是怀疑是自己推动不力,后续工作不到位,但真正处于产品流程之中,才发现,产品经理和交互也在竭尽所能地推动产品体验的升级,然而太多因素阻碍着这种推进,包括工作节奏、开发实现、产品整体规划等等,其中尤其以开发实现逻辑上的阻碍最为明显。


在听了众多开发大牛对代码逻辑和架构的初步说明后,深深体会到,原来用户体验和开发实现之间真的是相爱相杀,彼此互相依赖共生,同时又有着不一样的期许……


从用户体验层面来说,产品经理和设计师需要考虑多种不同的用户使用场景,以此给出适合每种场景的不同解决方案,同一个功能在不同场景下可能存在不一样的表现;而开发逻辑,则希望更多的是整合的、统一的解决方案,这样能减少代码量,也能让整体架构的拓展性更强,不至于在日渐增多的新功能新需求面前,代码越来越复杂,最后变成一团乱麻。


举个最简单的例子,在某一个按钮的点击反馈中,可能存在弹窗、toast等不同的反馈形式,在用户体验层面,我们会判断反馈内容对用户的重要性,如果是轻量级反馈,则用toast更为合适,而如果是必须要确保用户知道的反馈,则使用弹窗更为合适。但在开发实现层面,不同的反馈形式需要后端做不同的定义,势必增加工作量和代码的复杂度,能用同一行代码来跑不同场景自然是开发们所期望的,这就势必与用户体验的理念背道而驰。


但这种表象上的背道而驰只是短时性的,从长远来看,大家的目标都是一致的,都是为了让产品更加好用,更新迭代更快捷。不可否认的是,用户体验的好坏,除了人机交互层面的设计,还必须包含系统的稳定和快速,如果代码冗余复杂,显然对系统性能会有很大的影响,代码的架构可拓展性差,那么开发迭代的成本会越来越高,用户需求的落地性也就越来越差,这些都应该是用户体验的一环,也必须是产品经理和交互需要权衡利弊的一环。


期望上的不同导致了部分问题无法理想化地去解决,另一个方面的阻碍,则是功能实现的逻辑无法支持交互方案。


我们的设计工作,大部分还是在已有产品上进行修修补补,确保以最小的成本去实现新增的用户需求,极少设计师有机会实实在在地从零开始搭设产品框架。那么我们的设计就会套上产品已有实现逻辑的枷锁,尤其是新人设计师,对产品本身的实现逻辑不熟悉,在做出一些看似完美和用户体验很好的交互方案后,开发一评审,发现在现有框架下根本无法实现。


在前期交互评审时发现这些问题还为时不晚,但若到了开发进行中,甚至版本即将提测,才发现这些设计细节,在改动的过程中就有可能牵一发而动全身,看似只有交互稿上的一点小改动,也许对程序员们来说是几天的工作量。因此,什么是交互的工作经验,除了掌握和灵活应用各种需求的解决方案外,还有对产品的熟悉程度,包括对底层开发逻辑的熟悉度。


当然这不代表缺乏经验的设计师就一定会把项目搞砸,知道自己的不足,在设计过程中对不确定的问题,与前后端开发做实时的沟通,一定能事半功倍。


产品经理之所以被戏称为产品狗,也是因为时常需要为频繁变更需求而求爷爷告奶奶,变更需求之所以这么受抵触,但却时常发生,主要原因也是在于,变更需求本身,对于产品经理来说只是轻易的一句话,而对于交互设计师来说,需要重新修改交互稿,设想和穷尽需求变更之后可能出现的不同情况,再交由开发的话 ,又会变成更为庞大和繁杂的一通代码修改,会让下游的人产生前期做了很多无用功的沮丧感。


交互设计师,夹在产品经理和开发之间,比开发更为了解产品经理在满足用户需求层面的理念,同时也比产品经理更为了解开发们在细节实现上所做的大量工作,那么也就更为适合做用户体验和开发实现之间博弈的主导者。若产品经理发起需求变更,可与其明确需求的优先级,与开发一起,共同商量成本最低的实现方式。如果一味地从源头开始推进工作,先出需求,再做设计方案,最后交由开发实现,则一定会出乱子,也一定是在增加各个角色的工作量。


经验、流程、博弈,任重而道远。


网易云免费体验馆0成本体验20+款云产品!

更多网易研发、产品、运营经验分享请访问网易云社区